commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Fernández <>
Subject Re: [ALL][RDF] github Commons RDF vs. Apache Commons Sandbox RDF
Date Thu, 15 Jan 2015 11:04:17 GMT
Hi Benedikt,

On 15/01/15 09:40, Benedikt Ritter wrote:
> I just want to let you know, that I've joined the discussion, the github
> commons rdf community is currently having at github [3]. I think it is time
> for the PMC to take action here since it feels like there is a conflict in
> the beginning.

OK, although a bit too early, I'm fine jumping into dev@commons.a.o to 
discuss this in the apache way.

First I'd like to apologize with the Apache Commons community, because I 
wanted to keep this conflict out until we could have a solution, which 
honestly we do not have yet beyond a proposal under discussion:

> I'm really confused by this whole situation. This is what happend from my
> POV: the Commons RDF community at one point had the idea of moving to
> Apache Commons (which in my eyes made sense, given that fact the Apache
> Commons is a place to share code between Apache projects). You really began
> pushing things, you even requested a git mirror on behalf of the Apache
> Commons project from Infra, which now is unused [1]!
> Then Commons RDF decided that it didn't what to join Apache Commons
> anymore, which was okay (at least for me).

Since I was the person who push for that step, I fell I need to properly 
explain it.

I think at that stage we had three issues: The first one was about git, 
and how the tool was used for agreements on the design. Second, the 
single mailing lists was understood as a barrier for communication. And 
the third, Commons RDF was not yet providing an implementation.

OK, the first one was easy to solve; even if we may loose the nice 
github interfaces, we can keep the workflow based on PRs, that's fine. 
The single mailing list was in fact seen as a kind of problem; on the 
one hand, getting so much noise, but on the other hand also generating 
noise irrelevant for another projects. And about the third one, once we 
got established the API we are in a much better position to provide 
basic implementations. And that's why temporally decided to go back to 

> Later Reto showed up and wanted to try things out in the Apache Commons
> Sandbox. This is perfectly okay for us. Every Apache Committer may start
> new ideas in our sandbox (in fact we lately granted commit access to all of
> our repositories to all ASF committers [2]). However to actually grow out
> of the sandbox and become a proper component, there has to be a community
> around said component. At the moment, I don't see such a community around
> the Apache Commons Sandbox RDF component. But who knows, maybe there will
> be such a community one day? Maybe not. We do not force things. We just let
> people work with the code (inside the sandbox) the way they like. The is no
> threat to this component at all. We don't have an evil plan to destroy
> Commons RDF.
> The differences regarding how to implement the RDF spec is not of our
> business. None of the current Apache Commons team know RDF. Who are we to
> judge which approach is the right one?

We started Commons RDF with the vision of aligning, and allowing 
portability, across the two major and already established RDF libraries 
(Apache Jena and OpenRDF Sesame). I neither have nothing to say how each 
library interpreted and implemented the RDF specification. But I know 
quite well the troubles that that duality causes even for basic things. 
Therefore we started a trip together those tow project (Andy and Peter 
and traveling with us) for designed a basic API that can be considered 
"common". And that's what we have now at github.

I'm not against other implementations, more basic or bound to concrete 
use cases, that's good. But I think just yet-another API would not help. 
And here where we come closer to the point of conflict: the current code 
at Apache Commons Sandbox RDF proposes a new API as a Commons bound to 
an existing implementation (Clerezza) with a very low adoration in the 
developers community, forgetting the background and ignoring it makes 
the incompatibility issue even bigger.

Therefore my proposal for Commons RDF is the following:

* Commons RDF proposes an API that addresses portability issues. I'd 
recommend to start form what we currently have at github which was 
actually designed by committee and both Jena and Sesame already started 
to implement.
* We evolve the current design in the context of Apache Commons Sandbox
* We keep separated the API from the implementations:
* We keep clear the point that the major established RDF Toolkits 
(Apache Jena and OpenRDF Sesame) are the recommended implementations
* We make an open call for contributing basic implementations to the 
project. We can adopt the one provided by Stian, and also work with Reto 
to move the Clerezza-based implementation (aka Apache Commons Sandbox 
RDF) to that API (what seems to be what he is willing to do anyway). The 
feedback from those implementations would be consider for evolving the API.

We can easily organize in different Maven artifacts if we all agree on 
this setup.

> I hope we can settle this issue once and for all. Right now it feels like
> "Apache Commons are the bad guys" and I don't think we deserve this.

I think we never said that, and I personally do not have that feeling. 
We are people with experience in Apache, and we do respect each project, 
specially one as good as Apache Commons.

I just want to ask about the option of having a dedicated dev mailing 
list, keeping the general style for announcements or things relevant for 
the whole project

I really believe we can arrive somewhere.

Thanks for bring this discussion, Benedikt.


Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message