wiki:Taskforces/CMDI/Meeting20160303

CMDI Taskforce virtual meeting 2016-03-03

  • What?
    • CMDI 1.2 specification meeting
  • Who?
    • Members of the CMDI taskforce and other people involved/interested in specification process
  • When?
    • 3 March 2016, 14.00 - 16.00 CET (on basis of doodle)
  • Where?
    • Skype (Please send your skype handle to twan.goosen or Twan Goosen)

Documents

Agenda

(Tentative)

  • Discuss comments in review version of the spec
  • Update on the work on the toolkit
  • Planning
  • ...

Notes

Meeting notes

  • Thorsten will proof read the current version of document in the week after the meeting and submit his findings the week thereafter
  • Menzo will move all references in glossary to normative references or bibliography (in the wiki)
  • CMD instance diagram by Oddrun
    • cmd:Components should be green (part of envelope)
    • expression of potential number of different components/elements will aligned with table (* notation)
  • Document structure tables:
    • The proposed notations @{attr}i and <{prefix:element}>i well be replaced with @{attr}* and <{prefix:element}>*. These will be covered by the typographical conventions section.
    • We haven't found a suitable standard for representing default values (for an evaluation, see below), so for now we will stick with the current approach
  • Empty components: we can be CMDI compliant, but also have to deal with legacy. Components with attributes are allowed, but discouraged. New, entirely empty components will not be possible (also see findings below)
  • We will have at least one more 'internal' edit and review round, then review by one or more externals

Planning:

  • The specification will remain open for commenting and suggesting on Google Docs until 11 March
    • The suggested changes in Google Docs will then be transferred to the wiki page until 18 March. Please avoid performing major edits to the document (basically anything that is not an in-line change suggestion) until after this transfer!
    • A new review version will be made available via Google Docs after this and will be open for suggesting and commenting until the next CMDI 1.2 specification meeting
    • A follow-up meeting on the specification will be planned in the week after Easter (week 13)
  • Work on the infrastructure happens in parallel over the course of the next couple of months (scheduled release in May)
    • A meeting to discuss the further infrastructure implementations will be planned in the week before Easter (week 12)

Notation of value ranges and defaults

  • ORM (Object Role Modelling) http://www.orm.net/pdf/orm-jcm9.pdf Currently, ORM does not provide explicit support for initial/default, values. However UML initial values and relational default values could be supported by allowing default values to be specified for ORM roles. At the meta-level, we add the fact type: Role has default- Value. At the external level, instances of this could be specified on a predicate properties sheet, or even entered on the schema diagram (e.g. by attaching an annotation such as d: value to the role, and preferably allowing this display to be toggled on/off).

Empty Components

Found 97 component specs with an empty component. If we remove the ones that do have an attribute 57 are left. Not all of these are actually in use.

If we look at the profiles used by a last harvest we are left with 17 empty components (these might have attributes):

"clarin.eu:cr1:c_1320657629631""Service"
"clarin.eu:cr1:c_1360230992140""Reliability"
"clarin.eu:cr1:c_1379939315560""subject"
"clarin.eu:cr1:c_1379939315568""recordContentSource"
"clarin.eu:cr1:c_1375880373019""accessCondition"
"clarin.eu:cr1:c_1379939315574""recordIdentifier"
"clarin.eu:cr1:c_1375880373020""extension"
"clarin.eu:cr1:c_1379939315567""part"
"clarin.eu:cr1:c_1379939315564""location"
"clarin.eu:cr1:c_1379939315569""recordChangeDate"
"clarin.eu:cr1:c_1379939315570""recordCreationDate"
"clarin.eu:cr1:c_1379939315572""recordOrigin"
"clarin.eu:cr1:c_1375880372994""name"
"clarin.eu:cr1:c_1379939315571""descriptionStandard"
"clarin.eu:cr1:c_1381926654589""editorialDecl"
"clarin.eu:cr1:c_1423750293167""Service"
"clarin.eu:cr1:c_1320657629647""Service"

If we remove the ones that do have an attribute we are left with 4:

"clarin.eu:cr1:c_1320657629631""Service"
"clarin.eu:cr1:c_1379939315564""location"
"clarin.eu:cr1:c_1423750293167""Service"
"clarin.eu:cr1:c_1320657629647""Service"

3 are based on the core Web Service profile, which uses this hack (note 2). Location is part of the MODS components of the UB Utrecht.

If we filter on public availability instead of usage we are left with:

"clarin.eu:cr1:p_1282306194485""TITUS_metadata"
"clarin.eu:cr1:p_1271859438175""Virtual Collection"
"clarin.eu:cr1:c_1311927752331""Service"
"clarin.eu:cr1:c_1320657629631""Service"
"clarin.eu:cr1:c_1299509410081""Service"
"clarin.eu:cr1:c_1328259700933""Service"
"clarin.eu:cr1:c_1379939315564""location"
"clarin.eu:cr1:c_1381926654591""Service"
"clarin.eu:cr1:c_1423750293167""Service"
"clarin.eu:cr1:c_1418833904841""FieldtripDomain?"
"clarin.eu:cr1:c_1418833904840""FieldtripLanguage?"
"clarin.eu:cr1:c_1320657629647""Service"

Here we have again Service and Location. Virtual Collection is controlled by CLARIN ERIC. FieldtripDomain? and FieldtripLanguage? are recent and might be adapted still. If you look at the empty components in TITUS metadata it looks like they are actually meant as elements.

Looks like we could adapt the ISO 24622-1 constraint in the spec., and see the current empty components as legacy. The CR editor could disallow creating new empty components. And the validator could issue an error when a component is really empty, and a warning if it has an attribute but no element or component ... in a gradual move to get rid of the legacy.

Last modified 8 years ago Last modified on 03/04/16 14:19:48