[foaf-dev] RDF triple assertions live forever?

[Reto Bachmann-Gmür]

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 at gmuer.ch ] foaf:lastName "Gm=FCr".

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 at gmuer.ch ] tfoaf:namingPeriod [tfoaf:lastName =

"Gm=FCr"].

The above graph is true at any point of time as it is entailed by the =

following more comprehensive graph:

[foaf:mbox mailto:reto at gmuer.ch ]
    tfoaf:namingPeriod [tfoaf:lastName "Gm=FCr", tfoaf:ends "2002-06-04],
    tfoaf:namingPeriod [tfoaf:lastName "Bachmann-Gm=FCr", 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=3D/application/stylesheets/c=
ombined =

(requires XSTL capable browser)
3. see =

http://jena.svn.sourceforge.net/viewvc/*checkout*/jena/gvs/trunk/doc/triple=
-vs-molecule-versioning.html?revision=3D3297 =

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 at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080327/7b=
83ec18/signature.pgp