The Placelab Ontology
Please note, that this page is being constantly updated! We intend on improving this page daily. If you have any questions, please leave a comment!
This just in:
Check out the situation ontology here! This ontology shows the correlation between a situation or activity and the contextual data used to represent it. This is explained below.
This page demonstrates how we created the placelab ontology. We hope by providing an example ontology such as this, and the process by which it was created, we can help people develop other ontologies. If you do, let us know!
Location
The placelab apartment contains 8 distinct locations. You can see them most clearly in this picture:
From left to right, you see the living room, dining room, kitchen, office and bedroom. On the bottom right is the master bathroom, while the powder room is located bottom centre. The hallway runs between the dining room and bedroom.
To show you how we define these locations and their relationships, lets take an example:
### http://ontonym.org/0.8/placelab.owl#hall
:hall rdf:type location:SymbolicRepresentation , owl:Thing ;
owl:sameAs :hallway ;
location:connected :foyer ,
:kitchen ,
:masterbedroom ,
:office ,
:powderroom .
In this example, we show an instance of a SymbolicRepresenation. This is defined as being connected to the foyer(entrance), kitchen etc. Connected, as noted in our location ontology is a relationship where by the other location is “adjacent and directly accessible to this one”. This is a fairly simplistic location definition. We could define dimentions of rooms etc
Objects
Objects in placelab are all the physical things which can be sensed. These include cutlary, cereal boxex, tables, chairs, remote controls … you get the idea. In Ontonym, anything physical in an environment that is not a person or a sensor can be defined as a physical resource. There can be logical resources too, such as printing functions or a tivo command to record Fraiser. In the example below, we define the TV. It is a farily simple definition, and can be extended with make, model etc if you are willing to create a TV ontology. As it is, we just define a television, with a unique ID television121. This resource is located in the livingRoom. That’s all we know about the TV, so that is all we can realistically state.
###placelab.owl:television121
:television rdf:type resource:PhysicalResource , owl:Thing ;
location:locatedIn :livingroom .
Althouth the definition of the TV is fairly simple, it is quite important, because we will use this resource when defining sensors. No point in defining sensors if there is nothing to sense, right?
Sensors
Placelab has lots of sensors installed in it. Just a few of these are:
Current to electrical sockets
Water flow to the taps, shower, washing machine and dishwasher
Gas flow to the hob on the cooker
Light levels in the rooms
RFID: The user (only the male participant unfortunately) wore an RFID reader on his wrist, meaning when he came into contact with objects which had RFID stickers attached, it was recorded. This is why it is necessary to define objects!
Object Motion: There were accelerometers attached to a bunch of things too, so we can tell if an object was moving or not.
Infra-Red Motion: As people moved around the house, they trigger these motion detectors.
Defining a sensor properly is very important. People looking at sensor data need to know what that data means, and in what context it is being provided. So, when developing a sensor, it is very important to show what a sensor can do, what its range of outputs is and how accurate it is. If you are using an off-the-shelf sensor like the ones in placelab, this information should come with the sensor’s documentation.
As an example of how you would define a sensor, lets take a look at the Current sensor. This sensor reports the number of Amps going to an electrical socket every second. It has an accuracy (according to the placelab documentation) of +-1.5%. Its range of outputs is 0-5 Amps.
From this information, we can define the sensor using an instance of the class Sensor. First we create a subclass of Sensor, called CURRENT. We then create an instance of that type as shown below.
We give this instance a type CURRENT, an identifier, a frequency and a quality value. This quality value define all the sensor’s capabilities.
Sensor Definition
placelab:B00000053B36B26 rdf:type :CURRENT , owl:Thing ;
device:identifier "0B00000053B36B26"^^xsd:string ;
sensor:frequency :CURRENTFrequency ;
muo-vocab:qualityValue :CURRENTPrecisionAccuracy ;
The quality value of out sensor has two properties: a precision value and an accuracy. Since we dont know any better we give an accuray of 1, meaning 100%. If you are confused about the difference between accuracy and precision, have a look at the Ontonym documentation, or alternatively read the Ontonym paper, where it is explained in detail.
Precision Accuracy
###placelab:CURRENTPrecisionAccuracy
:CURRENTPrecisionAccuracy rdf:type sensor:PrecisionAccuracyPair , owl:Thing ;
sensor:accuracy "1"^^xsd:double ;
sensor:precision :CURRENTPrecisionValue .
The precision value defines 2 things: The precision — we get 0.075 by getting 1.5% of 5, which is the maximum reading the sensor can output.
Precision Value
### placelab:CURRENTPrecisionValue
:CURRENTPrecisionValue rdf:type
sensor:PrecisionValue , owl:Thing ;
muo-vocab:numericalValue "0.075"^^xsd:double ;
muo-vocab:measuredIn electric-current:Ampere .
Rules
While we have discussed creating the ontology, and given the source, we also have created a few rules based on the placelab sensor readings. These were created to illustrate the use of rules, and the ability to perform inference. Using these rules allows very good flexibility with a trade-off on reasoning time. If you have any suggestions about how we might speed up this process, please, let us know!
The rules below are in the format of Jena’s general purpose rule engine. The source code on how these are actually used will be up here soon, so keep an eye out!
[light: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:LIGHT),
(?A classifications:readingValue ?C), greaterThan(?C, 5)
-> createClassification(?A")] [water: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:WATER),
(?A classifications:readingValue ?C), greaterThan(?C, 100)
-> createClassification(?A)]
[gas: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:GAS),
(?A classifications:readingValue ?C), greaterThan(?C, 5)
-> createClassification(?A)] [motion: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:MOTION),
(?A classifications:readingValue ?C), greaterThan(?C, 0)
-> createClassification(?A)] [om: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:OM),
(?A classifications:readingValue ?C), greaterThan(?C, 0)
-> createClassification(?A)] [current: (?A sensor:observedBy ?B), (?A rdf:type event:InstantEvent), (?B rdf:type placelab:CURRENT),
(?A classifications:readingValue ?C), greaterThan(?C, 0)
-> createClassification(?A)]
[location: (?A sensor:observedBy ?B),
(?C sensor:observedBy ?D),
(?B rdf:type placelab:MOTION),
(?D rdf:type placelab:OM),
(?B location:locatedIn ?X),
(?D location:locatedIn ?Y),
(?A classifications:readingValue ?E),
(?B classifications:readingValue ?F),
greaterThan(?E, 0),
greaterThan(?E, 0),
equal(?X, ?Y)
->
print("LocatedIn", ?X)]
Situations
This section is still under development, so if you are finding it a bit confusing, don’t worry. It will be made readable soon!
When we have “context”, we must now determine the situation. How we define “context” and “situations” is pretty simple. A situation is a set of contexts.
Therefore, a situation ontology is quite simple, with a situation type, and an “identifiedBy” property, which relates a situation to a context. This property can be used multiple times, thus linking a situation to multiple
separate contexts. If you want to determine which are the most useful contexts in identifying a situation, you can use “identifiedBy” with context-value objects, instead of just contexts. That way, when a situation is determined, and you are adding this info to the ontology, you can simply update the count of the recurring contexts. After a while, you will see that the most useful contexts are the ones with the highest count.
First, lets look at how a context(or classification) is defined. This is not particularly exciting…just an object of type classification which is derived from a specific sensor. This could be many sensors, but this example uses one only.
### http://ontonym.org/0.8/classifications.owl#PL_030000004BFDA026
:PL_030000004BFDA026 rdf:type :classification , owl:Thing ;
provenance:derivedFrom placelab21:BFDA026 .
The interesting part comes here, where we define a FeatureProbability, which is a classification-value pair, where the value is the probability of
that classification appearing when a situation is determined.
### http://ontonym.org/0.8/classifications.owl#watching_tv_030000004BFDA026
:watching_tv_030000004BFDA026 rdf:type :FeatureProbability ,
owl:Thing ;
:probability "99"^^xsd:int ;
:classification :PL_030000004BFDA026 .
A situation then is a set of classification-value pairs.
### http://ontonym.org/0.8/classifications.owl#watching_tv
:watching_tv rdf:type :activity , owl:Thing ;
:identifiedBy
: watching_tv_030000004BFDA026 ,
:watching_tv_150000004C1DAD26 ,
:watching_tv_1A00000053B37626 . . .and so on . . .
No Comments Yet