content, format, ctype, or xtype ?

[Alberto Micol]

Arnold Rots wrote:
> 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.
>
>   
And we also store ecliptic coordinates, exactly because our solar system 
archive users
need to search in boxes which are time-drifting along the ecliptic 
("conversion of bounds is extremely nasty").

So, 3 types of coordinates: equatorial, galactic, and ecliptic, to 
satisfy all our communities.

Thanks Arnold,

Alberto

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


-- 
Alberto Micol
Telephone: +49 89 32006 261
Fax:       +49 89 32006 898
Virtual Observatory Standards Group Lead
Virtual Observatory Project Office
Data Management and Operations Division
European Southern Observatory