Re: SPARQL Update (almost?) LC ready from my side ...

On 30/04/11 00:36, Axel Polleres wrote:
>
> On 29 Apr 2011, at 17:44, Andy Seaborne wrote:
>> On 29/04/11 10:47, Axel Polleres wrote:
>>> Greg, all,
>>>
>>> I finally addressed point
>>>    "4) blank nodes in QuadPattern aren't mentioned explicitly in OpDeleteInsert"
>>> which came from your review...
>>
>> Comment on this below.  There's a remaining sk-ism and I'm not clear
>> that the bnode template renaming is in the right place.
>
> yes, you're probably right about that one, see below.
> Didn't touch the document yet; I need to sync with
> Alex/Paul first not to run into conflicts while editing,
> won't edit before Monday... so, in what follows, I just write down how
> I suggest/plan to address the things Andy raised.
>
>>
>>>
>>> In order to address this, I refined the definition of Dataset()
>>> which now explicitly mentions the treatment of blanknodes in QuadPatterns, see
>>>
>>>    http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetPattern
>>>
>>> Please check (and I hope no more major concerns/flaws with that definition)
>>>
>>> As far as I can see, this addresses the last of the major issues in Update from my side...
>>> I would kindly ask Paul/Alex to look through the reviews and answers and any "*Open" points
>>> again to be sure and check pubrules, but I hope this brings us now pretty close to LC readiness!
>>>
>>> If anybody still sees any LC roadblocks for Update that I've missed, please let us know!
>>>
>>> cheers,
>>> Axel
>>
>> Revision 1.120
>> By the way: the CVS log entry is
>>
>> --------
>> Revision 1.120  2011/04/29 09:42:21  apollere2
>> Added missing
>>
>>
>>
>> --------
>> i.e. several blank lines.  Yes, something missing!
>
>
> :-) cvs log Overview.xml ...
> ----------------------------
> revision 1.120
> date: 2011/04/29 09:42:21;  author: apollere2;  state: Exp;  lines: +6 -1
> Added missing<ul/>
> ----------------------------
>
> :-) ... fixed that in the xml to ...
>
> "
> Added missing&lt;ul/&gt;
> "
>
>>
>> I took a slightly hurried pass over the formal definitions.  Comments
>> below. No showstoppers in the design, but some things could do with fixing.
>>
>> See the 5 "[Major]" below.
>>
>>          Andy
>>
>>
>> [MUST]
>> **Remove editors note about issue-59.
>
> You mean, the reference to he ISSUE? Is it harmful/forbidden to leave a reference to a CLOSED issue in?
> I think you are probably right in the sense that we should mark all "AT RISK" parts uniformly across our LC docs.
> We can go with the "red box" as you have it in
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#grammar
> just leaving the sentence:
> "
> The following shortcuts have been proposed for graph management and are marked "AT RISK". The SPARQL WG is seeking comments and feedback from implementers and end-users regarding this proposal.
> "
> in such a red box.

If the issue is closed, they are not really at risk?  Just seems confusing.

>>
>> ** Definition: Graph Store
>>
>> [Minor improvement]
>> avoid "identified"
>> """
>> zero or more named slots identified by an IRI iri sub i.
>> """
>> ==>
>> """
>> zero or more named slots.  The unnamed slot holds an RDF graph; each a
>> named slot is pair of graph and an associated IRI.
>> """
>
> Fine with me.
>
>> Remove "Note:"
>
> you just mean the bold "Note:", not the actual note, I assume... fine to remove that.

No - remove the whole thing.  if it says "slightly abusing notation" you 
are just asking for trouble!

>
>>
>> ** Definition: Abstract Update Operation
>>
>> [Editorial]
>> The languge defines a "An Update Operation"
>> Either drop "Abstract" or include in first line.
>
> fine.
>
>>
>> [Minor] it would be nice to say what "atomic" means
>>
>
> fine. somthing like:
>
> "Here, by atomic we mean that the operation performs the described transformation of the Graph Store either completely or leaves the Graph Store unchanged."
>
>
>> ** Deal with 4.2 @@@
>>
> @@@ is currently only used to mark "merge"
> if all agree we don't need the merge definition here anymore, I am fine to simply drop.
>
>> ** 4.2.4  Dataset( QuadPattern,  μ )
>> [Minor]
>> case '{}' is covered by '{' TriplesTemplate? '}'
>
> true, but kinda prefer to make it explicit, if no objections.

