"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Profile patterns in implementation of Observation Feature Types


Related pages


This discussion relates to the practicalities of deploying solutions based on the ObservationsAndMeasurements specifications.


An Observation is a concrete class. It can be "soft-typed" to contain any specific observation metadata and results.

It may also be specialised to document the constraints and, in theory,

Modelling a specialisation

To specialise an Observation, it is necessary to constrain the Observation model to use specific types, in particular for the result element.

In UML this is modelled by overwriting the property name in the specialised class.

This is harder to realise within an XML schema however. It is necessary to have the element defined as a global element so that a substitutionGroup reference can be included.

The 1.0.30 version of Observations and Measurements schema has the following definition
   <complexType name="ObservationType">
         <documentation>Observation event.   
         carries a generic  "result" properties of type "anyType".</documentation>
         <extension base="om:AbstractObservationType">
               <element name="resultDefinition" type="swe:SWE_RecordSchemaPropertyType" minOccurs="0">
                     <documentation>Allows additional soft-typing information concerning the result structure to be recorded locally. 
Typically this will be a "schema" for the result-tuple, needed to complete the description of the result structure where its type is Record or NumericRecord.</documentation>
               <element name="result" type="anyType" nillable="true">
                     <documentation>an xsi:type attribute may appear in the instance to indicate the type of the result</documentation>

Whereas the latest version removes the result element, and expects specialisations that define result. (This implies however that Observations is no longer a concrete class)

Not quite true. As noted in the spec, om:Observation remains concrete, with result being anyType. But, in a conscious deviation from the UML model implemented precisely to avoid derivation by resriction, an additional class om:AbstractObservation was introduced as the parent to all concrete classes. The om:Observation class is a sibling to the other concrete observations, instead of being a parent.

I decided that this "implementation pattern" (which does deviate from the standard UML-GML encoding rules) was useful, and I did come clean about it in the spec. It is a pattern that applies potentially any place you have an abstract base class in the UML in which you know that you will almost always be overriding the type of one or more properties in the derived concrete classes. i.e.
  • create a convenience class to act as the root, which omits the properties that you know will be overriden,
  • derived classes are all by-extension, adding the required properties back in
  • if a concrete general class is needed, then define it as a sibling to the other concrete classes
  • if the whole hierarchy is needed in a content model, use ns:AbstractClassPropertyType in the content model definition

-- SimonCox -- 30 Oct 2006

An alternative might be to define an ObservationResult method and then let profiles define valid substitution groups.

Using a constraint language

In the last few weeks we've been looking at Schematron some more. It provides a way to implement "restrictions" or "profiles" - like the case we have big-time here where the basic type has a lot of flexibility, too much for a plausible client implementation. It is really hard to "restrict" this using an XML Schema mechanism, and impossible in another namespace.

But you can express the condition in a few lines of Schematron as follows:

<sch:pattern name="Check Observation result types">
   <sch:ns prefix="foo" uri="http://my.friendly.serviceProvider.org/">
            <!-- Schematron has its own namespace prefix binding syntax -->
   <sch:rule context="//om:Observation/om:result">
            <!-- the om:Observation can occur anywhere in the document -->
      <sch:report test = "@xsi:type and @xsi:type != 'foo:bar'">If there is an xsi:type it must be foo:bar</sch:report>
            <!-- note: XSLT/XPath/Schematron are not XML Schema aware, so they don't know about "QName" as a datatype for literals; hence this is a string comparison, so relies on a standard namespace prefix -->
      <sch:report test="not(@xsi:type) and not(./foo:Baz)">If there is no xsi:type then the element must contain a &lt;foo:Baz&gt; element</sch:report>
            <!-- however, namespace prefixes are interpreed correctly within XPaths -->

This is a formal statement of the constraint, which can be inserted in the data processing pipeline to check incoming documents, and/or published as part of a service profile that describes the "contract" between the server and client. However, for the people using a data-binding framework that is configured by simply reading the XML Schema - they will have to figure out how to add the rules in separately, and not sure if the Schematron helps them much.

-- SimonCox - 21 Nov 2006

WFS Implementation Issues

A WFS service can only advertise one instance of a featureType, so if multiple configurations are used to deliver specialised observations, a query cannot be directed at a particular configured backing store, except by introspection of the query contents to match some pattern.

<wfs:Query typeName="wqdp:wq_timeseries">
must explicitly reference a specialised type.

No known WFS implementations have a dispatching mechanism capable of this content-sensitive behaviour.

NB There is a change request for WFS to support explicit query models per feature type - this may provide a way to resolve the difficulties,

So, this implies that Observation will, in practice, be an abstract class, and services will expose only specialised types. Clients will therefore need to know how to determine the semantics of the specialised types in order to exploit Observation patterns, which are probably sufficiently complex and valuable to warrant dedicated handlers in many applications.

Coverage analogy

This constraint on Observations is now at odds with the equivalent pattern - the ISO 19123 CV_Coverage. Coverages are soft-typed classes that bind domain specifications to range sets.

One could argue that a coverage is actually a sub-class of Observation, however the ISO model does not provide support. Another way of looking at it is that Coverage is the result type of a Observation specialisation - one can easily imagine this a FieldObservation or a DistributionObservation (is there a common semantics that would reconcile these?).

Coverage is a soft-typed class that allows an application to bind a domain specification and a range set to a container that holds operations that can be performed against this content.

Profiles redux

This process of constraining a general model to a particular content model is just the familiar, but poorly modelled, profile pattern. One possible perspective is that a profile definition, as implemented, generates a number of specialisations of other objects. In the case of Observations, a implementation profile might generate:

  • A subclass of Observation with an appropriate result type
  • A subclass (or constraint? ) of PhenomenomPropertyType, ProcedurePropertyType
  • A constraint for gml:FeaturePropertyType
  • Content bindings for some ScopedName data types
  • A query model for access via a WFS
  • a query model for access via a Sensor Observation Service

these would all need to be self-consistent, and hence automated generation from a single modelled profile would be desirable.

Topic revision: r6 - 15 Oct 2010, UnknownUser

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).