LDP PATCH Proposals
Contents
1 TurtlePatch 2011
Link: http://www.w3.org/2001/sw/wiki/TurtlePatch
Author: Sandro (circa 2011)
Summary: subset of SPARQL Update with INSERT and DELETE clauses.
Example:
PREFIX foaf <http://xmlns.com/foaf/0.1/> PREFIX s <http://www.w3.org/2000/01/rdf-schema#> DELETE DATA { <http://www.w3.org/People/Berners-Lee/card#i> foaf:mbox <mailto:timbl@w3.org> } INSERT DATA { <http://www.w3.org/People/Berners-Lee/card#i> foaf:mbox <mailto:timbl@hushmail.com> <http://www.w3.org/People/Berners-Lee/card> s:comment "This is my general description of myself.\n\nI try to keep data here up to date and it should be considered authoritative." }
Pros:
- can be implemented using full SPARQL implementation
- easy to implement from scratch (parser + runtime)
Cons:
- no support for bnodes
Status:
- implemented in Banana-RDF
Remarks:
- Sandro talked about "TurtlePatch plus variables" but this is not in the spec
- James Leigh argues that
with blank node identifiers [through skolemization], the above solution handles blank nodes quite well, IMHO, without any of the NP problems other solutions have
2 RDF Patch
Link: http://afs.github.io/rdf-patch/
Champion: Andy Seaborne
Summary: diffs for RDF dataset
Example: (A is for Add and D for Delete)
A <http://example.org/alice> <http://xmlns.com/foaf/0.1/name> "Robert" . A <http://example.org/bob> <http://xmlns.com/foaf/0.1/knows> <http://example/alice> . A <http://example.org/alice> <http://xmlns.com/foaf/0.1/name> "Alice" . D <http://example.org/bob> <http://xmlns.com/foaf/0.1/name> "Robert" . A <http://example.org/bob> <http://xmlns.com/foaf/0.1/name> "Bob" .
Pros:
- easy to implement from scratch (parser + runtime)
Cons:
- specified for an RDF dataset, not an LDPR
- blank nodes are system dependant, so not well specified in the case of LDP. Skolemization?
Remark: actually pretty much the same than TurtlePatch, but it feels like it was written for a different use-case.
3 EricP's proposal
Champion: EricP
Summary: SPARQL subset with DELETE, INSERT and WHERE clause. The WHERE clause is restricted to a simple BGP with no var-predicates (see grammar).
Example:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
DELETE { ?s foaf:name "Alex" }
INSERT { ?s foaf:name "Alexandre" }
WHERE { ?s foaf:name "Alex" }
or
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DELETE { ?bob foaf:knows ?alice } INSERT { ?bob foaf:knows ?eve ; foaf:trusts ?eve } WHERE { ?bob foaf:knows ?alice . ?alice foaf:mbox <mailto:alice@example.org> . ?eve foaf:mbox <mailto:eve@example.org> }
which involves two disconnected query patterns.
Pros:
- can be implemented using full SPARQL implementation
- in practice, still easy enough to implement from scratch (parser + runtime)
- can be used to reach some bnodes
Cons:
- some queries can be NP-complete, e.g.
?a foaf:knows ?b . ?b foaf:knows ?c . ?c foaf:knows ?d . d foaf:knows ?e .
Status:
- implemented in Banana-RDF
Remark: one could argue that in practice, LDPRs are not supposed to be crazy big, and that most queries won't end up with the worst-case complexity.
4 EricP's proposal + nailed graph
Champion: TimBL
Summary: same as previous one, but the BGP returns a single matching node. Some additional constraints are put on the query: nailed nodes and IFP (Inverse Functional Property).
Pros:
- can be implemented using full SPARQL implementation
- in practice, still easy enough to implement from scratch (parser + runtime)
- can be used to reach some bnodes
- expected not to be NP-complete
Cons:
- we further restrain the number of bnodes that can be matched. Shouldn't be an issue in practice.
Status:
- I implemented a similar restriction in Banana-RDF when the BGP is a tree pattern.
- TimBL told me that Tabulator already implements that approach.
4.1 Definition of a nailed graph (TimBL)
A nailed graph is a graph for which every node is nailed.
A nailed node is one which has a URI or is connected to a nailed by a inverse functional or function property arc of the appropriate direction.
- if n has a URI then {} nails n.
- if p is IFP and W(m) nails m then { n p m } U W(m) nails n.
- if p is FP and W(m) nails m then { m p n } U W(m) nails n.
A nailed graph is a graph in which every node n is nailed.
When doing a patch the WHERE clause is the union of the nailing graphs of the variables which have been inserted to match bnodes.
[ Sandro comment: I'd change this to be talking about graph shapes, where "FP" is the property of a predicate occurring in the graph only in 1-to-1 or many-to-1 configurations, rather than the actual OWL notion of a Functional Property, which isn't actually about the graph itself. ]
5 Joe Presbrey's PATCH
Champion: Joe Presbrey
Summary: format is Turtle. For each triple { s p o }, { s p ANY } is deleted and { s p o } is added. His implementation forbids the use of blank nodes.
Pros:
- super easy
Cons:
- can't have { s p o1; o2 } anymore
- can't delete
- no bnodes
Status:
- Joe implemented this approach in one of his projects (I guess either data.fm or ldpy)
6 Pierre-Antoine Champin's RDF-PATCH
Link: https://github.com/pchampin/rdfpatch
Champion: Pierre-Antoine Champin
Summary: extends RDF Patch with property paths, rdf:list shortcuts. Binding variables is mentionned but not yet specified.
Example: (more examples here)
- example of complex path
A <http://champin.net/#pa> -<http://xmlns.com/foaf/0.1/member>/<http://xmlns.com/foaf/0.1/homepage> <http://www.univ-lyon1.fr/> . A "Andy Seaborne" -<http://xmlns.com/foaf/0.1/name>/<http://xmlns.com/foaf/0.1/nick> "AndyS" .
Pros:
- more capabilities than Andy's version
- native support for rdf:list
- can access some bnodes through URI + property path (without knowing label)
Cons:
- relies on skolemization for general handling of bnodes
- not a sybset of SPARQL Update (but easy syntax)
Status:
- implemented (with a test suite) at https://github.com/pchampin/rdfpatch (in Python + rdflib)
7 GRUF
Link: http://websub.org/wiki/GRUF
Author: Sandro (circa 2010)
Summary: A namable-blank-nodes custom format, with list operations
Pros:
- Efficient
Cons:
- Like rdf-patch, it's not exactly RDF
8 TurtlePatch 2014
Revision of TurtlePatch (Sandro, 2014) to say: use virtual Skolemization. That is, when you GET or PATCH a resource through application/turtlepatch, you see/manipulate a Skolemized view. This solves the blank node problem.
