Schema Updates

There are a number of (mostly small) changes being proposed for ISO 19115-2, 19115-1, and 19157 conceptual models. These changes are listed as issues in the 19115-2 Milestone (https://github.com/ISO-TC211/XML/issues?utf8=%E2%9C%93&q=is%3Aissue%20milestone%3A%2219115-2%20Revision%22%20). These changes have been working their way into the schemas in a branch called 19115-2-Revisions. The URL for this branch is https://github.com/ISO-TC211/XML/tree/19115-2-Revisions. Please contact [email protected] if you have questions, problems, or contributions.

##New Namespace Versions We have taken a new approach to namespace changes in this schema update. In the past, when conceptual models were updated, existing UML classes were extended with new classes and new namespaces were created. For example, when ISO 19115-2 was created, MD_Metadata was extended with MI_Metadata and the gmd namespace was extended with the gmi namespace. This cause alot of confusion and difficulties for tools.

As we developed ISO 19115-3, we changed the relationship between UML packages and namespaces, creating new namespaces as we tried to achieve the one UML package = one XML namespace goal. Now, as we update exiting classes, we are creating new versions of the appropriate namespace.

Namespaces that were revised in this update and the new URIs that will go into effect when these updates are accepted:

1. Citation and Responsible Party (cit): http://standards.iso.org/iso/19115/-3/cit/2.0
2. Metadata for Acquisition (mac): http://standards.iso.org/iso/19115/-3/mac/2.0
3. Metadata for Resource Content (mrc): http://standards.iso.org/iso/19115/-3/mrc/2.0
4. Metadata for Resource Lineage (mrl): http://standards.iso.org/iso/19115/-3/mrl/2.0
5. Metadata for Spatial Representation (msr): http://standards.iso.org/iso/19115/-3/msr/2.0

ISO 19115-2 Revision

###XML Namespaces During the development of ISO 19115-3, we created a new namespace titled Metadata for Acquisition and abbreviated mac. This namespace includes the XML implementation of the classes that were included in the MI_AcquisitionInformation package. This allows the namespace of the root metadata element to remain the same (mdb:MD_Metadata) whether or not a particular metadata record includes mac:MI_AcquisitionInformation.

###MI_AcquisitionInformation

1. Add MD_Scope

###MI_Platform

1. Change sponsor to CI_Responsibility
2. Add otherProperty, otherPropertyType
3. Change citation to [0..1] - See question below.

###MI_Instrument 2. Add otherProperty, otherPropertyType

1. Add content
2. Add history
3. Add sensor

###LE_Processing

1. add otherProperty, otherPropertyType
2. add LE_ProcessParameter - See question below.

Questions

2. Change MI_Platform/citation to [0..1]??? The citation role was originally 0..*. The new document shows it as 0..1. I am not sure there is a good reason to limit the number of citations to 1. This seems like a typo.
3. LE_ProcessParameter - The initial approach implemented this as an extension of SV_Parameter. Steve Richard had the following comment: Currently LE_ProcessParameter is a subtype of SV_Parameter, which introduces a dependency between Extended Lineage Information and ServiceInformation. If you look for 'parameter' in the full TC211 UML model, there are at least 15 'parameter' classes defined in 10 standards, so people have felt free to create local parameter classes specific to particular models. I'd suggest rather than extending SV_Parameter (admittedly a nice generic parameter type definition) and having to deal with the dependency, define the LE_ProcessParameter class in the Extended Lineage Information package (would have to define a local 'parameter direction' enumeration as well). I don't see any particular benefit in reusing the definition in ServiceInformation.
4. Figure 2 - MI_Instrument needs sensor? MI_Sensor is not in the diagram.
5. MI_RangeElementDescription - This class is used to define missing values associated with datasets. The way MI_ContentInformation is defined, this information is attached at a very high level in the model - to MD\CoverageDescription. This means that all attributeGroups and attributes included in a MD\CoverageDescription must have the same fill values. This is an unfortunate restrictuion that makes the model difficult to implement. it would be more effective to allow connections of MI_RangeElementDescriptions to MD_SampleDimensions as well.

##ISO 19115-1 Ammendment ###CI_Party

1. Add partyIdentifier: MD_Identifier [0..*]

###MD_SpatialRepresentation

1. Add scope: MD_Scope [0..1]