This is because you want to write things like

<kkk> :rel [ :- &lturn:bnode:xyz>;
a foaf:Person;
foaf:mbox <mailto:joe@eg.com> ] .

instead of

<kkk> :rel <urn:bnode:xyz> .
<urn:bnode:xyz> a foaf:Person;
foaf:mbox <mailto:joe@eg.com> .

The :- keyword (timbl also proposed ‘is’) just gives a name to the blank node. It’s semantically equivalent to owl:sameAs,
on an infering DB, but most DBs won’t be inferring. But it allows the human reader to see the structure of the graph a lot more easily, especially as the graph gets larger. Perhaps one can think of it as the equivalent of the rdf/xml ‘about’ attribute.

Henry

http://nurture.nature.com/tony/yads/

Blurb reads as such: “YADS implements a simple, safe and predictable recursive data model for describing resource collections. The aim is to assist in programming complex resource descriptions across multiple applications and to foster interoperability between them.”

So, the YADS model makes extensive use of bNodes to manage hierarchies of “fat” resources – i.e. resource islands, a resource decorated with properties. The bNodes are only used as a mechanism for managing containment. There is certainly no intention to globally reference the bNode “resource”. I guess one could say that the actual resources managed by YADS (those accorded a URI) are qualified (witth properties) *in context*. That is in the context of the complete YADS description. The “fat” resource managed by the bNode does not have or need a permanent global identifier.

Seems to me that bNodes perform a very useful function. Yes, I am aware of the “smushing” problem but I think this is a red herring. bNodes give us the possibility of creating local “clumpiness” within the general RDF graph. If everything is reduced to global resources then the RDF graph will remain flat and homogenous and generally unspeakably uninteresting. IMHO. Like the primitive universe with no synthesis of elements and especially the heavier elements. Just a primordial soup.

I think Danny is also “spot on” when he talks about the cost of minting URIs. As a publisher we are all too aware that URIs are expensive to maintain. This is why scholarly publishing in particular has invested considerable effort in developing the DOI (Digital Object Identifier – http://doi.org/) as a solution to maintaining persistent reference linking (see also CrossRef – http://crossref.org/). Even disposable URIs have an associated cost to mint. I guess top of my head the only no-cost solution to minting URIs would be data: URIs because there is no naming authority to contend with. (I’m not sure about the ethics of using someone else’s DNS name in a tag: URI.)

In sum, bNodes are useful. Less is more.

urn:bnode:sflsdjflskdjflksdjf

Great podcast with Nova Spivak btw.

From my work at Talis, and from conversations with many people putting RDF to work, being able to diff and patch RDF graphs is very very important. You just can’t do that sensibly with the endless indirection that bnodes require. With named nodes (URIs or literals) it’s trivial.

I also don’t think your example is any more difficult with a URI vs a bnode. True, it’s easier to write down in N3 using bnodes, but it’s almost the same markup for RDF/XML. Also, just because it’s written down as a blank node doesn’t mean it has to be parsed that way into a triple store – the parser could substitute generated URIs and nothing would break, no meaning would be lost.

Having said that bnodes should be avoided if good uris can be found. And often with a little web site organisation uris can be created for people for example. It certainly helps a lot to have dereferenceable urls. Exchanging bnodes for URNs does not seem to give one much, apart from the trouble of having to mint urns.

There is a good case for bnodes. Imagine you tag something with “bank”. You want to say something like

</page.html> :tagging <http://tagger.com/bblfish/tag/10002>.
<http://tagger.com/bblfish/tag/10002> :by <http://bblfish.net/people/card#me>;
:tag [ a skos:Concept;
skos:label “bank” ] .

Here you say that you are tagging something with a concept, but you don’t yet know which concept it is.
Perhaps later that tag can be nailed down as being a and then the blank node will be given a URI.

This helps keep things indeterminate while they are.

I’m not entirely convinced that bNodes should be removed from RDF. But avoiding them for practical reasons is usually a good idea.

I did think of one thing that bnodes give you over using a URI: they are guaranteed to be safely handled when smushing documents, i.e. that can be used to prevent accidental merging that could occur when the same URI were inadvertently used in two documents. But we smush documents containing a mix of URIs and bnodes all the time and this has never really presented itself as a problem, so I think it’s only a minor advantage.

The other thing to consider is that in every RDBMS implementation of RDF I have seen bnodes are converted to URIs internally so they can be stored in the subject column of a triple table.