plements 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
Rep
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?
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?
>
> >>>>>
> >>>>>
> >>>>> 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
he 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 UC
t; 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
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
>>>
>>>
>>>
>>&
ell 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
Date: Wednesday, 28 March 2018 at 09:29
> To:
> 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
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
Reply-To:
Date: Wednesday, 28 March 2018 at 09:29
To:
Subject: Re: Contribution proposal for Jena: support of a datatype for
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
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/j
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 M
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 jscience by jsr363 - Unit
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
15 matches
Mail list logo
