Re: Deleting subgraphs via SPARQL

just my (hopefully related) 2 cents from a practical pov:

I experimented a little bit with adding editing frontends
to an RDF store, and from my (limited) experience, you get
in trouble sooner or later when you work directly with the
aggregated statements in the store. It's comparable to
directly editing data in a data warehouse. The stuff is
coming from various places and by editing/updating it you
don't only invalidate provenance information, you also make
it extremely difficult to keep the data consistent when sources
are refreshed or resources get consolidated by a smusher.
Furthermore, with all this SemWeb stuff still being quite
researchy, you'll probably want to drop a whole KB and
re-populate the store from the list of maintained sources
at least once during working on a project.

I found using two different stores (a "final" store, optimized
for querying, and a store that uses a relational model to
facilitate CRUD operations) to be quite helpful to avoid sync
chaos. When statements from the 2nd store are added to the KB,
it's just another source, so the same provenance tracking
mechanism can be used. If you want to change/delete something,
you simply change the source statements or disable the source
and "refresh 'n' resmush".

Of course this does not allow the exclusion of a subset of
statements of a source, but it's probably more straight4ward
to implement some sort of filter *before* data is added
instead of adding and then removing the data each time a
source is refreshed.
hm, what about a blacklist of SPARQLy patterns which are
run against a source result before the statements are added.
This would at least solve the bnode id problem. Once SPARQL
endpoints are more deployed, it could be possible to
completely specifiy sources as SPARQL results, e.g. "source x
is the graph returned by query y via endpoint z", instead of
the now common "source x is the graph served at URI y".

</bla>


benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.bnode.org/

Received on Thursday, 23 June 2005 09:58:33 UTC