content, format, ctype, or xtype ?

[Francois Ochsenbein]

Hi Alberto,

Just a precision about vizier (at the end of your message):
while coordinates in 'standard' frames are computed on the
fly, they are not actually stored (currently) in vizier.
I'm not a fan of adding gigabytes of computed data to gigabytes
of original data; and as far as celestial positions are concerned,
I would better promote a standardisation to a common reference frame 
rather than asking every data provider to understand, compute
and eventually store positions in galactic, ecliptic, icrf, fk4, 
etc etc...

--Francois

>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).
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================