I agree. I can imagine plenty of use cases for such a powerful pair of extension points.
Maxime, how can we help you attack that work? Is there a design that is already clear to you? Are there any blockers we can help remove? ajs6f > On Mar 28, 2018, at 5:08 AM, Rob Vesse <rve...@dotnetrdf.org> wrote: > > 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 <maxime.lefranc...@emse.fr> > Reply-To: <dev@jena.apache.org> > Date: Wednesday, 28 March 2018 at 09:29 > To: <dev@jena.apache.org> > 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 <a...@apache.org> 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 <ki...@apache.org> 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<maxime.lefranc...@emse.fr> >>> 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/ >> > > >
