content, format, ctype, or xtype ?

Wed May 13 12:11:25 PDT 2009

Francois Ochsenbein wrote:
> 
> Well, I feel it's important to summarize what we are talking about
> and try to reach a consensus, if possible... Sorry for the length
> of this message, but I hope it will help to take a final decision
> 
> This discussion which involves DAL (TAP) and VOTable groups started
> essentially because a requirement to deal with time and STC-regions
> was raised in TAP. The question then is: how to characterize as 
> "time" and "STC-regions" these entities in a VOTable ? Can these 
> be accomodated by the existing VOTable FIELD attributes or do we 
> need yet another attribute for this ?
> 
> Let me summarize the various attributes currently existing which
> characterize the columns in VOTable:
> 
> -- datatype : integer / float / char / boolean
>               represents the hardware storage 

Life would be easier if we also had DATETIME, in ISO-8601 format.

> 
> -- unit :     examples are:  deg  arcsec/yr km/s  AU ...
>               (specifies also the physical dimension)
> 
> -- ucd :      examples are  pos.eq.ra  pos.pm;pos.eq.ra
>               (specifies semantics with a restricted controlled vocabulary)
> 
> -- utype :    example "stc:AstroCoords.Position2D.Value2.C1"
>               (specifies the exact parameter role in a data model)
> 
> -- width :    number of characters required for the String edition of value
>               (e.g. '3' for an integer implies a value between -99 and 999)
> 
> -- precision: number of decimals or significant digits
>               (e.g. 'F2' for a representation with 2 decimals)
> 
> Norman's terms could be mapped into
> 'value space'    --> datatype (all possible representations of a value 
>                      which can be stored in our computers)
> 'lexical space'  --> width + precision (the String representation of
>                      the value) + unit
> 
> I would like to add that, from a physicist's point of view, the 
> 'frame' or 'system' in which the value is expressed is also
> fundamental (e.g. a velocity in a frame tied to Earth can't be
> compared directly with a heliocentric velocity); this latter 
> knowledge is covered essentially by the 'utype' attribute.
> 
> Now the question about the 2 entities required by TAP
> (notice they both refer to space/time):
> 
> 1. STC-string characterising regions:
>    -- is obviously of datatype = string (= array of char's)
>    -- is an expression born in STC data model, and therefore
>       is clearly related to a data model
>    ==> therefore would logically be described by a utype
>        (as pointed out several times)
> 
> 2. Time is more tricky: 

Note, btw, that Time can also be expressed in a STC-S string.

>    -- there is no "time" datatype (from the database point of view,
>       there is no unique way of storing a time)
>    -- units could be, as already pointed out, seconds, days, weeks,
>       years, ... all these represent a time (and, as Alberto pointed
>       out, why do we require sexagesimal here when we agreed to
>       remove it from angular quantities ?)

Because ISO-8601 is a representation that contains annual and seasonal
information that is important for certain data.

>    -- ISO-8601, as already pointed out, is not a unit, not a datatype,
>       and even not a system (from the database point of view, the
>       TIMESTAMP represents local time, and TIMESTAMPs from different
>       databases can't be compared directly)

ISO-8601 is a format to express a DATETIME data type (or a TTIMESTAMP
data type, as some call it). I though we had agreed that these would
only be expressed in the limited number of time scales allowed by STC.
So, local time zones do not come into play.

> 
> Therefore the new attribute ('ctype' or 'xtype' or ..?) would
> essentially be added only to specify 'this string is a time
> expressed in ISO-8601'. Clearly this would help for e.g.
> interpreting this string as a number to be used along the
> x-axis of a plot (a nice topcat plot :-) but does not solve
> all the other problems (which time, how to compare times delivered 
> from different databases, ...)
> 
> 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
>     (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)

That would be my preferred solution: "datetime".
But the array size may be shorter or longer (see below under precision).

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

This may be the next best solution; however, it would be nice to be
able to tie it to a time scale...

>     (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"')

This is the worst possible kludge. Introducing non-unit values in unit
attributes opens the door for all kinds of ad-hoc measures that will
totally wreck the whole system.

There is one more option:
      (a6) No, use an STC-S string: "Time TT GEOCENTER 2009-05-13T19:09:30"
      	   or: "Time TT GEOCENTER MJD 54964.798264"

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

ISO-8601 has no units (obvisouly); however, associated errors,
resolutions, etc., will.
For JD and MJD it's obviously 'd'.
The precision of ISO-8601 depends on the number of digits:
    CCYY-MM-DD[Thh[:mm[:ss[.sss...]]]]

> 
> Should we envisage a vote to achieve a final decision ?
> 
> --Francois
> =======================================================================
> 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
> =======================================================================
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------