Ticket #34 (reopened task)

Opened 10 years ago

Last modified 9 years ago

Attributes of MO_ObservationCollection

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

Description

MO_ObservationCollection is the obvious place to start when producing ISO19115 metadata for export (to GEMINI, INSPIRE et al).

To that end, it needs appropriate attributes so that a query over a MO_ObservationCollection (and it's associations and their attributes .... and down to some sensible depth) will yield the appropriate "D" metadata.

The same argument applies to some extent to ISO19131

This task is to comb through the DPS and MD specs and see what minimal arguments will be necessary.

Change History

comment:1 Changed 9 years ago by sventour

  • Status changed from new to assigned
  • Owner changed from ventouras to sventour
  • Milestone set to V3.4 UML Final

comment:2 Changed 9 years ago by sventour

  • Priority changed from major to minor

comment:3 Changed 9 years ago by lawrence

We think we can get rid of observation collection. Do so!

comment:4 Changed 9 years ago by lawrence

So a set of arguments:

  • get rid of it, make the direction of the associatoin between obs and project so that an obs knows about it's project, and a query is needed to get the collection of observations for that project, but
  • Rapid: data held at more than one data centre. Need a collection description somewhere so that a person can find all rapid data. (NB: means the multiplicity on funders, and data centres should be more than one in project)
  • An observation, ought not have more than one process,but it can nillable or at a higher level (e.g. just flights not instrument details). That way we could do it via a query for all uncomplicated cases. (It might have some implicatoins for process)
  • A growing collection will have ever changing time properties on the observation (which is usefu). Resultime the last resulttime of the collection.
  • All of which suggests rather than kill it, we put it in as a specialisation, with the context as a project.
    • A different specialisation of OM_Observation than MO_Observation
    • Project points to it (unlike MO_Obs which points to project)
    • Has a different FOI (more like ISO keywords, and scientific aims - cloud properties etc)
    • Has MD_Metadata (unlike MO_Observation which does not)
    • Project can have multiple collections (e.g. a BADC collectoin and a BODC collection)

PUT IT IN LIKE THIS

comment:5 Changed 9 years ago by lawrence

We tried again to get rid of it, or to make it not a specialisation of OM_Obs.

Getting rid of it:

  • No we can't because the arguments above ... (different FOI, different process) (We had wanted just to use MO_Observation, because it is inherently a collection via the MO_result attribute (itself pointing to multiple things ... but we can't because of the process issue).

OK, can we not make it a specialisation? What do we really wnat?

  • The extent (in time and space) so we don't have to query over members.
    • It would be nice to expose the phenomenon time as a special thing ...
  • A simplified common process. (This is one of the main possible definitions, but it has to be optional since the collection may be only via project).
  • Common permission?????? (Definitely not a common one, would hide data too easily e.g. CMIP5 example, so let's remove it).
  • Observation collections may form part of multiple projects (reason why we need it), means we need an identifier!
  • A collection does not have a result, so it can't be a specialisation!
  • Do we still want a FOI? (Or is project enough ... but we need to get ISO keywords from somewhere to export to MD_Metadata ...)

How about:

MO_ObservationCollection
 + process: MO_Process [0..1]
 + identifier:MD_Identifier
 + metadata:MD_Metadata
with inbound association from
 MO_Project
and outbound aggregation association to
 member: MO_Observation [0..*]
and optionally aggregates itself via subCollection.

so it composes metadata, and a MO_Observation can query to find it's (potentially multiple) metadata records.

So, we might expect this to be the place where at CEDA, we store our MD_Metadata records ... (in a MO_ObservatoinCollection instance) from where they can be extracted and exported ...

comment:6 Changed 9 years ago by domlowe

  • Status changed from assigned to closed
  • Resolution set to fixed

Data scientist feedback suggested remove common process. Description used for describing common collection criteria.

Consider as finished for 3.4.

comment:7 Changed 9 years ago by sventour

  • Status changed from closed to reopened
  • Resolution fixed deleted

On No , another issue:
An observation can be a member of many observation collections.
But sould an observation be a member of at least one observation collection?
Or even can an observation be considered as an observation collection with one member ( itself) ? From the discussion with the Data scientist Support the answer is yes. An observation can stand alone , as an observation collection - a Data Entity in MOLES 2 - with a project knowing about it and relevant metadata.

comment:8 Changed 9 years ago by sventour

A reminder for discussion:
MO_ObservationCollection has an attribute additionalMetadata which points to a resource of non-ISO metadata and the asscociation with MD_metadata class for ISO conformant metadata.

For HadCM3 data there will be MOLES records (metadata) and a link to CEDA repository for MetOffice? metadata.
How can a user understand an instance of MetOffice? metadata? Probably needs an access to the relevant schema.
What is the difference with an instance of MD_metadata ( if it is available)?

comment:9 Changed 9 years ago by lawrence

  • Priority changed from minor to critical
  • Milestone changed from V3.4 UML Final to V3.X Next Release

Discussed in detail today.

At 3.4 we have

  • MO_ObservationCollection as a standalone class pointing to MO_Observation and MD_Metadata.
  • MO_Observation is a specialisation of OM_Observation, and thus has a default association with MD_Metadata.

We note that in practice it might be better to make MO_ObservationCollection a specialisation of MD_Metadata. In doing so we can consider aspects of linkages with Gemini et al.

comment:10 Changed 9 years ago by lawrence

  • Version changed from V3.4 to V3.5
Note: See TracTickets for help on using tickets.
 Trac Powered
Site hosted at the
British Atmospheric Data Centre
for the