W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 1999

Re: RDF API / URIs of reified statements

From: Jonas Liljegren <jonas@paranormal.o.se>
Date: Sun, 05 Dec 1999 23:39:14 +0100
Message-ID: <384AE992.4461FB3D@paranormal.o.se>
To: Gabe Beged-Dov <begeddov@jfinity.com>
CC: Sergey Melnik <melnik@DB.Stanford.EDU>, RDF Interest Group <www-rdf-interest@w3.org>
Gabe Beged-Dov wrote:
> Models are Resources
> ==================
> Many of the participants have indicated their desire for being able to
> treat models as resources. I just wanted to point out what may be obvious
> which is that each set operation returns a new model. Each of these result
> models should also have their own URI. This falls under the issue of NoName
> resources.

The handling of new versions of models is not clear yet.

 1. Often you want to say something about the state of affairs right
    now. Like "On what address does this person live?" or "How is the
    weather tight now?" This is things that change with time.

 2. Maby you want to correct, reorganize or add to a description of

I always visualize the model URI as a resource you could retrieve with
a http GET request. The web page would show up as serialized RDF/xml.

This URI is owned by the people with the power to decide over the
content of the URL document. (And that fact could be described in some

The application should differ between models it owns and models it
doesn't own. You could make a local copy of a model, but you have no
right to change it. That would make the cached copy faulty.

You could state your own version of things in your own model and you
could comment on things in others models, using reification.

 Model versions

It is up to the model owner to decied on the handling of new

In many cases, you would like to have a version number as part of the
URI. Later versions would subclas/extend/override things in the
previous version. That would be the case for core schemas used in
applications, like core literal value types, logic representation, and
many other things.

But I wouldn't want to make it a whole new model for every change in a
big database. As an example, http://rdf.cogsci.princeton.edu/wn16/
would not have to change to http://rdf.cogsci.princeton.edu/wn17/ if
you changed the wording of a description in one of its entries.

It's up to the application to have a current copy of a model.

 Problems with lack of model versions

You can't make good comments of statements that change or
disappear.  A statement of a model could be made false if the content
of the model changes.

This should be expected in many cases. An RDF description service
could state that a particular PICS server is to be trusted for giving
accurate ratings of used automobile web auctions. The PICS server
would be a model (the top one in a hierarchy of models), and that model
could change from day to day. But the statements from the meta-service
would still be valid. 

As another example: every web index and even, in the future, the RDF
web pages indexed by the web index would be models. You can't continue
changing the uri for every single change in any single other uri.

But the lack of model versions would be a problem in cases where you
say somehting like "everything in this model is true", and then a
nasty error makes its way to the model. Other things to say about a
model could be about its origin, its size, etc.

I think that the problems with statements about models could be
handled on a higher level, in RDF itself. You can never be sure to
have the absolutly latest version of a model. You can only state what
you believe to be true. Statements about the size, last modification
date, and other things about a model should be updated by the
application. Two applications (or RDF caches) could have conflicting
data about the last modification date. This could be used to determine
if an update is in place.

But the real problem of the lack of versioning comes if you decide to
use models as the base for naming triples. (to be continued... ;)

/ Jonas  -  http://paranormal.o.se/perl/proj/rdf/schema_editor/
Received on Sunday, 5 December 1999 17:29:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:21 UTC