Re: RDF PATCH and Downstream consequences of blank nodes [was Re: SPARQL Profile for PATCH]

On 2014-09 -23, at 22:34, David Booth <david@dbooth.org> wrote:

> BTW, I want to draw attention to the fact that the need for defining an RDF-specific PATCH operation is *entirely* a consequence of RDF's allowance of unrestricted blank nodes.  I do not think that blank nodes should be eliminated from RDF, but I am convinced that RDF's current treatment of blank nodes is a significant design flaw that has *many* downstream effects that are ultimately detrimental to RDF's adoption. The need for RDF PATCH is another example.

I disagree.  Most people use blank nodes in a reasonable fashion. 

> 
> Unix/linux diff and patch utilities have been used successfully for *decades*, with many other information representations.  Imagine how simple and easy it would be if we could just generate canonical N-Triples and use standard diff and patch against that!

You can do that if you want.
With RDF you have a graph, not a tree.  Not an ordered list.
There are canonicalization algorithms as you know. Just not a standard.

For many of my applications, the app which changes the data knows what it is changing and so the diff does not have to be generated form the new and old graph. The UI widget which changes the value knows what it is changing.


>  But we can't, because blank nodes are unstable across RDF serializations and no canonical way to generate them has been standardized.  This, in turn is because generating a canonical form of unrestricted RDF is a hard problem (NP-complete), because of blank nodes.  The problem is *much* easier if the use of blank nodes is limited to *implicit* blank nodes -- those that are generated implicitly by the use of square brackets "[]" or parentheses "()" for lists in Turtle -- and indeed this is the vast majority of blank node use.  (See "Everything You Always Wanted to Know About Blank Nodes", by Hogan, Arenas, Mallea and Polleres:
> http://www.websemanticsjournal.org/index.php/ps/article/viewFile/365/387 )
> 
> For this reason the use of "Well Behaved RDF" was proposed, which limits the use of blank nodes to implicit blank nodes:
> http://dbooth.org/2013/well-behaved-rdf/Booth-well-behaved-rdf.pdf
> I don't know if Well Behaved RDF is the best solution to this problem. Maybe someone will come along with a better idea.  But I am convinced that the current treatment of blank nodes in RDF is a serious problem that we should fix in order to make RDF simpler to use, understand and adopt.

I think that in theory the paper you quote http://www.websemanticsjournal.org/index.php/ps/article/viewFile/365/387
does a nice job and in practice people tend to use them in a constrained way. 
You have one definition of well-behaved RDF.

Two others are:

Locally: - Each blank node can be uniquely identified WITHIN THE GRAPH IN QUESTION by a path from a non-blank node or constant.

Globally: - Each blank node can be uniquely identified WITHIN THE WORLD by a path over [inverse] functional properties  to a non-blank node or constant.

We discussed this in a diff paper ages ago...  I can't find the paper but here is a some code from 2005:

	https://www.w3.org/2000/10/swap/delta.py

This generates diffs. cwm will accept  diffs to patch a graph.
See https://www.w3.org/2000/10/swap/test/delta/detailed.tests


> I really don't like having to make excuses for RDF when it cannot be used in a similar way as nearly every other information representation -- such as being able to easily compare two RDF documents for "equality" (which in RDF becomes a complex graph isomorphism problem) or generate a simple diff and patch -- all because of RDF's unrestricted treatment of blank nodes.

Here is some code from 2003:
	https://www.w3.org/2000/10/swap/cant.py

This is what we use for testing equality of graphs in the CWM regression test suite.
It works in practice on graphs we use.

> Clearly this is not something that the Linked Data Platform working group can fix.  But I think it is important to bring it to people's attention, in the hope that we will someday soon have the creativity and gumption to fix it.

The LDP WG defines a constrained form of "non-pathalogical" RDF in which their patch system works.

> I should also acknowledge that there are some who do not feel that RDF's treatment of blank nodes is a problem.  Fine.  It may not be a problem to an elite few who are well steeped in the subtleties of description logic, model theory and RDF Semantics, and who don't mind having to use RDF-specific tools instead of generic tools.  But having tried for over 10 years to explain RDF to a wider audience of regular software developers, I am convinced that subtleties like RDF's treatment of blank nodes *are* a problem to a much wider audience of *potential* RDF users who would be more inclined to adopt RDF if it didn't have complexities like this.  As it is they are more likely to stick with JSON or XML, whose complexities they already know, rather than venturing into the obscure and esoteric world of RDF.
> 

I think developers (like me) left to their own devices will produce RDF graphs which are typically tree-like and well-behaved in the ways they need, in fact.

> RDF tools are not as mature as those for XML or even JSON, which is much younger than RDF.  I believe blank nodes are one specific reason they're not.  The fact that we still don't even have a simple, standard way to compare RDF documents and compute diffs and patches, is a perfect example.

I think blank nodes are valuable and essential.  I would hate to have to clutter my data with names for those nodes.

RDF tools have been around for a while.

(I have it on my (rather long) agenda to move the SWAP (cwm etc) suite from the old CVS repo to github, as it could do with some TLC, but I use it all the time.   I just tried the CVS to git import and it fails "Fetching RDFSink.py   v 1.3.2.1 \n Unknown: error " ... sigh) 

Repo - http://dev.w3.org/cvsweb/2000/10/swap/

Tim

> David
> 
> 

Received on Wednesday, 24 September 2014 05:59:35 UTC