Re: major open issues SPARQL Update

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 Tuesday, 26 April 2011 14:13:24 UTC