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

Re: postponed issue? USING DEFAULT

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 29 Apr 2011 06:28:45 +0100
Cc: <public-rdf-dawg@w3.org>
Message-Id: <2CE584EF-D2AB-4D77-9C06-B989A3841FFC@deri.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>

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.
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:29:15 GMT

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