content, format, ctype, or xtype ?

[Patrick Dowler]

(replying only to dal list)

Thanks for this Francois!
On Wednesday 13 May 2009 09:16:15 Francois Ochsenbein wrote:
> Finally, from the VOTable point of view, the questions I would
> like to get a definitive answer to is:
>
> (a) Do we need a new attribute to specify an ISO-8601-formatted time ?
>     The possible answers are:
>     (a0) No, restrict the expression of time to JD or MJD or ... number

If there was some other way to know a column contained time values, one could 
restrict numeric (datatype="double") to MJD and string (datatype="char") to 
iso8601. That reduces the problem specifying it is a time enough that one of 
ucd, utype, and ref (to a PARAM or group) may suffice. See below...

>     (a1) Yes, a new attribute is required (which name ? which content?)
>     (a2) No, use a new datatype (equivalent to 'char' as far as the
>              data storage is concerned, with an arraysize reflecting
>              the accuracy, i.e. '19' for full date YYYY-MM-DDThh:mm:ss)

Would this mean, by extension, adding all the ADQL datatypes? Or all the STC 
datatypes? I think this would be a bad idea to conflate the low-level container 
and then data... in data modelling there is a fuzzy line between model 
elements (concepts) and data types and different people draw it in different 
places. Our problem here is that ADQL by necessity has datatypes for things 
that are model elements elsewhere :-)

>     (a3) No, use a utype related to the STC data model
>              (e.g. utype='stc:AstroCoords.Time.TimeInstant.ISOTime')

In the TAP discussion so far we have tried to avoid specifying/requiring usage 
of the utype attribute so that it is left to data providers to describe their 
content/model. That makes TAP directly usable with a variety of models. At the 
same time, we don't want to require generic applications that 
consume/manipulate VOTable to have to grok all the data models in use to figure 
out of a column is a timestamp.

Also, I refer back to a previous post where several people asked about 
multiple utypes: http://www.ivoa.net/forum/dal/0905/1196.htm

Unless someone can answer the multiple utype questions, I also do not think we 
can discount REGION as simply solvable by the utype mechanism either. 

>     (a4) No, use a UCD (e.g. ucd='time.iso8601'; could be secondary
>              e.g.  ucd='time.release;time.iso8601')
...

>     (a5) No, use a special unit (e.g. unit='"iso8601"')

The STC model already does this with energy: you tell the difference between 
wavelength, frequency, and energy by the units rather than a utype. I have 
implemented code that takes this approach... and I don't like it :-) 

On the other hand, FITS WCS has ctype values (paper 3) to specify exactly 
which "energy" type one means.

> (b) Except if (a0) is decided, how should the other field attributes
>     be filled:
>     -- which datatype: only char
>        (remember, VOTable may convey FITS or binary data...)
>     -- which units ? must be empty ?
>     -- ucd / utype ?
>     -- precision ?

It should be noted that TAP 0.42 page 19 specifies the mapping between VOTable 
and ADQL types. This mapping is needed so that users can know the column type 
of uploaded tables and use them correctly in queries. You have to know the 
column type to write the correct ADQL. The symmetry of output tables have the 
same mapping is 

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" ?

Specifically for upload to a TAP service, if the ucd attribute was missing, the 
service would put the timstamp values into a VARCHAR column instead of a 
TIMESTAMP column. Some things might still work. If someone replies that there 
is a suitable UCD fragment for position (pos?) and energy (?) then maybe we 
just have to spell this out (specifically, the table in TAP 0.42, page 19 would 
be changed from VOTable:format to VOTable:ucd and we would specify UCD 
fragments that signify the content).

PS-when I say ucd="time" I really mean the ucd attribute contains a "time" 
fragment. Can we make this precise enough?

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090513/4dafd98c/attachment-0003.html>