Re: postponed issue? USING DEFAULT

On 28/04/11 13:47, Axel Polleres wrote:
> 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
>

I propose we add it to SPARQL 1.1

 Andy

>
> 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 13:07:11 UTC