Re: Abstract syntax for updates

I would like to draw the WG's attention to a problem with all these proposals to use SPARQL-style syntax to modify, update or alter RDF graphs by adding or deleting triples. It is not a problem with their substance or intent, but a conceptual difficulty. None of these proposals make sense as stated; they conflict with the basic RDF conceptual model as normatively specified in [1]. 

The basic issue is that an RDF graph is defined to be a mathematical set of triples, and sets do not have state. It is impossible to modify a set, or add triples to a set or delete triples from a set, since any such additions or modifications will result in a different set. A set is defined by its members, and has no other criteria of identity. Thus it does not make sense to speak of 'adding A to {B, C}'. One can construct the set {A, B, C}, of course, but this set cannot be identical with the set {B, C} unless A is identical to one of B, C. 

Now, it is quite clear what the updating proposals actually mean. They are using the term 'RDF graph' to refer to a computational entity which might be called an RDF resource, ie a datastructure or document of some kind which represents an RDF graph, and can be modified by adding or deleting triples, and then represents a different RDF graph, one with more or fewer triples in it. But these entities are not themselves RDF graphs, and indeed do not correspond to anything in the RDF concepts document. 

One might well draw the conclusion that this mismatch between the normative language in the RDF specifications, and the obvious practical business of dealing with RDF representations, illustrates a failure or omission in the RDF specs themselves; and I would agree. (See the slides in [2] for more on this topic, where the term 'surface' was used for what I am here calling an RDF resource.) Nevertheless, I feel it is important to keep the terminology correct as it currently stands, even at the cost of being somewhat longwinded. So I suggest that these documents all first define a notion something like  what I have temporarily called "RDF resource", and then use this terminology rather than "RDF graph" when speaking of updating. (The thinking behind this terminology, BTW, is inspired by Fielding's notion of a Web resource as a time-dependent emitter of representations, in his influential REST model.)

Pat Hayes

[1] http://www.w3.org/TR/rdf-concepts/
[2] http://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk

On Oct 12, 2010, at 10:38 AM, Axel Polleres wrote:

> Dear Ross,
> 
> Thanks for the input which the group may consider for defining the formal update semantics. We have not formally acknowledged this before now, as the specification has been been under active modification. Being a committee process means that the evolution of the specification may not necessarily align with any one contribution.
> 
> You can check the current working draft of the SPARQL/Update specification that the group is working on, which is an evolution of the SPARQL/Update proposal you cite in your paper [4], at:
> 
> http://www.w3.org/TR/sparql11-update/
> 
> (please note that there will be a new release of this document by the end of this week, so you might want to hold off until then to check details)
> 
> You should find that this aligns with your proposal in some instances, though it differs significantly in others.
> 
> Comments on this document and its future versions are/will be highly welcome!
> 
> Thanks, Axel, on behalf of the WG
> 
> 
> On 31 Mar 2010, at 12:32, rjh06r wrote:
> 
>> DAWG,
>> 
>> I have been working on an abstract syntax for an RDF Update language which deliberately has much in common with SPARQL Update. The syntax presented, [1], concisely tackles several issues discussed in this group. For instance...
>> 
>> - Conditions (WHERE etc) are captured by guarding updates with an internalised SPARQL query.
>> 
>> - Blank nodes are handled by a query discovering the node. The discovery moves the scope of the blank node around the query so that they may be treated in the same way as URIs.
>> 
>> - Named graphs are primitive enabling the declaration of federated queries and updates.
>> 
>> - Optional extensions, choice and recursion, offer significant power for updating linked lists and other linked data structures. The syntax is fully concurrent.
>> 
>> The languages is explained in detail in the paper, [1]. The introduction replicates the examples in the SPARQL update specification, if the syntax is a barrier. The last sentence may be controversial. Perhaps the operational semantics mimic some of your intuition...
>> 
>> Regards,
>> 
>> Ross
>> 
>> 
>> [1] http://eprints.ecs.soton.ac.uk/18602/
>> 
>> --
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 13 October 2010 14:39:12 UTC