Re: Action 644 : Review Update

A couple of comments and questions below. In particular, I have
questions around LOAD...


On Thu, Jun 14, 2012 at 5:44 AM, Olivier Corby
<Olivier.Corby@sophia.inria.fr> wrote:
> I reviewed the document:
>
> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml
>
> (date of the document: 2012 June 5)
>
>
> I have found some typos and I have some comments.
>
>
> Regards
>
> Olivier
>
>
>
>
> "W3C Working Draft 05 January 2012"
> ->
> Change the date

Done.

> Remove this:
>
> "The end date of the Last Call review period is 06 February 2012, i.e.,
> comments on this working draft are due on or before this date."

Done.

> 2.3 Entailment and Consistency
>
> We may also mention that SPARQL Update can be used to update an ontology
> (RDFS or OWL) and hence the update may interact with entailments.

Added the following at the end:
"Also of note is that some stores may be capable of performing
entailments with respect to an ontology capable of higher level
processing, such as RDFS or OWL. Updates may interact with these
entailment regimes in these systems."

> 3.1.3 DELETE/INSERT
>
>
> "If any solution produces a triple containing an unbound variable or an
> illegal RDF construct, such as a literal in a subject or predicate position,
> then that triple is not included in the output RDF graph."
>
> This sentence is ambiguous in case of delete.

Any triple that doesn't exactly match something in the graph won't be
removed, regardless of how well formed it may be. However, I changed
the text to say the following:

"If any solution produces a triple containing an unbound variable or
an illegal RDF construct, such as a literal in a subject or predicate
position, then that triple is not included when processing the
operation: INSERT will not instantiate new data in the output graph,
and DELETE will not remove anything."



> "Blank nodes are prohibited in a DELETE template"
>
> Should an application raise an error in this case ?

I presume that is what "prohibited" would mean. We don't define what
happens in the case of a syntax error. This is similar, only
complexity leads to it not being defined in the grammar.

Unless there is disagreement, I don't plan to define what happens in
the case of something prohibited being detected.

> 3.1.3.1 DELETE (Informative)
>
> "Example 6:
> This example request deletes all records of old books (with date before year
> 2000) "
>
> The text is contradictory with the example which searches for dates greater
> than 1970.

Fixed.

> "The template can contain triples with no variables (known as ground or
> explicit triples), and these will also be inserted, providing the solution
> sequence is not empty."
>
> I would write "provided that" instead of "providing"

Done.

> 3.1.4 LOAD
>
> Which format must be supported by LOAD ?
> RDF/XML ? Turtle ? ...

I don't know that any format MUST be supported. As for those that are
supported, I presume that this is up to the store. Do we need to say
something here? It seems like a rabbit hole, since a complete
discussion could involve mime-types, conneg, links to the various
specs (both old and future), and so on.

> In the future, what will happen if an RDF document that contains named
> graphs is loaded ?

The sensible thing is that it would go into the graphs with the names
provided in the document. Otherwise, there should be a way to override
this and force the data into a given graph. It may even be desirable
to provide a mapping of graph names into new graph names (or the
default).

Regardless, this is a good point, and it's not handled by the current
spec. Given that this is due to come out from the RDF WG, shouldn't we
do something about it?

> The text says that the triples go into the default graph
> but users may expect that they go into the named graphs.
> In the same way, what happens if this document is loaded into a named graph
> that differs with the named graphs of the document ?

I would like to see default syntax like:
  LOAD document_iri
Loading everything into the named graphs provided in the document if
they are provided, and into the default graph if no named graph is
specified.

I would also expect to see:
  LOAD document_iri INTO graph_iri
Loading all triples that aren't in a specified graph into the default
graph, and those with a named graph going into the graph of that name.
Though that's just my presumption.

There would need to be a syntactic option to override the destination
graph, thereby forcing all triples into the destination. Something
like:
  LOAD document_iri INTO graph_iri OVERRIDE

I would expect a more useful proposition would be to allow mappings of
graph names. Something like
  LOAD document_iri INTO graph_iri MAP (<source1> <dest1>, <source2>
<dest2>, <source3> DEFAULT)

These aren't real proposals - just something to prompt a response.

> 3.2.1 CREATE
>
>
> What happens if the store has a fixed set of graphs ?

I haven't encountered such a thing. But if a store does not allow the
creation of a graph then this should return an error. I've added this:
"If the graph may not be created, then a failure MUST be returned,
except when the SILENT keyword is used."

The use of MUST is appropriate here, right?


> 3.2.2 DROP
>
> "The GRAPH keyword is used to remove all triples from a graph denoted by
> IRIref"
> ->
> The GRAPH keyword is used to remove a graph denoted by IRIref

Done. Looks like it was copy/pasted from CLEAR.


> "After successful completion of this operation, the graph is no longer
> available"
> ->
> the graph(s) is (are) no longer available

Done.


> 4.2.1 Dataset-UNION
>
>
>
> " Dataset-UNION(DS2( ... , Dataset-UNION(DSn),{}) ... )"
> ->
> Dataset-UNION(DS2, ... Dataset-UNION(DSn, {}) ... )
>
>
> I think it could also end with :
>
> Dataset-UNION(DSn-1, DSn)

I agree with that, though I'll respect the author and leave it alone here.

I've changed it from:
  Dataset-UNION(DS1, Dataset-UNION(DS2( ... , Dataset-UNION(DSn),{}) ... )
to:
  Dataset-UNION(DS1, Dataset-UNION(DS2, ... , Dataset-UNION(DSn,{})...))


> 4.3.4 Load Operation
>
>
> "A Load Operation OpLoad is an Update Operation in which new triples (from a
> remote graph) are added in the Graph Store, either in the default slot or in
> a named slot, if specified"
>
> -> add a "." at the end

Done.

> 4.3.5 Clear Operation
>
>
> "OpClear(GS, iri) = GS if iri not in graphNames(GS); otherwise, OpClear(GS,
> irij) =
> GS minus {(irij, Gj)} ) union {(irij,{})}"
>
> ->
>
> OpClear(GS, iri) = GS if iri not in graphNames(GS); otherwise, OpClear(GS,
> irij) =
> ( GS minus {(irij, Gj)} ) union {(irij,{})}
>
> add "(" after "="

Done.

> In addition I would add: iri = irij

I was unhappy with the definition, since there was nothing to link
irij and Gj together. I've appended this to the end:

, where (irij, Gj) ∈ GS and iri = iris

If that didn't render correctly, the character before GS is &#x2208;

> 4.4.2 Drop Operation
>
> "OpDrop(GS, iri) = GS if iri not in graphNames(GS); otherwise, OpDrop(GS,
> irij) = {DG} union {(irii, Gi ) | i ≠ j and 1 ≤ i ≤ n}"
>
> I would add: iri = irij

Done.

> Table 1: Mapping from Update Requests to Update Operations
>
>
> "OpDeleteInsert(GS, TrDataset(GS,UsingClause*) ,QuadPatternDEL,
> QuadPatternINS, GroupGraphPattern)"
> ->
> OpDeleteInsert(GS, TrDataset(GS,UsingClause*), QuadPatternDEL,
> QuadPatternINS, GroupGraphPattern)
>
> move space after ","

Done.


Regards,
Paul

Received on Tuesday, 3 July 2012 21:39:29 UTC