VOUnits RFC

[Norman Gray]

RIck and Markus, hello.

On 2013 Jul 29, at 13:22, Frederic V. Hessman wrote:

> On 29 Jul 2013, at 14:00, Norman Gray <norman at astro.gla.ac.uk> wrote:
> 
[...]
>> qudt-unit:Ampere   rdf:type   rdfs:Resource
> [...]
> Yuk!  But we COULD provide a handier wrapper around qudt:  they do the work, and only we pass a simplified version - highly filtered - to any interested VO client?

Yuk, indeed.  I would suggest that direct engagement with the QUDT stuff is only for... Enthusiasts.  It's all good stuff, and I think exactly the right way to articulate this information, but there are some technological barriers to getting at it (not because they're high barriers, but because they're unfamiliar ones).

The Unity library takes that framework (in a pre-downloaded version), and bakes it into a more convenient form <http://www.astro.gla.ac.uk/users/norman/ivoa/unity/javadocs/uk/me/nxg/unity/UnitDefinition.html>

We don't mention the QUDT stuff in the VOUnits document, because I thought it might be offputting.  Do you (this question is to the list generally) think we should?

>> I take it that the reason why we're discussing the parsing of strings like "mm.s**-2" rather than "-3/m/1:0/s/-2" (something like which would avoid many problems) is because we expect that the strings we're discussing will be basically the human-readable ones.  Having an explicit unit-string grammar means that data providers can write the human-readable things in the confidence that the result will _additionally_ be reliably machine-readable.  Or, where it's not machine readable (because someone wants to use 'jupMass') that it is at least partially machine readable, and that that partial readability is non-ambiguous.
> 
> Sounds reasonable.

I should perhaps work this text into the VOUnits rationale section.

>> This conversation is not, I think, really about whether or not we should permit non-round scale-factors (that's merely a minor edit to the grammars), but I can't neatly characterise what it _is_ actually about.

> So isn't this conversation about what one SHOULD do with units and about what one COULD do with units?

Yes to both.  We've tried, in the document, to stress that this document makes very modest recommendations (ie, we don't have to start a big Quantities fight about this), without going too far and suggesting that it's trivial.  I don't think I/we have quite the right balance here.

I think that a discussion of the QUDT stuff might be a suitable 'and there's more...' addition to section 3 of the document.

Perhaps this discussion is, at base, about telling me in what respects I need to make the document clearer in its aims and non-aims.

Markus:

> Well, in that case: Unless someone dislikes them very heavily, let's
> just allow arbitrary floats as prefixes, preferably in the standard
> floating-point literal form basically every programming language out
> there uses, shan't we?  Simple, quick, does the job, not network
> access required to parse units, and a very happy me.  Perfect!

But the big problem with this -- returning to this specific point -- is that this would break the property that, since VOUnits is in the near-intersection of the other syntaxes[*], anything written in the VOUnits syntax is has an equivalent parse-tree when it's parsed using one of the other syntaxes[**].  That is, VOUnit strings are valid and unambiguous in all three syntaxes (with the qualification in [*]).  If we allow non-round scale factors -- which FITS and OGIP don't -- then this stops being true.

I'm not defiantly wedded to this property, but I would like this group to positively assert that this is a property not worth keeping.

[*] The only exception is that OGIP doesn't parse '.' as multiplication, but since OGIP allows only '*' and CDS allows only '.', some sort of break was unavoidable.

[**] ... at least when using these particular grammars.  This property might not be true in, say, a FITS parser which resolves the ambiguities in the FITS spec in a different way.

I worry that we're turning this into a three-way discussion which is long enough that it might put other people off contributing.  I don't want to cut it short, but: everyone else -- please shout!

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK