Linked Data, Blank Nodes and Graph Names

Hi All,

To cut a long story short, blank nodes are a bit of a PITA to work with, 
they make data management more complex, new comers don't "get" them 
(lest presented as anonymous objects), and they make graph operations 
much more complex than they need be, because although a graph is a set 
of triples, you can't (easily) do basic set operations on non-ground 
graphs, which ultimately filters down to making things such as graph 
diff, signing, equality testing, checking if one graph is a super/sub 
set of another very difficult. Safe to say then, on one side of things 
Linked Data / RDF would be a whole lot simpler without those blank nodes.

It's probably worth asking then, in a Linked Data + RDF environment:

- would you be happy to give up blank nodes?

- just the [] syntax?

- do you always have a "name" for your graphs? (for instance when 
published on the web, the URL you GET, and when in a store, the ?G of 
the quad?

I'm asking because there are multiple things that could be done:

1) change nothing

2) remove blank nodes from RDF

3) create a subset of RDF which doesn't have blank nodes and only deals 
with ground graphs

4) create a subset of RDF which does have a way of differentiating blank 
nodes from URI-References, where each blank node is named persistently 
as something like ( graph-name , _:b1 ), which would allow the subset to 
be effectively "ground" so that all the benefits of stable names and set 
operations are maintained for data management, but where also it can be 
converted (one way) to full RDF by removing those persistent names.

Generally, this thread perhaps differs from others, by suggesting that 
rather than changing RDF, we could layer on a set of specs which cater 
for all linked data needs, and allow that linked data to be considered 
as full RDF (with existential) when needed.

It appears to me, that if most people would be prepared to make the 
trade off of loosing the [ ] syntax and anonymous objects such that you 
always had a usable name for each thing, and were prepared to modify and 
upgrade tooling to be able to use this not-quite-rdf-but-rdf-compatible 
thing, then we could solve many real problems here, without changing RDF 
itself.

That said, it's a trade-off, hence, do the benefits outweigh the cost 
for you?

Best,

Nathan

Received on Thursday, 7 April 2011 17:46:57 UTC