comparable units should be reduced on division
VladimirAlexiev opened this issue · 4 comments
I use UCUM on the semantic web through LINDT (https://github.com/OpenSensingCity/jena-ucum by @maximelefrancois86, @Antoine-Zimmermann).
I'm trying to find the conversion factor of LB-PER-H
for qudt/qudt-public-repo#285 (@steveraysteveray).
I tried this query at https://ci.mines-stetienne.fr/lindt/playground.html:
PREFIX cdt: <http://w3id.org/lindt/custom_datatypes#>
select ("1 [lb_av]/h"^^cdt:ucum / "1 kg/s"^^cdt:ucum as ?conv) {}
The result is "1.0 s.[lb_av]/h/kg"^^cdt:dimensionless
.
This might be formally correct but is highly useless: I expect to get 0.00012599803
or 0.00012599803^^xsd:double
or as last resort "0.00012599803"^^cdt:dimensionless
(or a number approximately equal to this).
I'm posting this here (@keilw, @magnonasc) instead of jena-ucum
because I guess it comes from the core java-ucum engine.
Why is this important: java-ucum
includes a bunch of conversion factors and this is the most natural way to get them out.
We have a big discussion at w3c/sparql-dev#129 whether UoM factors should be used as encoded in Java (LINDT), or should be explicitly put into triples (QUDT), and being able to get them out of java-ucum
will provide a bridge.
No it has nothing to do with that "Core Java UCUM Engine" wich came out of UOMo UCUM a project I maintained many years ago and still keep it alive, but it is of lesser priority right now.
So I'll close this ticket, please raise them with the java-ucum
project.
The only thing I got out for this organization is a thought of maybe in the future exposing the multiplication factor of a UnitConverter
even on an API level, see unitsofmeasurement/unit-api#225. The new Github discusison also seems very favorable of what you do in w3c/sparql-dev#129 btw, you might like to start using that feature instead of the issue tracker some day ;-)
We won't reduce the precision of any such calculation, that is up to each implementation, e.g. we earlier had some that run on Java ME Embedded without BigDecimal
, but we don't do it in the implementation under the hood of systems-ucum
, which has very little to do with java-ucum as mentioned.
@keilw Could you kindly point me to that repo? I searched for java-ucum and I only find https://github.com/FHIR/Ucum-java, which is probably not it.
With @grahamegrieve it sounds a lot like it, he was also a main contributor behind the UOMo UCUM bundle some years ago and the code there looks very similar, except UCUM-java is not compatible with any Units of Measurement JSR.