UTYPEs in VOTABLE for data models

[Alberto Micol]

Jonathan McDowell wrote: 

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


I tried hard to agree with everbody ;-) but I failed :-)

The more I look into Jonathan's proposal for SIA UTYPEs
the more I see that, given a UTYPE not only you know "almost" exactly
what it is, but also how to process it. We can easily get rid of the 
"almost"
by simply adding the units of the UTYPE without the need to invoke a UCD.

In fact:

>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.
>
the units are enough to resolve the ambiguity between surface brightness 
and flux density.

Maybe the problem is in the fact that almost all the UCDs/UTYPEs needed 
for SIAP
are more of the "engineering" type (wcs, cdmatrix, naxes, etc) than 
"scientific".

To me,

UCD = wcs.ctype
and
UTYPE = /obs/data/axes/wcs/type

are completely identical and not at all orthogonal.
With the difference that the UTYPE tells it's a wcs.type of an 
observation as opposed
to a wcs.type of a simulation (/sim/data/axes/wcs/type).

When we go to more "astrophysical" UCDs then we do not have UTYPEs
available (yet?). For example that fact that a quantity is a volume can 
be said
by setting the UCD to be PHYS_VOLUME; unless we get the Quantity data model
to describe what a volume is and in which context, we do not have a 
utype for that.

More than being orthogonal, I would say that (let's see how provocative 
this sounds):

(UTYPEs + units) carry more info (a superset of) than just their 
respective (UCDs + units)
but we do not have all UTYPES we need, hence we still use UCDs for all 
other cases ...

Alberto
PS: At least I think I do agree with Doug! :-)