W3C home > Mailing lists > Public > semantic-web@w3.org > September 2007

Re: statements about a graph (Named Graphs, reification)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Tue, 4 Sep 2007 18:30:49 +0200
Message-Id: <4C3E2FA6-4619-4372-AB7E-46FB8DEDC396@cyganiak.de>
Cc: "K-fe bom" <u9x3n_15so@hotmail.com>, <semantic-web@w3.org>
To: Michael Schneider <schneid@fzi.de>


On 4 Sep 2007, at 15:29, Michael Schneider wrote:
> Ok, then let's discuss more practical issues (leaving this subtle RDF
> semantics stuff to the academic world). Until now, we had the only  
> usecase
> that someone wanted to annotate a complete RDF document, which  
> already exist
> somewhere having an URI. This is certainly the easiest case to  
> handle in
> practice.

Yes. I think it's also by far the most common case.

> But there will probably often be the more demanding situation,
> where I want to make assertions about some ad hoc set of RDF  
> triples, which
> is not yet published as a special RDF document anywhere.

To be honest, I'm not sure that this case occurs *that* much in  
practice. Triples tend to exist in chunks, and the chunks are usually  
meaningful in the domain of discourse, and thus make natural units of  

But then I'm not involved with the advanced research stuff where I  
can imagine this to be very important: attaching uncertainty values  
to statements, describing inference proof chains, recording  
differences between RDF graphs and so on. So we will probably need  
more sophisticated mechanisms at *some* point in the future.

> In your previous
> post, you already gave a hint how one can handle this situation:
>> I put the statements into the document itself, or into an external
>> document, whatever is more convenient.
>> To process this kind of data, you need an implementation of the RDF
>> Dataset or Named Graph Set, which keeps track of the source of
>> statements. Most RDF toolkits have support for this these days. E.g.,
>> when you load multiple documents into a Jena Model, it won't know
>> which statements are from which document. When you load them into a
>> Dataset (called DataSource in Jena IIRC), then it remembers which
>> statements are in which graph.
> But I have difficulties to understand this. Let's make a case: I  
> have a
> graph G. Now I like to annotate any single triple t_i (or singleton  
> subgraph
> G_i) in it (e.g. I like to store different provenance information  
> about each
> triple). I understand that with NamedGraphs, I can do the following  
> for each
> i:
>    G_i { t_i } .
>    G_i p_1 o_1 .
>        ...
>    G_i p_n o_n .
> But how can I bring this information into the Semantic Web, acutally?

You mean publishing or exchanging such annotations? Well, you could  
serialize them as TriG or TriX documents, or offer a SPARQL endpoint,  
but I think that neither plain RDF nor named graphs/SPARQL nor  
reification are truly well-suited to this use case.

N3's formulae might be a better match in theory, but lack  
implementations in practice.

> Creating a separate RDF document for each of the G_i hardly seems  
> to be a
> practical solution.

Yes, of course.

> But I certainly haven't understand the second one of the
> above paragraphs?

I was talking about how you can manage named graphs internally in  
your application. Publishing such annotations is a different story.


> Cheers,
> Michael
> --
> Dipl.-Inform. Michael Schneider
> FZI Forschungszentrum Informatik Karlsruhe
> Abtl. Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: Michael.Schneider@fzi.de
> Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
> FZI Forschungszentrum Informatik an der Universität Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des bürgerlichen Rechts
> Az: 14-0563.1 Regierungspräsidium Karlsruhe
> Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi  
> Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
Received on Tuesday, 4 September 2007 16:31:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:02 UTC