All, I am just reading Reto's email and the links he provided. His story resonates and I share most of his concerns. I am still not sure of the goals and scope of this project beyond getting Jena and Sesame under the same roof, as least for some parts...
I guess banana-rdf is here to stay :-/ Alexandre On Tue, May 19, 2015 at 10:00 AM, Reto Gmür <[email protected]> wrote: > Hi all, > > While I think this project is making good progress for a common API for > triple stores, there seems to be no motivation to address the issues which > in my opinion prevent it from being a generic RDF API. > > In my opinion an essential albeit controversial aspect of RDF is not being > appropriately modeled with the code in the project. I've tried to start > discussion on this issue based on actual code implementing use cases to > show advantages/disadvantages of the various approaches. Unfortunately I > don't see the willingness to allow such an evidence based evaluation or any > disposition to compromise. The code from the github project is regarded as > the authoritative reference against which changes need a consensus to be > accepted. > > I'm also disappointed that this code has now been published as commons:rdf, > despite me raising objections against this name. One reason for the > objections is that in the clerezza community there was the idea since its > incubation to publish the RDF API as a commons project eventually. > Currently the clerezza commons RDF API is imho closer to the standard, is > proven to work by having adapters against various backends and is actually > in use in two apache projects. Nobody at clerezza would mind adopting a new > carefully designed and standard compliant RDF API, however the current > proposal does not satisfy our requirements that motivated us in the first > place to design an API against the standard rather than against concrete > implementations. > > To provide a bit more details about the debate: > > Many people would prefer not to have blank nodes in RDF or to have them in > a way that they loose their essential properties (11 years ago I had such a > view too: http://markmail.org/message/tjmi4uyybahl3n7n). An API for RDF > should in my opinion model the abstractions which are present in the > standard and not extend them based on how one would like the standard to be. > > The introduction of blank node identifiers (beyond the limited scope of > concrete serializations) in my opinion massively reduces the usefulness of > the concept of blank nodes, if anonymous node get assigned a name they are > no longer what they are supposed to be. > > To show that this is not a purely theoretical debate I've shown code > examples that can only be easily implemented without blank node labels[1]. > On the other hand with https://issues.apache.org/jira/browse/COMMONSRDF-13 > I've asked for example code showing the alleged practical advantages of > exposing such an artifact. Actual code would either allow me to see that > some use cases can indeed not (easily) be implemented without these labels, > or else to provide an implementation that shows that the use case can be > implemented without. > > So anyway after a lot of not so rewarding discussions I have to move > forward and focus on communities where I can be creative and code. There > certainly is some talent in this community and it's good if the makers of > major triple stores discus on a common API, but quite clearly for the > apparent aims of the project I'm neither need nor particularly wanted. I > would have preferred it's name not to claim to model the RDF standard when > in fact it promotes a particular reduction/interpretation/trivialization of > the standard. > > Cheers, > Reto > > > [1] this is: > - A Sparql backed implementation: > http://mail-archives.apache.org/mod_mbox/commonsrdf-dev/201503.mbox/%3CCALvhUEVOnkBsZe-=8sgmboorsefb3urimhgyzqllu8f+n34...@mail.gmail.com%3E > - Wrapping Java Object as RDF: > http://mail-archives.apache.org/mod_mbox/commons-dev/201504.mbox/%3CCALvhUEXZekZwd4JQ1TdnjH32HVybrohHORrWUYmqyTwTrJ%3DqiA%40mail.gmail.com%3E > > On Tue, May 19, 2015 at 10:40 AM, Sergio Fernández <[email protected]> > wrote: > >> Hi everybody, >> >> it's time to move forward the project, in different lines: >> >> * Last week we have published our first release (0.1.0-incubating). Now we >> should work together to support its implementation in the different >> libraries (Jena, Sesame, Clerezza, Banana, etc.) >> >> * That should be the basics for improving and refactoring the API towards >> 0.2.0. We already have many things registered on Jira, and we have to start >> to work on prioritize them. >> >> * In parallel we could still maintain the 0.1.x simple implementation (I >> created a 0.1.x-maintenance branch for that), although I'd not put that as >> the main focus of the project. >> >> Anything else? All feedback is always very welcomed! >> >> Cheers, >> >> -- >> Sergio Fernández >> Partner Technology Manager >> Redlink GmbH >> m: +43 6602747925 >> e: [email protected] >> w: http://redlink.co >>
