Many forms of information can be labeled as context information. For example the current time of day, or outside temperature are examples of basic context informa- tion. User location and current activity are examples of more relevant and higher level context information. At an abstract level, context information can be any in- formation which is not available from within the system. This information describes attributes external to the network.
High levels of context information can be gained from lower levels. For example, if John is currently in ‘Meeting Room A’, and the room has 3 occupants, it can be inferred that John is currently in a meeting. Notice that it is inferred that John is in a meeting, and not simply that John is in a meeting. Ontology languages can be used to derive high level context information from low level information.
<owl:Class rdf:about="#OccupiedRoom"> <rdfs:subClassOf rdf:resource="#Room"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasOccupant"/> <owl:onClass rdf:resource="#Person"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger"> 3 </owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Figure 7.1: OWL representation of an OccupiedRoom Room is specified as a room with 3 or more occupants.
Suppose, through various means, an employee’s location can be derived by the office system. The real-time description of the office meeting room may be that shown in Figure 7.2. As the meeting room has 3 occupants, the reasoning system can infer that the room is occupied. John’s location shows that he is in the meeting room. In turn the meeting room is occupied, and so we can infer that John is in a meeting.
In this manner, some research projects have concentrated on describing con- text information through ontology languages. This allows them to derive high level contexts by inference. Wang et al.[98, 99] discuss scenarios where the availability of a user is derived from context information such as current activity and location. This derivative is specified through rules concerning ontology information. The Gaia project [16, 80] moves beyond simple rule-based inference, exploring the use of prob- ability, fuzzy logic and Bayesian networks in order to derive context information.
The use of context information within a home network allows a more personalised system [28]. Allowing the user to customise the behaviour of the system based on information, such as location or current activity, would only help in integrating home networks into daily life. For example, a HouseLight monitoring system could manage room lights, switching off those in rooms where no users are present. This service, in turn, could then be a component of an EnergySaver service. In a similar manner, service invocation could be time-driven. A MorningRoutine service could
<owl:Class rdf:about="#MeetingRoom"> ... <owl:Restriction> <owl:onProperty rdf:resource="#hasOccupant"/> <owl:someValuesFrom rdf:resource="#Paul"/> </owl:Restriction> ... <owl:Restriction> <owl:onProperty rdf:resource="#hasOccupant"/> <owl:someValuesFrom rdf:resource="#David"/> </owl:Restriction> ... <owl:Restriction> <owl:onProperty rdf:resource="#hasOccupant"/> <owl:someValuesFrom rdf:resource="#Simon"/> </owl:Restriction> ... <rdfs:subClassOf rdf:resource="#Room"/> </owl:Class>
Figure 7.2: OWL representation of the MeetingRoom
switch on the heating at 7am, and then switch on the coffee machine at 8am, while displaying the latest news headlines on a display which is in the same location as the user.
A context-aware home network is certainly an attractive prospect. A typical home network may contain a number of simple devices and services from which context information can be gained, such as IR sensors, chair occupancy sensors, on- line calenders and television recording schedules [9]. From such raw data sources, information about availability, current activity and location could be derived.
Projects exist where developers have integrated context-aware applications into a home care environment, for example the Amigo project [39] and Construct. Con- struct [23] is a middleware platform which supports context gathering in home care networks, and represents the data through RDF. This augments the support avail- able from the home care network, where service invocation can be heavily trigger based. (E.g. If the user is watching TV, and it is after 12pm, present the current time vocally every 10 minutes).
the information to be independent from how it is represented [59]. This prevents issues of standard lock-in where only specific applications can understand what the information means. Using ontology languages also allows the context information to be disseminated back into more basic data. For example, suppose John is cur- rently engaged in a BoardMeeting activity. In addition to first inferring that John is unavailable, an agent can then check the definition of BoardMeeting, perhaps dis- covering who comprises as the Board, and then inferring that these people are also unavailable.
The success of ontology-based context aware systems depends on the ontologies being tightly controlled and well defined. The use of ontologies is more suited to small, local domains, than that of an all-encompassing standard. The reason for this restriction is that definitions of high level context information, such as activity, availability and preference can be closely related to the particular domain in which they are being used. One view of a person’s unavailability may be different to that of another. Having an ontology particular to a small domain allows developers to ensure it is strongly suitable for that particular domain. Using a universal approach may require heavy customisation of the ontologies in order for them to be correct.