Ticket #12 (assigned task)

Opened 10 years ago

Last modified 9 years ago

SensorML and ISO19115 part 2 - implications

Reported by: lawrence Owned by: lawrence
Priority: major Milestone: V3.5 UML Final
Component: UML Information Model Version: V3.5
Keywords: simonc Cc:

Description (last modified by lawrence) (diff)

We also need to document our thoughts on potentially incompatible mappings between ISO19115 part 2 and SensorML which has not been resolved.

The implications might appear in ticket:29, and to a lesser extent ticket:14, since we need to clearly allow post-hoc processing of data from sensors -- by which we mean much later post-hoc, so late that it doesn't sensibly sit within an "original" sensorML process, and I don't think anyone is claiming that SensorML covers all possible numerical analyses of observational data.

See also ticket:29 and to a lesser extent ticket:14.

The Issue

ISO 19115-2 separates

  1. instruments (which do data acquisition) - MI_Instrument from
  2. processing (the means by which a data product has been transformed from the raw state to its current state) - LE_Algorithm

ISO 19115-2 also separates

  1. elements used in acquisition and processing - MI_Instrument & LE_Algorithm from
  2. instances of their use - (LI_Lineage containing LE_ProcessSteps using LE_Algorithm) & (MI_Operation containing MI_Events using MI_Instrument)

It appears that SensorML bundles all these into sml:Process, and the justification for that is as follows (slightly reformatted):

It has been argued that the traditional separation between the measurement and the processing of observation is getting rather blurred and getting more and more so, due to more processing going on within sensors (think of a digital camera) as well as more on-board processing before the data hits the ground. In that context attempts to distinguish between sensing and processing are more troublesome than helpful.

Hence, SensorML derived it all from a base Process model with inputs, outputs, and perhaps parameters ... if it's determined to be helpful and practical to better make the distinction between Instrument and Algorithm, SensorML can develop profiles to do so; or have both instruments and algorithm properties point to SensorML System and Process, respectively.

If we bring O&M into it we get, in ISO 19115-2 terms,

  1. om:Observation could be mapped more or less to just MI_Event, while
  2. sml:Process maps to MI_Operation + MI_Event + MI_Instrument + LI_Lineage + LE_ProcessStep + LE_Algorithm.

which implies that SensorML is an _implementation_ of multiple classes from the conceptual model, so its UML should not be interpreted at the same level as ISO 19115-2 or O&M.

However, it should be noted that SensorML can specify if the input is a real physical stimulus (using the Observable element) or a digital number (by using any of the SWE common data types). What this means is that there is a contrast between the way ISO 19115-2 model and SensorML do things:

  1. SensorML has a small number of classes, with lots of optional content elements. The content elements that appear tell you what kind of 'sensor' or 'process' it is. i.e. you have to look inside before finding out if you are interested and what you can do with it.
  2. SO 19115-2 spreads similar functionality over a larger number of classes. The name of the class tells you what kind of 'process' it is. You don't have to look inside.

Which brings us to a philosophical point: should SensorML extend from existing ISO classes, or not? If so which? There is an argument SensorML should be an implementation spec with ISO 19130 serving as the abstract spec.  ISO19130 reuses and extends ISO19115-part 2 classes. Note that ISO19115-part 2 is primarily about discovery, and could not be used, to say, rerun processes, which is one of the design goals of SensorML. But the bottom line here is that the SensorML classes sit somewhat on their own, and will be difficult to map sensibly into what we've done.

Hopefully there will be an Annex to SensorML 2.0 explaining how to map from ISO 19115-2 [and 19130] to SensorML, maybe vice versa.


sensorML1.jpg Download (84.4 KB) - added by lawrence 10 years ago.
UML of SensorML 1.0 courtesy of Johannes Echterhoff

Change History

comment:1 Changed 10 years ago by lawrence

  • Milestone set to V3 UML Final

comment:2 Changed 10 years ago by lawrence

  • Status changed from new to assigned
  • Owner changed from Bryan Lawrence to lawrence

SWE lost the concept of a sensor that produces numbers, instruments do physical sampling, followed by algorithms. Algorithms do computation.

ISO Part II has the acquisition separated from lineage ...

comment:3 Changed 10 years ago by lawrence

  • Description modified (diff)
  • Summary changed from Collision issues between SensorML and ISO19115 part 2 to SensorML and ISO19115 part 2 - implications

comment:4 Changed 10 years ago by lawrence

I'm struck by the issue of class comnlexity. The SensorML approach of requiring one to look inside classes makes real implementation difficulties which we should avoid in MOLES.

  • If we stick to only knowing about classes types, it's possible to consider manipulating classes via the name alone. I can build software that knows which objects it can manipulate. However, there is much more complexity in handling all possible complex characteristics which an object might have.

Changed 10 years ago by lawrence

UML of SensorML 1.0 courtesy of Johannes Echterhoff

comment:5 Changed 10 years ago by lawrence

  • Milestone changed from V3.2 UML Final to V3.4 UML

comment:6 follow-up: ↓ 9 Changed 10 years ago by lawrence

See also Ted Habermans's  page

comment:7 Changed 10 years ago by lawrence

  • Milestone changed from V3.4 EOF Support to FebMtg

comment:8 Changed 9 years ago by lawrence

  • Version changed from V3.2 to V3.5
  • Component changed from Documentation to UML Information Model
  • Milestone changed from FebMtg to V3.X Next Release

comment:9 in reply to: ↑ 6 Changed 9 years ago by domlowe

Replying to lawrence:

See also Ted Habermans's  page

Ted's page has been moved to  here

Note: See TracTickets for help on using tickets.
 Trac Powered
Site hosted at the
British Atmospheric Data Centre
for the