Re: SPARQL update and datasets

On 3/25/2010 6:38 AM, Axel Polleres wrote:
> What is not entirely  clear to me is how that treats the corner case mentioned at:
>    http://www.w3.org/2009/sparql/meeting/2010-03-09#line0159
> i.e. do I understnad correctly that you mean that the FROM/FROM only affect the query part dataset, but
> that inserts without GRAPH specified still go to the unnamed graph.

I'm not sure why it's unclear?

"""
    * Triple patterns within a template that are not within a GRAPH
clause are inserted into / deleted from the query's default graph. This
graph is determined as follows:
       * If the query has a single FROM clause, that is the default graph
       * If the query has no FROM clause, the default graph is the Graph
Store's unnamed graph (implementation defined)
       * If the query has multiple FROM clauses, the query is an error
and/or undefined.
"""

This example is precisely the 3rd case; it's either an error or 
undefined (up to an implementation).

Lee

>
> Axel
>
> On 25 Mar 2010, at 05:40, Lee Feigenbaum wrote:
>
>> This is in reference to http://www.w3.org/2009/sparql/track/actions/202
>> . It's not a complete proposal, but has most elements of one. I have not
>> discussed this with Paul.
>>
>> 1/ Add FROM and FROM NAMED clauses to the INSERT/DELETE update form(s)
>> in the same syntactic location and with the same semantics as SPARQL
>> Query. This means:
>>
>> # UPDATE outline syntax : general form:
>> [ WITH<uri>  ]
>> DELETE { modify_template [ modify_template ]* }
>> INSERT { modify_template [ modify_template ]* }
>> [ FROM<uri>  ]
>> [ FROM<uri>  ]
>> ...
>> [ FROM NAMED<uri>  ]
>> [ FROM NAMED<uri>  ]
>> ...
>> WHERE GroupGraphPattern
>>
>> The FROM and FROM NAMED clauses together specify an RDF Dataset. The
>> default graph of the RDF Dataset is the RDF merge of the graphs
>> identified in the FROM clauses. (This is as in SPARQL query.) All
>> pattern matching in the GroupGraphPattern is performed against this RDF
>> Dataset as per SPARQL Query semantics.
>>
>> I'd _like_ to be able to say that the RDF Dataset is a subset of the
>> Graph Store, but given that the Graph Store defines a single unnamed
>> graph whereas the RDF Dataset allows me to craft a default graph as the
>> merge of multiple graphs, I don't know how to formally specify this
>> subset relationship.
>>
>> 2/ Deal with the confusion between WITH and FROM/FROM NAMED by removing
>> WITH entirely.
>>
>> On a recent teleconference, someone asked what the relationship between
>> WITH and FROM/FROM NAMED would be. My gut reaction was:
>>
>>     -- WITH gives the default graph for the INSERT and DELETE templates,
>> while FROM/FROM NAMED give the graphs for the query pattern.
>>
>> I still think this is workable, but I also think it is confusing at
>> best. Instead I would propose:
>>
>>     * No WITH clause.
>>     * Triple patterns within a template that are not within a GRAPH
>> clause are inserted into / deleted from the query's default graph. This
>> graph is determined as follows:
>>       * If the query has a single FROM clause, that is the default graph
>>       * If the query has no FROM clause, the default graph is the Graph
>> Store's unnamed graph (implementation defined)
>>       * If the query has multiple FROM clauses, the query is an error
>> and/or undefined.
>>
>> In my mind, this would make SPARQL Update treat graphs and datasets in
>> basically the same way as SPARQL Query, with the distinction that the
>> template part of the update statements can refer to graphs not in the
>> RDF Dataset by means of a GRAPH clause.
>>
>> WITH g1
>> INSERT { x y z }
>> DELETE { a b c }
>> FROM g2
>> WHERE { ... }
>>
>> becomes
>>
>> INSERT { GRAPH g1 { x y z } }
>> DELETE { GRAPH g1 { a b c } }
>> FROM g2
>> WHERE { ... }
>>
>> To me, this _slightly_ more verbose form is well worth removing the new
>> WITH construct and unifying the dataset semantics of SPARQL Query and
>> SPARQL Update.
>>
>> 3/ As with SPARQL Query, if no FROM or FROM NAMED is given, then the
>> dataset is determined by the implementation. (I suspect this is just as
>> in the update draft now - the dataset in this case is the Graph Store.)
>>
>> This means that a query like the example in 4.1.4 works by changing the
>> WITH into a GRAPH clause. That is:
>>
>> PREFIX foaf:<http://xmlns.com/foaf/0.1/>
>> WITH<http://example/addresses>
>> DELETE WHERE {
>>     ?person foaf:firstName 'Fred';
>>             ?property      ?value
>> }
>>
>> would become:
>>
>> PREFIX foaf:<http://xmlns.com/foaf/0.1/>
>> DELETE WHERE {
>>    GRAPH<http://example/addresses>  {
>>     ?person foaf:firstName 'Fred';
>>             ?property      ?value
>>    }
>> }
>>
>> ...which, if we're counting characters, is 3 characters longer.
>>
>> Anyway, we can discuss later at the face-to-face, and my apologies for
>> the very late nature of this proposal.
>>
>> Lee
>>
>>
>>
>
>

Received on Thursday, 25 March 2010 10:54:37 UTC