Re: Considering a PATCH model for LDP

ISSUE-17

-----

Another factor to consider is how patches are processed and how they 
combine.

e.g. streaming
e.g. combining patches.

The abstract model covers this but the Trig documents don't follow the 
model in a natural way.

Refined text for the model proposed.

-----

[[
The semantics of the PATCH model are based on SPARQL Update. Namely the 
subset of SPARQL Update is limited to:

     Subset of INSERT DATA
     Subset of DELETE DATA
]]

but clarify that a SPARQL Update is a sequence of operations, performed 
in the order give.

[[
A LDP-PATCH update is a sequence of changesteps, with each changestep 
performed in the order in the sequence.

A changestep is either:

DELETE DATA (with no GRAPH)
INSERT DATA (with no GRAPH)
]]

== TriG documents

The TriG document approach dopes not fully reflect these semantics (the 
original or refined text).

The advantage of the TriG-ish format is being about to reuse a general 
parser.  If addition restrictions are added to align to the model there 
is, in effect, a new language, requiring a new parser to validate it so 
the advantage of reusing TriG has been lost.

For example: combining two patches (any of the TriG suggestions has 
these issues):

{ <> ldp:insert :g1 ; ldp:delete :g2 }
:g1 { ... }
:g2 { ... }

+

{ <> ldp:insert :g3 ; ldp:delete :g4 }
:g3 { ... }
:g4 { ... }

==> the concatenation as files is the same as:

{ <> ldp:insert :g1,g3 ; ldp:delete :g2,g4 }
:g1 { ... }
:g2 { ... }
:g3 { ... }
:g4 { ... }

which has lost the order of g2->g1->g4->g3 needed for changesets 
(deletes and inserts don't freely mix).

Even the OSLC original version

oslc:deleteGraph {}
oslc:insertGraph {}

behaves differently in a merge (the ordering of deletes and inserts 
changes).

And Trig does not say each name is used once:

oslc:deleteGraph {}
oslc:insertGraph {}
oslc:deleteGraph {}
oslc:insertGraph {}

will be legal TriG (but does not do delete-insert-delete-insert, it does 
all deletes, then all inserts; it is not streamable).

== Streaming

Changes can be applied as received, not waiting for end of request.

The TriG format would require parsing the whole file before executing 
because a processor must do all the deletes before the inserts but the 
format does not require the deletes to be either contiguous or even 
first in the file.

In the refined model, execution is more clearly in order received.

== Composition

If we have two patches, P1 and P2, then the TriG merge is not the same 
as P1 then P2.  Concatenating the documents is not the same as 
performing one operation then the other (you have to sort out the bNode 
labels - it's a text processing step, not a deep analysis of the operation).

Being able to combine patches is useful because we don't have 
multi-operation transactions over HTTP. Consolidating a number of 
patches together means you can ship around a single change unit that can 
be applied atomically.

(c.g. a git or hg push - a number of commits in order)

== If TriG

if you want a TriG format, then

{ <> :changes ( <#del1> <#ins1> <#del2) ) }

<#del1> { ... }
<#del2> { ... }  ## NB order of graphs does not matter
<#ins1> { ... }

nearly works (not streamable, concatenation does not work on lists).

	Andy

Received on Sunday, 17 March 2013 16:16:50 UTC