[QUANTITY] Data Model for Quantity v0.5

[David Berry]

Alberto,
        Thanks for the comments on the Quantity stuff. Here are my initial
responses to some of your points (hopefully other will respond to those
I have missed).

> 0b.- Compatibility issue (context-related)
>     How do I know whether two quantities (fetched from different providers)
>     are "compatible"? Of course "compatibility" first needs a definition ...
>     In the document such problem is mentioned, but not addressed, and I
> think it is
>     a problem which has probably the highest priority, if we want to
> exchange quantities.
>
>     UCDs are referred to, but "compatibility" is a different matter;
> example:
>     I got two quantities, one is the isophotal diameter of a galaxy at
> the limiting
>     surface brightness of 25 Bmag/arcsec2 the other is the diameter but
> at a limiting
>     24Bmag/arcsec2. They have the same units, and, correct me if I'm
> wrong, the same UCD.
>     But they are incompatible. I cannot take the average of those two
> quantities,
>     'cause they physically mean something else.
>

My suggestion on this is to provide a range of sub-classes of the Frame
class described in the Quantity document (section 4.7). A Frame is
intended to provide a complete description of the nature of the values in
the Quantity. This includes an indication of what the values represent (a
UCD?) together with any extra information necessary to completely define
the specified system in which the values are measured. For a basic Frame,
this extra information will probably just consist of a statement of the
units in which the values are stored. However, sub-classes of Frame will
obviously be needed to describe other value systems which have more
complex requirements. So for instance we should have a sub-class of Frame
called SkyFrame for describing values which represent positions on the
sky. A SkyFrame would extend Frame by adding properties to hold the
equinox, epoch, reference system, etc. Likewise we could have a SpecFrame
to describe spectral position, with extra proprties for standard of rest,
rest frequency, etc. So for your specific example we could have a
sub-class of Frame which added a property to hold the limiting surface
brightness.

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.

Note, as it says in the document, two or more Frames can be joined
together to form a compound Frame. Thus a SkyFrame and a SpecFrame could
be compounded to form a Frame which could describe a spectral cube.


> 2.- UCDs are briefly mentioned here and there; UCDs and their relationship
>     with the Quantity DM probably require more attention, and deserve a
> full chapter.
>     Only then we will be able to identify flaws or unnecessary redundancy.

As I say above, my view is that the Frame class should contain a UCD which
describes the nature of the Quantity values. This UCD need only be a very
simple label since all the extra information needed to define the value
system are contained in other properties of the Frame class (or
sub-classes of the Frame class).

> 3.- When speaking of coordinate systems, what's the relationship with STC?

If you leave out regions, an STC document is directly equivalent to a
compound Frame - that is, an STC document (minus regions) describes a
coordinate system but does not encapsulate lists of specific axis values.
I see STC as a specific serialisation of a certain type of compound Frame.
We need software which can create such a Frame object from an STC document
and which can create an STC document from such a Frame object.

> 6.- In the example 2 on page 26 the Magnitudes are given without
> reference to a bandpass,
>     and its zeropoints. How would you see that done properly?

We presumably need a "MagnitudeFrame" (another sub-class of Frame) which
encapsulates all the information needed to define a magnitude system
precisely.

> 7.- In the various examples various units are given (eg, "km s^-1", etc.)
>     We should have a standard set of allowed units and a standard set of
> operators.
>     At CDS (or is it the standard SI?) a blank is not allowed,
> multiplication is a dot "."
>     exponent is just concatenated, etc.: the right spelling would be
> "km.s-1"
>     We have to have a common set of rules and names to interoperate.
> This should
>     be mentioned in the document.

FITS-WCS paper one (http://www.atnf.csiro.au/people/mcalabre/WCS/wcs.pdf)
also defines a syntax for describing units within simple strings. On the
specific issue of multiplication, FITS-WCS allows " ", "." or "*" to be
used.


David