Ticket #44 (assigned task)

Opened 11 years ago

Last modified 10 years ago

MOLES Observation class

Reported by: sventour Owned by: sventour
Priority: critical Milestone: V3.5 UML Final
Component: UML Information Model Version: V3.5
Keywords: Cc:


In ISO 19156 there are the following specialisations of OM_Observation class according to the observation result:

OM_DiscreteCoverageObservation - result CV_DiscreteCoverage
OM_PointCoverageObservation - result CV_DiscretePointCoverage
OM_TimeSeriesObservation - result CVT_DisccreteTimeInstantCoverage

Do we need to specialise futher the OM_Observation in MOLES 3.4
a) according to the result (coverage ) domain - this should be in line with CSML 3.0
and/or b)
to accomodate additional attributes (e.g external identifier )

Change History

comment:1 Changed 11 years ago by sventour

  • Priority changed from major to blocker

comment:2 Changed 11 years ago by sventour

  • Status changed from new to assigned
  • Owner changed from sventouras to sventour

comment:3 Changed 11 years ago by lawrence

We have a choice between specialising the observation and constraining it to produce a specific result.

  • Conclusion: we should not constrain the result of a MOLES observation (it might be an observation collection, it might be a coverage).

Do we need extra attributes?

  • Do we need an identifier? (Why, is an MD_Identifier needed when we have a GML feature type, which itself has identity). Better question: does a specific observation need a name?
  • Do we want to abstract the feature type of the result into the observation as metadata? What about the resolution of a grid for a coverage? (definitely important for modelling).
  • Can we exploit a constraint on the MD_Metadata record to capture most of this, rather than specialising Observation?

Need to stop and consider what part of the use of ISO19115 classes is associated with which parts of the instances of real world examples. When is hte process instance created? When is hte MD_Metadata record created (how?). Does it extract and compose information from the process records? Do we bind the observation to a pre-existing process record, with "event specific" parameters.

comment:4 Changed 11 years ago by lawrence

At this point we think it's dangerous to profile MD_Metadata, since there are already MD_Metadata profiles of interest. Better to compose some more MD_Metadata classes into the MOLES profile of O&M, so that the external MD_Metadata instances can extract the information from the O&M instance iff they want to!

So that says we need to specialise O&M observation. So now the questions is: what are the key attributes?

comment:5 Changed 10 years ago by lawrence

(From Meeting):

  • We need an identifier to support the use case of packaging an observaiton (with say, a subset of data) and giving it to a user. We can then store that observation description, with an identifier, and allow a query against (say) a checksum associated with that observation, so the user knows they got the right data.
  • Get me all the observatoins in an area? That returns a list of identifiers which point to observations with properties (result, process etc).
  • Do we need a specific one in the UML model? Not necessarily, we can use gml:identifier that we get from the canonical gml serialisation BUT that implies we know we're serialising to GML! So we need to make sure that all serialisations give identifiers to Feature Types - as happens with GML Feature types via GML objects. Also gml:identifier (as opposed to gml:id) is not mandatory.
  • gml:id's don't need to be persistent in any meaningful way (even though the filter spec default for WFS filters on these). If we put an explicit identifier, we are implying you'll get the same observation back via some sort of external query on that identifier via an interface. We can do this by making a mandatory identifier and serialising it using a gml:identifier.
  • Bottom line: introduce an identifier.

comment:6 Changed 10 years ago by lawrence

bounding box:

  • The temporal bounding box information appears in the observation explicitly via the phenomenonTime.
  • In CSML we constrain the feature of interest to be a sampling feature, and indeed that is the domain of the result.
  • We should put the envelope of the domain of the result as a specific attribute of the observation (slightly more general than CSML). (This then is the EXTENT of the coverage domain - or the envelope of the EXTENTS of multiple coverages.)

comment:7 Changed 10 years ago by lawrence

(nb: although the moles2 deployment has no attributes, it's relationships map best onto an observation concept)

comment:8 Changed 10 years ago by lawrence

Remember we can add arbitrary key value pairs via the parameter NamedValue? attribute, so we don't have to have it all in the basic MOLES model.

We could get description, abstract etc, via the FT GML serialisation. If we want them.
We might want to record the provenance of *this* observation record (stored, response to query etc), but again, we could do that via the NamedValue? attributes ....

So that's enough for MOLES 3.4

comment:9 Changed 10 years ago by lawrence

Oh no it's not, we need to put permissions on the observation. since the result is a ci_onlineresource, we want folks to kwow what the permsisons are without navigating hte link and finding out the hardway. It can also be used locally for management?

So new attribute: permissions:MD_Constraints (maybe specialise in a future versoin)

So that's enough for MOLES 3.4

comment:10 Changed 10 years ago by lawrence

Oh not it's not, we need resolution in there too. Spatial and Temporal resolution (to support querying).

We also need a feature type keyword ...

(This makes observation itself result metadata and that's exactly what's intended!)

So that's enough for MOLES 3.4

comment:11 Changed 10 years ago by lawrence

  • Make all MO_Observation attributes optional (not voidable, means 0..) ... that way a moles processor can parse a vanilla observation without breaking.
    • What about the constraint on MD_Metadata, if we leave that, a vanilla ob could break ... so remove constraint , but put a guidance note that MOLES systems would not normally include such a relationship (which could be generated by querying by the project if an export is required).
    • Similarly, allow the constraint ongoing to support no attribute present ...
  • Make resolution of type characterstring (the state of the art is not clear)

comment:12 Changed 10 years ago by domlowe

Discussed metadata links and how the model allows for multiple profiles of 19115.
To do: For clarity change name of role 'metadata' in ObservationCollection? to 'isometadata' so an ObseverationCollection? can have 'isometadata' and/or 'additionalMetadata'.

comment:13 Changed 10 years ago by lawrence

  • Priority changed from blocker to critical
  • Version changed from V3.4 to V3.5
  • Milestone changed from V3.4 UML Final to V3.X Next Release

Still some questions as to the linkage with MD_Metadata.

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