[QUANTITY] Requirements and apology

[Doug Tody]

Dave -

If we are talking about data values, WCS, data quality, etc., then we
are modeling an entire dataset, not a quantity.  We need to address both
issues but they are at opposite ends of the spectrum.  Quantity needs
to be a low level concept (about the same level as a UCD) or it is being
confused with something else.

	- Doug


> 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.