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:
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.
We (re)agreed:
ObservingConfiguration
becomes a placeholder (as above)
DataReductionPipeline
should be renamed -> 'Processing' (or similar) as above.
ObservingLog
to the general model. This is another 'placeholder' that will be implemented differently for each discipline; interface TBD.
Processed
or Extracted
as a placeholder for reaching such data from the Observation model
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).
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.
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.
The observation model looks like it will become a skeleton 'high level' model, with most of its components modelled separately. We need to:
Observation
model; ie what does the Observation
model need to know about them?
Proposal
) for radio, optical, etc.
-- MartinHill - 27 May 2004
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
Working Groups
Interest Groups
Committees