Observation data model comments

[Pierre Didelon]

Hi Jonathan,
comments concerning history/versionning.

Jonathan McDowell wrote:

> Hi Anita,
>  Here are my comments on your revised observation model.
> 
> I'll label the initial Observation V0.2 draft as
> [V0.2] and Anita's draft as [R].
> 
> [Apologies for the typo in the earlier document: the file is called V0.2
> but the document says V0.3. There is no difference. Oops.]
> 
>    ========================================
> In the context of Anita's model I would like to distinguish between the
> core (aggregated) parts of the V0.2 Observation model and things that
> are mentioned but peripheral.
> 
> For peripheral objects:
> 
> The [R] ObservationGroup in Anita's model corresponds to our [V0.2] tree
> model of an archive.
> 
> pThe [V0.2] MeasuredData object corresponds to what I have normally
> called a source catalog - the decomposition of the observation into
> distinct pieces (`sources') described by parameters. This is linked to
> an Observation, but I don't see it as part of the Observation object.
> However, by stretching our concept of Observation, we could think
> of it as a separate Observation object (perhaps better, we could define
> a more generic Dataset object which covers both as special cases), in
> which the MeasuredData is the [V0.2] ObsData and the [R] AnalysisMethod is the
> [V0.2] Provenance (processing). To say this another way: if we ask
> `where did this data product D1 come from?' the answer may be 'I ran this
> processing on another data product D2' or `I made this observation of the
> sky and put the raw result in D1' or `I made this obs of the sky
> and put raw stuff in D2, and then ran processing on D2 to make D1'.
> 
> Now in the context of our data model describing observational metadata,
> maybe it doesn't matter if D1 is an image, or a catalog of derived
> properties. In either case you have a description of the data product
> (ObsData, MeasuredData) and a description of how you got it (AnalysisMethod,
> Processing, ObservingProtocol, or whatever). So I'm not convinced that 
> AnalysisMethod should be a separate class from Processing. I think it's
> already covered in the diagram where you have another Observation 
> coming in with the `composition' box.

I agree, it is better to try not separate similar "things".

Every piece of data (from polarized-spectral-data-cube to simple value)
which needs to be handle by and for history, could have a  common "behavior"
against history handling, then implementation choice is coming.
All "objects" (data handled during processing) can inherit from
a single class handling history and versionning, or aggregate such a class
or be associate with it or implement an "history-version" interface.
 From inheretance to interface implementation it goes from
ease of use/implementation to complete recoding.
A class wich encapsulate information and implements a default
behavior seems more usefull to me than an interface.

Then you can have specialization of data in image, params/quantities, spectra, catalogs...
and of processing in observation, calibration, analysis....
@ http://www.ivoa.net/twiki/bin/view/IVOA/IVOADMObservationsWP
root.ps gives the basic relation between data and processing
to handle history/version infos, hist-ex1.ps and hist-ex2.ps
illustrate two possible realisations of links between data and process
for one processing step..

Sincerely yours,
-- 
Pierre 
--------------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
--------------------------------------------------------------------------