Hi,
> > A catalogue is not a table, generally speaking. It can be expressed
> > as a table or as a set of many tables, but that is not the point.
> > A catalogue is a set of derived data: derived from imaging, spectral,
> > event lists, time series, interferometric, or other types of data.
> > The data model must describe not only the structure of the "table",
> > including attributes and values, but also inheritance, provenance,
> > semantics, error columns, and more (units, formats, column-column
> > relationships, table-table relationships).
>
> This really just sounds like defining the VOTable superclass. If there is
> more to it than that might I suggest changing the name of this DM from
> Catalogue to Derived Data Set or something similar because when I think of
> a catalogue, I think of a tabulated structure, be it for books in my local
> library or lingerie from Victoria's Secret.
>
The Catalogue data model will hopefully provide a formal way to describe
an astronomical catalogue "completely".
This will include more than simply saying it is a table with a certain
number of columns whose meaning can sometimes be described by some string
expression. The fact that some catalogue instances can be serialized
into such a structure does not mean that a catalogue "is-a" (VO)table,
or a (VO)table "is-a" catalogue.
It is precisely the task of the DM group to define ways by which one can distinguish different tabular data structures by providing means for describing their contents, i.e. by providing a model for the meta-data that should be attached to the structure.
To stay with your metaphor, such a description will help you make the right choice in the morning so that you will come to work wearing a boxer short instead of the latest Harry Potter.
Cheers
Gerard Received on 2004-07-27Z08:57:09