-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MI_Band Changes #168
Comments
mac:MI_Sensor is a property of mrc:MI_Band, and mac:MI_Sensor is a subtype of mac:MI_Instrument. Use cases--
ContentInformation already has an abstract parent class in mcc;, so mac: can be decoupled from mrc with no problem. |
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. |
On MI_Band/sensor being a citation. The MI_Sensor object includes a citation that, I think, accomplishes the goal you describe. |
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. |
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. |
Add MI_Sensor,
nominalSpatialResolution -> Real (used to be distance which makes more sense)
The text was updated successfully, but these errors were encountered: