The Sun BabelFish Blog

Keeping track of Context in Life and on the Web

My brother recently started putting together a podcast of an interview with my mother using Garage Band. It turned out to be very funny as my mother would tend to speak about things assuming that everyone knows about the context in which she speaks. So my mother (Heidi) will speak about "the heads lying around in our garden" which for someone not familiar with her career as a sculptor would make them wonder a little about what is going on in our house. People who meet Heidi in real life, of course immediately deduce these facts from the context: seeing my mom wearing clay covered clothes and a funny hat is usually a good indicator that we are not here dealing with an accountant. But on a podcast, one has to assume that people listening may know nothing at all about her profession, and since they have only her voice to go on, things can be a little confusing. My brother spent a lot of time decontextualising the infromation in the interview...

Decontextualised information is useful, and on the web more so that in other places, but it is not without drawbacks.
Decontextualising information makes it a lot longer. I can say "This house is big", but if I wanted to decontexualise it properly I would have to give information as to where the house is located, at what time of the house's existence this was the case, and in relation to what the predicate big was applicable.
Also, surprisingly, complete decontextualisation of information in fact looses some information. So if I give you a map of the Paris underground when you ask me where you are, you will have all the information you need, but one essential piece will be missing, your relation to the map: where you currently are, your context. If you call the talking clock, you want to know the time now, not the time it was at the time it was that time, which would be completely uninformative.
Finally deciding on the best framework for decontextualising all data, what some seem to call an upper ontology, is work in progress, and it is quite possible that there may never be a final one, as such work itself takes place in a context, which may be the object of future assertions. In any case we always have Gödel's incompleteness theoremto take account of, which says that there can be no final compelete theory of anything.

So we both need more decontextualised information on the web, and yet we can never hope to have a framework to express information in a completely decontextualised way. And if we found a framework that decontextualised information well enough for all our needs it would very certainly be very complex and difficult to understand. Most people live in a local, present tense world. That is what we have been naturally selected for.

But there is a simple solution, which my brother examplified in his podcast, when he lifted the information from my mother's local context to one more easily understood in the wider context of the web. And this is what Guha's 1995 paper Contexts: A Formalization and Some Applications is all about. I discovered this accident thinking about temporal relations. And it has helped me feel immensely more comfortable about the Semantic Web project.

So say you start off with the now:temperature relation, that is clearly very context sensitive, but that you keep the context of where and when you fetched the information in your database.

@prefix now: ≤http://eg.org/now#≥ .
@prefix : ≤http://eg.org/meta#≥ .
@prefix god: ≤http://eg.god/ont#≥ .
@prefix tr: ≤http://www.isi.edu/~pan/damltime/time-entry.owl#≥ .
@prefix log: ≤http://www.w3.org/2000/10/swap/log#≥.

{  :blue now:temperature "22" .
   :white now:temperature "21" .
   :red now:temperature "23" . }
                 :fetched [ :at "2006-03-23T10:00:00Z";
                            :from ≤http://people.gov.org/ssn/123456789≥ ] .

You can then develop the following lifting rule to move the above information out of its temporal context into a more general context

@forAll :Obj, :Temp, :FetchTime, :Fmla .
{ :Fmla :fetched [ :at :FetchTime ];
         log:includes { :Obj now:temperature :Temp } .  }
         => { :Obj god:timeslice  [ tr:inCalendarClockDataType :FetchTime;
                                    god:temperature :Temp ] .  } .

Then if you run this through cwm you get

hjs@bblfish:1$ cwm time.n3 --think --filter=time.n3
#[snip]
      @prefix god: ≤http://eg.god/ont#≥ .
      @prefix : ≤#≥ .
      @prefix tr: ≤http://www.isi.edu/~pan/damltime/time-entry.owl#≥ .

     :blue     tm:timeslice [
                                   god:temperature "22";
                                   tr:inCalendarClockDataType "2006-03-23T10:00:00Z" ] .

     :red     :timeslice  [
                                 god:temperature "23";
                                 tr:inCalendarClockDataType "2006-03-23T10:00:00Z" ] .

     :white     :timeslice  [
                                 god:temperature "21";
                                 tr:inCalendarClockDataType "2006-03-23T10:00:00Z" ] .

As you see the information in the larger context is a lot more verbose that the temporal one. But it is just one simple rule away. The advantage of the information in the larger context, is that it is then possible to merge information (graphs) collected from different places into one unified database. True, we can merge all the graphs where the now:temperature information was said at the same time using the same now:temperature relation. But with the god:timeslice relations we can merge information from all the objects in our universe at any point in time.

Posted at 11:21AM Apr 04, 2006 [permalink/trackback] by Henry Story in SemWeb  |  Comments[1]