Handling Change on the Semantic Web

Status

$Revision: 1.2 $ $Date: 2002/05/01 17:53:07 $

A proposal and some discussion

 
  I have a better idea.   Here it is.  I'll try to integrate and
  explain it better soon.

       People/Systems make signed & dated (identified & timestamped)
       assertions.  These are in some language mapped by its
       interpretation to an RDF Graph.

       Some of these are available to the system answering our query.

       kim,8am: George is in San Francisco
       
       [ Contrast with the absolute form, which agents may form
       internally: "At 9am, Kim believed George was in San
       Francisco".  If this were to be expressed externally, what
       would its place in time & believer be?  Could it be changed?
       What would it mean if it were changed.   All assertions must be
       signed & dated to be usable. ]

       Two Assumptions:

       "No News means Nothing Changed"

          This is painful, but necessary.  It's often incorrect,
	  but what else can you do?  You aim your rocket for where
	  the moon appeared to be going, but you can't possibly
	  know if the moon is going to be there when you arrive, or
	  even if it's still really there when you start your trip.
	  (Light takes time to get to you; your body/mind takes time
	  to understand the light when it arrives.)

       "Contradiction Means Something Changed"

          Three kinds of contradiction can be used:

             kim,9am: I do not know whether George is in San Francisco
	     (local retraction)

	     kim,10am: No one knowns whether George is in San Francisco
	     (global retraction)

	     kim:11am: George is not in San Francisco
	     (refutation)

          One might also assume Contradiction Means Someone Made a
          Mistake, or Contradiction Means Someone Is Lying, but this
	  assumption should generally be made first.   The other two
	  are harder to deal with.

Introduction

Think of the Semantic Web as big collection of facts. People are putting in facts that they believe are true and want to share with others. People are taking out facts that they no longer believe are true, or no longer want to share with others. It's a lot like the Web today, except the facts are RDF Statements, instead of words on web pages. Another difference is that people should be allowed to take out facts that others put in.

What about trust? Each addition or removal of knowledge must be evaluated based on some trust criteria. The facts that you see in the big collection will depend on which authors you chose to trust.

Proposal

  1. We have a subclass of rdf:Statement, change:Change, which adds source (author) and time-of-effect properties. (Behavior in the absense of these being known is undefined.)
  2. change:Change has two subclasses, change:Addition and change:Removal.
  3. The software which fetches-and-parses RDF should (logically) turn the fetched RDF into a collection of change:Addition objects with the author and effective point-in-time provided by the underlying medium. The author should be verified in some manner appropriate to the current trust rules. (Should we also use data from within the document? Probably, but trust issue get more complex.)
  4. Software which provides read access to RDF should be parameterized by trust preferences and two time values: (1) the cutoff time, giving the maximum time-value for Changes to process, and (2) the "as-of" time, giving the point in time for which the state of the world is being queried. You could use the cut-off time to examine historical state, but you will miss any information added about events after the events occured.
  5. Time-Loops (time-travel paradoxes) are possible. They are probably no more detectable than loops in computer programs.
  6. Conditionals are time-independant (although they may be added and removed at points in time, of course). As knowledge is added and removed, they will cause other knowledge to be added and removed. It's fine to have a conditional conclude that knowledge should be removed. This can cause paradox-loops as well.
  7. The conclusions of conditionals get a change:source which is usable to construct a proofs.

Example

We want to track where Eric is at all times. Various people are employed in this effort.

The simple query { person:eric loc:location ?x } should return ?x bound to the place Eric is believed to be. If we have no data about his current location, we'll get no matches. If we have several facts, we might get several matches. (He might be in Boston and Massachusetts; he might be reported (incorrectly) to be in Boston and San Francisco).

We should be able to ask where he was in the past by simply passing an as-of time to the query engine.

We should be able to display all his moves by querying to all the Additions and Removals such statements. Some of those may come from conditionals (like "If Eric is in Boston, Eric is in Massachusetts"), because the inference engine produces Changes (or appears to produce them, when queried, at least). This allows us to see who is saying he is each place (and no longer at each place).

@@@ fill in working example. :-)

Sandro Hawke
First: 2002-03-29; This: $Id: change.html,v 1.2 2002/05/01 17:53:07 sandro Exp $