[QUANTITY] Requirements and apology

[David Berry]

Ed,

> What I meant was that a list of atomic quantities (all of the same
> property) needs
> another list explaining why each number is different, eg. because it is
> the property of
> a different object or at a different position.  A list of atomic
> quantities always becomes
> a dependent variable in need of an independent variable.  Thus, an array
> quantity should include  Arguments that are quantities, or when the
> quantity is an independent
> variable, the Argument is a simple index.

I'll assume for the moment that Ray's message was meant to imply that a
Quantity could contain multiple values for the quantity, maybe in the form
of a 1D list or other structure. In this case, his model is very close to
the "model" I proposed yesterday (http://www.ivoa.net/forum/dm/0192.htm
etc). One difference is that Ray doesn't include a WCS component within
Quantity. I would maintain, with you, that if a Quantity can contain
multiple values, then you need some way of describing the significance of
the position of a value within the complete ensemble of values. This is
the purpose of the the WCS component I suggested. It contains a collection
of Frames which describe all the relevant coordinate systems (including
pixel coordinates, or some other system used for locating a particular
value within the ensemble), together with Mappings which describe how to
convert positions from one Frame to another. Like all the other
components, the WCS component would be optional (for instance an unordered
collection of values wouldn't need a WCS).

So I would say that, with the addition of an optional WCS component, Ray's
model could be a very usefull building block for higher level structures.

The other issue is that Ray's model doesn't include a QUALITY component.
The two options are 1) to put quality information "inside" the quantity as
I suggest, or 2) to put it "along-side" the Quantity (that is as another
component of the object which contains the Quantity). I think a useful
working principle for a Quantity would be that you should be able to
interpret and use it independantly of its parent structure. That is, if
you extract a Quantity from its parent structure you should still be
able to make use of it. This would argue in favour of putting the QUALITY
information *inside* the Quantity.

David