Comments on Canadian VO data model

[Patrick Dowler]

On April 24, 2003 01:48, DIDELON Pierre wrote:
> About the documentation of Canadian VO Data Model - Pierre Didelon
>
> > From: Jonathan McDowell <jcm at head-cfa.cfa.harvard.edu>
> > Date: Tue, 22 Apr 2003 13:40:10 -0400 (EDT)
> > To: dm at ivoa.net
> > Subject: Comments on Canadian VO data model
> >
> >
> > Canadian VO Data Model Comments     - Jonathan McDowell
> > -------------------------------
> >
> > The Canadian VO have published details of the data model used to
> > describe images in their archive.
> > The relevant documents are at
> > http://services.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/doc/cvo/
>
> There is a lack of an UML model (even a crude one, box & lines)
> to clarify the general design of the model and
> the top level objects/tables concerned.

True. I will try to rectify that sometime soon.

> 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)

- 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)

- 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. 

** 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.)