- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Fri, 29 Apr 2011 01:34:13 -0400
- 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 UTC