Observation data model comments

[Anita Richards]

Thanks for your comments, Pierre.

> Data Charaterisation gives you the data state, while history and
> versionning will help users to understand how these data
> have been obtained. If Processing details are not important
> you need only 2 bidirectionnal links (or 4 unidirectionnal links)
> between all data for which you want to handle history.
> Version and history links in diag.
> http://www.ivoa.net/internal/IVOA/IVOADMObservationsWP/root.ps.
> Details concerning  history can be added later on, storing
> which process (with wich conf.) has produce each data.

Yes, we have to distinguish between what should be bundled with the
original data (e.g. AIPS HIstory FITS extension table), and what the VO
needs to know.  It isn't always easy to access, let alone interpret the HI
file so that might be passed on in case the user is an expert, but
ignorred by VO tools.  So I ahve added a version variable to Processing, I
understand that could be passed to ObsData? The crucial thing is that, as
Processing determines Characterisation, the right version is used if the
VO needs to consult Processing e.g. to extract the photometric standard or
zeropoint or the angular resolution.  But maybe we aren't likely to have
tools to do even that in the near future....

> I think that aside versioning you need first history to link successive
> processing step, then it will be ok! You have two possibilities
> regarding a processing 1) a process give new type/kind of products; it
> is a 1st version of a prod step, or 2) a process have the same (or
> almost) inputs and outputs (only the soft version, or config param
> values are diff) then you have a diff. version of an pre-existing data.
>
> nevertheless if this give you a frame where you can store information,
> it does not resolve all possible ambiguities. Data producer has to
> decide inn fine wether if high spatial-res/low sensitivity and low
> spatial-res/high sensitivity are diff. step of analysis (1 :: history
> branch) or diff version of of the same production level (2 :: version
> branch) I would guess 1!

Yes, I think that in practice situation 1) is where there are separate
processing branches outside  direct VO control; 2) could cover simple
cases like Aladin resampling, or cumulative processing.  Of course as the
VO and interferometry data suppliers get more sophisticated, more and more
gets shifted to 2).

This does produce another requirement though, which is, as Obs v0.2 notes,
some classes in Characterisation are mutually dependent, e.g. Sensitivity
as a function of other entries in the matrix.  I don't know how easy this
is to impliment in practice.
> >
>
> Concerning the schema, I don't understand why you have inheritance
> between ObsData and MeasuredQuantities and not an historical
> (processing) link.
You are probably right, I don't fully understand UML as you can see, but I
am not sure everyone else does either so I am not quite sure which
model style to copy.... Logically I agree with you, I just don't quite see
how to represent it.

> a detail; ObsCatalogue is confusing (me at least) with (source) catalog.
> ObservationList or ObservationLog wouldn't be better?

Good point. I will change that.

thanks
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).