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:
https://github.com/commons-rdf/commons-rdf/issues/43#issuecomment-69916423
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
github.
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.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernan...@redlink.co
w: http://redlink.co
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
