(This being notes from what is supposed to be a fortnightly meeting on general information modelling issues, as applied to CSML, MOLES, and our support of the MetOcean? OGC working group and various INSPIRE activities.)

General CSML Discussion

We were discussing progress on the finalisation of CSML3.

The current set of CSML3 tickets are  here.

In this discussion we were reminding ourself that if we have a model with

  • A hasAssociation B, and
  • we want to specialise B, to alway be C, then
  • we have to specialise A to D so that
  • D hasAssocation C

At which point we could, in cases where C is effectively a constrained B (as opposed to an extended B), choose not to implement C as a class at all, but simply as a constraint on D so that it can only be associated to certain restricted versions of B.

All that might seem a bit esoteric, but it affects choices of how CSML3 might specialise Observations and Measurements ... in the simplest and most transparent manner. Specifically, it's clear that a CSML observation needs to be a specialisation of an O&M observation, and one that admits certain specialisations of result (the CMSL "feature types").

Other CSML issues include

  • at least one, possibly two new feature types:
    • one to support delineating a volumn of air/ocean with a common property (e.g. volcanic ash above a certain level), and possibly
    • one to support certain classes of trajectory aggregations (as recnetly discussed on the CF list).
  • ongoing suport for storage descripters
  • temporary support for referencable grid and multipoint, which although accepted as GML change requests, have yet to be implemented, and
  • the need to exploit SWE phenomenon from 1.0 for the mean time, but recognising the need for informative examples to support CF cell methods.

So we need to foreshadow CSML4 which fixes these issue to use a future version of GML and a future cannonical spec for SWE phenomenon.


Here the main discussion was about the relationship between CSML and MOLES as an exemplar of the relationship with other specialisation of O&M.

The main conclusion we drew was that

  • the result of a MOLES observation should be constrained to be the members of a set of acceptable result types, which would mainly be other specific specialisations of O&M (ie the result type is not going to be a coverage, but an observation!)

Taking CSML as an example, this has some interesting implications:

  • The MOLES Feature of Interest needs to be have a spatial shape which is the envelope of the shapes of the features of interest in the result observations. It may optionally include sub features of interest which are themeslves the aggregated features of interest of the result observations.
  • We need to work through how this works for Ollie Raymond's use of MOLES like observations, it might mean that we need to have a specific result type in MOLES as well, or it might mean Ollie's stuff needs to be in it's own specialisation. We should tee up a virtual meeting with Ollie to find out what he's done and how it compares with the current version of MOLES.
  • An information pipleline to populate MOLES would parse the "aggregated" related observations to generate this envelope feature of interest descriptor and possibly harvest the aggregated domains of the observation results (which in the CSML pattern is the same as the sampling feature feature of interest).
    • Such a pipeline would be designed to minimise human intervention ...

We agreed that the computation part of MOLES should be addressed in the Jan/Feb? time frame as part of the Metafor refactor to O&M.

The list of activities required to finish MOLES3.4 is No results

We also discussed the way INSPIRe and ISO deal with the relationship between types and the need to specialise those by realising specific types, and the "normal" specialisation by UML class specialistion of Feature Types. We realised we didn't really understand what what was going on ...

 Trac Powered
Site hosted at the
British Atmospheric Data Centre
for the