Sexagesimal metadata

[Patrick Dowler]

Sexagesimal values are strings that can be further parsed/interpreted so
that falls right into what xtype is for. It would be two closely related
xtype values.
I say "strings" because of the colons in the serialization... they could in
principle be {double,3,ra} and {double,3,dec} (eg) if that serialization
was potentially useful/acceptable. #scope-creep

The other alternative, which is always a possibility when thinking about
xtypes, is to introduce two new datatype(s) in VOTable, but in the past
there was reluctance to introduce non-primitive types there. Certainly
adding xtypes is more backwards-compat friendly than new datatypes.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Thu, 10 Mar 2022 at 09:17, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

> Dear Semantics and DAL,
>
> following the report I gave on VOUnit usage in the VO at the last interop
> (https://wiki.ivoa.net/internal/IVOA/InterOpNov2021Ops/uuc.pdf)
> Gilles Landais at CDS has done a good job of tidying up the units
> reported by VizieR to conform to the VOUnit standard (the results are
> not yet visible in the public VizieR service).
>
> But one issue that remains is how to flag up sexagesimal quantities,
> which are currently marked up like this:
>
>    <FIELD name="RAJ2000" ucd="pos.eq.ra;meta.main" ref="J2000"
>           datatype="char" arraysize="12" unit="'h:m:s'">
>    <FIELD name="DEJ2000" ucd="pos.eq.dec;meta.main" ref="J2000"
>           datatype="char" arraysize="13" unit="'d:m:s'">
>
> The unit, by long VizieR tradition, is quoted as 'h:m:s' or 'd:m:s'
> (including the single quotes), which is probably recognised as an
> ad hoc indication by quite a bit of client code out there.
> However this is not legal VOUnit syntax, and they're not really units
> anyway since the columns they apply to are not numeric, but it's not
> obvious how to indicate sexagesimal content of columns in VOTable metadata.
> You can infer it by noticing ucd="pos.eq.*" and datatype="char",
> but it seems like there ought to be a more explicit way to do this,
> especially considering how common this case is in the tables we deal
> with.
>
> So: what would be the VO-compliant way for CDS to proceed here?
> (note I'm not claiming that they are going to follow any such advice,
> that's for Gilles to decide).  Do we just leave consumers to make a
> good guess based on UCD and datatype?  Could it be a job for DALI/xtype?
> Something else?
>
> Mark
>
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20220310/41363339/attachment-0001.html>