Re: RDF based messaging, negotiating, and dataset semantics

Am 10.07.2017 um 12:25 schrieb Graham Klyne:
> On 10/07/2017 09:24, Florian Kleedorfer wrote:
>> If it was a problem, it seems to me, RDF databases were wrong to 
>> support SPARQL
>> Update, because it allows changes to RDF graphs - but I never read 
>> anywhere that
>> that is problematic.
>>
>
> SPARQL Update allows updates to RDF graph containers, not to RDF 
> graphs.  So no problem there (apart, maybe, from some unclear or 
> muddled use of terminology).
>
> I just checked the SPARQL Update spec [1], and I'd concede the 
> language could be clearer...
>
> "A Graph Store is a mutable container of RDF graphs..." is clear enough.
>
> But a following sentence says "Operations may specify graphs to be 
> modified...", which is less clear.  Read in conunction with the 
> definition of graph in RDF Concepts [2], it becomes fairly clear that 
> it's not the graph that is modified but the container.  Maybe better 
> to have said somethinglike "Operations may specify a graph within the 
> container to be updated..."?
>
> #g
> -- 
>
> [1] http://www.w3.org/TR/2013/REC-sparql11-update-20130321/#graphStore
>
> [2] http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph
>
I agree the specification is a bit confusing.

In section 3.1 "Graph Update" [1], it says:

"Graph update operations change existing graphs in the Graph Store but 
do not explicitly delete nor create them [...]."

and

"The INSERT DATA operation adds some triples, given inline in the 
request, into a graph. This SHOULD create the destination graph if it 
does not exist. [...]. "

This seems to mean that RDF graphs can be modified.

However:

In Section 4.1.1 "Graph Store" [2], it says,
"A Graph Store GS is a mutable container of RDF graphs. It has one 
unnamed (default) slot and zero or more named slots. The unnamed slot 
holds an RDF graph; each named slot is a pair of a graph and an 
associated IRI. The Graph Store can be viewed as a mutable RDF Dataset."

The question is: how is mutability defined? The solution:
4.1.2 "Abstract Update Operation" [3]:
"An Update Operation Op is an atomic operation that accepts some 
arguments Args and transforms a Graph Store GS to another Graph Store 
GS' [...] An Update Operation can create new slots and new RDF graphs, 
or can remove existing slots and the corresponding graphs. It can also 
alter the state of each slot individually. "

I think we have all been talking about the same thing all along:
1. RDF graphs are sets of triples. Sets are different if their contents 
differ, there is no notion of mutability of sets. (That was Pat Hayes' 
point)
2. RDF graph containers, such as RDF datasets or Graph Stores can be 
mutable.
3. RDF graph containers may assign names to RDF graphs.
It follows that an update operation on graph X in the RDF graph 
container causes a new, different RDF graph to be associated with the 
name X, which is derived from the old RDF graph by applying the update 
operation.

In short: RDF graphs are always immutable. Over time, graph stores may 
return different RDF graphs for the same name. Just like a variable can 
take different values. It is obviously not the value that changes (a 4 
does not become a 5), but the variable is assigned a new value. I will 
try to keep that in mind.


1. https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#graphUpdate
2. https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#def_graphstore
https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#def_updateoperation

Received on Monday, 10 July 2017 13:53:54 UTC