[QUANTITY] Data Model for Quantity v0.5

[David Berry]

Pierre,

> > I think we are not starting from nothing, or anywhere near nothing. There
> > are already developed systems in regular use around the world which are
> > similar to the proposed Quantity model. It must surely make sense to
>
> What are the premiss or forerunner in the astronomy field?
> did some generic/general standard available for this purpose,
> can VO adopts and use them for interoperability?

I was thinking of the Starlink AST library, although Brian, Jonathan and
Pat could probably quote other systems. AST uses Mappings and Frames in a
way which is very similar to the Quantity model. AST has been in regular
use for several years, but has hitherto only been used for describing
coordinate systems and their inter-relationships. I gave a presentation
on its use for this purpose at the IVOA interop meeting last May at
Cambridge (see http://www.starlink.ac.uk/~dsb/ast/IVOA_WCS_talk.html).
One of the new ideas (for me) in the Quantity document is that a similar
system can also be used to describe the Quantity values themselves, not
just their coordinate systems. That is, just as a position in a data array
can be described using several different coordinate systems, so the data
values in the array could potentially also be described in several
different systems (different calibrations, different flux systems, etc).
AST has proved to be particular good at automatic recognition and
transformation of coordinate systems, and the same approach could be
also be used for data values.

The current Quantity model though goes beyond AST in that it also deals
with the storage of bulk data. In Starlink we decided to split off the
storage of bulk data from the description of the coordinate systems
associated with that data. The later is done by AST and the former by
HDX and NDX (Starlink systems for associated data, error and quality
arrays with extra meta-data, also presented at Cambridge - see
http://www.astro.gla.ac.uk/users/norman/note/2003/hdx-overview/ ). But in
the current Quantity model these functions are all wrapped up together
into a single model.

So speaking from the Starlink point of view, the current Quantity model
looks very similar (excluding its serialisations) to what we have been
using for some years within our application software. Obviously, there
have been many other strong influences on the current Quantity model,
some significantly different to the Starlink approach, mainly from
the groups at GSFC (Brian and Ed), and at the Hardvard-Smithsonian CfA
(Jonathan and Mark), with additional words of wisdom from Pat.

The point is, whilst not being so common as (say) FITS, there *is*
astronomical software out there which uses ideas similar to the current
Quantity model.

> IMHO one major goal of Quantity would be to procure support
> for this kind of problematic : ability to transmit simple parameters
> sufficiently described (inside the VO frame).

We intended that the BasicQuantity would satisfy this particular
requirement.

> It is why I feel that XML serialization is the most important
> part of Quantity.

I think of serialisations as defining data formats, not data models (which
I think are more to do with programming interfaces). A given data model
can in principle be serialised in many different ways.

> The actual Quantity even if quite reasonnable in comparaison
> of some previous ideas on the list, seems to me really complicate
> for very simple parameter exchange. The most simple qantity (ex. p25)
> as the flavor of a degradated PARAM structure existing in VOTable!

The idea of the BasicQuantity was that it could be as simple as you wanted
it to be. Maybe the example serialisation doesn't really show this. Can
you give us an complete example of what you would want from such a basic
Quantity? That is, what information would you expect such a Quantity to
contain in addition to the actual value? Then we can see how your
requirement may be met by the proposals in the current doc.


> Complete description of whatever astronomical data is not in the scope
> of Quantity but preferably in Observation global view.

I agree. The Quantity is meant to be a general purpose "bucket" into which
you can put one or more samples of any arbitrary phenomenon, together
with *optional* extra meta-data which allows you to express the position
and value of those samples in a range of systems. [There are other things
too like optional errors and optional quality, but they are not the focus
of the current document.] These Quantity buckets are intended to be used
like building bricks by higher levels models such as Observation. It is
these higher level models which define the relationships between the
various Quantities.

> For tabular data VOTable exists, and it can be used for vectors
> eventually if needed, and complete metadata is then available in there.
> So the most evident "ecological territory" available for quantity
> seems to be very restricted to "simple described parameters".
> It is only my opinion obviously, share perhaps by few persons
> and eventually by nobody.

But would you not agree that VOTable is a data *format*, not a data model?
At the moment, the Quantity document contains a suggestion for an "initial
cut" serialisation. There will no doubt be other additional serialisations
of the Quantity data model. For instance, I think it is obvious that we
need to see a FITS image as another valid serialisation of the Quantity
model. Another valid way to serialise a Quntity could be as one or
more columns in a VOTable. There could be others.

The point of a data *model* is that it provides a single common structure
into which a disparate collection of external data *formats* can be
mapped, so that they can all be handled uniformly. The only thing which is
"special" about the suggested data format in section 7 of the document
is that it has been specifically designed to map exactly on to the data
model, and so is guaranteed to be loss-less.

May be what we need now are some genuine test cases which we can attempt
to cast into the proposed Quantity model. After this I think we will all
be in a better position to assess the current proposal and see where it
may need to be changed.

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