Re: Contribution proposal for Jena: support of a datatype for quantity values

On 15/06/18 14:49, Maxime Lefrançois wrote: Dear all, Regarding our contribution proposal to enable extensions to override SPARQL operators in Jena We finally got the agreement from our institution to contribute to the Apache foundation. Question 1: what is the procedure to upload the form?

Re: Contribution proposal for Jena: support of a datatype for quantity values

On 15/06/18 14:49, Maxime Lefrançois wrote: Dear all, Regarding our contribution proposal to enable extensions to override SPARQL operators in Jena We finally got the agreement from our institution to contribute to the Apache foundation. Question 1: what is the procedure to upload the form?

Re: Contribution proposal for Jena: support of a datatype for quantity values

Some comments: > > Add use of the standard Java Service Provider API to load things > automatically found in the classpath: > > > > - In TypeMapper --> a method that uses the Service Provider API to find > more Datatypes > > Should this be a method, or rather additional behavior for

Re: Contribution proposal for Jena: support of a datatype for quantity values

See comments in-line... ajs6f > On Jun 15, 2018, at 9:49 AM, Maxime Lefrançois > wrote: > > Dear all, > > Regarding our contribution proposal to enable extensions to override SPARQL > operators in Jena > > We finally got the agreement from our institution to contribute to the Apache >

Re: Contribution proposal for Jena: support of a datatype for quantity values

Dear all, Regarding our contribution proposal to enable extensions to override SPARQL operators in Jena We finally got the agreement from our institution to contribute to the Apache foundation. Question 1: what is the procedure to upload the form? About the how, I would like to discuss first

Re: Contribution proposal for Jena: support of a datatype for quantity values

We're (well, Andy is) working on 3.7.0 now. We've been trying to maintain a 6-month or so release cadence, so you've hit a really good time to begin this work. That having been said, I don't think anyone would say that we are especially stringent about it, so I wouldn't worry too much about the

Re: Contribution proposal for Jena: support of a datatype for quantity values

Well, I think I have a pretty clear idea how I would do this. We would end up using a registery 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. I am currently requesting the right to

Re: Contribution proposal for Jena: support of a datatype for quantity values

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

Re: Contribution proposal for Jena: support of a datatype for quantity values

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

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:

Re: Contribution proposal for Jena: support of a datatype for quantity values

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)

Re: Contribution proposal for Jena: support of a datatype for quantity values

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

Re: Contribution proposal for Jena: support of a datatype for quantity values

ajs6f > On Mar 26, 2018, at 5:40 PM, Bruno P. Kinoshita 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

Re: Contribution proposal for Jena: support of a datatype for quantity values

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

Contribution proposal for Jena: support of a datatype for quantity values

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