W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: Questions about Update 1.1

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Fri, 16 Oct 2009 16:14:56 +0100
Message-ID: <492f2b0b0910160814g6d26b6e5yf860ca085a424d1@mail.gmail.com>
To: Steve Harris <steve.harris@garlik.com>
Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
>>> 2) Can you delete bNodes with DATA? DELETE DATA { <a> <b> _:z }
>>> doesn't really make much sense. Some stores (including Jena and
>>> 4store) allow you to quote bNodes like DELETE DATA { <a> <b> <_:z> }
>>> but that's non-standard.
>> Yes - this is more of a problem now we have update and not just query.
>> We could document the <_:...> usage.
> Garlik would be in favour of that. We've found it invaluable when dealing
> with FOAF data in particular.
> However, I'm not quite sure how it fits in with the semantics of RDF. It's a
> form of skolemisation I suppose, in our case it just externalises what's
> happening inside the store.

Hm, it could be quite difficult for users to know what the actual
bnode IDs are because you might have to rename them in a merge. If I
think ahead to OWL where you have imports, we just name them all apart
in any case, so if a user asks our OWL reasoner to load some ontology
that contains <a> <b> _:z, it will end up as <a> <b> _:genID_1 in the
reasoner. Now the user would first have to query and hope that the
query reveals the internal bnode name and then it can be deleted.
It does not really speak against the usage of <_:z> it would just be
hard to use with systems that freely rename bnodes, which is perfectly
ok for a system to do. So I am not totally against it, but it might
cause confusion for users because the system behavior is hard to


> - Steve

Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
United Kingdom
+44 (0)1865 283529
Received on Friday, 16 October 2009 15:15:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC