W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: ISSUE-20: SPARQL Update: Empty vs non-existent graphs

From: Paul Gearon <gearon@ieee.org>
Date: Fri, 8 Jan 2010 10:30:48 -0500
Message-ID: <a25ac1f1001080730w183100apa6ed9b2fc6905e6d@mail.gmail.com>
To: Steve Harris <steve.harris@garlik.com>
Cc: Andy Seaborne <andy.seaborne@talis.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On Fri, Jan 8, 2010 at 6:09 AM, Steve Harris <steve.harris@garlik.com> wrote:
> On 7 Jan 2010, at 21:06, Paul Gearon wrote:
>>
>>> Some related issues in update are about adding triples into an empty
>>> graph
>>> vs a non-existent graph (does it automatically get created?)
>>
>> I'd rather not. If this is needed then it can be done with:
>>  CREATE SILENT <uri>
>>  INSERT DATA { GRAPH <uri> { triples } }
>
> I have a very strong preference for not requiring an explicit CREATE, I've
> already encountered usecases where this makes things very annoying, e.g. I'd
> like to:
>
> INSERT {
>  GRAPH ?s { ?s ?p ?o }
> }
> WHERE {
>  ?s a :Thing .
>  ?s ?p ?o .
> }

I see your point, and I understand that graph creation isn't like
table creation in SQL, since no structure is needed. I'm uncomfortable
with the fact that it's not possible to prevent insertion into
non-existent graphs (something I've seen users depend on), but the use
cases are directly contradictory, and yours is probably more
compelling.

> 4store would require some work to detect new graph URIs being used, and
> explicitly create a graph, but I think it's worth it to avoid annoying
> users.

I was thinking it would be easy in Mulgara, but then I realized that
security (when it's enabled) is done on a graph basis. I suppose that
means if a user has graph creation status, then they should get
read/write privileges on every graph they create.

> N.B. it's not necessary to detect removing the last triple from a graph, as
> that doesn't necessarily have to explicitly remove the graph.

That makes me happier.  :-)

Regards,
Paul Gearon
Received on Friday, 8 January 2010 15:31:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT