use cases and Re: Comments on Canadian VO data model

[Alberto Micol]

Regarding Pat's answer to Jonathan:

> - a data model does not stand alone. It is integrally related to the query
> model one adopts. You need types that reponds sensibly to queries and you
> need queries that can leverage the available types. Thus, the DM is only half
> of the story (IMO :-).
>
and

> Thus, it is part of the Archive data product you download
> to tell you how to use the data correctly.
>
and

> > A.2  Why no spatial_bins ? This seems a critical piece of info
> >      (e.g. 1024 x 1024 image, or 1x1-spatial-pixel spectrum...)
>
> Didn't see the need for it...
>
I see Pat's point of differentiating Archives (products) and Catalogs (products metadata,
defined to be the ones that people will query upon),
and I do understand the CVO requirement that calls for a data model
integrated with the queries it supports; this choice simplifies the implementation.

Nevertheless, I do not agree with Pat in that I think that the most generic data model
should stand alone.
It is of course fine to implement a partial data model when one has a specific problem to
solve, but the IVOA data model has to be able to support many different views (ie queries),
and the users won't necessarily be people.

Pat's data model stops at the user query level, and delegates the rest to some intelligence
placed somewhere else. The more general data model might want to go deeper.
Suppose (in CVO) that a piece of software wants to read the pixel values of an image;
the image might be in fits format, but does not need to be; a fits file might be structured in many different ways. A well defined data model could describe the image format, so that
a generic image reader based on the data model could be conceived.

We need people looking at things from different perspectives.
We should probably try to compile a list of use cases and data model requirements,
basing it on the existing data models (cvo, cfa, cds, astrovirtel, astrogrid).
What remains to be seen is if such list is complete or whether more scenarios have
to be envisaged.
It would be nice if we could come up with a proper list before Cambridge.
What do you think ?

Here the Astrovirtel data model use case:

A data model to describe ESO and HST telescopes, instruments, cameras, filters, detectors, controllers, and observing modes
in order to build:

1) a metadata service to help astronomers finding instruments with certain characteristics
    eg, which ESO instruments offer a certain resolution and field of view in the R band ?
    (this is probably a good bridge case between the Registry and the DM)

2) a Limiting Magnitude (or Flux) Calculator (LMC) for archived images.
   This requires a data model describing things like the telescope area,
   the filter transmission curves, the detector sensitivies,  the pixel scale, the seeing, etc

Alberto

--
Alberto.Micol at eso.org                         Tel: +49 89 32006365
HST Science Archive       ST-ECF              Fax: +49 89 32006480
ESA/RSSD/SN               c/o ESO             Karl Schwarzschild Str.2,
http://archive.eso.org/   No ads, thanks.     Garching bei Muenchen,
http://www.stecf.org/     HTML emails         D-85748 Germany


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20030423/42029045/attachment-0001.html>