This page to discuss moving metafor towards O&M (ISO19156) compliance, possibly in accordance with MOLES use of ISO19115-2.


The basic concept of O&M is that the result of an observation of a property of a feature of interest is made using a process:

O&M Core model

The sampling features pattern goes a bit further and says that we can use a sampling feature specialisation of a feature of interest, in which case the result should be a coverage where the domain of the coverage is the sampling feature itself. (This inherits from CSML).

Ideally in an O&M pattern one would have re-usable processes, with event specific parameters in the observation. We'll come back to that.


In ISO19115-2 we have some additional concepts available:

Processing pieces of ISO19115-2

CIM 1.5

A brief summary of CIM 1.5 is here (not all relations and attributes shown):

CIM 1.5 Brief Summary

Possible Evolutionary Steps (BNL version):

  1. NumericalActivity splits into two pieces:
    1. An Observation (to bind everything together with runtime parameters, much as simulation does currently), and
    2. A MF_NumericalProcess abstract base class which itself specialises from LE_ProcessStep
      1. We think about the attributes of this and the possible use of LE_Processing and/or a specialisation of it.
      2. And the existing subclasses of numerical activity sit pretty much where they are, but we think carefully about the relationship between the observation and the numericalactivity (some attributes ought to be promoted to the observation?)
  2. The process part of our new observation is constrained to use a M4_NumericalProcess.
  3. The output of the MF_NumericalProcess is an MF_DataObject.
  4. The observation result is constrained to be the same MF_DataObject instance.
  5. The observation context is specialised to become the experiment (and hence) numerical experiment (this would be a good pattern for MOLES).
  6. (See ticket:930, we probably want to have ensemble as a bigger concept than simulation)
  7. (See ticket:945) we do need a configured model concept.

A slightly different approach (the above may yet be better) is documented here

Problems with CIM Software?

CIM software (at 1.5) can be summarised in the following diagram (most of the interesting properties to the metafor project are not shown on this diagram):

main structure of the cim software package at v1.5

What's interesting about this is that it mixes "common" software concepts (e.g. language) with ESM concepts. It's certainly not suitable for plugging into other models (of software) as it stands.

Things to consider:

  1. Does it really make sense to consider that software components major inheritance is from a DataSource, particularly one with those properties? (Clearly the fact that components may want to couple together is important, but that feels like the wrong thing to do).
  2. Can we split the SoftwareComponent into pieces that are more generic and pieces that are ESM specific? THe generic pieces could then be more reusable, and potentially map onto the Open Provenance Model.
  3. The distinction between what the component is for, and the way it is used needs to be more clearly delineated. (There is enough confusion between what scientific and numerical properties are for anyway).
  4. The specialisations of ModelComponent and ProcessorComponent feel wrong, perhaps the distinction is between things that primarily operate on inputs to produce outputs, and things that primarily produce outputs (even though they will have input parameters and initial and boundary conditions)?
  5. Are entry points really dependencies?
  6. Does one really want to aggregate couplings into a composition via a description? What do we expect that description to tell us about couplings?

From left field:

  1. What semantics would we get from a WRF registry? (e.g.  user guide and  pdf)
  2. Should we pay any attention to the semantics of the  Common Component Architecture?
    • See  Larson et al, 2004 for a discussion of the relationship between ESMF and CCA in an ESM context, eg Several notable distinctions exist between CCA and the ESMF component frameworks. The primary distinction is that the CCA provides a general component model, while the ESMF provides a specialized component model tailored to a specific application domain (CWO applications). Moreover, the CCA enables dynamic composition of componentbased applications at run time, while the ESMF dictates static linkage of a component hierarchy. The CCA does not provide concrete classes with which to build components, while the ESMF does (the ESMF infrastructure). In this sense, the CCA is component framework, while the ESMF is an application framework.
    • See also sidl

Component Properties

Component properties seem to be overloaded with far too many attributes and specialisations. How do these differ from inputs and outputs if they have intent (in, out, inout) (there are name,value pairs attributed to OASIS in the ConnectionProperty and CouplingProperty pieces of Connections and Couplings respectively).

Component properties as described in CIM 1.5

Couplings Etc

Ideally this piece of work wouldn't address this part of the CIM, but there does appear to be some redudancy into other classes, so we'll include this here for completeness:

cim 1.5 couplings etc

Notes on using Fullmoon and Hollowworld to generate the Quality schema

Dominic Lowe

An attempt was made to take just Quality part of the ConCIM model and see if it could be modified so that it could be run through Fullmoon for automated schema generation in order to to develop the AppCIM according to standard UML to GML encoding rules. This will ensure that the resulting XML schema and instances are syntactically ISO compliant and also fit in with the current best practice in this type of domain modelling activity. (best practice from INSPIRE, ISO, OGC, etc).

The attempt was largely successful with just a few minor UML problems which need more investigation. The following notes are pretty detailed and partly a reminder to me.

  • Set up the HollowWorld and ISOTC211 repositories in Enterprise Architect (google "SeeGrid HollowWorld" for more info on how to do this).
  • Created explicit links between CIM classes and the ISO classes where appropriate (e.g. specialisations).
  • Remove the circular dependency between the Quality and Shared models. The 'document' object in Shared currently requires a quality attribute of type 'CIM_Quality'. This makes for a circular import in XSD - quality.xsd imports shared.xsd and shared.xsd imports quality.xsd which seemed to cause me some problems in validation. To remove this dependency I changed the type of the quality attribute to 'DQ_Element' from ISO 19115. (CIM_Quality is a specialisation of DQ_Element)
  • Created a 'Package Dependency' diagram, needed by fullmoon. Shows the one-way import (Quality imports Shared).

adding quality shared package dependency diagram

  • The Document stereotype is currently ignored by Fullmoon - to capture the relationship inheritance must still be used in UML - so CIM_Quality specialises the Document class. Anything else requires modifications to Fullmoon (the scope of which I haven't understood yet). However I created a UML Profile for CIM with a Document stereotype that can be used in UML but it doesn't 'do' anything in Fullmoon.
  • Created a CIM Classmap to configure Fullmoon where needed. (available in svn)
  • DocumentID - how to constrain this to a GUID as before using Fullmoon? Currently modelled as a CharacterString. Needs more thought.
  • DocumentVersion - again, modelled as a CharacterString
  • Need to address how to handle Codelists - taking into account latest approach in metafor. Currently they are encoded in the XSD (temporarily).
  • Some of the import statements are not yet appearing in the output xml schemas generated by fullmoon. Need to work out why not.
  • The association 'subissue' on CIM_QualityIssue - where subissue is also a CIM_QualityIssue, does not get properly represented in XSD. Need to work out if this is an XSD issue or Fullmoon issue.
  • Finally, fixed all the associations and tagged values to satisfy Fullmoon conformance tests.

Here are the models for info:


adding quality shared package dependency diagram


adding quality diagram

Further info

Realised I already wrote up some other notes on this process... so have merged them here.

The model is in the subversion repository here. However to view it properly in Enterprise Architect you would have to also upload the HollowWorld and ISOTC211 models. So for ease of viewing an html version is available and can be exported by the following command.

svn export

Then open the index.htm file in a browser.