content, format, ctype, or xtype ?

Francois Ochsenbein francois at vizier.u-strasbg.fr
Thu May 14 15:05:07 PDT 2009


(sent to 2 discussions groups dal + votable, since it concerns
really both)

Thanks for the reactions about the VOTable/TAP connection;
it just happened that Mark and me were thinking more or less
simultaneously about enumerating the various possibilities
for a final decision. I try here to give below some kind of 
summary about the answers. Before just 2 comments about 

=> Ray's suggestion of adding "anyAttribute" (possibility of
   adding any extra attribute to FIELD): even though it's an
   appreciable flexibility, I'm really afraid that would go
   against our goal of interoperability

=> Steve's remarks about time definition and leap seconds: 
   personnally I would applaude if we would reach a consensus
   about a SINGLE recommendation of time scale across the IVOA,
   even if the recommendation would be to use something as 
   strange as the number of seconds elapsed since a starting 
   date (e.g. UTC 2000-01-01T12:00:00.0000 = JD2451545.000000000): 
   at least we would be able (theoretically) to compare timestamps
   unambiguously. The connection with database TIMESTAMP would not
   be so complex, since SQL includes functions to convert a
   timestamp into a number of seconds elapsed since some reference
   date/time (which might be just the interval defined as a 
   difference of TIMESTAMPs).

   
Short summary of options:
-------------------------

(a) Date-time, timestamp, ...
    (a0) Restrict the expression of time to JD or MJD or ... number
    (a1) Create a new attribute (which name ? which content?)
         =M2 (Mark's option#2)
    (a2) Create 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)
         =M1 (Mark's option#1) [
    (a3) Use a utype related to the STC data model
             (e.g. utype='stc:AstroCoords.Time.TimeInstant.ISOTime')
         =M4 (Mark's option#4)
    (a4) Use a UCD (e.g. ucd='time.iso8601'; could be secondary
             e.g.  ucd='time.release;time.iso8601')
    (a5) Use a special unit (e.g. unit='"iso8601"')
	 =M3 (Mark's option#3)
    (a6) No, use STC-S string (e.g. 'Time TT GEOCENTER 2009-05-13T19:09:30')
             [from Arnold] 

It seems difficult to derive a strong answer from the various
messages posted, but the impression I have after reading your
messages is that:
  (a4) (ucd) is among the favorite solutions, provided it does 
       not hurt the Semantics group; 
  (a1) (new datatype) looks attractive [but conflict between
        model and low-level data container?] 
  (a5) could be accomodated (except Arnold?) [and after all, 
       'iso8601' has something to deal 'time' unit].
  (a1) strangely nobody seems to favor a new attribute...

Ah, Patrick, just about multiple utypes (or ucds): it's in fact
possible to assign (indirectly) more than 1 utype (or ucd) to a
field, via the GROUPs (a field may be referenced in several
groups). A bit cumbersome, but on the other hand it can neatly
underline multiple inheritences.

While writing this, Tom's message came in (placing (a5) at top);
I would personnally basically agree with his argumentation.

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



More information about the dal mailing list