Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ansell.peter@gmail.com
 designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
Date: Fri, 16 Jan 2015 11:29:36 +1100
Message-ID: 
 <CAGYFOCRpVnR5OJ+yJrTqLMbuskOQSzxNT71wpYEJoDadWYC3Xw@mail.gmail.com>
Subject: Re: [ALL][RDF] github Commons RDF vs. Apache Commons Sandbox RDF
From: Peter Ansell <ansell.peter@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8

The Clerezza team were all notified about the effort to put a common
RDF API together on GitHub and they responded positively at that
point. The only sticking point then and now IMO is the purely academic
distinction of opening up internal labels for blank nodes versus not
opening it up at all. Reto is against having the API allow access to
the identifiers on academic grounds, where other systems pragmatically
allow it with heavily worded javadoc contracts about their limited
usefulness, per the RDF specifications:

https://mail-archives.apache.org/mod_mbox/clerezza-dev/201406.mbox/%3C5398B07C.5000507@apache.org%3E

However, for some more background we could refer back to discussion
about restructuring both Clerezza and Stanbol to make them more
maintainable and useful to the community:

https://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3CCAA7LAO2X++Uk8PoNM+b9=f9v2DN5zdZLjh2BjE0MmrZCYafnZQ@mail.gmail.com%3E

In particular, as Rupert Westenthaler mentions there, the goal to
simply promote the Clerezza RDF model as commons.rdf would not achieve
much given the share that Jena and Sesame have.

The Commons RDF effort that Sergio has brokered, including Andy (Jena)
and I (Sesame), and including both Scala (w3c/banana-rdf@github) and
Clojure (drlivingston/kr@github) project representatives will provide
the common JVM RDF API that Rupert referred to as being necessary.

The main points as I see it that are necessary before starting the
process that was aborted last time (echoing Sergio's comments):

* Mailing list clutter: both in terms of the wide range of technical
discussions from commons rdf, and general email traffic from other
commons sub-projects discouraging potential participants from joining
in the discussion.
* Being able to use GitHub pull requests for code review, including if
necessary the sending of comments there to the apache mailing list
that is decided to be used for that purpose. The actual merging will
be done by hand in this case, but the code review features there are
too useful. The patching of PR comments back to apache mailing lists
has already done, so there is no technical issue for this, just
deciding which mailing list the comments will go to.
* Having it okay that the commons rdf api is a project that
principally aims to create a set of interfaces, and not host any of
the scalable implementations of the API. Stian Soiland-Reyes has
written a basic implementation, but in practice, any large dataset
will not load into that implementation and be queried efficiently, so
it is only going to be used for small in-memory tasks.

I hope there is no bad blood from the aborted effort last time. There
were a variety of causes, including the reasons above but we all
joined the GitHub discussion with the goal of hosting the project
inside of the Apache Foundation and IMO Apache Commons is still likely
the best way to do that for our small (in terms of code) project.

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org