On 21/06/13 18:31, Rob Vesse wrote:
I went ahead and submitted a pull request for various
typographical/editorial tweaks
I've added a use case section that talks about HTTP PATCH. Not really a
"use" (why did the app call PATCH?) but going back, it's good to point
out the role it could play in PATCH.
I also went ahead and renamed Minimise Actions to Canonical Patches as
that makes a much clearer name for it, not sure this is quite the correct
terminology though
That's a better name ...
Maybe just call it "reversible", which is the main point.
Or a "Strong RDF Patch"
Andy
Rob
On 6/20/13 3:38 PM, "Rob Vesse" <[email protected]> wrote:
I did read some of the working group discussions around the patch format
and some of the stuff they were discussing made me want to cry at the
horrific syntax abuses some people were proposing to make
Steering them towards something that is simpler like RDF patch would seem
a good idea
Rob
On 6/20/13 3:03 PM, "Andy Seaborne" <[email protected]> wrote:
BTW, I got a ping from LDP-WG about a patch format. That WG want
something sub-SPARQL, this maybe a useful input.
I've looked before at RDF-encoded versions (Talis ChangeSets, using
TriG) but without further syntax or processing rules, they don't stream
and it needs a whole request read in before processing. That a severe
limitation.
Example:
@prefix diff: <http://example/diff#> .
@prefix : <http://example/data#> .
<#g2> { :s :p 456 }
<#g1> { :s :p 123 }
<#g1> { :x :q "foo" }
{ <> diff:delete <#g1> ;
diff:insert <#g2> .
}
with the manifest default graph last, you can't tell anything about
<#g1> or <#g2> so the best I can imagine is to stash them away somewhere.
And does not cope with datasets (a graph-grouped complex manifest would
work but then any simplicity is lost and production of such patches is
looking a bit troublesome)
And then there's blank nodes.
Restricted SPARQL Update(INSERT DATA, DELETE DATA) sort of works ...
except bNodes. An advantage is adding naturally "DROP GRAPH" and
"DELETE WHERE".
Andy
