Ticket #35 (assigned task)

Opened 9 years ago

Last modified 9 years ago

should we ignore the O&M hostedProcedure

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


O&M (Fig 11) has:

  • BNL: SF_SamplingFeature has an association (hostedProcedure) which is an OM_Process. The SF_SamplingFeature is a "Platform" for the process.
  • O&M: A common role for a spatial sampling feature is to host instruments or procedures deployed repetitively or permanently. If present, the association Platform shall link the SF_SpatialSamplingFeature to an OM_Process deployed at it. THe OM_Process has the role hostedProcedure with respect to the sampling feature.

We have some problems with this:

  1. This blurrs the distinction between process and instrument. Instruments may well be hosted at spatial locations, but the process of creating a result may occur elsewhere. (This is an issue to do with acquistion of specimens and results etc which we cover elsewhere).
  2. In the case of remote sensing, the spatial sampling feature which is relevant to the feature of interest is not the same as the location of the platform which may carry the instrument, and indeed the processing may occur elsewhere (consider a satellite, downlinking "data" for remote processing).

This concept is already present in MOLES 3.2 where we see that MO_Acquisition can be specialised into flights and cruises, field trips and fixed deployments.

  • There is a location/position associated with these "platforms".
  • Similarly, there is an observationSite which is a SF_SamplingFeature or a collectedSpeciment which is a SF_Specimen as an association.

More generally, an instrument can be deployed

  • at a sampling feature
  • on a platform at a sampling feature
  • at a station which is a sampling feature
  • on a platform remote from the sampling feature
  • on a station remote from a sampling feature

(Here we use station and platform as essentially the same thing which differ only in that a station does not move.)

Now an acquisition is a process which results in either a specimen or a result, so it (might) use a platform, but it definitely uses an instrument.

If we want to use O&M in a way that consitently handles, physical specimens, result gathering locally and remotely, then we can't use the platform piece of O&M!

The task: get Simon to agree that this is the case

Change History

comment:1 Changed 9 years ago by sventour

This  diagram shows a proposed model for the acquisition location.

The methodology to reach this model is:

There are two main categories of acquisitions:

  • Acquisition at the samplingFeature
  • A remote from the samplingFeature Acquisition

open a parenthesis

A codelist instead of specialisations of class MO_ResultAcquisition

In MOLES 3.2 the class MO_Acquisition has the specialisations:FieldTrip,FixedDeployement,Flight etc.

Instead, taking advantage of the meaning of the codelist we propose the class MO_ResultAcquisition to have an attribute type of Data Type codelist. See  this figure.

close the parenthesis

Acquisition at the Sampling Feature

The class MO_ResultAcquisitionAtSamplingFeature, see  this diagram, ( a specialisation of MO_ResultAcquisition) represents acquisitions that occur at the sampling feature and is associated with SF_SpatialSamplingFeature which has the role acquisitionLocation with respect to MO_ResultAcquisitionSamplingFeature. This association complements the Platform association which links the SF_SpatialSamplingFeature with an OM_Process ( which has the role hostedProcedure with respect to the sampling feature.)

However, the acquisition location can be referenced by using a geometric description ( SF_SpatialSamplingFeature ) ; text or identifier; or both . Therefore the attribute location: MO_ResultAcquisitionLocation of MO_ResultAcquisitionAtSamplingFeature is introduced and the previous model is modified to  this .

A remote from the Sampling Feature Acquisition
If the attribute location: MO_ResultAcquisitionLocation instead of being attribute of the class MO_ResultAcquisitionAtSamplingFeature is attribute of the class MO_ResultAcquisition the model covers also the case of a remote from the sampling feature acquisition. The specialisation MO_ResultAcquisitionAtSamplingFeature is not needed anymore. See  this diagram .

This modelling for the acquisition location it seems that can describe the location of any acquisition step including specimen acquisition. Thus the relevant Union has been given the name:MO_AcquisitionStepLocation .

NOTE The location of any Acquisition step is the location of the used instrument(s).
If a platform is used , the exact position of the instrument can be described in the MO_ResultAcquisition attribute processAcquisitionDetails:CharacterString.

Action: Examples to validate the model.

comment:2 Changed 9 years ago by lawrence

  • Owner changed from simon to sventour
  • Status changed from new to assigned
  • Version changed from V3.4 to V3.5
  • Milestone set to V3.X Next Release

We should revisit this in the context of today's discussion about re-use of process, and certainly resolve it in the context of 3.5

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