comparable units should be reduced on division

[VladimirAlexiev]

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 https://github.com/qudt/qudt-public-repo/issues/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.

[VladimirAlexiev]

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 https://github.com/w3c/sparql-12/issues/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.

[keilw]

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 https://github.com/unitsofmeasurement/unit-api/discussions/225. The new Github discusison also seems very favorable of what you do in https://github.com/w3c/sparql-12/issues/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.

[VladimirAlexiev]

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

[keilw]

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.