Another subtle point to keep in mind is that 4h 33min +/- 1.5 min is
slightly different in meaning
from its decimal representation. The difference is that 4h 33m is the
measured value from a gaussian distribution with dispersion of 1.5m and
then rounded to the nearest minute and IS different from 4h 33m 00.0s
+/- 90.0s. This additional piece of information is lost upon
decimalization.
Yes, I am aware that for 99.9% of real life usage this distinction is glossed over. And VOTable, if it is indeed just a quick and dirty way to get the VO going and get data to applications does not need to worry about it. However, one upshot of not having sexigesimal allowed is to make such a format inadequate for sending data for archiving to CDS or ADC. There has been great care at these places to ensure that the full meaning and significance of the measurements retain full fidelity for the once in awhile application that really needs it. Examples would be determination of the errors in astrometric proper motions or parallax where the additional error from rounding could be significant.
Therefore, I am not arguing that VOTable must have things like sexigesimal, just that we be aware that the applicable space of VOTable depends on these decisions.
Ed
Mike Fitzpatrick wrote:
> On Fri, 21 Apr 2006, Mark Taylor wrote:
>
> > On Thu, 20 Apr 2006, Thomas McGlynn wrote:
> >
> > > At it's clear that the USNO table is incorrect in the new version
> > > (since it specifies that the column is a double).
> >
> > I've just retrieved a table from the USNO-B conesearch using the URL:
> > http://www.nofs.navy.mil/cgi-bin/vo_cone.cgi?CAT=USNO-B1&RA=50.1&DEC=-37.5&SR=0.16
> > It has RA and DEC FIELD components with the attributes
> >
> > datatype="double" arraysize="3x1"
> >
> > which, while you might argue it's eccentric, is not incorrect, this is
> > exactly how you specify an array-valued column according to both
> > versions 1.0 and 1.1 of the standard.
>
> Perhaps it wasn't clear but I raised this as an example in support of
> your, Tom, and Roy's various points: As Tom says this isn't what one
> expects of a coord in a votable (where the first, correct, shot at
> deciphering the chars would be decimal degrees), and where
>
> datatype="char" arraysize="*"
>
> would allow Roy's "3h 40m" as well as "3Hrs 4Min", "three hours..." et
> al as being legal but no less confusing.
>
> While I'll lawyer whether an ascii representation of an IEEE double is
> any more meaningful than sexigesimal, I fully support the notion that we
> all be clear that decimal degrees be used as the standard. If the votable
> standard allows "abuses" such as USNO-B returns we should clarify the
> format if needed which would address your concerns. That still leaves
> open the question of how software developers should handle a sexigesimal
> value or other string and whether the registry should/could provide a
> compliance metric saying the votable you get from a provider has all
> the MUSTs or might play loose with what is technically legal but not at
> all expected.
>
> This raises another issue though: If i write code that does something to
> a votable I won't know whether it is compliant unless there is a 'source'
> identifier in the table I can use to check against the registry
> compliance metric. All I'd see is valid xml against the schema but would
> have no way to know it's the weird usno-b convention of coords until I
> try to parse it. Something like a restricted vocabulary of allowed
> 'units' fields would at least tell me what formats I'm supposed to be able
> to handle.
>
> -Mike
>
>
Received on 2006-04-21Z15:11:13