Little data models

martin hill mchill at dial.pipex.com
Thu Oct 16 06:44:44 PDT 2003


I (and some other AstroGrid folks) need to start extracting and comparing data
models in the *next fortnight* (and that's only because I'm on holiday next
week); not in the next few months.  So I admit to being disappointed that
neither the data modelling group nor the UCD group can help me do this!

So I need to start, but I would like to do so in the context of the VO.  So I
would like to propose a variation on Brian's procedure.  Because while I'm sure
he's a nice bloke, and I do know his name, and don't disagree with *everything*
he says, I do believe his roadmap started wrong, and went wronger...  I really
don't think we will agree any abstract models for a long long time given the 
Quantity discussion, and I also don't think the 'level' concept is right...

First, let us assume that we all know what we are individually doing - we all
know how our data is structured within our own disciplines/areas of expertise. 
This is what Brian called our own namespace, and already exists.  What I (as an
implementer) want from you experts is some specific models, so that I can use
them when comparing data from different disciplines. In Brianspeak, we want to
move models from individual namespaces to the VO space so I can use them
(because as a non-astronomer, I don't have any in mine).

Remember that there are two 'depths' to building models.  We must not confuse
'ownership' with 'generalisation'.  An example general -> special:

Quantity -> Brightness -> Flux
                       -> Magnitude -> Johnson/Vega
                                    -> Wierderer
         -> Coordinate -> WCS
                       -> Solar
                       -> Galaxy
         -> Passband   -> Standard (eg K)
                       -> Shaped
                       -> Point

Trying to agree the general is very hard as we (in this case) have to think
about how all the specifics might be defined.  

The second 'depth' is the assembly of compound components, for example:

Spectral Energy Distribution 
     |
     |--- Coordinate
     |
     |--- Brightness
             |--- Value 
             |--- Passband

I suggest that we concentrate on the oft-used specialised 'leaves' at the
moment, as these are what we will use in practice, and see what the common
denominators are later.  We will be able to agree much more quickly on how to
describe a point World Co-ordinate than a co-ordinate.  Especially if we start
with a simple one and allow ourselves to extend it later by adding components -
for example, we might start with a simple +/- error, and worry about other error
types later.

I also suggest that we separate out common reference data.  For example, we
might have a WorldCoordinateFrame *instance* which includes equinox, perhaps
epoch for groups of observations, perhaps similarly error (depending on the
situation) - and then all coordinate instances refer to that frame instance. 
Similarly a Passband model which is referred to from brightnesses.

And finally we must either associate a UCD (or set of UCDs) with each of our
tags or allow them to be inserted - I haven't seen anything about this yet!

My first proposed data model will be for World Coordinates as this is my
immediate urgent requirement.  I have seen hints that such a model exists but I
can't find it, so if it does, let me know where it is!

The second will be for brightness which is my next most urgent...


-- 
Martin Hill
07901 55 24 66
www.mchill.net



More information about the dm mailing list