Observation Model:

Anita requested (and it was agreed) that anyone writing an object model include a 10ish word phrase defining the object and/or its purpose.

Doug requested (and it was agreed) that Characterisation might be useful elsewhere and so should be self-contained.

Martin requested (and even Anita agreed that we mark off areas of the model (eg ObservingConfiguration ) that are discipline specific as follows:

1. Define what is required from the rest of the model of the area to be marked off (this is the interface)
2. Model completely separately the different object structures that implement these things for different disciplines

There followed some discussion on filter/gratings but I believe this can be deferred to the appropriate discipline.

Brian requested (& it was agreed) that as above, we separate off anything else that looks like it might be re-used as a separate package.

Name change requested: DataReductionPipeline -> DataReductionSystem/Process

Martin believes that the Characterisation object is too vague, and that the minimum set are named (even if they are also aggregated by list and found by UCD), which are: 2d-position, spectra, time. [MCH: If we're going to model our data we need to note the characteristics of it otherwise we're not really modelling it ] Martin also doesn't like the term Characterisation as such vague terms imply the object/relationship has not been properly thought out, so JM has actioned him to think of a better term. Ooops.

We agreed that partially implementing models is OK. [MCH: We probably need to agree what are the minimum/mandatory parts though if it's going to be useful to the VO?] There will also be custom models that people can either map to the VO, or make use of bits of the VO model by linking to it.

Radio Observational Model (Anita Richards)

We (re)agreed:

• ObservingConfiguration becomes a placeholder (as above)

• DataReductionPipeline should be renamed -> 'Processing' (or similar) as above.

• Add an ObservingLog to the general model. This is another 'placeholder' that will be implemented differently for each discipline; interface TBD.

• Add Processed or Extracted as a placeholder for reaching such data from the Observation model

• "Systematic errors on position need to be made explicit".

There was something funny about modelling radio coverages vs optical coverage (& resolution vs depth) that I didn't understand. -- AnitaRichards - 28 May 2004 I think it might have been how we need to characterise the potential images (etc.) which can be made on-demand from radio (or x-ray etc.) data, so some of the fields in Characterisation need to be ranges (and eventually they will be interdependent functions).

Radio Observation Model (Peter Lamb)

• Some discussion on Proposal but will leave until later - leave as placeholder for now. Looks like Proposal would be a very useful thing to model however so it can be searched, so Jonathon has asked for volunteers to manage it.

• On AntennaPosition : some things are wanted but some things are necessary for external use. The model needs to make clear what is necessary for the rest of the model, and things that might be useful for holding data/representing state about a particular observatory.

Summary thoughts (Martin Hill, my impressions)

The observation model looks like it will become a skeleton 'high level' model, with most of its components modelled separately. We need to:

• Work out what the interfaces are for each of these components to the Observation model; ie what does the Observation model need to know about them?
• Work out what the mandatory parts are
• Model the separated components (eg Proposal ) for radio, optical, etc.

-- MartinHill - 27 May 2004