[QUANTITY] Data Model for Quantity v0.5

[David Berry]

Alberto,

> I might very well be completly wrong, but all the following sentences
> (sorry David to quote you here, but this shows quite well the point):
>
> > My suggestion on this is to provide a range of sub-classes of the
> > Frame class
>
> >Having all the extra information within sub-classes of the Frame class,
> >allows us to create utility software which will take any two Frames
> >and determine if it is possible to transform values from one Frame to the
> >other, returning a Mapping to do so if possible.
> >
> >
> >We presumably need a "MagnitudeFrame" (another sub-class of Frame)
> >
>
> makes me think that
>
> 1) it will take very long to come up with a full set of standard sub-classes

Probably true, but to do just the common ones may not take so long. A
large amount of the work of defining what is needed has already been
done by things such as Arnold Rots STC schema. But however we tackle the
job, the amount of work remains much the same - we need to decide on a
prioritised list of the coordinate systems and the data value systems
which the VO is interested in, and then decide what extra information is
needed to define each of those systems. This is work which has got
to be done no matter what Quantity model we adopt. Having done this, there
should be little extra effort involved in defining a collection of Frame
sub-classes to describe these systems. And if the list is prioritised we
can get the most important ones done quickly.

> 2) only very sophisticated software will be able to understand what is what

I suspect the document may make it sound more complicated to a new reader
than it really is. The most complicated parts are probably not the most
essential, and could be left to later. For instance, from experience I
know that creating an algorithm which, given two arbitrary Frames of any
sub-class, can determine the Mapping between them (if any) is certainly
quite complicated but can be done (Starlink have had a working implementation
of this algorithm for several years). The simplification of complex
Mappings is another hard algorithm, but more advanced algorithms such
as these would probably not be needed for an initial implementation.

> 3) it would be impossible to describe the columns of a catalog in a
> simple VOTable

Why? What we are suggesting here is a data model, not a data format
(although I suppose you could see the suggested XML serialisation as a
data format). I see no problem with modelling a column in a table as
a list of values together with meta-data describing the context of those
values. This seems to me to be consistent with the model of a CoreQuantity.
The question of how you translate between a VOTable column and an
in-memory CoreQuantity just depends on how the context metadata is stored
in the VOTable. If the VOTable community want to "plug in" to the DM
work, then one way would be to store a direct serialisation of one or more
suitable Frames in the VOTable. Alternatively, if VOTable develops its own
way of storing the metadata, then so long as the data is complete and is
stored uniformly, then it should be possible to create a CoreQuantity from
the VOTable description.

> I understand that sophistication allows complete description of the
> thing to be described,
> on the other hand semplicity allows fast development, and fosters
> usability by the other
> working groups.
>
> Shouldn't we first concentrate on the latter?

I agree, but it is a case of making sure that you do not "paint yourself
into a corner". The ideal goal is to provide a simple model which meets
the immediate needs, but which allows properly for future extension in a
consistent way. If we do not think now about the broader picture, about
what the likely needs for future extension are going to be, then we could
end up with a system which meets the immediate needs but which can only be
extended (if at all) by bolting unwieldy ad-hoc conventions on to it (I
think we have allseen this happen before!). I'm certainly not saying that
the current Quantity doc has got this exactly right, but it does at least
make us think about future needs for things like automatic matching of
coordinate systems and data value systems, etc.



David
















----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX                                Tel. 01772 893733
                                             01257 273192