Re: Abstract syntax for updates

* Pat Hayes <phayes@ihmc.us> [2010-10-13 09:38-0500]
> 
> 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.)

Hmm, I'm trying to sort through the implications of resource... RDF uses URI references to identify resources. RDF syntax labels objects with the XML attribute rdf:resource. While I agree in principle, I'm not sure that the world doesn't see "resources" as the things in RDFXML's rdf:about="" or in turtle's <>s.

Can't we address this by separating graphs from their lables? (I'm not sure exactly which bits of text you read as adding to graphs.) For example:

s/This property specifies the RDF named graph
 /This property specifies the lable of an RDF named graph/

Noting that "An R2RML mapping defines a mapping from a relational database to an RDF dataset", I'm expecting that this dataset is a set of RDF graphs (set of sets of triples). Can we define this by functional inclusion: the dataset includes the graphs produces by Foo() and Bar(); Foo() produces graphs with FooPrime for each column...?

> 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
> 
> 
> 
> 
> 
> 

-- 
-ericP

Received on Wednesday, 13 October 2010 15:05:16 UTC