content, format, ctype, or xtype ?

[Alberto Micol]

> On 13 May 2009, at 21:37, Doug Tody wrote:
>
>     On Wed, 13 May 2009, Patrick Dowler wrote:
>
>     So.... UCD?
>
>     It looks like I object to everything but ucd: it allows one to say
>     "this is a
>     time". Maybe restriction is enough:
>
>     MJD: DOUBLE <->  datatype="double" ucd="time"
>     ISO8601: TIMESTAMP  <-> datatype="char" ucd="time"
>     STC-S: REGION or POINT <-> datatype="char" ucd="pos" ?
>
>
> While I agree with Alberto that in "strong" interfaces with formal
> parameters and data models we often want to constrain the units and
> representation, I question whether this is a good idea when we merely
> want to expose arbitrary external data (such as tables).  In this case
> it is probably best, as well as simplest, to make as few changes to the
> external data as possible.  Hence unless we are populating the fields
> of a well defined VO data model we should pass through whatever is
> in the external data table, and merely aim to describe it accurately.

That would mean that ALL clients would have to know how to 
interpret/translate/parse
ALL possible combination of units/ucds/utypes. I would not call this 
"best and simplest"
from a client point of view.

And if we consider the non negligeable fact, very well presented by 
Fabien Chereau at the
last Interop in Baltimore, that coding a client that can make sense of 
the different VOTables
returned by various data provides is a nightmare, then I think that the 
solution to expose
to the VO external data as they are, it is actually (from a pragmatic 
point of view)
a vo-stopper.
/* Fabien showed how Virgo handles SIA/SSA responses: a mixture of guesses
translated in complicated if/then/else playing with field names, ucds, 
utypes, and units
and most of the time even that fails.
*/


If, on the other hand, the server already implements the translation of 
a time field
internally stored as "number of seconds since 1-JAN-19xx", into the VO 
standard (e.g.) iso8601,
all clients will know what to expect, without having to take any 
assumption.
Only at the server side the correct knowledge to translate the internal 
values
to the VO standard might be available. A client instead might take wrong 
assumptions.

Notice that I am only asking to standardise units and representations, 
not reference frames,
and only for few well identified cases.

So far we have spoken of:

- angles (decimal degrees) [RA is an angle]
- timestamps/datetimes (iso8601?)

and I would add

- time intervals (like exptime, period; in seconds?),
- wavelengths (meters?),
- frequencies (Ghz?),
- energies (keV?).
- magnitudes (in mag, and not in eg dmag)

more?

It should not be a big deal to standardise those most used concepts. The 
rest untouched.

Alberto
I appreciate the problem of exposing the original data as they were 
expressed by the authors of a catalog.
That is indeed important, and I am even thinking whether we should pass 
the original
data untouched (as a display-string attribute?) along with the standard 
representation of it.
Again, we are only talking of few quantities here...
Vizier already took this kind of approach when it was decided that the 
original catalogs are stored
and served as they were conceived by the authors, but extra columns 
(e.g. RA,DEC FK5 J2000)
are computed, stored, and served to allow homogeneous access throughout 
the entire collection
(the MAIN ucd was invented, I think, for this).