Data Model Landscape

[Anita Richards]

Dear Francois et Mireille,

Thank-you for the summary.  Before I make a few comments, I would like to
ask if we can establish a road-map with some dates and targets.  The
summary by Francois and Mireille suggests some priorities, I would like to
see us establish those i.e. deadlines to produce models (separately from
the argments over what goes in them!)

...
>     At a higher level we have "Observation" which mainly consists of
> Characterization and Provenance with a couple of other smaller components.
>
>     The Resource metadata model (presently implicit) is at a higer level than
> Observation in some sense but describes metadata in a coarser way.
>
>     Is there also room for  an implicit DM component for Query datamodel?
...
>       Some other concepts like Curator or Data Collection are probably common
> with Resource Metadata (see d) and some Missing Practical stuff (data format,
> compression, Packaging of missing Science and calibration data) have to be
> formalized : see the mail posted by one of us (FB) to the list two weeks ago.
....

The Observation data model already overlaps with Registry Resource
Metadata in an adhoc but fairly clear way.  We need to formalise this - I
suggest that we don't mess with RM, but identify the means by which the
Obs DM can supply the required Registry information.  This seems fairly
straightforward for the Registry Identity section (for now let's only
worry about access to exisiting VO-friendly data resources!) and the data
description (coverage etc.).  That is, the parts which tell you where the
data are and what they are seem to be under control.

That leaves the question of how you access the data in a useful form,
which is likely to involve calling other services ranging from a generic
VO tool to match coordinate equinoxes, to specialised data provider tools
for stacking optical franes, extracting images from visibility data etc.
Registry Curation and Service metadata partly cover this, especially when
we have dealt with the 'Missing Practical stuff' which includes Curation
information.  However the IVOA Registry Service section is the least
developed (AstroGrid has done more on this). I would like to see some
examples of what you see overlapping between the Observation DM and Query
and Registry Service which might address this.



>     We also have more dedicated (specialized) data models: The Spectrum
> one, and the Radio one.
I think that these have different intents; the spectral model seems to me
to be something which should be as generic as the Observation model,
adopted by the IVOA for use whenever we have multi-wavelength data.  The
Radio model is an application of the Obs model (and the spectral one when
it settles down!) to a particular domain; it should be completely
consistent with Obs DM where it overlaps but also contains domain-specific
material and, at the most detailed level, may contain facility-specific
material.  I don't think that it would be appropriate for the IVOA to say
that radio observatories MUST use the radio data model to publish data to
the VO, but that they should publish data in a way which relates to the
Obs and other standard data models, and the Radio DM is the recommended
way to do that....

>      We will probably split Observation in two efforts, starting by a
> completion of Characterization (as Jonathan proposed, because it's
> more urgent for use by DAL WG).

Sounds good

> C) What are the possible relationships between all these datamodel
> components?
>
> In the case where we try to use low level DM components in high level
> ones (eg. , STC or BasicQuantity in Characterization) we can probably
> use the low level DM component as an attribute type in the high level
> one, as was proposed if we remember well by Gerard Lemson . For example
> the Characterization.coverage.[].support is of type "STC.region", while
> a Characterization.coverage.[].bounds.? is of type "BasicQuantity".
....
>    All these show that we have many ways to make our various DM components
> "collaborate" or interact. That's a good reason to develop further  the
> DM components  we allready have, without waiting a speculative
> "grand-unification".

It would be useful to have an example (diag.? rough outline?) of the
links etc. you  mention applied to some specific data/services

thanks

Anita


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