[CATALOGUE]Starting Data Model Subgroup
Kirk Borne
borne at rings.gsfc.nasa.gov
Mon Jul 26 12:11:00 PDT 2004
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).
We will *not* have to rebuild all this stuff that we already have,
if we simply recognize the work of the former-ADC group, which started
building the catalogue model already, as expressed in "dataset"...
http://xml.gsfc.nasa.gov/#dataset
Furthermore, UCDs already provide the semantics.
- Kirk
> From owner-dm at eso.org Mon Jul 26 14:51:05 2004
> From: "Roy Williams" <roy at caltech.edu>
> To: "Jonathan McDowell" <jcm at head.cfa.harvard.edu>, <dm at ivoa.net>
> Subject: Re: [CATALOGUE]Starting Data Model Subgroup
> Date: Mon, 26 Jul 2004 11:37:34 -0700
>
> > The VOTable
> > is a serialization of a simple table, but an astronomical catalog
> > is more than a table - it will have extra standard metadata linking
> > the sources to their parent observations and extraction algorithms,
> > for instance.
>
> You will use inheritance, I hope. Not just build everything from scratch?
>
> We already have a simple example. A ConeSearchResponse inherits from the
> VOTable model. It is a VOTable that must have RA, Dec, and ID attributes.
>
> We can also inherit curatedTable from Table by adding the VOResource
> curation information.
>
> Please tell me you are not going to rebuild all this stuff that we already
> have....?
>
> Roy
>
>
More information about the dm
mailing list