I think work towards Option 2 would be the most valuable to the community
The SPARQL specification allows for the overloading of any operator/expression where the spec currently defines the evaluation to be an error so extending operators is a natural and valid extension point to provide The Terms of Use for UCUM would probably need us to obtain a licensing assessment from Apache Legal as it is a non-standard OSS license even if the code that implements it is under BSD (which is fine from an Apache perspective). Therefore having a well defined extension mechanism and then having UCUM support live outside Apache Jena that as an extension implementation maintained by yourself would be the easiest approach Rob From: Maxime Lefrançois <[email protected]> Reply-To: <[email protected]> Date: Wednesday, 28 March 2018 at 09:29 To: <[email protected]> Subject: Re: Contribution proposal for Jena: support of a datatype for quantity values Dear all, Happy to see you are interested the UCUM datatypes ! Ok so let's dive in the technical details. # Compare Jena 3.6.0 and Jena 3.6.0-ucum https://github.com/apache/jena/compare/master...OpenSensingCity:jena-3.6.0-ucum # Modules, dependencies, licences Two modules forked so far: jena-core and jena-arq. One dependency added to jena-core (after a minor change I made today): systems.uom:systems-ucum-java8:0.7.2 -> BSD license of systems-uom, and license of UCUM http://unitsofmeasure.org/trac/wiki/TermsOfUse --> this use implementation of JSR 363 indeed - Units of Measurement API (see attached for the transitive dependencies, all from https://github.com/unitsofmeasurement ) # External module ? I would have been happy to develop a separate extension of Jena for the UCUM datatypes. One of the main reasons why this is not possible was pointed out by Andy: I had to add a new value space VSPACE_QUANTITY to overload the SPARQL operators '<>=' and arithmetic functions '+-*/'. Indeed, there are two parts: the necessary extensions for operators, and the units themselves. We could choose some other unit system than UCUM, but 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. # possible directions I see three main possible directions of work there: 1. work on the proposal as and potentially integrate it completely 2. work on jena-core and jena-arq to make the definition of new datatypes and the overloading of operators as easy as the definition of new custom functions --> so that I can easily implement UCUM datatypes as an extension (and not a fork) 3. add VSPACE_QUANTITY value space and NodeValueQuantity in jena-arq, and externalize the support for the UCUM systems of unit in an external module Best, Maxime Le mar. 27 mars 2018 à 17:16, Andy Seaborne <[email protected]> a écrit : Extending the operators for SPARQL is a new value space VSPACE_QUANTITY. See (comparison): 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 and (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 with a new NodeValueQuantity for javax.measure.Quantity I'm seeing this a "one dimensional units" - a quantity and a unit. Even then, there are two part - the necessary extensions for operators and the units themselves to allow for other unit systems (?). There are new dependencies in jena-arq and jena-core. http://unitsofmeasurement.github.io/ JSR 363 - Units of Measurement API BSD-license and an old version of something is on central: http://central.maven.org/maven2/javax/measure/unit-api/1.0 if that's the right thing. --- Maxime - what are the dependencies for this contribution and for which pieces are they needed? Andy On 27/03/18 15:49, ajs6f wrote: > Bruno raises an interesting question-- would this contribution have any > effect (or should it) on jena-spatial? Would it be either necessary or if > not, appropriate to integrate there? (I'm particularly interested in this > because it might help decide between core and an extension.) > > > ajs6f > >> On Mar 26, 2018, at 5:40 PM, Bruno P. Kinoshita <[email protected]> wrote: >> >> Hi Maxime, >> Don't know whether it would be best as part of jena core or in an extension, >> but sounds very interesting! Will let others comment on this. >> At work, one item in my backlog is to replace jscience by jsr363 - Units of >> Measurement >> | >> | >> | >> | | | >> >> | >> >> | >> | >> | | >> Units of Measurement >> >> Units of Measurement provides a set of APIs and services for handling units >> and quantities. >> | | >> >> | >> >> | >> >> >> We use it for weather forecast and GIS, with things like wind speed, rain >> amount, etc. >> I think another GIS library that we use did the switch as well (some OGC lib >> I think). >> Perhaps it would be nice to consider taking a look at their api for >> compatibility with other systems. >> CheersBruno >> >> Sent from Yahoo Mail on Android >> >> On Tue, 27 Mar 2018 at 2:07, Maxime Lefrançois<[email protected]> >> wrote: Dear all, >> >> I am Associate Professor at MINES Saint-Étienne, France, working on >> Semantic Web and Linked Data. I'd like to let you know about our >> project *Custom >> Datatypes for Quantity Values*[1], that leverages the Unified Code of Units >> of Measures, a code system intended to include all units of measures being >> contemporarily used in international science, engineering, and business. >> Using our UCUM Datatypes, one can encode and query quantity values in a >> lightweight manner: >> >> PREFIX cdt: <http://w3id.org/lindt/custom_datatypes#> >> PREFIX ex: <http://example.org/> >> >> SELECT ?value1 ?value2 ?result >> WHERE{ >> VALUES ( ?value1 ?value2 ) { >> ( "1.0 m/s"^^cdt:speed "2 s"^^cdt:time ) >> } >> BIND( ?value1 * ?value2 AS ?result ) >> } >> >> Results in >> >> ---------------------------------------------------------------------- >> | value1 | value2 | result | >> ====================================================================== >> | "1.0 m/s"^^cdt:speed | "2 s"^^cdt:time | "2.0 m"^^cdt:length | >> >> See our demonstration online [2]. >> It uses *a fork of Jena where we implemented UCUM datatypes* [3] (in >> jena-core and jena-arq, with several unit tests) our implementation uses >> the recent JSR 385, Units of Measurement API 2.0, and the UCUM extension >> [4]. >> >> This is not the first project I develop into/using Jena. >> - I forked it to Supporting Arbitrary Custom Datatypes in RDF and SPARQL >> fetching some Javascript definition at the URI of the datatype [5] >> - I develop SPARQL-Generate, an extension of SPARQL implemented on ARQ to >> generate RDF from web documents in XML, JSON, CSV, HTML, CBOR, and plain >> text with regular expressions [6] >> >> >> If you agree we me that supporting UCUM datatypes would be a nice addition >> to Apache Jena and a nice contribution to the Semantic Web community, I >> would be willing to help to integrate our contribution to other modules >> (with jena-tdb, ... ), and help maintaining it in the future. >> >> Best regards, >> Maxime Lefrançois, >> Associate Professor, MINES Saint-Étienne >> >> [1] - http://w3id.org/lindt/custom_datatypes# >> [2] - http://w3id.org/lindt/playground.html?example=05-Multiply >> [3] - http://w3id.org/lindt/custom_datatypes#implementation >> [4] - >> https://github.com/unitsofmeasurement/uom-systems/tree/master/ucum-java8 >> [5] - https://ci.mines-stetienne.fr/lindt/spec.html >> [6] - https://ci.mines-stetienne.fr/sparql-generate/ >
