UTYPEs in VOTABLE for data models

[Jonathan McDowell]

Hi Doug, Roy, nvometa, and (I am extending this dicussion to:) dm at ivoa,

> It was asked:
> > > What is the API for UTYPE? What can I *do* with a UTYPE?

Aside for newcomers: UTYPE is the proposed tag to label data model
elements when a data model is serialized as a VOTABLE. I note that the
question of whether this is a good thing to do to a poor innocent
VOTABLE (or poor innocent data model, depending on your side of the
fence) is not the current subject for discussion.

> Doug Tody replied:
> Short answer: given an element which has only a UTYPE tag, and nothing else,
> you know exactly what it is, that is the interface to which it belongs
> (protocol, data model, etc.), and the specific parameter or attribute of
> that interface.

I disagree slightly.

That's not the same as 'know exactly what it is'. I think you mean
'know exactly how to process it'. If you mean this literally, UCD would
be completely redundant. In fact, I argued (in an offlist email)
that UCD and UTYPE are largely orthogonal. To amplify your comment:

  given an element which has only a UTYPE tag, and nothing else,
  you know the interface to which it belongs
  (protocol, data model, etc.), and the specific parameter or attribute of
  that interface.
  
  BUT

  you do not necessarily know what physics it represents - that is the
  job of the UCD. I believe there will be instances which
  have identical UTYPE but different UCD. 

The example I've given in the past is that of the observable in
a spectrum - a data model for a spectrum would have elements
pointing to the pieces of the spectrum, but a spectrum whose
observable was flux density and another whose observable was
surface brightness might have exactly the same data model.
They would be distinguished because the data model would
have a UTYPE element 'obs/data/ucd' saying 'Here is the UCD
which describes what the observable is', and the element's *value*
would be the UCD for either flux or surface brightness as
appropriate.

Now it's true that we may eventually have a sufficiently elaborate
data model that defines a class 'surface brightness
spectrum' and a class 'flux spectrum', both derived from
'general photon spectrum' and with very slightly different
methods allowed - a method to calculate the integrated
monochromatic source flux, for instance, would be mildly different
for surface brightness and for flux density - (although
to my personal taste that is an over-use of OO, I realize there
are people on the team who will want this)
- but in any serialization there is no need to distinguish the
two (two of N, N large) types of spectrum beyond saying
that the data structure is a `spectrum' and the particular
thing being spectrummed is `surface brightness'. This latter
piece of metadata is best serialized using the UCD paradigm,
it would be silly to have different UTYPEs for each of
   surface brightness spectrum
   flux spectrum
   flux axis on a graph
   surface brightness image
   surface brightness table column
   flux limit used to select this catalog
   bolometric luminosity limit used to select this catalog
   surface brightness limit used to select this catalog
   maximum-flux header keyword
   
there are two orthogonal questions being answered here:

1) Doug's question "what is it?" meaning "what role does this metadata
          play in this dataset?". This question is answered by UTYPE.

2) The Ortiz-Derriere question "what is it?" meaning "what physics
         does this metadata refer to?". This question is answered by UCD.

These are different questions, with N and M possible answers respectively,
best modelled by N+M dictionary entries of N UCDs and M UTYPES, 
and not by N*M dictionary entries of some meta-unified mistaken monstrosity.

(It may be that the N*M concepts generated by this product indeed
are best instantiated by N*M different software classes in the OO
world, although I remain dubious, but that's a different question again.)

I earlier circulated to Roy and Doug an attempt to map SIAP to UTYPEs,
which I'm going to send in the next message.

 - Jonathan