Changes between Version 1 and Version 2 of ISO2ebRIMIssues


Ignore:
Timestamp:
Mar 7, 2009, 1:28:10 PM (15 years ago)
Author:
heikki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ISO2ebRIMIssues

    v1 v2  
    1010== Introduction ==
    1111
    12 The specification in OGC 07-038 section F about how to register ISO metadata in a ebRIM registry is rather obscure. This page lists uncertainties in how to interpret that document.
     12The specification in OGC 07-038 section F about how to register ISO metadata in a ebRIM registry is rather obscure. Apart from a very loose use of language relating to specific technical concepts like XML 'elements' and 'attributes' (usually anything is called an 'attribute' or a 'property' in that document, regardless), there are more things unclear. This page lists our uncertainties in how to interpret that document.
    1313----
    1414
    1515== the list ==
    1616
    17 Table F.2 describes the creation of a ResourceMetadata object.
     17Table F.2 describes the creation of a !ResourceMetadata object.
    1818
    19  - fileIdentifier : the table says it is not mapped, but "see Table F.1". Does this mean the information (already put in a MetadataInformation in table F.1) must be repeated in this ResourceMetadata ? In this case I opted for YES.
    20  - h
     19 - fileIdentifier : the table says it is not mapped, but "see Table F.1". Does this mean the information (already put in a !MetadataInformation in table F.1) must be repeated in this !ResourceMetadata ? In this case I opted for YES.
     20 - language : the table says it is not mapped, but "see Table F.1". Does this mean the information (already put in a !MetadataInformation in table F.1) must be repeated in this !ResourceMetadata ? In this case I opted for YES.
     21 - parentIdentifier : the table says it is not mapped, but "see Table F.1". Does this mean the information (already processed into an extra !MetadataInformation in table F.1) must be repeated ? In this case I opted for NO, as there already is a parent !MetadataInformation as per table F.1.
    2122
     23
     24Table F.15
     25
     26 - "The existence of an instance of MD_Metadata.referenceSystemInfo will possibly imply to create an instance of !CitedItem along with an instance of the association Auhority between !IdentifiedItem and !CitedItem."
     27
     28*possibly* ? what is that supposed to mean ? I'm assuming : if there is an authority element in referenceSystemInfo.
     29
     30 - alternateTitle : this has cardinality 0..n, but this spec doesn't mention it. I'm assuming they mean to say "for each".
     31 - date : must be mapped to <<slot>> created, <<slot>> modified or <<slot>> issued. The spec does not say *how* this must be mapped. I'm using 'creation', 'revision' and 'publication' from the codelists used in ISO.
     32 - date : this has cardinality 1..n, but this spec doesn't mention it. I'm assuming they mean to say "for each".
     33 - identifier.MD_Identifier.code : "Identifiers with no codespace do not carry sufficient information and are not mapped to externalIdentifier, for which the codespace is required." BUT MD_Identifier *never* has a codespace, per the XSD. Only its substitutiongroup RS_Identifier may have a codespace. I'm assuming they intended to say, RS_Identifier.
     34
     35Table F.16
     36
     37 - everytime, an Organization is created. So in this way these Organizations are never re-used / shared between data referring to them. Does not seem to make much sense, to me.
     38 - individualName : is ignored, but not "If needed". Well .. I'm ignoring it.
     39 - organizationName : this must be organisationName (with 's') in ISO.
     40 - organizationName : this is not a required element in ISO. What if it is absent ? The created Organization will be rather non-descript.
     41 - about the !CitedResponsibleParty Association : "The association Type has a set of subtypes operating to the same object types: PointOfCOntact, Author, Originator, Publisher." This is not true, no such subtypes are defined. From clues elsewhere in that document I take it this stuff is handled by classifying the association.
     42 - the codelist values for gmd:role can be many other things than just 'pointOfCOntact', 'author', 'originator', or 'publisher'. If it is not one of those 4, I ignore it so no classification will be created. Does it make sense to you?
     43
     44TO BE CONTINUED
     45 
    2246----