Re: Review of SPARQL 1.1. Update editors' draft

Hi,

On 18 May 2010, at 17:13, Paul Gearon wrote:

> Thanks for all the work Alex.
> 
> On Mon, May 17, 2010 at 5:33 AM, Alexandre Passant
> <alexandre.passant@deri.org> wrote:
>> Hi Lee,
>> 
>> Thanks a lot for your feedback.
>> Here are some first answer regarding your comments / queries.
>> I'll let Paul complete some points, and we'll get back to you re. other unanswered comments
> 
> Jumping ahead....
> 
> <snip/>

[...]

> 
>> On 16 May 2010, at 03:53, Lee Feigenbaum wrote:
>>> * We haven't closed ISSUE-37, but I would propose that:
>>>  PROPOSED: Close ISSUE-37 noting that SPARQL 1.1 will not address basic federated update in any way, no change needed.
>> 
>> I agree with the proposal but I haven't seen such proposal in minutes of previous TC.
>> Could it be addressed in tomorrow's t-con ?
> 
> While I don't want to see updates applied in a federated way, it would
> be awkward to prevent federation in the WHERE clause. After all, it
> might be handy to remove data based on data found in another store.
> 
> Can we get opinions from people about this please?

I haven't think of that, but that would make sense to allow SERVICE in the WHERE clause from an update, indeed.
Could we propose a vote in that direction "SPARQL/Update allows the use of SERVICE in the WHERE clause"

[...]

> 
> <snip/>
> 
>>> * 4.1 "Graph update operations change existing graphs in the Graph Store but do not delete them." Given the provision that empty graphs can be removed after any operation, this statement is not strictly true, right?
>> 
>> indeed, I'd suggest "Graph update operations change existing graphs in the Graph Store and may delete graphs when DELETE/DELETE DATA operations lead to graph(s) with no triples."
>> Haven't changed anything so far.
> 
> I added the word "explicitly" along with a second sentence:
> 
> "Graph update operations change existing graphs in the Graph Store but
> do not explicitly delete nor create them. An implementation MUST
> create graphs that do not exist before triples were inserted into
> them, and MAY remove graphs that are left empty after triples are
> removed from them."

Fine with me

[...]

>>> * 4.1.6. LOAD needs more explanation of what documentURI means. Do I need to dereference this URI? Is it an indirect relationship between the URI and the triples to be loaded (a la FROM/FROM NAMED)? That is, can I ever do LOAD <urn:TheGraph> INTO GRAPH <...> ?
> 
> I don't want to over specify this, so I've written the following:
> 
> "The documentURI specifies the URI of a document such that a store
> will be able to identify, locate and read the document. Common forms
> will be URLs with the http: or file: protocols. Once the document has
> been read, the resulting triples will be inserted into the destination
> graph.
> If no destination graph URI is provided to load the triples into, then
> the data will be loaded into the default graph."
> 
> Yes, I think it should be possible to "LOAD <urn:TheGraph>", though it
> will be up to an individual store as to how it wants to interpret
> that. Most stores will probably indicate an error, while others may
> have a particular mechanism for locating documents for different types
> of URI schemes (maybe URNs get mapped to a configured RDBMS?). I want
> to keep the door open for any kind of URI an implementor wants to
> accept. That means I don't want to enumerate what can be accepted, nor
> do I want to specify anything that can't be accepted (such as a URN).
> 
>> I'd suggest to replace documentURI by remoteGraphURI, adding that : "The remoteGraphURI has to be dereferenced and the retrieved triples should be added in the Graph Store into the specified graph or the default graph"
>> Will it be explanatory enough ?
> 
> I missed this bit before I wrote my last response, but I'll stick to
> what I said. "Dereferencing" implies a URL, which I don't want to
> limit the operation to. Other than that, I think the new text covers
> the same points, right?

Yes, fine as well.
I'd however like to mention dereferencability here.

=> "The documentURI specifies the URI of a document such that a store will be able to identify, locate, dereference and read the document."

[...]

> 
> Stores that do not record empty graphs will always return success.
> 
>>> * Section 5: As we've discussed, we need a formal model for the update language. I think it needs to cover (perhaps among other things), Graph Store, transformations on a graph store, transformations on a graph, what it means to "process" a triple, success and failure criteria for each operation, what it means to optionally remove an empty graph between operations, what it means to abort later operations in the face of failure of one operation, the relation between Graph Stores and RDF datasets, the relationship between the unnamed graph and default graph, the processing model of DELETE/INSERT statements ...
> 
>> So far, I moved previous 3.2.1 here, and added a note re. the upcoming formal model.
> 
> Yes, we need to do it. I'm good at reading formalisms, but not writing
> them. Any experts here?

Not an expert neither but reading the document sent previously by Ross (http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Mar/0009.html).
It however won't be for that round.

> 
>>> * 4. s/must Be/must be
>> 
>> done
> 
> ??? It was still there after I did a cvs update.

So I guess I hadn't actually changed it (or there was more than one ?)

> 
> 
>>> * Throughout the document, I think it would be helpful for examples to be more complete, showing the Graph Store before the operation and then again after the operation.
> 
> That will take a long time. I can't get it done for this publication round.

If we don't ack. the publishing on tomorrow's call, I can do it by friday so it may go in that publication round.

Best,

Alex.

> 
> Regards,
> Paul Gearon

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Monday, 24 May 2010 18:04:21 UTC