VOUnits RFC

[Frederic V. Hessman]

On 29 Jul 2013, at 14:00, Norman Gray <norman at astro.gla.ac.uk> wrote:

> Rick:
> 
>>>> <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 skos:definition,
>>>> but it works just fine.
>>> 
>>> While I'd like such a resource, building basic VOUnits mechanism on
>>> it opens a whole new can of worms -- who's going to maintain it?
> 
> This is actually closer than you think.
> 
> The Unity Java library exposes URLs for each of the units it knows about (the C library doesn't because implementing things in C is even less fun than doing so in Java, but it could be added).
> 
> These URLs are those of <http://www.qudt.org/>, which is a very comprehensive collection of the messy information about dimensions, definitions, names and so on, which is at the heart of any manipulation of units.  If anyone wants to do stuff with units, we should just get behind the QUDT effort and keep it in one place, rather than reinventing this stuff badly.
> 
> Now, using that QUDT information isn't trivial (and this is why I haven't advertised this before), but all the information is there.
> 
> For example:
> 
> qudt-unit:Ampere   rdf:type   rdfs:Resource
> qudt-unit:Ampere   rdf:type   owl:Thing
> qudt-unit:Ampere   rdf:type   qudt:Unit
> qudt-unit:Ampere   rdf:type   qudt:ElectricCurrentUnit
> qudt-unit:Ampere   rdf:type   qudt:ElectricityAndMagnetismUnit
> qudt-unit:Ampere   rdf:type   qudt:SIBaseUnit
> qudt-unit:Ampere   rdf:type   qudt:SIUnit
> qudt-unit:Ampere   rdf:type   qudt:PhysicalUnit
> qudt-unit:Ampere   rdf:type   qudt:ScienceAndEngineeringUnit
> qudt-unit:Ampere   rdf:type   qudt:BaseUnit
> qudt-unit:Ampere   rdfs:label   "Ampere"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:Ampere   skos:exactMatch   <http://dbpedia.org/resource/Ampere>
> qudt-unit:Ampere   qudt:quantityKind   qudt-quantity:ElectricCurrent
> qudt-unit:Ampere   qudt:symbol   "A"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:Ampere   qudt:literal   "A"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:Ampere   qudt:uneceCommonCode   "AMP"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:Ampere   qudt:abbreviation   "A"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:Ampere   qudt:conversionOffset   "0.0"^^<http://www.w3.org/2001/XMLSchema#double>
> qudt-unit:Ampere   qudt:conversionMultiplier   "1"^^<http://www.w3.org/2001/XMLSchema#double>
> qudt-unit:Ampere   qudt:code   "0050"^^<http://www.w3.org/2001/XMLSchema#string>
> qudt-unit:SystemOfUnits_CGS-ESU   qudt:systemAllowedUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_CGS-ESU   qudt:systemUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_SI   qudt:systemBaseUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_SI   qudt:systemDefinedUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_SI   qudt:systemUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_SI   qudt:systemCoherentUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_Planck   qudt:systemAllowedUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_Planck   qudt:systemUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_CGS-EMU   qudt:systemAllowedUnit   qudt-unit:Ampere
> qudt-unit:SystemOfUnits_CGS-EMU   qudt:systemUnit   qudt-unit:Ampere

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?

>>> To me, this seems a high price to pay to solve a problem 80% of which
>>> is solved by allowing arbitrary scale factors.  The remaining 20%
>>> (telling the user that 1.89813e27 kg really is meant to mean "mass of
>>> Jupiter assumed here") are interesting, true, but IMHO it's fine if this
>>> kind of -- human-oriented -- information is in the human-oriented
>>> pieces of metadata, i.e., the column name and its description.
>> 
>> No, we shouldn't give up the units metadata without a fight, because that information, once gone, is gone forever (well, until your software asks a human in a pop-up window).

> The issue here may be about which 80% is important.

As always, one man's 80% isn't another woman's 80%….

> 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.

> 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.

As is often the case, I stormed in as a late semantic elephant in your units china store after noticing that "mas" wasn't going to be allowed, "M_Jupiter" (however you want to spell it) was going to be a no-no, and that units metadata was going to be stripped off and thrown away.  As is also often the case, I brain-stormed what I thought was a _relatively_ simple solution and Norman then pointed out that the solution had already been invented, albeit perhaps not quite in the form we'd like.

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

Your sincere pachyderm,

Rick