Re: String representations of numeric values

From: Mark Taylor <m.b.taylor-at-bristol.ac.uk>
Date: Fri, 28 Apr 2006 10:04:00 +0100 (BST)


Francois and others,

On Fri, 21 Apr 2006, Francois Ochsenbein wrote:  

> Thanks for all the comments -- the IVOA meeting is coming soon and
> this point of time/angle representations in VOTable could be one of
> the subjects if wished.

Although this suggestion has met with considerable resistance on the list, I would still like to discuss it at Victoria.

Even if one takes the position that the correct answer in the case of angles is to require data providers to use decimal degrees and simply to ignore tables which don't do so, I think (having heard representations from solar physicists at least) that this doesn't solve the problem of times, since unlike unlike angles there is no obvious zero point. MJD is one convention, but there are others (e.g. JD), and there is currently no way within VOTable to specify which of these conventions you're using. The correct answer to this may be STC, but we don't currently have that within VOTable either. People know what is meant by ISO-8601 time strings. I'm not a time expert so it may be that this format carries subtle ambiguities as well, but from a pragmatic point of view it's clear that it would satisfy a need of a large number of potential users of the format without a major change.

> As Clive mentioned, the VizieR output can display the coordinates in
> sexagesimal, e.g. from
> http://vizier.u-strasbg.fr/viz-bin/votable?-source=USNO-B1&-c=0-90&-oc.form=sexa&-out.add=_RAJ,_DEJ
>
> The conventions that are used there correspond to Mark's P2 suggestion:
>
> > P2. Modify the definition of the "units" attribute so that it is
> > permitted to contain either a catstd-format unit string as at
> > present, or a special representation string as in P1.
> > We could possibly say that for numeric-valued columns it works
> > as at present, but for string-valued columns it has the new sense.
> > However one could conceive of a case where you want both
> > representation and units (though I can't think of any actual
> > examples), which would be problematic for this scheme.
>
> and such units are "quoted" as "h:m:s" or "d:m:s", i.e. the FIELD definition
> contains unit="&quot;h:m:s&quot;" . In fact the "quoted" units were
> originally introduced to accept any non-standard unit.

This seems like as good a convention as any; it's clear that similar solutions are being used by different projects to address this problem. But without standardisation, these solutions are not going to be interoperable. I would be perfectly happy to standardise on this "quoted unit" convention.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
Received on 2006-04-28Z11:04:39