Consistent encoding of Sensor/Instrument details

kateroberts commented 8 years ago

The model currently has generic placeholders "otherPropertyRecord: Record" and "otherPropertyRecordType: RecordType", under MI_Instrument {and Platform} and MI_Sensor.

Its been suggested that, where a user decides to capture details of a sensor/instrument, within the 19115-2 record (rather than linking out to that detail), the instrument/sensor details could be captured using those placeholders.

I think that the problem with this approach is that each person will do so differently - which defeats the purpose of interoperability.
eg even if 3 different people decided that they want to capture the instrument type, instrument's model code, and manufacturer [say]:

one might label these: 'instType', 'mcode', and 'manuf',
one might label these: 'tclass', 'number', and 'manuf'
one might label these: 'sensorGroup','brandno', and 'producer'.
To avoid this, I suggest that we identify those common concepts that we can, and either: i) provide explicit fields for "known" common concepts; or ii) provide an extensible codelist, which can be applied as a label within those placeholder records.

The concepts that I would provide explicit fields, or a codelist term for, include: (for Instrument/Platform/sensor):

Manufacturer: CI_ResponsibleParty, with role of : manufacturer and distributor (OrgName: Davis Instruments) Model name –long
Model name –short
Model code/number
Model description
Model version
Model documentation : CI_OnlineResource
Object type (with codespace)

Object's Serial number
Object's Local ID
Object's localName

(the naming could be improved, but hopefully the concepts are clear-ish?)

Kate

tedhabermann commented 8 years ago

Kate,

Thanks for your thoughts on this...

The question is really about the degree of standardization - more (a list of standard things with standard names) or less (Record/RecordType). If we standardize more - then current communities that are using different things or names would be less likely to adopt the standard. If we standardize less - there may be problems with interoperability between communities...

I would suggest that the Record/RecordType approach - allowing communities to describe their structures and use them in this (small) section of metadata, supports interoperability within communities and also allows users to increase interoperability by using the other parts of the standard. This is the approach we are using in NASA - we have a existing standard structure for additionalAttributes in the NASA community and we will use it in all of these locations. In fact, we are already doing that as an extension. Of course, we will describe this approach (I think you can see https://wiki.earthdata.nasa.gov/display/NASAISO/Additional+Attributes) and share it with other communities that are looking for a standard approach. I suspect that that sharing process will encourage interoperability more quickly than we can agree on a single set of things and a standard set of names for those things...

Ted

==== Ted Habermann ======================== Director of Earth Science, The HDF Group Voice: (217) 531-4202 Email: thabermann@hdfgroup.org ==== HDF: Software That Powers Science ====

From: kateroberts notifications@github.com<mailto:notifications@github.com> Reply-To: ISO-TC211/19115-2Revision reply@reply.github.com<mailto:reply@reply.github.com> Date: Wednesday, March 9, 2016 at 1:50 AM To: ISO-TC211/19115-2Revision 19115-2Revision@noreply.github.com<mailto:19115-2Revision@noreply.github.com> Subject: [19115-2Revision] Consistent encoding of Sensor/Instrument details (#30)

The model currently has generic placeholders "otherPropertyRecord: Record" and "otherPropertyRecordType: RecordType", under MI_Instrument {and Platform} and MI_Sensor.

Its been suggested that, where a user decides to capture details of a sensor/instrument, within the 19115-2 record (rather than linking out to that detail), the instrument/sensor details could be captured using those placeholders.

I think that the problem with this approach is that each person will do so differently - which defeats the purpose of interoperability.

eg even if 3 different people decided that they want to capture the instrument type, instrument's model code, and manufacturer [say]:

one might label these: 'instType', 'mcode', and 'manuf',
one might label these: 'tclass', 'number', and 'manuf'
one might label these: 'sensorGroup','brandno', and 'producer'. To avoid this, I suggest that we identify those common concepts that we can, and either: i) provide explicit fields for "known" common concepts; or ii) provide an extensible codelist, which can be applied as a label within those placeholder records.

The concepts that I would provide explicit fields, or a codelist term for, include: (for Instrument/Platform/sensor):

Manufacturer: CI_ResponsibleParty, with role of : manufacturer and distributor (OrgName: Davis Instruments) Model name -long

Model name -short

Model code/number

Model description

Model version

Model documentation : CI_OnlineResource

Object type (with codespace)

Object's Serial number

Object's Local ID

Object's localName

(the naming could be improved, but hopefully the concepts are clear-ish?)

Kate

Reply to this email directly or view it on GitHubhttps://github.com/ISO-TC211/19115-2Revision/issues/30.

dr-shorthair commented 8 years ago

The issue is how to support extensibility. The options presented are: (1) through specifying all the requirements we currently know from every application we know about; (2) through a general extension point.

The obvious problems with (1) are a bloated standard, yet still inevitably incomplete. The risk with (2) is non-standardization.

The art of information modelling is in picking the sweet spot - too much detail, too early, makes evolution difficult, while not enough allows too much diversity and therefore non-interoperability.

The answer is generally a mechanism for well-governed extensions, with governance of the extensions delegated to recognized authorities. For example, soft-typing combined with externally managed vocabularies for the terminology, where there is a mechanism for recognition or endorsement of the external vocabularies.

smrgeoinfo commented 8 years ago

I think the idea in this case is related to the data type registry thinking—a ‘recordType’ is essentially a data type. So if there’s a way to describe and share record (data) types, then people implementing the edge cases (instrument descriptions) at least have the potential to describe what they’re doing so that others might reuse…. I agree that having some concept like ‘instrument type’ with a high-level vocabulary would be good for interoperability. The trick is how to get some kind of buy in on a shared instrument type vocabulary steve

From: Simon Cox [mailto:notifications@github.com] Sent: Thursday, March 10, 2016 5:56 PM To: ISO-TC211/19115-2Revision 19115-2Revision@noreply.github.com Subject: Re: [19115-2Revision] Consistent encoding of Sensor/Instrument details (#30)

The issue is how to support extensibility. The options presented are: (1) through specifying all the requirements we currently know from every application we know about; (2) through a general extension point.

The obvious problems with (1) are a bloated standard, yet still inevitably incomplete. The risk with (2) is non-standardization.

The art of information modelling is in picking the sweet spot - too much detail, too early, makes evolution difficult, while not enough allows too much diversity and therefore non-interoperability.

The answer is generally a mechanism for well-governed extensions, with governance of the extensions delegated to recognized authorities. For example, soft-typing combined with externally managed vocabularies for the terminology, where there is a mechanism for recognition or endorsement of the external vocabularies.

— Reply to this email directly or view it on GitHubhttps://github.com/ISO-TC211/19115-2Revision/issues/30#issuecomment-195122159.

ISO-TC211 / 19115-2Revision

Consistent encoding of Sensor/Instrument details #30