Re: [foaf-dev] RDF triple assertions live forever?

Dear Philip

Whether triples live forever or not seems of little relevance, the truth 
value of triples depends on the world against which they are evaluated 
and the universe we live in is different at every point time.

RDF semantics "assumes, implicitly, that URI references have the same 
meaning /whenever/ they occur" [1], this assumption makes triples 
expressing the meaning of the named node of invariable truth value. 
However, I don't think that this has any effect of accidental properties 
of a resource. Of course, opinions on which properties are essential and 
which accidental may diverge. Some might regard the statement  "ex:Alice 
rdf:type ex:HumanBeing" as expressing an essential property of Alice but 
not of HumanBeing, others might argue that after a certain degree of 
cyborgisation Alice would still be Alice as the constant meaning of 
ex:Alice but no longer a HumanBeing. I think a safe approach is to 
consider everything but the name itself as accidental properties.

RDF provides no means to un-assert or to negate a graph. Ontologies 
however can be either designed to describe invariable worlds (or 
time-slices of a changing world) or to describe a world including its 
temporal dimension. In the latter case true triples never become false 
as long as the world is consistent with the assumptions of the ontology 
designers.

For example using FOAF we have a graph

[foaf:mbox mailto:reto@gmuer.ch ] foaf:lastName "Gmür".

Which was true till 2002-06-04 and false since then. With another 
ontology designed to describe a changing world (tfoaf) the graph would 
be more complicated:

[foaf:mbox mailto:reto@gmuer.ch ] tfoaf:namingPeriod [tfoaf:lastName 
"Gmür"].

The above graph is true at any point of time as it is entailed by the 
following more comprehensive graph:

[foaf:mbox mailto:reto@gmuer.ch ]
    tfoaf:namingPeriod [tfoaf:lastName "Gmür", tfoaf:ends "2002-06-04],
    tfoaf:namingPeriod [tfoaf:lastName "Bachmann-Gmür", tfoaf:starts 
"2002-06-04].

Whether to use an ontology describing a changing world or not depends on 
the scope of the description. For many use-cases adding the temporal 
dimension in the description would mainly make it less compact and 
harder to use (for humans as well as for computers evaluating queries).

Rather than as a set of (named) graphs the semantic web can be seen as a 
set of (named) changing graphs. Keeping tack of these changes is not 
trivial as versioning systems are typically designed for text-files and 
not for graphs. The result of a research project I did for HP labs is 
the the Graph Versioning System GVS [2].

GVS keeps track of different graph-over-times and allows to get 
aggregations of sets of these graphs for any point in time. GVS bases on 
graph decomposition rather than quads which is better suitable for 
threating b-nodes as existential variables, i.e. versioning the 
expressed content rather than the triples [3].

Cheers,
Reto



1. http://www.w3.org/TR/rdf-mt/
2. 
http://gvs.hpl.hp.com/documentation?stylesheet=/application/stylesheets/combined 
(requires XSTL capable browser)
3. see 
http://jena.svn.sourceforge.net/viewvc/*checkout*/jena/gvs/trunk/doc/triple-vs-molecule-versioning.html?revision=3297 
for a discussion of the topic


Phillip Rhodes wrote:
> Semantic Web community:
>
> In a discussion that has arisen recently on the foaf-dev list, somebody
> pointed out that they've been told that RDF triples live forever.  
> That is, once something is asserted it is considered asserted until, 
> as it
> was put, "the entropic heat death of the universe."
>
> This seems counter-intuitive to me, as I can see plenty of data - 
> which might be expressed in RDF - which changes, expires, or is otherwise
> not valid for perpetuity.
>
> Can anyone here elaborate on this?  Is it really a widely held axiom 
> that triple assertions "live" forever?  If so, what is the 
> justification, and how does one deal with changing data that would
> invalidate a previous assertion?
>
>
> TTYL,
>
>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev