[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