Review of SPARQL Update submisson (ACTION-54)

Hi all,

With regards to ACTION-54 I just reviewed the SPARQL Update Member  
Submission [1].
Here are a few comments / questions.

## INSERT vs INSERT DATA

First, having INSERT / DELETE and INSERT DATA / DELETE DATA is imho  
not intuitive. I think we should provide a single operator whether  
data to be included / removed is a concrete set of data or a template  
+ pattern. SPARQL+ from ARC2 uses the same operator for both [2]. Andy  
mentions the reasons for that choice during the first F2F, but I  
cannot remember it.

## Modify and Moving data between graphs

It is not clear to me if the current approach in MODIFY allows to deal  
with different graphs, e.g if example 2e can be replaced by

MODIFY <http://example/bookStore2>
INSERT {
  ?book ?p ?v
}
DELETE
{ GRAPH  <http://example/bookStore>
    {
      ?book ?p ?v
   }
}
WHERE
{ GRAPH  <http://example/bookStore>
    { ?book dc:date ?date .
           FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime )
   }
}

I'm also thinking that some syntactic sugar would be welcome for  
moving / replacing data (e.g. MOVE would be INSERT + DELETE)
E.g. the previous example 2e would be

MOVE INTO <http://example/bookStore2>
  { ?book ?p ?v }
WHERE
   { GRAPH  <http://example/bookStore>
      { ?book dc:date ?date .
        FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime )
        ?book ?p ?v
      }
   }

While 2b could be

MOVE INTO <http://example/bookStore>
{ <http://example/book3>  dc:title  "Fundamentals of Compiler Design" }
WHERE
{ <http://example/book3>  dc:title  "Fundamentals of Compiler Desing" }

## The SILENT keyword

I would rather have the SILENT option not in the language itself, but  
in the protocol. Considering that SILENT can be used as a debugging  
mode, I'd prefer to simply add / remove a variable in the protocol  
calls rather than modifying all my SPARQL queries if I want to  
enable / disable that verbosity in existing applications using SPARQL/ 
Update.
BTW, if we keep that option, esp in the protocol, it would make sense  
to have it also for the SELECT.

## Security issues

I guess that would worth a complete topic, but is that something we  
plan to address in the WG, by giving some solutions or at least  
pointers to existing technologies (oAuth, FOAF+SSL, etc.) ?

Best,

Alex.

[1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/
[2] http://arc.semsol.org/docs/v2/sparql+

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

Received on Thursday, 16 July 2009 15:27:07 UTC