Sergey Melnik wrote:
> 
> do you think the API draft [1] and digest-based URIs for models
> adequately address the need for model versioning that you pointed out in
> your last posting [2]? Or is an explicit mechanism still needed in your
> view?
> 
> [1] http://www-db.stanford.edu/~melnik/rdf/api.html
> [2] http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0012.html


I wanted the model to 
  1. be a way to say something about a group of statements. 
  2. differ between local and remote statements.



Let's say we have a RDF service that give us some useful information
about a person, like phone number, home address, occupation, etc.  The
service URL could be:
    http://rdf.some.org/person/

The service has access to some sort of database over a lot of
persons. The URL http://www.some.org/person/ would lead to a HTML
search form, but the URL for the RDF version will lead to a document
in RDF, describing its identity and capabilities.

The URL for an actual person could be the country version of the
social secutiry number.  A swedish person:
    http://rdf.some.org/person/sv/19720529-1234

This would be the URL of a RDF document, stating the name, addres,
home phone number, occupation, e-mail address, birthdate, etc, for
this person.


Now, assuming MD5 model URIs, we would like to differ between:

 1. The URI of the service
 2. The URL of the service
 3. The URI for the physical person
 4. The URI of the model describing the person
 5. The URL of the model describing the person
 6. The URI of the model describing the service
 7. The URL of the model describing the service

* The person could change his phone number and even his name. (He
  could also change his SSN, but that would mean URI aliases and
  that is another story.)

* The service is controlled by some owner. But it could be mirrored
  across the world, thus the URL could differ.

* The RDF model could be copied or cached, thus the URL could differ.



The local application will directly or indirectrly state the degree of
trust in the service. In some form:
    service --trust--> 'high'

It will get a copy of other information about the service from the
Service URL. This would be a model with a MD5 URI:
    service -- owner --> some.org
    service --  url  --> alt1
    alt1    --  _1   --> http://rdf.some.org/person/
    alt1    --  _2   --> http://rdf.mirror.se/some.org/person/
    service -- label --> 'Some person directory'
    service --updated--> 'some date'
    and more... 
    (maby something aboutEach person model in the directory)


The local application would retrieve a copy of the service model, and
would have to say something about it:
    service_model --origin --> http://rdf.some.org/person/
    service_model --updated--> 'some other date'
    service_model -- owner --> some.org
    and more...

In the same way, the local application would annote the copy of the
person_model.


The application would internaly couple every statement with its
model. And it would handle identical statements in multiple models as
the same statement. The purpose would be to handle the version and
origin of the model.


What happens when a new version of the specific person model appears
and gets downloaded? The model would have a new URI. The application
would have something like:
    person_model1 --origin -->
http://rdf.some.org/person/sv/19720529-1234
    person_model1 --updated--> 'some time ago'
    person_model2 --origin -->
http://rdf.some.org/person/sv/19720529-1234
    person_model2 --updated--> 'a couple of minutes ago'

(The possibility of several URLs for the same model complicates
this. It is not realy the origin that is of intrest, but rather what
some.org has to say about this person.)

The application could keep a history if it wanted to. It would have to
contain som logic about what version to use. The only difference
between the two versions would perhaps be the home phone number. All
the other statements would now be coupled with two models.

If it wanted to do an update, it would have to delete all statements
from model1 that has no coupling to any other model. (reference
counts?)

If this was a small update in a very large model, it would still have
to go through every statement two times. First it would have to
couple the statement to the new model. After that, it would sever the
couple to the old model.

If the application do want to keep a history, it would have situations
like this:
    person --home_phone_number-->'+46-31-123456'
    person --home_phone_number-->'+46-31-445567'

These statements would have to diffrent URIs that will be used with
the reification of the statements. I have previously suggested that
the model could be modeled as a bag of statements. But now, I would
use something like this instead:
    statement1 --model--> person_model1
    statement2 --model--> person_model2

In this way, you could retrieve both the origin and date of the
statement. And the origion would lead yot to the degree of trust you
would put in the statement.



I like this. =-)  It seems that it does work to differ between the URI
and the URL.