VOTable and VOUnits

[Grégory Mantelet]

Dear Apps,

I also agree that we probably confident enough to use a MUST there. A 
SHOULD seems like a much better approach, because, VOUnit /should/ 
really be encouraged when speaking about units in a VO context.

I agree too with Marco that TAP should at least recommend using VOUnit 
for the TAP_SCHEMA.columns.unit column. This is indeed missing in the 
specification, though most of TAP services already try to do it by default.

Cheers,
Grégory


On 19/05/2023 12:40, Markus Demleitner wrote:
> Dear Colleagues,
>
> On Fri, May 19, 2023 at 12:09:41PM +0200, Molinaro, Marco wrote:
>> Il giorno ven 19 mag 2023 alle ore 11:54 Mark Taylor <
>> m.b.taylor at bristol.ac.uk> ha scritto:
>>
>>> I believe we could write MUST without breaking the rules;
>>> it's not true that previously valid VOTables would become invalid,
>>> since only VOTables declaring version='1.5' would need to be
>>> bound by new requirements introduced in VOTable 1.5.
> Nice trick.  I like it.
>
>>> But, my opinion is that we ought to stick with SHOULD at least for
>>> now, and perhaps indefinitely.  It's nice if units can be
>>> machine-readable, so VOUnit should be encouraged, but my guess is
>>> that the overwhelming usage of the units attribute in VOTable is
>>> being read by humans, and for that purpose non-VOUnit-compliant
>>> units are much better than no units at all.
> If you're talking about all the mad units introduced for technical
> reasons (or, umm, linguistic economy) like the almost proverbial
> "millicrab": VOUnits provides for that.  You'd be writing m'Crab'.
> Or, if you absolutely have to, 'dex'.
>
> If you're talking about large amounts of metadata in different
> syntaxes:  Well, that *is* a point. But then... VizieR has cleaned up
> their unit strings recently, and if a MUST here can entice other data
> centres to do the same thing, that'd certainly be wonderful.
>
> By the way, pyVO (if I understand matters right -- Brigitta, perhaps
> you can chime in) is transitioning to making QTables from stuff
> coming from the VO by default, in which case (I think) units are
> parsed by a machine all the time whenever pyVO is in the game.  This
> may shake the "overwhelming usage" argument a bit.
>
> Still:
>
>>> The danger of writing MUST here is that data providers who have a
>>> load of human-readable-but-non-VOUnit-compliant units will provide
>>> no units rather than rewriting them, to avoid compliance errors.
> I think none of us is confident enough for a MUST at this point, and
> probably a SHOULD will already work nicely enough to nudge people
> towards using good, machine-readable unit strings, in particular if
> that way their users can then write
>
>    table["radial_velocity"]/(0.01*u.pc/u.Gyr)
>
> or something like that.
>
>> specifications (e.g. from talks in last week's interop),
>> we might put an issue on both VODataService (which is
>> not in github, AFAIK) and TAP to clarify the texts there.
>> Similarly to what's up here in VOtable.
>>
>> Would that help? Is it too much?
> Well, I'd say it's a classic for our -Next wiki pages.  And I'm
> definitely surprised I've not introduced the VOUnits "should" into the
> last VODataService update (where it would have nicely fit).
>
> But yeah, VODataService was probably the last standard published out
> of Volute (its cycle started in 2018 when I still had hoped we could
> escape github).  I suppose we'll have to touch it anyway (if only for
> product-type support), so pulling it over to github would be a nice
> touch.  I'll do it some time July-ish, but I'd love to be beaten to
> it.
>
>            -- Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20230524/ea79eb9e/attachment.htm>