temporal relations

I have been thinking a about temporal relations [1] recently, which  
led me to the following thought.

Imagine I have some measurement apparatus that has a built in web  
server that serves rdf. This server can measure the temperature of a  
number of balls identified by their color, blue, white and red. To  
express the temperature of the balls the ontologists developed a  
now:temperature relation which gives the the temperature of an object  
now. So when fetching the page http://eg.org/temp.n3 the following  
representation is returned

@prefix now: <http://eg.org/ont/> .

<#blue> now:temperature "22"^^xzd:celsius .
<#white> now:temperature "21"^^xzd:celsius .
<#red> now:temperature "23"^^xzd:celsius .

There is no question that this data can be used by a consumer. If the  
consumer wishes to store the data though he might find it a little  
difficult in the above form. Imagine that 10 minutes later he fetches  
the same file and now receives the following representation

@prefix now: <http://eg.org/ont/> .

<#blue> now:temperature "12"^^xzd:celsius .
<#white> now:temperature "11"^^xzd:celsius .
<#red> now:temperature "13"^^xzd:celsius .

it is clear that he could store both graphs in the database quite  
nicely as long as he keeps them separated in graphs with clear  
temporal provenance information

{ <#blue> now:temperature "22"^^xzd:celsius .
   <#white> now:temperature "21"^^xzd:celsius .
   <#red> now:temperature "23"^^xzd:celsius . }
                 :fetched [ :at "2006-03-23T10:00:00Z"^^xsd:dateTime;
			   :from <http://eg.org/temp.n3> ] .
	
{ <#blue> now:temperature "12"^^xzd: celsius .
   <#white> now:temperature "11"^^xzd:celsius .
   <#red> now:temperature "13"^^xzd:celsius . }
                 :fetched [ :at "2006-03-23T10:10:00Z"^^xsd:dateTime;
			   :from <http://eg.org/temp.n3> ] .

but merging the two graphs in a simple way should lead to nonsense  
such as

<#blue> now:temperature  "22"^^xzd:celsius ,  "12"^^xzd:celsius  .

which would say that the blue ball had 2 temperatures simultaneously.

It seems that sentences containing the now:temperature relation are  
indexicals relating to some property of the graph containing them.  
Another way to put this would be to create another ontology "god"  
that looks at things from outside of time. This ontology has a  
god:temperature relation that relates an object at a time to its  
temperature. In this ontology the first graph could be expressed as

@prefix god: <http://eg.god/ont#> .
@prefix tr: <http://www.isi.edu/~pan/damltime/time-entry.owl#> .
<#blue> god:timeslice [ tr:inCalendarClockDataType  
"2006-03-23T10:00:00Z"^^xsd:dateTime;
                        god:temperature "22"^^xzd:celsius ] .
<#white> god:timeslice [ tr:inCalendarClockDataType  
"2006-03-23T10:00:00Z"^^xsd:dateTime;
                        god:temperature "21"^^xzd:celsius ] .
<#red> god:timeslice [ tr:inCalendarClockDataType  
"2006-03-23T10:00:00Z"^^xsd:dateTime;
                        god:temperature "23"^^xzd:celsius ] .

After expressing the second graph in a similar way it is easy to see  
how they can be merged.
Facts like

<#blue> god:timeslice [ tr:inCalendarClockDataType  
"2006-03-23T10:00:00Z"^^xsd:dateTime;
                        god:temperature "22"^^xzd:celsius ],
                       [ tr:inCalendarClockDataType  
"2006-03-23T10:00:00Z"^^xsd:dateTime;
                        god:temperature "12"^^xzd:celsius ];

Seem to capture exactly all the information we had. Of course  
expressing things in the god ontology takes more space. There is also  
a small information loss in the god ontology view of things in that  
an agent receiving the god representation would not necessarily know  
that this was the temperature of the balls *now*, say if the agent  
did not have a clock. But otherwise it is as much as we can ask for.

The question then is: how does one convert relations from one  
ontology to another? Would the following rule do? [2]

@forAll :obj, :t, :fetchtime
{ { :obj now:temperature :t } :fetched [ :at :fetchtime ] }
	=> { :obj god:timeslice [ tr:inCalendarClockDataType :fetchtime;
                                   god:temperature :t ]  } .


I tried running the following file through "cwm time.n3 --think" but  
it does not add the facts I was hoping it would.

v-----time.n3--------------------------------v
@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#> .

{ <#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> ] .

@forAll :obj, :t, :fetchtime .
{ { :obj now:temperature :t } :fetched [ :at :fetchtime ] . }
         => { :obj god:timeslice  
[ tr:inCalendarClockDataType :fetchtime;
                               god:temperature :t ] .  } .
^-------time.n3-------------------------------^


Any ideas on what is wrong with my n3?

Also if this is does work, one could create a vocabulary to annotate  
different types of indexical properties, so that one could then  
create rules that could automatically convert them to mergeable graph  
structures.


Henry


[1] http://blogs.sun.com/roller/page/bblfish/20060320
[2] followign the definitions given at http://www.w3.org/2000/10/swap/ 
doc/Reach

Received on Thursday, 23 March 2006 10:31:01 UTC