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

Re: major open issues SPARQL Update

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 26 Apr 2011 15:00:41 +0100
Message-ID: <4DB6D009.9030808@epimorphics.com>
To: public-rdf-dawg@w3.org


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.

>          b) we leave that up to the implementation

+1

>
>   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.)

>         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.

>
> 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 Tuesday, 26 April 2011 14:01:08 GMT

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