SV: [RDF] Version handling

[Stefan Andersson]

> I meant to ask; what is the best way of handling this?

Ah, damn - a concrete question.

> We don't have to have the ultimate versioning system. It would be nice
> if it could be extended to the ultimate system. :)

Mmmm... * dreamy voice *

> The basic thing we want to do is to filter out previous versions of a
> statement.  Let's say that I chnage the phone number. The old
> statement remains but should not normaly be shown.

Yeah, there is a few 'atomic' filters - 'current valid version (a.k.a.
latest)' that deserves an extra optimization boost, but (as you know) I
think it's an interesting idea to think of a filter as a 'virtual model', so
you have this vast ocean of resources, and look thru the 'latest'
spectacles, you'll only see the model consisting of all the 'latest'
resources.
 
> We could base the version handling on statements bound to a point in
> time.  Every statement belongs to a model and the model has a creation
> date (and maby should have a last-updated-date (in case for "open
> models")).
> 
> The date information could be used to see what information is the most
> recent.  But I could have two phone numbers so it wouldn't be right to
> just exclude one of the numbers if the other is more recent.  The old
> number must be expired in some way.

Actually, that's a rather interesting example. It illuminates the point that
it is not enough with f.ex. 'home phone'. And I still maintain that you
never 'change' a statement. You revoke an earlier statement, and make a new.
It kind of solves your problem, doesn't it?

> Time based versioning is nice because it let's you examine a systems
> state in a previous time.  But updated information could also be about
> correctd information. The old information wasn't correct at any time.

See above.
 
> Help me out here...

Rocket ranger to the rescue!

> > In 'the real world' we do remember stuff that an agent has said before
> > even if that agent says something else now. Is the discrepansies between
> > now and then too wide, or if we encounter them too often, we will have
> > to downgrade our trust in that source. Once more trust. Trust is key.
> 
> Well. that's not the problem.

Ummm. You lost me on this track?
 
> > My point being that every statement is separated in time and space from
> > every other statement. The idea that two statements are 'the same' is a
> > connection done on the idea plane - thus one would need a layer of root
> > data, and another interconnecting layer of 'sameness' or 'class'.
> 
> Yes. And I think that one simple way to do it is that just say that
> the new statement should replace the old.  That would be
> 
>     new_statement --replaces--> old_statement
> 
> If you combine this with the trust thing, you would have to implement
> an efficient way to select all non-replaced statements except those
> replaced by non-trusted statements, unless those in turn has been
> replaced with a trusted statement...
> 
> I just ask for an efficient model for the implementation.

Well. Based on my work with this kind of models in content managing, I'd say
that what you need is a 'created' - 'revoked' model, where you'd apply a
cached filter on what resources are 'created' but not 'revoked', these are
your current model.
(Actually, our CM model was a wee bit more complicated, as you had four
states: 'created', 'updated', 'published', 'revoked' to separate the two
levels of publishing - the level where only the author saw the changes, and
the level where everybody could see the changes.)
 
> > Actually - one could say 'version' roughly means 'sufficiently
> > equivalent', that is, 'all those instances could fill roughly the same
> > function, but with small, maybe critical, differences'.
> 
> Ah. Now I think that I understand.

Versioning points to the fact that you should be able to say 'this instance
is a sub-instance of this instance' a.k.a. 'version'.

> You can produce two statements about diffrent things, but that
> contradict each other in some way.  Which of the statements should we
> follow?

The trick is to isolate the discrepancy - the very thing I was hoping we
could implement intelligently in WRAF.

/Stefan