[QUANTITY] The discussion so far

[Ray Plante]

On Thu, 30 Oct 2003, Jonathan McDowell wrote:
> Here's my understanding of the issues so far, 

Thank you!

> What should Q be called? Is Quantity an OK name?

I agree with Gerard's point that we need to clarify what we're 
modeling--that is, *semantically* what are we talking about.  I think the 
general definition I gave before is a good starting point, but it will be 
refined when we decide what's included:

Here's what I think is a sensible cut:

   Quantity -- the description of the value itself
   Measurement -- a Quantity and its context: where in the measurement 
      space it corresponds to and its relationship to other concepts 
      (i.e. properties). 
   Image, Spectrum, Observation (?) -- examples of collections of 
      heterogeneous Measurements.  There may be one Measurement that is 
      primary (the "data") but other Measurements ("metadata") are needed 
      to properly process the primary one.

   Phenomenon -- I agree that this is separately modelable concept.

My interpretation of these semantics in terms of where the various 
attributes go:
   Quantity: 
      the phenomenon name
      the (numeric) value
      the unit
      the error:  with the perspective of an error describes a probability 
          distribution for the true value.  
   Measurement:
      WCS
      quality

Given this cut, a Position, for example, would be a type of Measurement.

You could put the WCS and quality as optional bits of Quantity; however, 
that changes the semantics.  You would need to adjust the definitions 
above accordingly. 

> Is the name of the (phenomenon, variable, etc) part of Q?
>  McDowell: I would like to see a name as part of Q - then scalar Qs
>   can serialize as a FITS keyword.

It's probably a good idea; however, in practice, I expect that we won't be 
handling generic Quantity objects, but specialized versions (e.g. 
Frequency) in which the name is locked in.

> Does Q support arrays? Multi-dim arrays?

In short, I say yes; however, I think arrays (of any D) only make sense if 
the values are fully homogeneous--i.e. same unit, same error model.  
Otherwise Q becomes much more complicated.  It would be easier to create 
an aggregation of Qs to handle the individual tagging of components.  

This constrains vector quantities to cartesian coordinates; in 
polar coordinates, the units are not uniform.  

Note however, I would not put strong emphasis on any requirement intended 
to support hold large arrays in a quantity (e.g. image data).  When we get 
to moving these things around (through function calls or across the 
internet), storage efficiency issues become important.  In practice, I 
expect we will use Quantity components to "tag" data stored in various 
containers (FITS, VOTable, etc.).  

> Does Q support complex types?
>  McDowell: suggest we not rule this out, but an initial implementation  
>    would only support basic datatypes.

Agreed.

> Should Measurement inherit from Q vs use it as e.g. aggregation?
>  (Thomas yes, inherit?)
>  (Didelon no, aggregate)
>  (McDowell no, aggregate)
>  (Lemson no, "uses")
(Plante no, aggregate)

> Should Q support string values?
>  (Thomas, Oct 25 0845, yes)
>  (Plante, Oct 29, no)
>  (McDowell, strongly yes)

I agree with Gerard that string values should be handled as a 
"Classification".   To be convinced otherwise, I need an example of string 
type that semantically supports the concept of an Error.  (It probably 
needs to pass some mathematical muster as well: can you multiply and 
divide with it?)

> Should Q also be used for metadata?

In my mind, This is the primary use for the data model.  As I've said 
before, "data" may use some other storage mechanism.  

cheers,
Ray