comparable units should be reduced on division
- Langage dominant
- Java
- Étoiles
- 26
- Forks
- 18
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
(This poor issue is looking for a home, was posted as https://github.com/unitsofmeasurement/uom-systems/issues/182 but evicted from that project)
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:
```sparql
PREFIX cdt:
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 because `s.[lb_av]/h/kg` is a dimensionless unit (the factor I'm looking for), but is left unreduced. 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 (@grahamegrieve) 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 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.
https://github.com/unitsofmeasurement/unit-api/discussions/225 is a bit related (exposing the multiplication factor of a UnitConverter)
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.