implement LINDT UCUM units of measure

[VladimirAlexiev]

I think that the LINDT UCUM units of measure of @maximelefrancois86 are very useful, see https://github.com/w3c/sparql-12/issues/129 for a description and discussion.

Is there interest to port LINDT from a Jena fork (https://github.com/OpenSensingCity/jena-ucum) to rdf4j?

A useful discussion is in https://lists.apache.org/thread.html/77cebe345679553c1df0a97d3c7ce29ad5555d2231522557420a8ae0@%3Cdev.jena.apache.org%3E . Excerpts from the mlist thread:

• Maxime Lefrancois @maximelefrancois86:
  • our implementation uses the recent JSR 385, Units of Measurement API 2.0
  • uses https://github.com/unitsofmeasurement/uom-systems/tree/master/ucum-java8 (a new Jena dependency)
  • touches jena-core and jena-arq; may need integration in other modules (jena-tdb, ... )
  • Compare Jena 3.6.0 and Jena 3.6.0-ucum https://github.com/apache/jena/compare/master...OpenSensingCity:jena-3.6.0-ucum
  • UCUM is very comprehensive and has different implementations in different programming languages. It would be possible to implement UCUM datatypes in other RDF-SPARQL engines.
  • not possible to implement as External module (extension): I had to add a new value space VSPACE_QUANTITY (and NodeValueQuantity for javax.measure.Quantity) to overload the SPARQL operators '<>=' and arithmetic functions '+-*/'.
  • see VSPACE_QUANTITY: https://github.com/OpenSensingCity/jena-ucum/blob/jena-3.6.0-ucum/jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java#L566
  • see eg multiply: https://github.com/OpenSensingCity/jena-ucum/blob/jena-3.6.0-ucum/jena-arq/src/main/java/org/apache/jena/sparql/expr/nodevalue/NodeValueOps.java#L283
• Andy Seaborne @afs (ajs6f on that mlist):
  • would this contribution have any effect (or should it) on jena-spatial? Would it be either necessary or if not, appropriate to integrate there?
  • What is the relation to QUDT? http://www.qudt.org. ANSWER: UCUM codes are in QUDT 2.1, see comments by @dr-shorthair in https://github.com/w3c/sparql-12/issues/129
  • Comparator<NodeValue>? (Thinking of sorting.) Comparing by implicit value can get into unstable sorting
  • Is arithmetic involving numbers also going to be supported?
  • does not follow XSD so "1m*2" becomes 2.0m: from integer to decimal
  • Is cdt:length * cdt:length a cdt:area?
  • Can the query cast? If so, how does it set the measurement scale? A "cdt:cast(quantity, unit, datatype)" would be nice.
• implementation design that will use a registry like for custom functions or datatypes. That registry would contain an ordered list of SPARQL operator handlers, pre-filled by one for handling XSD datatypes.
• @jeenbroekstra wrote in Dec 2018: My 2 cents on adding this to RDF4J:
  • the starting points for looking at extending the RDF4J SPARQL engine for this would be the ExtendedEvaluationStrategy, and more particular for operator overload we should look at QueryEvaluationUtil and XMLDatatypeMathUtil.
  • It is a bit unfortunate that these are currently written as util classes, rather than as an extensible set of objects. While it's possible to just add this new functionality into the util classes, it might be a good opportunity to reorganize the code to better follow the open/closed principle.
  • I would recommend, by the way, not porting Jena code directly. We can look at it for inspiration but a direct port is likely not covered by the licensing terms.
• See https://github.com/w3c/sparql-12/issues/129#issuecomment-723330194 and https://github.com/w3c/sparql-12/issues/129#issuecomment-723336695 on the topic of UCUM's license

[afs]

"ajs6f" and "afs" are different people.

[hmottestad]

Also wanted to note that this would be useful to support in SHACL too. So a user could require a certain unit of measure or a certain value range regardless of the UoM.

[abrokenjester]

I'm interested in this, but have very limited bandwidth to spend time on it myself.

There is also a possible legal issue due to the fact that the UCUM license is somewhat murky (see w3c/sparql-12#129 (comment) ). As also noted in that comment I doubt that the use to which we put it will in fact conflict with the license, but we may need to pass it by the EF legal team to make sure.

It might be worth doing a first spike of an implementation outside of the core RDF4J project, and then once we have something a bit more stable (both technically and legalities-wise) contribute it into the project for better integration.