SPARQL Update (almost?) LC ready from my side ...

Greg, all,

I finally addressed point 
 "4) blank nodes in QuadPattern aren't mentioned explicitly in OpDeleteInsert"
which came from your review...

In order to address this, I refined the definition of Dataset()
which now explicitly mentions the treatment of blanknodes in QuadPatterns, see

 http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetPattern

Please check (and I hope no more major concerns/flaws with that definition)

As far as I can see, this addresses the last of the major issues in Update from my side...
I would kindly ask Paul/Alex to look through the reviews and answers and any "*Open" points
again to be sure and check pubrules, but I hope this brings us now pretty close to LC readiness!

If anybody still sees any LC roadblocks for Update that I've missed, please let us know!

cheers,
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 Friday, 29 April 2011 09:47:39 UTC