About releases and votes

2018-03-27 Thread Andy Seaborne 
Since we have a new PMC member, Chris, I thought I'd put down more 
detail than usual about releases.


There are some changes coming through about discouraging MD5.

There are some simplifications we can do about NOTICE and LICENSE files.

== The "Release"

The "release" is the source-release.zip file that will end up in 
/dist/jena/source/.


The files going into /binaries/ and the files going to maven central, 
including the copy of "source-release", are "convenience binaries".


Our process is documented at:

https://cwiki.apache.org/confluence/display/JENA/Release+Process

== Update to Apache release policy:

MD5 checksums are being discouraged for the source-release, the file 
that goes in https://www.apache.org/dist/jena/source/.


Files uploaded to maven central are not affected - they remain as 
md1/sha1/asc - and I think MD5/SHA1 is effectively baked into maven.


The Apache parent POM, does not seem to seem to deal with this so I'm 
proposing we add a manual step at about step 10 to calculate sha512 
checksums and delete the MD5 checksums


https://cwiki.apache.org/confluence/display/JENA/Release+Process#ReleaseProcess-Step10-UploadtheReleaseCandidate

(and change the download.html page).

== Possible future changes.

Now we are committed to a single release cycle for all modules, there is 
no need to have NOTICE and LICENSE files at the top of every module.  We 
can just have the ones in the top directory which should already be correct.


We do need separate N files to go into binaries like the Fuseki sever 
jar.  These are in "dist/" subdirectories in the codebase.


The W3C test suites need there own files.

== The Process

There are two parts - the basic of an Apache process (conducted 
properly, legal clean, signed) and what we as a community decide on top 
of that.


Strictly, a vote is at least 3 +1 and a simple majority (you can't veto 
a release, that should have happened when the code went into the codebase).


As a community, we haven't pushed through a release on that minimal 
basis before. We try to sort things out and do a new release candidate. 
Doing a 2nd, 3rd, ... release candidate isn't too bad although not zero 
cost. The most bumpy things have been instabilities in the test suite - 
unintended order dependencies and with random things on different 
hardware. Deciding on a case-by-case basis rather than a set of rules 
for all eventualities seems fine to me.


It does not have to be perfect. My view is that the question is "is it 
better?" We are shipping fixes and improvement.


We tend to classify modules into two groups: the principle modules which 
are a blocker on getting a release out, and rhe rest including legacy 
ones (e.g. Fuseki1, SDB).  At the moment, jena-maven-tools does not pass 
its test suite and is not in the build.


Ultimately, it's the Release Manager decision.

== Voting

The VOTE email will have various links and details in it:
All links are https and to Apache servers.

Proposed dist/ area:
  -- URL to the files to go in  https://www.apache.org/dist/jena/
  -- You must download the "source/" area.
  https://dist.apache.org/repos/dist/dev/jena/

Keys:
  -- Keys to import to verify the .asc on source-release.zip.-
  https://svn.apache.org/repos/asf/jena/dist/KEYS

Staging repository:
  -- URL to the files to go to maven central --
  https://repository.apache.org/content/repositories/orgapachejena-?

Git commit (browser URL):
  -- URL to the commit on Apache hardware, not Github.
  http://git-wip-us.apache.org/repos/asf/jena/commit/??

Git Commit Hash:
  -- full SHA1 hash of the commit.
  --"[maven-release-plugin] prepare release ..."

Git Commit Tag:
  -- The tag. Note that tags in git can be moved later.
  -- It is the commit SHA1 that matters.


When voting on a release candidate the following points need to be checked:

+ is there a source archive?
+ is the GPG signatures correct?
+ are the checksums correct?
+ does everything work?

+ can the source archive really be built?
 (NB This requires a "mvn install" first time)
+ is there a correct LICENSE and NOTICE file in each artifact
 (both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
 if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?

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

2018-03-27 Thread Andy Seaborne 

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  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 
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: 
PREFIX ex: 

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/

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

2018-03-27 Thread ajs6f 

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 - 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 
> 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: 
> PREFIX ex: 
> 
> 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/

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

2018-03-27 Thread ajs6f 
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  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 
> 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: 
> PREFIX ex: 
> 
> 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/