W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

postponed issue? USING DEFAULT (was: Re: major open issues SPARQL Update)

From: Axel Polleres <axel.polleres@deri.org>
Date: Thu, 28 Apr 2011 13:47:45 +0100
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, Lee Feigenbaum <lee@thefigtrees.net>, Axel Polleres <axel.polleres@deri.org>
Message-Id: <91CBDAB9-88BD-4C66-A1BD-6EECFD7CC4D0@deri.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
p.s.: a small subissue I had discussed in the context of 1) with Paul was whether we need also 
  "USING DEFAULT"
to include the default graph of the store in the dataset... I am inclined to leave that out for this round and if people find it useful, it might be added in a future version of SPARQL. I'd like to raise whether we want to add that to "postponed issues" and marked that in 
 http://www.w3.org/2009/sparql/wiki/index.php?title=To_Last_Call

Axel


On 27 Apr 2011, at 23:25, Axel Polleres wrote:

> Andy, Lee,
> 
> thanks for the input, I tried to address that accordingly... 
> 
> I added a new section http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#mappingRequestsToOperations
> which defines the mapping from requests to concrete update operations in the formal model in a table
> That should address point 2)
> 
> Also, this should address point 1) by: 
>  (i)  I slightly changed the definition of OpDeleteInsert() adding an explicit parameter for the Dataset
>  (ii) in the translation table from the requests to update operations, I mention that this Dataset 
>      parameter is either GS, i.e. the Dataset corresponding to current state of the graph store, or the RDF dataset DS described by the UsingClause.
> 
> I also added a note, keeping the "how" exactly an RDF Dataset is obtained from the USING and USING NAMED clauses implementation dependent.
> 
> Finally, point 3) (define UpdateRequest as a sequence of UpdateOperations) is also addressed by the first line of that translation table.
> 
> As for point 4) that's still open since there are some more implications... 
> I'll get back to that... I tend to agree in between with Andy that the sk(), 
> sk-1() trick I tried, doesn't really work... I need to rethink the definitions of 
> Dataset( QuadPattern,  μ )
> and 
> Dataset( QuadPattern,  P, GS )
> slightly, I think.
> 
> best,
> Axel
> 
> On 26 Apr 2011, at 15:12, Lee Feigenbaum wrote:
> 
>> On 4/26/2011 10:00 AM, Andy Seaborne wrote:
>>> 
>>> 
>>> On 26/04/11 14:31, Axel Polleres wrote:
>>>> I have to go through the "Open" points from the reviews again once more,
>>>> but I see overall four *major* open issues for Update before we can go
>>>> to LC:
>>>> 
>>>> 
>>>> 1) semantics of USING, see also the example I put on
>>>> http://www.w3.org/2009/sparql/wiki/To_Last_Call#WG_issues_.26_needed_decisions_2
>>>> 
>>>> USING is the same as FROM, i.e. it allows to explicitly declare a
>>>> (NEW?) dataset with (NEW?) bnodes.
>>>> how USING/FROM is retrieving constructing that dataset is probably
>>>> something where we have one coin flip decision to make still:
>>>> a) we prescribe that bnodes in an explicitly declared dataset must be
>>>> disjoint from the grahp store
>>> 
>>> -1
>>> 
>>> This undermines the use case as I understood it for USING/USING NAMED.
>> 
>> Agreed.
>> 
>>>> b) we leave that up to the implementation
>>> 
>>> +1
>> 
>> Agreed.
>> 
>>>> 
>>>> When I discussed this with Paul, we came to the following conclusion:
>>>> a) would mean identical to FROM,
>>> 
>>> -1
>>> 
>>> (and my concerns about the intention to prescribe still stand -
>>> "identical" is a bad choice of word, "similar to" or "describes a
>>> datasets in a manner similar to FROM" - the point being one
>>> implementation can meet the dataset description using "FROM" etc
>>> definition in one way and meet it for USING in another.)
>> 
>> I still disagree with Andy's reading, but I'm also still happy with
>> Andy's suggested rewording. :-)
>> 
>>>> b) would leave some more freedom to preserve bnodes.
>>> 
>>> +1
>>> 
>>> Note if a system knows that one graph is the same as another, it does
>>> not need to rename bNodes. Renaming is a device to keep apart potential
>>> clashes; if it isn't a clash, no renaming is necessary.
>> 
>> Agreed.
>> 
>> Lee
>> 
>> 
>>>> 2) Need to bridge from Syntax to semantics
>>>> 
>>>> That is, how do we get from an Update request to the respective
>>>> "update Operation call"?
>>>> I have the following in mind here for each of the subsections of
>>>> section 4.3:
>>>> - We copy in essence the syntax snippets from Section 3 to section 4
>>>> and state how they map to the respective Update Operation call
>>>> 
>>>> 3) Need to define UpdateRequest as a sequence of UpdateOperations in
>>>> the formal semantics section...
>>>> I'd be grateful for ideas how to tackle that...
>>> 
>>> UpdateRequest = [ x Z| x is an UpdateOperation ]
>>> 
>>> UpdateOperation = oneof ....
>>> 
>>>> 
>>>> 4) blank nodes in QuadPattern aren't mentioned explicitly in
>>>> OpDeleteInsert - I think that might need attention
>>>> 
>>>> 
>>>> Axel
>>> 
>>> 
>> 
>> 
> 
Received on Thursday, 28 April 2011 12:48:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT