Ticket #8 (accepted task)

Opened 10 years ago

Last modified 9 years ago

Need to do a MOLES instance for GRAPE

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

Description

GRAPE: Global Retrieval of ATSR cloud properties and evaluation!

Change History

comment:1 Changed 10 years ago by lawrence

  • Type changed from defect to task

comment:2 Changed 10 years ago by lawrence

  • Status changed from new to accepted
  • Owner changed from Simon Cox to lawrence

comment:3 Changed 10 years ago by lawrence

Trying to do this has exposed a whole bunch of issues.

changeset:9 has some diagrams and classes to go with the discussion below. In the discussion that follows, changes to the UML appear as enumerated points.

  1. Moved Protocol to MO_Protocol, added a wee doc string.
  2. Made a movable copy of some ISO bumf ...

(both of those should probably go into trunk, but ... see below, we don't think we've fully bottomed out the issues with MO_Protocol, at least in comparison with the issue to be discussed here.)

Now, the issue here is that activity of doing GRAPE, as opposed to doing ATSR SST is not a journey, fieldtrip, or fixed ... it's the application of a new algorithm to radiances collected as part of the ATSR (SST measuring) project. So, strictly, this activity involves no deployment as currently defined.

  1. So, we introduce a new specialisation of MO_Deployment (MO_NumericalActivity) to recognise the deployment of an algorithm to generate new observations as opposed to the deployment of an instrument. (This is nicely conformant with Metafor, and would be good for ticket:29 issues).

Of course, an instrument was deployed, but it wasn't deployed FOR this activity. This is possibly ok, coz you get to the instrument via the source data, although you might want to
index that a bit more carefully ...

Now, we have the new idea that a NumericalActivity deploys an algorithm (which may or may not have input data) to produce an observation (much as other activities deploy instruments).

Now, how does compare with a protocol? So the ECN example was that a deployment involved a human carrying out a protocol to make an observation. So the protocol (being done by a human) was analogous to an instrument being run by a human. Now we have argued ourselves to having a numerical activity which involves an algorithm producing data.

So activities are things humans do, or machines do ... operated by humans .. and they involve running algorithms just as one operates a machine ...

At this point we could specialise MO_Instrument into physical instruments and protocols, but and find a way to get running an algorithm in here ... and fix what we've done with NumericalActivity.

But this brings us back to having now a relationship between specialisations of MI_Operation and data via algorithms without instruments. This is consistent with the arguments espoused in ticket:12, but it feels that we haven't got a unified concept of human protocols, physical instrument, and algorithms all fulfilling the same role ...

(By the way, Should MI_Event be in here somewhere rather than MI_Operation? Would that help or just add noise?)

comment:4 Changed 10 years ago by sjdcox

Looking at the play model, I think the general shape of the proposal is good.
Some details:

  1. should MO_NumericalActivity be "MO_Computation" to match "MO_Acquisition"
  2. a «Union» class has its options as member attributes, not associations (relevant to MO_Deployment)
  3. MI_Operation has 0..* significant events, so . MI_Event is essentially OM_Observation. We essentially specialize these semantics in the MO_Acquisition -> OM_Observation association. I don't think we want the rest of MI_Event properties, however, so OM_Observation should not be a specialization of MI_Event. MOLES4 will probably have some cleaning up to do in this area - maybe using 19115-2 as a pattern rather than a parent.

comment:5 Changed 10 years ago by lawrence

  • Milestone changed from V3.2 UML Final to V3.4 UML

comment:6 Changed 9 years ago by lawrence

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