[RDF] Version handling

[Jonas Liljegren]

Stefan Andersson <stefan@c64.org> writes:

> > But how do we say that one statement should replace another statement?
> > Or that a specific statement or group of them should be deleted?
> > 
> > What would be a good way of handling this?
> 
> I'd say there is no 'good' way of handling it. Either you go the full
> nine yards, and implement a system capable of handling true
> (hyperdimensional) context, which probably would be humongously big and
> slow, or you have to cut it down. And cutting down necessarily means
> letting out.

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

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


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.

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.

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.


Help me out here...



> 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.


> 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.


> That is, 'instance' has to be a recursive in the same way as 'class'
> is. Once more - class vs instance.

Now I lost you.


> 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.

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


> Sameness/Differentness as a vector... hmm. With increasing time one
> supposes increased accumulation of experience and inference, thus the
> versions ordered temporally represents increasing experience and
> inference... but where is the breaking points? Where is the 'this is one
> version, and now it has changed enough that we may call it another'? I
> see the analogy to the 'what is a model, and what is not'-question.
> Internal concistency seems like a good measure...

This is a question about the granuality of time?  Where shouldn't be a
problem to group models i larger groups.  The basic use for models is
just so that we don't have to have a lot of metadata about each statement.

And in the case of imported RDF/XML documents, there is a clear unit
that would become the model.


-- 
/ Jonas  -  http://jonas.liljegren.org/myself/en/index.html