Sergey Melnik wrote:
> 
> (3) changes: the generated URIs will only make sense, if the "context"
> of the URI remains intact. As soon as I add another property to the
> resource, or modify property's value, the URI breaks.
> 
> On the other hand, we can move the descriptions around in the document.
> I think this content-based approach works better than an XPointer-based
> one.

Yes. That would be better.

In this solution, you separate the URL of the source from the URI of
the model.

What was the purpose of having an model URI in the first place?

I was thinking of using the model URI as a way to keep track of the
origin of a statement. With your solution, we would have to put the
origin of the model in another statement. This separation of the model
URL and the model URI got me a little confused, but seems like the
better choise.

Cash handling and version handling is two very important factors for a
general implementation of RDF.

I am planning to cache as much as possible in my RDF schema
implementation. This cached value would depend on one or more
models. If the models change, you would have to clear the cache for
the affected method invokations.

I was thinking of pairing the origin URL with a date. But with the MD5
value for a model, that could be used instead.

Another way to do an effective cache would be to let every cahced
method register a callback with the source methods. A change in the
basic triple manipulation methods would trigger the change in all
dependent cached method values.

Which alternative would be the most effective in a big complex RDF
web?



In my DB-based implementation, I could get away with not computing a
model URI for the local changing data. But I would use it for handling
versions of external models.