Re: SPARQL update and datasets

That works only under your assumption that the FROM/FROM NAMED clauses are internal to the graph store, 
but wouldn't work if you want to use a query with a FROM/FROM NAMED clause to "import" data from an external 
graph (in an implementation that allows URI dereferencing), right?

An alternative option would be that the DEFAULT graph of the query (WHERE) part and the default/unnamed graph of 
the actual update (INSERT/DELETE) are decoupled, i.e. FROM/FROM NAMED only affects what the WHERE part is matched against.

best,
Axel

On 25 Mar 2010, at 10:53, Lee Feigenbaum wrote:

> On 3/25/2010 6:38 AM, Axel Polleres wrote:
> > What is not entirely  clear to me is how that treats the corner case mentioned at:
> >    http://www.w3.org/2009/sparql/meeting/2010-03-09#line0159
> > i.e. do I understnad correctly that you mean that the FROM/FROM only affect the query part dataset, but
> > that inserts without GRAPH specified still go to the unnamed graph.
> 
> I'm not sure why it's unclear?
> 
> """
>     * Triple patterns within a template that are not within a GRAPH
> clause are inserted into / deleted from the query's default graph. This
> graph is determined as follows:
>        * If the query has a single FROM clause, that is the default graph
>        * If the query has no FROM clause, the default graph is the Graph
> Store's unnamed graph (implementation defined)
>        * If the query has multiple FROM clauses, the query is an error
> and/or undefined.
> """
> 
> This example is precisely the 3rd case; it's either an error or
> undefined (up to an implementation).
> 
> Lee
> 
> >
> > Axel
> >
> > On 25 Mar 2010, at 05:40, Lee Feigenbaum wrote:
> >
> >> This is in reference to http://www.w3.org/2009/sparql/track/actions/202
> >> . It's not a complete proposal, but has most elements of one. I have not
> >> discussed this with Paul.
> >>
> >> 1/ Add FROM and FROM NAMED clauses to the INSERT/DELETE update form(s)
> >> in the same syntactic location and with the same semantics as SPARQL
> >> Query. This means:
> >>
> >> # UPDATE outline syntax : general form:
> >> [ WITH<uri>  ]
> >> DELETE { modify_template [ modify_template ]* }
> >> INSERT { modify_template [ modify_template ]* }
> >> [ FROM<uri>  ]
> >> [ FROM<uri>  ]
> >> ...
> >> [ FROM NAMED<uri>  ]
> >> [ FROM NAMED<uri>  ]
> >> ...
> >> WHERE GroupGraphPattern
> >>
> >> The FROM and FROM NAMED clauses together specify an RDF Dataset. The
> >> default graph of the RDF Dataset is the RDF merge of the graphs
> >> identified in the FROM clauses. (This is as in SPARQL query.) All
> >> pattern matching in the GroupGraphPattern is performed against this RDF
> >> Dataset as per SPARQL Query semantics.
> >>
> >> I'd _like_ to be able to say that the RDF Dataset is a subset of the
> >> Graph Store, but given that the Graph Store defines a single unnamed
> >> graph whereas the RDF Dataset allows me to craft a default graph as the
> >> merge of multiple graphs, I don't know how to formally specify this
> >> subset relationship.
> >>
> >> 2/ Deal with the confusion between WITH and FROM/FROM NAMED by removing
> >> WITH entirely.
> >>
> >> On a recent teleconference, someone asked what the relationship between
> >> WITH and FROM/FROM NAMED would be. My gut reaction was:
> >>
> >>     -- WITH gives the default graph for the INSERT and DELETE templates,
> >> while FROM/FROM NAMED give the graphs for the query pattern.
> >>
> >> I still think this is workable, but I also think it is confusing at
> >> best. Instead I would propose:
> >>
> >>     * No WITH clause.
> >>     * Triple patterns within a template that are not within a GRAPH
> >> clause are inserted into / deleted from the query's default graph. This
> >> graph is determined as follows:
> >>       * If the query has a single FROM clause, that is the default graph
> >>       * If the query has no FROM clause, the default graph is the Graph
> >> Store's unnamed graph (implementation defined)
> >>       * If the query has multiple FROM clauses, the query is an error
> >> and/or undefined.
> >>
> >> In my mind, this would make SPARQL Update treat graphs and datasets in
> >> basically the same way as SPARQL Query, with the distinction that the
> >> template part of the update statements can refer to graphs not in the
> >> RDF Dataset by means of a GRAPH clause.
> >>
> >> WITH g1
> >> INSERT { x y z }
> >> DELETE { a b c }
> >> FROM g2
> >> WHERE { ... }
> >>
> >> becomes
> >>
> >> INSERT { GRAPH g1 { x y z } }
> >> DELETE { GRAPH g1 { a b c } }
> >> FROM g2
> >> WHERE { ... }
> >>
> >> To me, this _slightly_ more verbose form is well worth removing the new
> >> WITH construct and unifying the dataset semantics of SPARQL Query and
> >> SPARQL Update.
> >>
> >> 3/ As with SPARQL Query, if no FROM or FROM NAMED is given, then the
> >> dataset is determined by the implementation. (I suspect this is just as
> >> in the update draft now - the dataset in this case is the Graph Store.)
> >>
> >> This means that a query like the example in 4.1.4 works by changing the
> >> WITH into a GRAPH clause. That is:
> >>
> >> PREFIX foaf:<http://xmlns.com/foaf/0.1/>
> >> WITH<http://example/addresses>
> >> DELETE WHERE {
> >>     ?person foaf:firstName 'Fred';
> >>             ?property      ?value
> >> }
> >>
> >> would become:
> >>
> >> PREFIX foaf:<http://xmlns.com/foaf/0.1/>
> >> DELETE WHERE {
> >>    GRAPH<http://example/addresses>  {
> >>     ?person foaf:firstName 'Fred';
> >>             ?property      ?value
> >>    }
> >> }
> >>
> >> ...which, if we're counting characters, is 3 characters longer.
> >>
> >> Anyway, we can discuss later at the face-to-face, and my apologies for
> >> the very late nature of this proposal.
> >>
> >> Lee
> >>
> >>
> >>
> >
> >
>

Received on Thursday, 25 March 2010 11:39:49 UTC