[QUANTITY] Pulling it all together

[Ray Plante]

On Thu, 22 May 2003, DIDELON Pierre wrote:
> just few comments which, I hope, are relevant and not too redundant.

Thanks!  These will help us focus the discussion.

> >   3.  Quantity as a Building Block

> I like the groups as mentionned by Roy.
> An argument of re-usability would be to try to re-use
> general element of VOTable which fullfill our needs,
> as for axample <PARAM><INFO><GROUP>...
> Is this unrealistic, not politically correct,
> or only relevant for the next step... implementation?

This is an interesting comment with many angles on it.  I'm going to try 
my hand at a few of them...

  *  I think it's interesting to recognize the common attributes.  My 
     next question is, is there a conceptual difference between what
     we mean as a "parameter" and what we mean as a "quantity"?  

     For the unfamiliar (see http://www.us-vo.org/VOTable/VOTable-1-0.htm):

              |--- COOSYS  |--- DESCRIPTION   |--- MIN
      PARAM --|            |                  |
              |------------|--- VALUES -------|--- MAX
                           |                  |
                           |--- LINK          |--- OPTION --- OPTION*

      PARAM attributes: ID, name, unit, datatype, ucd, value,
			precision, width, ref, arraysize

  *  One might argue that PARAM is a generic container, not a data
     model.  One could say that of my "Quantity", too; however, the
     intention was to "sub-class" this to define things like Flux and
     Frequency that carry more semantic meaning.  Perhaps if PARAM's
     basic model is sufficient, it could be used as a base class
     instead.  The main thing is that our model is first an abstract
     description of something and the relationships between its
     components. 

  *  Although we want our data models to imply an XML schema that
     could be used to hold things like quantities, it is not the only
     way.  VOTable is a good example as we could use GROUPS and PARAMS
     to hold the information.  What the data model tells us is what
     information needs to be included to fully describe the concept.  

> Concerning the reference frame, it is quiet obvious that sometimes,
> when basic default assumption are not straighforward, this information is
> crucial. As UCD try to catch the essential meaning of data (semantic?)
> to be able to handle it, some of them are certainly related to this subject
> (of Coor.ref.frame). Does somebody have an idea about it, and give some 
> insight of what is available? It is not clear to me, it exists certainly,
> but it is perhaps burry inside the UCD complexity (and fixed name).
> May be the refurbishing of UCD will clarify that with some
> common suffix and/or prefix or grouping protocol?

I think it's hard to fully understand the relationship between data
models and UCDs until we have some actual, usable data models in
hand.  In my own mind, I do not think that we should define the model
in terms of UCDs, partly because of the data model is fundementally 
different approach to capture these concepts.  More practically though, it 
would mean that the data model is not self-contained: one must 
"de-reference" the UCD to extract meaning.  

Nevertheless, there are at least two critical connections to UCDs that we 
must consider:
   *  the data model must identify which UCD a component corresponds to 
      where such a correspondence exists.
   *  the UCDs represent necessary concepts describing data; a data model 
      for particular topic area must have components that cover all of the 
      related UCD concepts. 

> Concerning error, I feel that it is, after the "value", the second parameter
> of great importance when working with data. 
> ...
> The question is; are data without error realy useful? for what?

If we look at the current practice, e.g. catalogs quoting quantities, we 
have lots of data without errors.  I think we can argue that the data is 
still useful, albeit in a limited way.  Also some errors are more 
important than others.  If we take the photometry measurement, the error 
on the actual flux value is more important (in practice) than an error on 
the frequency that the measurement was taken at.  In fact, it's rare that 
one would explicitly state the latter.  

> >   5.  Scalars and Vectors.  
> > 
> how did you forsee vector def. length+elems, elems+terminator or both?

either/both.  I think the latter represents the minimum information; 
however, being able to specify the length explicitly might be useful for 
refering to a quantitifiable concept (e.g. magnetic field) in the absence 
of an actual value.  

cheers,
Ray