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 >
