= ebXML : Transforming ISO19139 metadata to ebRIM : issues in the specification =

author: Heikki Doeleman

This page describes uncertainties arising from the obscurity of OGC 07-038, section F.
[[BR]]

----

== Introduction ==

The 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.
----

== the list ==

Table F.2 describes the creation of a !ResourceMetadata object. 

 - 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.
 - 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.
 - 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.


Table F.15

 - "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." 

*possibly* ? what is that supposed to mean ? I'm assuming : if there is an authority element in referenceSystemInfo.

 - alternateTitle : this has cardinality 0..n, but this spec doesn't mention it. I'm assuming they mean to say "for each".
 - 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.
 - date : this has cardinality 1..n, but this spec doesn't mention it. I'm assuming they mean to say "for each".
 - 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.

Table F.16

 - 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.
 - individualName : is ignored, but not "If needed". Well .. I'm ignoring it.
 - organizationName : this must be organisationName (with 's') in ISO.
 - organizationName : this is not a required element in ISO. What if it is absent ? The created Organization will be rather non-descript.
 - 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.
 - 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?

TO BE CONTINUED
 
----