search

ISO-TC211 / XML

XML schema, transforms, schematron rules, and examples for ISO TC211 Metadata Standards
45 stars 26 forks source link

MI_Band Changes #168

Open tedhabermann opened 7 years ago

tedhabermann commented 7 years ago

Add MI_Sensor, nominalSpatialResolution -> Real (used to be distance which makes more sense)

smrgeoinfo commented 7 years ago

mac:MI_Sensor is a property of mrc:MI_Band, and mac:MI_Sensor is a subtype of mac:MI_Instrument. mac:MI_Instrument has a content property of type mrc:MD_ContentInformation. This creates a circular dependency between mrc and mac in 2017 ISO19115-2 revision.

Use cases--

  1. assert that a particular 'band' in a coverage was measured by a sensor described using acquisition details.
  2. assert the structure of information produced by an instrument (or sensor).

ContentInformation already has an abstract parent class in mcc;, so mac: can be decoupled from mrc with no problem.
It seems like an edge case that someone would want to bring all the MI_Instrument baggage into a MI_Band content information description. MI_Band already inherits a otherProperty.Record that could be used to detail this information. I'd suggest that the sensor property on MI_Band should be a CI_Citation that provides a pointer to a complete definition of the sensor in a separate mac: document (or perhaps using ISO19130...). This would eliminate the circular dependency.

tedhabermann commented 7 years ago

Another addition to MI_AcquisitionInformation is the MI_AcquisitionInformation/scope/MD_Scope that can be used to identify the attribute(s) derived from a particular instrument/sensor without creating a dependence between mac and mrc. I think we discussed this topic, but I am nor remembering the content of the discussion.

tedhabermann commented 7 years ago

On MI_Band/sensor being a citation. The MI_Sensor object includes a citation that, I think, accomplishes the goal you describe.

smrgeoinfo commented 7 years ago

That doesn't solve the problem, there's still a dependency from mac to mrc (for MD_ContentInformation) and from mrc to mac (for MI_Sensor on MI_Band), so one could never use anything from one package without importing both.
In MI_Instrument, if the data type for the content property is mcc:Abstract_ContentInformation then mac would have dependency on mcc (which is already there). mrc would still have a dependency on mac since there's not abstract class for MI_Sensor. I still think that making that a link (by reference only) so that mrc doesn't have to import mac would be a good thing,

tedhabermann commented 7 years ago

Steve - am I wrong that the MD_Scope in MI_AcquisitionInformation solves the problem of linking acquisition information to an attribute(s), see earlier comment. I think we can drop MI_Sensor from mac and contentInformation from MI_Sensor. Then the connection from acquisition information / content is made as a link from mac to mrc.