- From: Axel Polleres <axel.polleres@deri.org>
- Date: Thu, 28 Apr 2011 13:47:45 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, Lee Feigenbaum <lee@thefigtrees.net>, Axel Polleres <axel.polleres@deri.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 UTC