content, format, ctype, or xtype ?

[Arnold Rots]

I would definitely argue that, while you are at it, the list of
"standard columns" should include both decimal (RA,Dec) AND Galactic
(l,b).

Although a minority of users (but a significant minority) searches in
l,b the conversion of bounds is extremely nasty, while the addition of
the two extra columns is trivial.

  - Arnold


Douglas Tody wrote:
> Hi Alberto -
> 
> Yes, this is exactly the issue I was alluding to.  The creators of
> these tables often go to a lot of trouble to get them just the way they
> are, and the community is used to seeing the data that way.  Plus one
> would like to have table presentation automated and straightforward.
> These considerations lead one to trying to change the table as little
> as possible.
> 
> In the past here we have usually dealt with this by adding additional,
> more standard columns for key items such as RA, DEC in standard units.
> Evidently Vizier does the same.  Perhaps something along these lines
> is the solution: if we have metadata such as the ID main or primary
> RA, DEC (used by default for spatial searching) these could have
> standard UCDs and units and probably be indexed.  There are only a
> few of these needed, as you say.  When it comes to arbitrary table
> columns and the complexities of reference frames I do not think we
> want to change the external data.
> 
> I agree that some standards or recommendations along these lines would
> be a good thing to have.
> 
>  	- Doug
> 
> 
> On Thu, 14 May 2009, Alberto Micol wrote:
> 
> >> 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).
> >
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------