W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > February 2010

Request for named graph templates "everywhere"

From: Sebastian Trueg <trueg@kde.org>
Date: Fri, 19 Feb 2010 12:25:04 +0100
Message-ID: <4B7E7510.9030401@kde.org>
To: public-rdf-dawg-comments@w3.org
Hello working group (in lack of a better opening line),

my name is Sebastian Trueg and I am the maintainer and lead developer of
the Nepomuk[1] semantic desktop system for KDE[2].
We use a local Virtuoso database to store all kinds of data about files,
emails, contacts, projects, and so on on the desktop. Basing the data on
the Nepomuk ontologies[3] and in specific NRL[4] we make heavy use of
named graphs. The main use is to attach reification data like creation
date, owner, and type of data (mostly ontology vs. instances).
In any case we have a whole lot of named graphs which act more or less
as a fourth node attached to the triples. As most RDF database APIs
nowadays expose quadruples instead of triples this seems like a natural
approach anyway.

Looking at named graphs as "just" a fourth node IMHO it makes perfect
sense to allow templates for graphs in all commands.
A simple example would be:

drop graph ?g where { ?g <foo> <bar> . }

But this also applies to insert queries:

insert { 
   graph ?g { ?s ?p ?o . }
where {
   blabla .
   ?g foo bar .

In the spirit of completeness one could even think of finally completing
construct queries and allowing for the following:

construct { graph ?g { ?s ?p ?o . } . graph <foobar> { .... } } where {
...... }

Thus, my question is: is there any good reason against allowing
templated named graphs in pretty much every command?

Thanks a lot for considering.
(Please CC me as I am not subscribed to the list.)

Sebastian Trueg

[1] http://nepomuk.kde.org
[2] http://www.kde.org
[3] http://www.semanticdesktop.org/ontologies/
[4] http://www.semanticdesktop.org/ontologies/nrl
Received on Friday, 19 February 2010 11:36:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:10 UTC