Comments on Canadian VO data model

[DIDELON Pierre]

Hi Patrick,

continuing discussion directly in the text...

> From patrick.dowler at nrc-cnrc.gc.ca Thu Apr 24 17:04:18 2003
> To: DIDELON Pierre <dide at discovery.saclay.cea.fr>, dm at ivoa.net
> Subject: Re: Comments on Canadian VO data model
> Cc: CADC at nrc.ca
> 
> On April 24, 2003 01:48, DIDELON Pierre wrote:
> > About the documentation of Canadian VO Data Model - Pierre Didelon
> >
> > The four catalog types are specialisation (certainly corresponding to
> > different step/level of processing) of a more general type
> > simply called Entry Catalog. Why distinguishing so deeply
> > the 4 types of catalog? SQL tables are differents, perhaps whith nothing
> > in common. But all these catalogs share certainly some properties
> > or behaviours?
> 
> Yes, the various catalogs are specialisations of an Entry Catalog.
> There is reason to the madness:
> 
> - many of the operations are common, hence part of Catalog, Entry, and 
> EntryProp
> 
> - the actual properties that define an Entry in a specific Catalog are
> described in the EntryPropMap for that Catalog; thus, the EntryPropMap for a 
> Catalog really is the thing that makes it a specific catalog (i.e. an 
> observation catalog) and says exactly how it is the same and/or different
> from other catalogs)
> 
I made something similar (http://terapix.iap.fr/doc/OODBIX/index.htm)
for the terapix project (http://terapix.iap.fr/) sometimes ago,
but no UML schema is available online too.
The main objects concerning this part were : DBCat, DBCatEntry, Bulk and BulkDescr.
A DBCat contained a list of DBCatEntry which have specific data members/attributes
and undefined (from DB point of vue) series (vectors of diff. type) of data,
that's the bulk, one for each DBCatEntry, which are described once at the level
of the catalog by the bulkDescr, which give for each value in the vectors
the name, the meaning and the units (something-like an UCD).
Replacing Bulk by Prop our design became very similar, at least, at a high
level of description.

> - this model and API does not necesarily imply an SQL database; it can be 
> implemented using an SQL DB as the back-end storage (as we do) or it can be 
> implemented completely as an on-the-fly processing system that stores 
> nothing, or something in between... however, in am SQL implementation of the 
> back-end, most of the table structure is the same since it encodes the parts 
> made visible in the EntryProp class: essentially every EntryProp has a value, 
> error, and provenance associated with it, along with a unique identifier. 
> From one catalog to the next, the differences are in the EntryPropMap and 
> hence in the data types used for value and error within the EntryProp(s)
> 
I am very interrested by the provenance associated with an EntryProp.
Does it means that the processing history is handled at the level of
individual values for each entry independantly?
In my design, because I thought at that time, 
that catalogs are commonly updated by columns as a whole,
I forsee to implement the processing history handling at that level;
the data provenance would have been handled column by column.

> - these 4 types of catalogs seem quite fundamental so making the distinction 
> doesn't seem to be a logical problem; however, in one snese we distinguish 
> much less because we use the same basic model (ie. same code and same API) 
> for all catalogs and only vary the content: things common to "catalogs" are 
> in the code/api and things that vary between catalogs are content. 

Can you explicit what is in common, except the structure use to store the data?

> 
> ** As a complete non-astronomical aside, I also am in the process of using 
> this model to track and store my music collection in a "music catalog". I had 
> to decide on the set of properties a "music entry" has, create an instance of 
> the catalog, and fill it up. If I deployed it the right way, my music 
> collection would appear in the CVO web app and you could search for entries 
> in the  "pddMusic" Catalog and download the music files from the "pddMusic" 
> Archive :-)
> 
> cheers,
> 
> -- 
> Patrick Dowler
> Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045
> Canadian Astronomy Data Centre    | Centre canadien de donnees astronomiques
> National Research Council Canada  | Conseil national de recherches Canada
> Government of Canada                   | Gouvernement du Canada
> 5071 West Saanich Road                | 5071, chemin West Saanich
> Victoria, BC                                   | Victoria (C.-B.)
> 
>
I saw that you plan to come to the interopMeeting in cambridge.
Perhaps could we meet there and have a more precise and fruitfull discussion
than what is possible by mail?
Sincerely yours,
Pierre
DIDELON
-------------------------------------------------------------------------------
CEA SACLAY - Service d'Astrophysique  e-mail : pdidelon at cea.fr
91191 Gif-Sur-Yvette Cedex            Phone : 33 (1) 69 08 58 89
-------------------------------------------------------------------------------