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

Re: postponed issue? USING DEFAULT

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Fri, 29 Apr 2011 01:34:13 -0400
Message-ID: <4DBA4DD5.4080903@thefigtrees.net>
To: Axel Polleres <axel.polleres@deri.org>
CC: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg@w3.org
On 4/29/2011 1:28 AM, Axel Polleres wrote:
>
> On 28 Apr 2011, at 14:06, Andy Seaborne wrote:
>
>>
>>
>> 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
>
> If we want that, may I suggest then to add it in Query for FROM as well.

I'm not at all comfortable with this change at this point in the process.

Lee

> It wouldn't seem to make sense to have the feature to be able to access the default graph of the graph store, or respectively, the implicit dataset accessible at a service, for constructing a new detaset for update, but not for query.
>
> i.e. if we want that, let's unify...
>
> [13]  DatasetClause  ::=  'FROM' ( DefaultGraphClause | NamedGraphClause )
> [14]  DefaultGraphClause  ::=  SourceSelector
> [15]  NamedGraphClause  ::=  'NAMED' SourceSelector
> [16]  SourceSelector  ::=  IRIref
> ...
> [45]  UsingClause  ::=  'USING' ( IRIref | 'NAMED' IRIref )
>
> to
>
> [13]  DatasetClause  ::=  'FROM' ( DefaultGraphClause | NamedGraphClause )
> [14]  DefaultGraphClause  ::=  SourceSelector
> [15]  NamedGraphClause  ::=  'NAMED' SourceSelector
> [16]  SourceSelector  ::=  IRIref | 'DEFAULT'
> ...
> [45]  UsingClause  ::=  'USING' ( DefaultGraphClause | NamedGraphClause )
>
> best,
> Axel
>
>
>>
>>          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 Friday, 29 April 2011 05:34:48 GMT

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