[CATALOGUE]Starting Data Model Subgroup - reinventing modelling

Martin Hill mchill at dial.pipex.com
Tue Aug 3 01:44:24 PDT 2004


Ed Shaya wrote:

> Pedro Osuna wrote:
>> For example, the XMM-Newton "1XMM" is a list of serendipitous sources
>> detected by the satellite in its observing campaign. The model for this
>> catalogue could consist of things like the provenance (ESA), number of
>> columns (400) number of rows (~32000), etc., or it might give more
>> relevant information like: column number three in the catalogue is the
>> Source.likelihood where likelihood is an attribute of the Source Data
>> Model.
>> I think this is an interesting point for discussion.....
>>
>>  
>>
> A catalog should be a list of sourceObjects which 
> holds/contains/aggregates  Quantities.  The quantities should be allowed 
> to be of arbitrary depth and detail.  That is, one should be free to 
> enter QuntitySets of QuantitySets.   

I'm happy with the next bit, which is a prose description of some of the things 
that Ed would like to see in the catalogue data model.  Bearing in mind my 
previous email though, our models can be relational rather than restricted to 
trees, so our catalogues might not be just a set of things that might be sets of 
other things.

However the above bit seems to complicate what should be straightforward; we 
already have a system for modelling 'things' that are aggregates of other 
'things' - they are 'Objects' in UML.  Let's model those things first, *then* 
see if there are common elements we can factor out to 'QuantitySets'.  Doing it 
the other way around is Bad Practice (as I have mentioned before) and adds an 
unnecessary layer of IVO-specific terms to what should be a straightforward 
exercise.

Let's hear more about what people need to know, and also about what people don't 
want to know.  For example, it seems some people don't care about Passband 
details for most cases; they just need a simple Fravergy error band on a flux 
measurement.  This implies we may need more than one way of modelling similar 
information.

Cheers,

Martin

> To make this more concrete, lets 
> talk about a general catalog of galaxies. We wish to provide at a 
> minimum basic data about each galaxy (ie. simple quantities: magnitudes, 
> ra, dec, morphological class).  Also, one wants the Observations of each 
> galaxy, such as Image.  We may just want to hold crucial metadata about 
> each image (exposure time, ra,dec, filter) and perhaps a URL to the 
> actual data.  But we may want to group these images into various 
> regions. So we have /galaxy/region/observation/image so far.  Region may 
> specify not just the location on the celestial sphere, but  also give 
> information on the type of region (spiral arm, interarm, open cluster 
> region, outerhalo, etc). There may be photometry catalogs created from 
> these images that are to be included.  These catalogs should have 
> starObjects with mags with errors and filter info, and location pointers 
> to pixel coordinates in the image.  Some of the photometryCatalogs are 
> the children of  images but some may be concatention of several tables 
> within a region.  That would be a child of the region.  Also in the 
> region may be some higher resolution images in a crowded region 
> (/galaxy/region/region/observation/photoCatalog).    We may want to 
> point out variable stars, supernovae, etc so one has special subCatalogs 
> of these.   There may be reasons for others to attach additional info 
> about  the variable stars since they may be messing up the TRGB 
> distances.  Finally there are outputs of the tip edge detectors and 
> their input paramters as well.
> 
> 

-- 
Martin Hill
www.mchill.net
+44 7901 55 24 66




More information about the dm mailing list