Re: [Sem] Fully worked out example for the “store the log of the execution of a SPARQL update” case

Here are my thoughts on deltas (which aren't SPARQL update logs).

A delta is represented as an instance of delta:Delta with properties 
delta:delete, delta:add, and delta:graph.
The properties delta:delete and delta:add have as value a list of quoted 
triples.   The property delta:graph is an identifier of a graph.  The delta 
represents the removal of the the triples in delta:delete from the graph 
identified by delta:graph followed by the addition of the triples in delta:add 
to it.  There may be other properties, for example allowing chaining of deltas 
or providing timestamps.

For example,
:delta1 rdf:type delta:Delta ;
   delta:graph my:graph ;
   delta:delete ( << :a :b :c >> << _:d :e :f >> << _:x :e ;f >> ) ;
   delta:add ( << :x :y :z >> << _:k :u :v >> << _:l :y :v > ) .

Each triple is fully opaque, even the blank nodes, which are treated as actual 
blank nodes in the target graph so the above does not fully capture a delta as 
it is only a surface representation of the underlying reality of blank nodes 
in my:graph.

Systems that work with deltas require a direct connection between blank node 
identifiers and blank nodes.   Either there is a surface syntax where all 
blank nodes have identifiers and blank node identifiers uniquely identify a 
particular blank node, or both graphs form part of an RDF system (perhaps 
distributed) that has a common internal representation of blank nodes.

As far as inferences go, blank nodes in the quoted triples are treated as 
constants so that (in a standard reading of blank node identifiers) the above 
graph does not even entail

:delta1 delta:delete ( << :a :b :c >> << _:d :e :f >> << _:x :e ;f >> ) .

as the common blank node identifiers between the two graphs identify different 
blank nodes.



On 5/12/23 06:04, Franconi Enrico wrote:
> Even if we don’t have the actual use case, would it be possible that some of 
> you tries to write down before today's meeting a /fully worked out example/ of 
> the expected behaviour of the “store the log of the execution of a SPARQL 
> update” case?
> This use case apparently still eludes the currently known variants of the 
> semantics for RDF-star explored so far.
> cheers
> —e.
> 
>> So we focussed on the semi-transparent case, which turned out that it could 
>> have several different interpretations, depending on how we interpret 
>> bnodes. So, we started to discuss “What’s in a semi-transparent bnode”. We 
>> considered the use case (?) on how to characterise in RDF-star the log of a 
>> SPARQL update.
> 
>

Received on Friday, 12 May 2023 11:45:00 UTC