Observation data model comments

[Pierre Didelon]

Hi Anita,

more comments. Not too much and nor too scrap I hope.

Anita Richards wrote:

> 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 am not sure to catch your point.
For me each data (ObsData, ProcessData...) has it's own Characterisation.
 From your comment it seems that you suppose that Characterisation is linked
to only ObsData (raw data or data sufficently related to it, to have
the same Characterisation). But then how do you handle Characterisation
for data processing which changes this considerably, like in your example
with high/low  spatial-res/sensitivity  outputs.
Or do I missed something?


>>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.

May be a simple line for simple relation/association?
Without triangle (inherritance) or diamond (agregation/composition).

I didn't understand either the two Observation box, and the link between them?
?association between Observation and Provenance => simple line (change needed?)
?agregation/composition between Provenance and Processing =>  diamond+line (ok)
?inheritance/specialisation between Processing and Composition => triangle+line (change?)
?agregation or association between Composition and Observation => change or not?

For me AnalysisMethod and Processing are two objects very similar,
which try to handle the overall data-process history, from ADU of detector
to very elaborated data like isophotal magnitude. Keeping the symetry between
data and processing, having one basic (and simple) class for each of these two kind
of information VO has to handle, will help to clarify (hopefully)
how data and processus history can be stored and dispatched.
The biggest gap beeing then the step between image processing and
catalog processing. Pat has some interesting experience on catalog processin.
But perhaps a clear gap has to be made between data directly obtained from
observation (related to only ONE observation, a set of data which shares prov.)
from the ones deduced from confrontation/agregation of several observation.
However it seems to me that such a separation is artificial, and sometimes
not realistice. For example calibration of bservational data uses elaborated
data deduced from previous experiment and so on.

Regards,
Pierre

PS : As pure intelectual curiosity what are the units of the 7D of visibility data?
Did yu have any ref. or doc available and usable for a beginner in radio data like me?