[CATALOGUE]Starting Data Model Subgroup

[Pierre Didelon]

Hi everybody,

some comment concerning provenance/history handling,
a little bit off from the main subject of this thread,
but which may (perhaps) impact deeply on catalog design.
Even if obvious as claimed by Pedro Osuna,
"In summary, there are obvious things to model from a catalogue, like its
provenance...", it can be complex depending of the level considered.

In fact a catalog history can be handled at different level;
- first it can be related to the whole catalog it self
	-> one catalog - one provenance/history
- it can be related to a column or a row
	-> one row/column - one provenance/history
- it can be related to a cell
	-> one cell - one provenance/history
- or even it can be related to a group of cell,
a sub-cube in the catalog cube ( of eventually n dim.)
	-> one sub-cube/group_of_data - one provenance/history
One obvious and simple example of this, is illustrated by
all RA, DEC ,ErrRA, ErrDEC obtained with one astrometric
calibration for a certain set of astronomical objects;
in this case this sub-cube (4 cols * n rows) has a common
history which can be different from a photometric data part
of the (same?) catalog.

I remember that I had a fruitfull conversion with Pat Dowler
in Cambridge (UK) concerning this subject, and their related experience
in CADC. He can may be add some comments on this subject.

But it can be seen already, that depending of the kind of granularity
we want to handle with provenance/history, the implementation may be
different and more or less complex.


Kirk Borne wrote:

> 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.
Yes. But how derivation is made, and how is it kept in (or with) the
catalog is not always identical depending of the kind of catalog.
I remember an article of C.Jaschek making a kind of classification
of catalog types between Observation Catalog to Compilation Catalog
of data collections merging and homogenisation :

http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1984QJRAS..25..259J&db_key=AST&high=3d9c6cf76d17675

some considerations may be of interest, as well as some from
another article concerning information and catalogues,

http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1973IAUS...50..275J&db_key=AST&high=3d9c6cf76d17675


> The data model must describe not only the structure of the "table", 
> including attributes and values, but also inheritance, provenance,
remarks, above.
> 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
As well as the CDS ReadMe and all former catalog descriptions they use,
(see http://vizier.u-strasbg.fr/doc/catstd.htx). All this, including VOTable,
must guide the DM group, but not frooze the DM Catalogue elaboration.
> 
> Furthermore, UCDs already provide the semantics.
> 
> - Kirk
> 

SY
--
Pierre
--------------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
--------------------------------------------------------------------------