Skip to content

Schema Updates

Jump to bottom
Ted Habermann edited this page Feb 27, 2018 · 12 revisions

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

  1. Add otherProperty, otherPropertyType
  2. Add content
  3. Add history
  4. Add sensor

LE_Processing

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

Questions

  1. 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.
  2. LE_ProcessStep/LE_Processing/softwareReference went from [0..*] to [0..1]. Seems like a typo.
  3. Figure 2 - MI_Instrument needs sensor? MI_Sensor is not in the diagram.
  4. 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.
  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 restriction that makes the model difficult to implement. it would be more effective to allow connections of MI_RangeElementDescriptions to MD_SampleDimensions as well.
  6. MI_Band/sensor - We added a sensor role to MI_Band as MI_Sensor which is now an extension of MI_Instrument. If we made this instrument/MI_Instrument, then it could be an Instrument or a sensor.

ISO 19115-1 Amendment

CI_Party

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

MD_SpatialRepresentation

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

MD_ContentInfo

  1. Add a rangeElementDescription to the MD_SampleDimension
Clone this wiki locally