Modelling Time
Rather than reinvent the wheel, Ontonym uses the the W3C OWL-Time ontology to represent all temporal information. OWL-Time is based on Allen’s interval based temporal logic that defines seven relationships between intervals (during, starts, finishes, before, after, meets, and equals) and their inverses for a total of 13 (equals has no inverse). OWL-Time provides a comprehensive vocabulary for expressing facts about topological relations among instants and intervals, together with information about durations and date-time information.
Although OWL-Time is more expressive that the XML Schema representations of time that it supports, we favour the latter due to built-in support in many technologies for working with such representations. support working with XML Schema date-time representations (e.g., the SPARQL query language).
The primary use of temporal information in Ontonym is to characterise the temporal properties of data captured by sensors. This comes in four forms:
- dynamism – the rate at which an observed value is expected to change
- temporal dimension – whether data describes past or planned state
- observation time – the time at which the observation was made
- sampling period – the frequency at which observations are made
We loosely define a sensor as as anything that encodes information about the state of real world. For example, a person who fills in a user profile is considered a sensor in our system.
There are many cases where information about all of these temporal aspects is not-available when new data is contributed. However, the greater the amount of information provided, the better our ability to interpret the model.
The adoption of Named Graphs for version 0.8 of Ontonym has allowed us to unify our approach to modelling temporal meta-data in our OWL models. To illustrate it’s use, consider a system where three sensors provide information about the location of Bob:
- A bluetooth sensor that infers Bob’s location via the presence of his mobile phone.
- A location summary sensor that summarises the historical location of people in order that individual readings need not be maintained.
- A calendar sensor that provides information about Bob’s planned activities and locations.
We begin by defining each of the sensors described above. In this example we only define the sampling period of the sensor. See the Sensor ontology page for further information on modelling sensors.
g:G1 {
:bluetoothSensor a sensor:Sensor ;
sensor:frequency
[ a time:Interval ;
time:hasDurationDescription
[ a time:DurationDescription ;
time:seconds "15"^^xsd:integer ] ] .
}
g:G2 {
:summarySensor a sensor:Sensor ;
sensor:frequency
[ a time:Interval ;
time:hasDurationDescription
[ a time:DurationDescription ;
time:hours "1"^^xsd:integer ] ] .
}
g:G3 {
:calendarSensor a sensor:Sensor ;
sensor:frequency
[ a time:Interval ;
time:hasDurationDescription
[ a time:DurationDescription ;
time:minutes "30"^^xsd:integer ] ] .
}
This code defines three graphs, G1, G2, and G3; each defining a sensor and its frequency. The bluetooth, summary, and calendar sensors are defined as having a sampling period of 15 seconds, 2 hours, and 30 minutes respectively. Despite supporting some XML schema representations, OWL-Time does not support the XML schema representation of a duration, using its own vocabulary instead. In the interest of brevity, we are considering adopting the XML Schema definition in the next version of Ontonym.
Starting with the bluetooth sensor, we can describe a sighting of a person as follows.
g:G4 {
:bob location:locatedAt :meetingRoom .
}
g:G5 {
g:G4 sensor:sensedBy :bluetoothSensor ;
sensor:observedAt
[ a time:Instant ;
time:inXSDDateTime "2009-04-10T13:05:00Z"^^xsd:dateTime ] .
sensor:temporalDimension
[ a time:Instant ;
time:inXSDDateTime "2009-04-10T13:05:00Z"^^xsd:dateTime ] .
}
Graph G4 describes the fact that Bob is located in the meeting room, whilst graph G5 states that this was asserted by the bluetooth sensor at 13:05pm on the 10th of April 2009, and that the statement in graph G4 is considered true at the time of the observation.
Note that we use the example of a bluetooth sensor sensing a person as a convenience. It is more likely that the sensor would sense the location of a bluetooth device, with external reasoning required to infer to the location of the person.
Next we look at a sample observation by the summary sensor:
g:G6 {
:bob location:locatedAt :bobsOffice .
}
g:G7 {
g:G6 sensor:sensedBy :summarySensor ;
sensor:observedAt
[ a time:Instant ;
time:inXSDDateTime "2009-04-10T12:00:00Z"^^xsd:dateTime ] .
sensor:temporalDimension
[ a time:Interval ;
time:hasBeginning "2009-04-10T09:00:00Z"^^xsd:dateTime ;
time:hasEnd "2009-04-10T10:30:00Z"^^xsd:dateTime ] ;
sensor:temporalDimension
[ a time:Interval ;
time:hasBeginning "2009-04-10T11:00:00Z"^^xsd:dateTime ;
time:hasEnd "2009-04-11T11:45:00Z"^^xsd:dateTime ] .
}
The statement in Graph G6 describes Bob being located in his office. Graph G7 states that at 12:00 on the 10th of April 2009 the summary sensor asserted that this statement was true (i.e., Bob was located in his office) from 09:00 – 10:30 and from 11:00 – 11:45 on the same day.
A similar approach applies for the calendar sensor:
g:G8 {
:bob location:locatedAt :Scotland .
}
g:G9 {
g:G8 sensor:sensedBy :calendarSensor ;
sensor:observedAt
[ a time:Instant ;
time:inXSDDateTime "2009-04-10T14:00:00Z"^^xsd:dateTime ] .
sensor:temporalDimension
[ a time:Interval ;
time:hasBeginning "2009-05-11T12:00:00Z"^^xsd:dateTime ;
time:hasEnd "2009-05-22T22:00:00Z"^^xsd:dateTime ] .
}
Graphs G8 and G9 describe predictive data provided by the calendar sensor, that describes the fact that Bob plans to be located in Scotland from the 11th to the 22nd of May 2009.
The final property of temporal nature we can describe is its dynamism, or expected rate of change. This allows a sensor to assert the length of time a value in the model is likely to reflect the true state of the world. For example, the coordinate location of a walking person is likely to change at the rate of seconds, while a representation at a higher granularity, such as a region of a city or country is likely to change less frequently, perhaps minutes, hours, or days. This value is only an estimation, and sensors are not be required to report it.
For example, in the context of the bluetooth sensor, we might extend graph G5 to state that we believe the value likely to be true for 10 seconds after it has been observed:
g:G5 {
g:G4 sensor:expectedRateOfChange
[ a time:Interval ;
time:hasDurationDescription
[ a time:DurationDescription ;
time:seconds "10"^^xsd:integer ] ] .
}
The interpretation of the expected rate of change property varies depending on whether it applies to historical, current, or predictive data. For historic data, the property has no meaning, and should be omitted. For current data, the meaning is as above — how long the asserter expects the value to match the real-world value. For predictive data, the value refers to how long the asserter expects the prediction to remain unchanged.
In many cases, assumptions about the data being worked with, or restrictions on storage or computing resources may allow or require part of the model to be omitted from an implementation. In order to limit the size of the data model, it makes sense to only temporally qualify data when necessary. For statements where no temporal data is asserted, we may assume that they are always true. For example, this allows an assertion to be made, such as bob’s name being “Bob” , with a temporal qualification being associated only if Bob changes his name at a later date.
The Ontonym model model also provides a nice approach for dealing with some of the less dynamic information in the system. For example, a sensor’s frequency may change over time, but we may represent this just like all other data, by temporally qualifying the old statement, and introducing one describing the new value. Sophisticated queries can be used to identify what the value of the sensor frequency was at the time a particular sensor reading was made.
As a final note, if we discover an incorrect statement in the model, such as the description of the frequency of a sensor, it is possible to “correct’” the model, whilst retaining the record of the old value, by using the temporalDimension property to assert the correct value as historic data. Values can be updated and old values corrected and re-corrected to an arbitrary depth using this technique. Timestamps can then be used to work out what the value of a property was at any given time (or more interestingly, what we thought the value of a property at a given time T1 was, at some other time T2).
No Comments Yet