Fine - just pointing it out.

>
>>
>> [Major]
>> 'GRAPH' VarOrIRIref '{' TriplesTemplate? '}''
>>
>> Consider GRAPH ?g {<s>  <p>  <o>  }
>> Need to say that if ?g is unbound, there are no triples.
>>
>
> good point. suggested:
>
> -------
> Dataset(QuadPattern, μ ) is the Dataset consisting of the empty default graph and a named graph (μ(VarOrIRIref), G) such that G is composed by all valid RDF triples obtained from substituting the variables in TriplesTemplate according to μ and combining these triples into a single RDF graph by set union.
> -------
> -->
> -------
> Dataset(QuadPattern, μ ) is the Dataset consisting of the empty default graph and, in case μ(VarOrIRIref) yields a valid IRI, a named graph (μ(VarOrIRIref), G) such that G is composed by all valid RDF triples obtained from substituting the variables in TriplesTemplate according to μ and combining these triples into a single RDF graph by set union.
> -------

And add what happens if it's not a IRI?  It's unspecificed in your text 
- implicitly it's do nothing, but it isn't defined.

>
>>
>> ** 4.2.5  Dataset( QuadPattern,  P, GS )
>>
>> [Major]
>> Doesn't the bNode replacement done by sk have to be in 4.2.4 not here?
>
> hmmmm...
>
>> because in 4.3.1 Insert Data Operation, the replacement needs to be done
>> but the operation is:
>>
>> OpInsertData(GS, QuadPattern) =
>>      Dataset-UNION(GS, Dataset(QuadPattern,{}))
>>
>> so no replacement is done.
>
> ... yes! :-) will change.
>
>> ** 4.3.1 Insert Data Operation
>> ** 4.3.2 Delete Data Operation
>> ** 4.3.3 Delete Insert Operation
>>
>> [Editorial]
>> "either in the default slot or in a named slot."
>> ==>
>> "in the default slot or in named slots."
>
>>
>> The either-or is confusing as it can be both.
>>
>
> fine.
>
>
>> ** 4.3.4 Load Operation
>> [editorial]
>> "; i.e.;" =>  "; i.e."
>
> fine.
>
>>
>> ** 4.3.5 Clear Operation
>>
>> [Major]
>> Definition: Load Operation
>> ==>
>> Definition: Clear Operation
>
> fine.
>
>>
>> ** 4.4.1 Create Operation
>> Definition: CreateOperation
>>
>> Generally, what happens on errors?
>> The defn says "create a new slot" and nothing about if the IRI is in use.
>
> yes, should say something like:
>
> "
>   OpCreate(GS, iri) = Dataset-UNION(GS, (iri, {}))  ... if iri not in graphnames(GS)
>                     = GS                            ... otherwise
> "
>
>>
>> ** 4.4.2 DropOperation
>> [Major]
>> OpDrop(GS, iri) = ... GS minus {(irij, Gj)}
>>
>> "minus" on GS isn't defined.
>
> add:
> "where minus here is set-difference"
> or alike.

That will work but it might be (eitorially) easier to write out GS and 
say "i = 1 to n except j"

Not a block on LC.

>
>>
>> ** 4.5 Mapping Update Requests to the Formal Model
>> [Major]
>> Table uses "Tr(GS,UsingClause)" but the Tr operation is "Tr(GS,Request)"
>> and "UsingClause" isn't a request
>
> right, sloppily re-used that out of  convenience...
> can rename "Tr(GS,UsingClause)" to something like "Tr<sub>Dataset</sub>(GS,UsingClause)" to set it apart.

I think I need to reread it (if time...) about USING and WITH.

 Andy

>
>
>
> Great, thanks again for the quick and on-spot remarks! Looks as we're converging.
>
> Axel
>

Received on Saturday, 30 April 2011 12:29:41 UTC