Re: First steps on SPARQL Update formal model

On 31 Aug 2010, at 15:46, Andy Seaborne wrote:

> 
> 
> On 31/08/10 12:39, Alexandre Passant wrote:
>>> >  [[
>>> >  Definition: CreateOperation
>>> >
>>> >  A CreateOperation OpC is an UpdateOperation in which (1) a new named slot<j>  and (2) a new graph are created in the GraphStore. The new graph is held in the new slot. Other slots and graphs are not affected.
>>> >
>>> >  OpC(GSS(GS, t)) = (S(DG, t), {(<i>, S(G_i, t)}, (<j>, S(G_j, t+1))
>>> >  ]]
>>> >
>>> >  I think OpC needs to take some argument so we can talk about them on the RHS.
>> Makes sense, I've added the following the the update operation definition:
>> 
>> ""It can accept some arguments""
>> 
> 
> some arguments for the defintional line.
> 
> Writing as:
> 
> OpC(<IRI>, silent, GSS(GS, t)) = GSS(GS, t) UNION (<IRI>, {}_t+1)
> 
> Gives opC arguments IRI and silent as well as the graph store.  The introduction of <IRI> means it's appearance on the RHS is connected to the operation.

Updated OpCreate and OpDrop with RHS.
Still wondering if t must be kept or not with the new notation, I'll think of it once we get all operations with their formal model.

> 
>> Should silent be in the formal model ?
>> To me, it's more from the implementation pov, as it having it or not does not make any change to the graph state after the operation.
> 
> Could do it that way.
> 
> SILENT affects whether further operations in the request are processed or not.  If the definitions say "this is an error", even if by not defining a particular set of parameters, then SILENT is having a semantic effect of don't generate this error.  That can be handled in the operation or the glue for the request.  It makes more sense to me to add to the operations but that is a style matter, not a requirement.
> 

It affects the upcoming operations but not the current one (neither the graph as said previously).
That's why I rather keep it outside the formal model - unless objections. 

>> If keeping the timestamp, I'd rather use t on the left side, and got t+1 as a result on the right side
>> So OpC(<IRI>, silent, GSS(GS, t)) = something_at_t+1
>> But t might indeed be not needed anymore
> 
> Agreed.  Further observation: requests are the unit of atomicity.  A sequence of operations leads to t being incremented several times but it's the overall effect on the GS that matters going from stare at time t, to state at time t-visble-next.

Will keep that change for later - when t might be dropped.

Alex.

> 
> 	Andy
> 
> 

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Friday, 3 September 2010 14:56:57 UTC