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