Re: SPARQL Update feature

On 13/07/2010 11:46 AM, Alexandre Passant wrote:
> On 7 Jul 2010, at 09:27, Andy Seaborne wrote:
>
>> >
>> >
>> >  On 06/07/2010 9:39 PM, Alexandre Passant wrote:
>>> >>  Hi,
>>> >>
>>> >>  On 6 Jul 2010, at 22:20, Andy Seaborne wrote:
>>> >>
>>>> >>>  It occurred to me we are missing a feature in SPARQL Update (language) - the ability to clear the graph store. That is, drop all the named graphs and empty the default graph.
>>> >>
>>> >>  Indeed, that makes sense, esp. when working with RDF store in dev / debug phase.
>> >
>> >  That was essentially the reason I came across it - thinking how I could set up a graph store for some teaching without having to reset the server to get the graph store into a known state.
>> >
>>>> >>>  While , in some stores, the similar effect can be achieved with
>>>> >>>
>>>> >>>  DELETE WHERE { GRAPH ?g { ?s ?p ?o } }
>>>> >>>  CLEAR GRAPH DEFAULT
>>>> >>>
>>>> >>>  because they drop empty graphs, it's not possible in general to drop all the named graphs.
>>>> >>>
>>>> >>>  Therefore either something to drop all named graphs, or something to reset the graph store is needed.
>>>> >>>
>>>> >>>  # Drop all named graphs.
>>>> >>>  DROP GRAPH ALL
>>>> >>>
>>>> >>>  DROP GRAPH ALL does not work very well if it's CLEAR GRAPH DEFAULT
>>>> >>>  (actually, I thought the syntax was going to be CLEAR DEFAULT, not CLEAR GRAPH DEFAULT)
>>> >>
>>> >>  What do you mean by does not work well ?
>> >
>> >  I don't think it reads well.  In SPARQL Query, GRAPH accesses the named graphs so DROP GRAPH ALL reads as drop all named graphs.
>> >
>> >  But in SPARQL Update we have "CLEAR GRAPH DEFAULT", i.e. using the word GRAPH for the default graph, so "DROP GRAPH ALL" can read as including the default graph ("ALL" meaning anything you could write here)
>> >
>> >  I think having just "DEFAULT" and not "GRAPH DEFAULT" is a bit clearer if we have a style that uses "GRAPH" to relate to named graph design applied uniformly.
>> >
>>>> >>>  # Clear the graph store.
>>>> >>>  RESET ALL
>>>> >>>  CLEAR ALL # but the named graphs aren't cleared, they are dropped
>>>> >>>  DROP ALL # but the default graph isn't dropped
>>>> >>>  ...
>>> >>
>>> >>  Since CLEAR does not necessary entail that the graph is removed (stores keeping empty graphs), I'd prefer to use DROP ALL.
>>> >>  However, since the default graph is never removed, that's also ambiguous as you said.
>>> >>  I guess it could be solved by indicating that a store MUST always have a default graph, and that if this graph is dropped, the system MUST restore it.
>>> >>
>>> >>  Hence, DROP ALL will DROP all graphs, and the system MUST re-create the default one (as an empty graph).
>>> >>
>>> >>  That would lead to
>>> >>
>>> >>  DROP [ SILENT ] GRAPH<uri>
>>> >>
>>> >>  =>
>>> >>
>>> >>  DROP [ SILENT ] (GRAPH (<uri>   | DEFAULT) | ALL)
>>> >>
>>> >>  (and DROP GRAPH DEFAULT == CLEAR GRAPH DEFAULT with the previous auto. default-graph creation feature)
>>> >>
>>> >>  Makes sense ?
>> >
>> >  I don't have an opinion whether DROPping the default should be allowed but if it is, meaning "clear" by implicit restoration is OK.
> Ok - so based on that and your previous comments re. GRAPH DEFAULT, that could be
>
> DROP [ SILENT ] (GRAPH<uri>  | DEFAULT | ALL)
>
> and
>
> CLEAR [ SILENT ] (GRAPH<uri>  | DEFAULT | ALL)

SILENT?  Isn't that only DROP and CREATE?

>
> In the DROP case, the DEFAULT is here for consistency with CLEAR, but when the default graph is DROPped, it is implicitly restored

Otherwise looks good to me.  I've updated the working copy of the 
grammar on my local machine so it does not get forgotten.

	Andy

Received on Tuesday, 13 July 2010 13:34:12 UTC