Thanks to the path into which I got involved in RDF I initially hated blank nodes. These days I use them a lot.
A use case I am interested in now is "document centric" where RDF competes (and cooperates) with XML and (particularly) JSON. People like the JSON data model, and in JSON-LD RDF Containers are exposed. Although Containers are often thought of part of the "old" RDF, they are essential for RDF to be a comprehensive data format. Containers solve many practical problems. For instance, the XMP spec from Adobe nails down a number of ambiguous points, and one thing it does is use a Collection to hold the names of the authors of a document. People care what order the authors are presented in, and this is an easy way to represent it. When I RDFize data that comes in from the outside that is (more or less) tabular, I usually create a blank node for each row. This works for the case where there is no primary key, but even in the case where there is a prikey, I start with the blank node representation and then, after the record is created, transform the record using RDF methods so that a URI generated from the prikey ends up on the left. Beyond that, blank nodes are useful for high-arity predicates and also for representing abstract syntax trees, mathematical formulas and stuff like that. Even though a lot of RDF data is essentially relational, it's awfully nice to have a universal system that handles anything. On Tue, May 19, 2015 at 2:04 PM, Alexandre Bertails <[email protected]> wrote: > 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 > >> > -- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype [email protected] https://legalentityidentifier.info/lei/lookup <http://legalentityidentifier.info/lei/lookup>
