VOUnits RFC

[Frederic V. Hessman]

On 26 Jul 2013, at 11:25, Norman Gray <norman at astro.gla.ac.uk> wrote:

> 
> Markus, hello.
> 
> On 2013 Jul 26, at 07:38, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
>> On Thu, Jul 25, 2013 at 05:54:40PM +0100, Norman Gray wrote:
>>> In particular (despite some comments on the RFC page and off-line)
>>> we have not extended the syntax of decimal numbers.  In fact, the
>>> only place where such a number would appear in this specification
>>> is in the form of a numerical scaling factor before a unit (for
>>> example '0.1nm', indicating that the Angstrom is the _unit_, as
>>> opposed to _quantity_): we restrict such scaling factors to round
>>> powers of ten, and in any case expect these to be rather rare.
>> 
>> For the record: I am still convinced that that is a restriction we
>> are going to regret -- allowing arbitrary factors is a small price to
>> pay for not having to touch data that has, say, "Jupiter mass" as
>> units and while having IVOA-valid unit strings.  It's *much* nicer to
>> have to commit to a choice for Jupiter mass, say, only in the
>> metadata rather than to bake that choice into the data itself.
> 
> That's an argument I hadn't thought of.  It's certainly a hygienically consistent position (so I stand beside you on that), but from a practical point of view, I suspect that data providers really do want to head columns 'jupMass', and I'm not sure it's up to us to say they oughtn't.

I'd say is is NOT up to us to say they oughtn't.  Same goes for "mas", which any astronomer should recognize immediately.  On the other hand, "uas" is something one has to tolerate, even though it's an abomination.

> Also (practically), from implementing the standard in the library, I ended up convinced that the issue of the list of 'known units' was a quite separate muddle from the muddle of syntaxes.  Enough of a muddle, that is, that it seemed wise to demand that unit-string parsers accept _any_ units which are syntactically plausible, and that they sort out their status as known, or deprecated, or allowed or forbidden to have prefixes, as a separate validation step.  (A further implication is that that validation step could potentially and safely be context specific).

Indeed, so a set of simple rules (e.g. multiple "/" are OK, since they are easily parsed and are actually more robust) and a vocabulary of common non-standard units is all we need.

<skos:Concept rdf:about="vou:units#jupiterMass">
	<skos:prefLabel>M_jupiter</skos:prefLabel>
	<skos:definition>1.89813e27 kg</skos:definition>
	<skos:altLabel>jupMass</skos:altLabel>
	<skos:altLabel>Mjup</skos:altLabel>
	<skos:altLabel>M_jup</skos:altLabel>
	<skos:altLabel xml:lang="en">jupiter mass</skos:altLabel>
	<skos:altLabel xml:lang="en">jupiter masses</skos:altLabel>
	<skos:related rdf:resource="iau93:#jupiter"/>
	<skos:scopeNote xml:lang="en">Case is not important.</skos:scopeNote>
</skos:Concept>

That way, your favourite unit parser could always simply ask vou:units for help.  Maybe I'm slightly misusing skis:definition, but it works just fine.

> If that's a reasonable conclusion, then it means that the question of what is and is not a 'known unit' becomes a less important one.  And that in turn weakens the case for encouraging people to put scale factors in front of unit strings.
> 
> And if, finally, those scale factors are not particularly encouraged, or required to be only round powers of ten, then the question of the syntax of that decimal prefix becomes moot.
> 
>> And, with it, you'd even have "0.0254 m" sanctioned as an IVOA-valid
>> unit.  Now, wouldn't *that* be nice?
> 
> That would be the International Inch, then, as opposed to the US Survey Inch of 0.025400051 m.

No worse than the concept of "magnitudes", which we're also stuck with for historical reasons.  Simply do

<skos:Concept rdf:about="vou:units#inch">
	<skos:prefLabel>inch</skos:prefLabel>
	<skos:definition>0.025400051 m</skos:definition>
	<skos:altLabel>\"</skos:altLabel>
	<skos:altLabel xml:lang="en">inches</skos:altLabel>
	<skos:altLabel xml:lang="de">Zoll</skos:altLabel>
	<skos:scopeNote xml:lang="en">U.S. Survey inch; the "international" inch is just 0.0254 m.</skos:scopeNote>
</skos:Concept>

and forget about it.

Rick