Quantity-based catalog model (Was: Re: Source Catalogue DM)

Jesus J. Salgado Jesus.Salgado at sciops.esa.int
Thu Sep 15 09:19:46 PDT 2005


Dear All,

Neither Pedro nor Matteo are here until next Monday, but I would like to
give my opinion about Anita's (only the preliminary ones) and Ed's
comments.

Even when I agree some of the fields are too 'fine grained', the idea of
the data model sent (in this case, a "Source data model" more than the
total "Source Catalog data model" as we talked months ago) is, in my
opinion, to identify the items that could describe a "Source", e.g., to 
have a concrete representation of the data. Of course, which ones (and
which not) are these fields is something to be decided, and your inputs
will help a lot to improve the model.

In the case of the Source catalog data model presented by Brian and Ed,
the "source" object is only (basically) a list of quantities. Of course,
this is quite flexible as most of the catalogs are presented as tables
and a quantity can describe without problems a field in a table (among
other things). 

However, it does not solve the question of what do you need to describe
a Source (it only leaves a placeholder to add all the properties that
the source could have, but without trying to define them). I think we
need something more detailed if we want to use this data model as a base
to inter-operate in the future.

On the other hand, Brian and Ed are doing a good work trying to identify
the links from the general Source data model to other data models
(Publications, Provenance,.. etc).

As Pedro presented in Poona:
http://www.ivoa.net/internal/IVOA/IVAODMCatalogsWP/Poona_2004_Catalogue_DM.pdf

(page 5)
possible links to provenance, curator, registry or other VO data models
are needed and there were some placeholders for those kind of
connections to be identified.

In the same graph (in the image inside red circles), four different
items were identified as "complex": the catalog general model (it
depends it you want to allow recursive references) (it was finally
decided to start with a not recursive model), "Astronomical Event",
"Astronomical Object" and, finally, "Source". As the catalog data model
was, more or less, restricted to be, at the end, a source catalog data
model, it was important to start finding a model for this last item.
 

Best Regards,
Jesus Salgado

On Thu, 2005-09-15 at 16:09, Brian Thomas wrote:
> 	Anita, All,
> 
> On Thursday 15 September 2005 07:45 am, Anita Richards wrote:
> > I appreciate the way that the model was drawn up with reference to some 
> > real source catalogues.  However, I think  that some of the fields 
> > suggested are too 'fine grained'.  I note these below.  Maybe that means 
> > that there is a need for a heirachical model with generic properties at 
> > the top level and more domain-specific properties in optional plug-ins. 
> 
> 	I agree completely. I (and Ed) have been working on a model which allows
> 	adoption of the format desired by (prior) proposal, but is expandable/
> 	changeable to meet other needs, in particular all the various catalogs
> 	which we have at our site (> 4000) which don't neatly fall into 
> 	the prior design.
> 
> 	Towards this end, I have put together a model which contains a
> 	number of components, and utilizes the Quantity to represent the 
> 	various fields in the catalog, and works well (so far) to represent 
> 	the contents of over a 100 catalogs from the CDS/ADC archive. I plan 
> 	to present this work at the ADASS/IVOA meetings this coming October. 
> 
> 	Some early documents, examples and schema (some which are now out of 
> 	date, but do a fair job of representing the scope of the work) may be 
> 	found at the following link:
> 
> 	http://archive.astro.umd.edu/VOCatalog
>  
> > 
> > What sruck me was that I imagined that the model was 'source-centred' - 
> > i.e. it should aim to provide information about an astronomical detection 
> > _or_ a generic model object - but it should not duplicate the role of the 
> > Observation and other DMs.
> 
> 	Well, the catalog model should adopt structures which are components
> 	of the other models. For starters, I believe that proper catalogs need the 
> 	'characterization', 'publication/reference', 'history/provenance' components.
> 	The model which Ed and I have been designing does just this.
> 
> 	=brian
-- 
Jesus J. Salgado


ESAC Science Archive Team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Science Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN



More information about the dm-catalog mailing list