DoNet Architecture
To define a home system, a human readable and also computable language is essential. The DoNet ontology makes use of SOUPA [4] and SOUPA extensions together with time-entry (sub-ontology of OWL-Time [5]) and OWL-S [6]. It gives means to enable multiple representations for things within a home system.
A building, a room, an area within a room, areas in between rooms, corridors etc., are all represented as DoNet SpatialThings. Items which have a function, or simply some sort of contextual relevant representation can also be defined. It is assumed that anything which has spatial properties can also hold a function and/or state, wherever it is located. DoNet provides means to define Services, Functions and their Relations with service managing entities. There are a number of important direct and indirect relationships between entities in DoNet. Amongst these we find both item and service management, as well as function and state holding relationships. The ontology also provides means to define user and their preferences. Influenced by the work done by Alferes, J.J. and W. May [1], we also define OWL event-condition-action rules (ECA). Such a rule can have an event, lack of event or time based triggers. The ontology also defines the concept of composite and language independent conditions, together with service invocation definitions as actions. These combined features provide an expressive rule definition language.
DoNet Architecture
Whilst still withholding to the concept of a context server [3], it relaxes the concept by defining all autonomous agents to have context interpretation and reasoning capabilities. The predefined agent types are a central event/context management agent, a physical and virtual function agents and a web application handling agent. Making the user interface accessible from any web accessible location is of obvious advantage for a home system since one can remotely oversee and control the environment. The user has access to a number of pages including a raw ontology editor, entity pages, a suggestion page and information page. DoNet also provides a rule editor based on Accord’s [9] puzzle editor interface. The interface consists of a puzzle piece choice area, an actual rules area and a proposed rule area. While a user is building the puzzle through this application the system builds intermediate rule representations, which are then persisted appropriately, on command, as OWL representations. Each puzzle piece has a set of editable properties which frequently contain function invocation parameters. Rules can be defined both at item or abstracted location level.
All DoNet agents are capable of interpreting ECA rules. These rules define the reactive behaviour of the agent. When an event matches a trigger, the agent reacts and performs the necessary actions. Using the OWL class hierarchy relationships and a general OWL Reasoner the system can reason on a number of relationships between locations and other entities (Figure 2).
Location Function and State flow
The three primary relationships which are used in DoNet to define a domotic space, include spatial subsumption, function propagation and state propagation. Rule based reasoners are used for energy saving and proximity while a case based approach is taken for device and rule detection. A sample consumption related rule is shown below:
(?item1 ditems:consumesLess ?item2) (?item1 ditems:consumptionDegree?v), (?item2 ditems:consumptionDegree?w), lessThan(?v,?w).The ability to quickly develop functionality within this framework is essential. For example to add media playing functionality the first step is to develop an agent which is capable of starting and stopping a media player and playing any file or play list. The software component must extend the DoNetAgent class. Alternatively one could re-use an existing agent and add the needed behaviour. The next step is to add structures in the space in OWL abbreviated xml format which define the agent, playing functions and services. After definition the function puzzle pieces are available for use in the editor and one can define rules based on the new functionality.
This work takes home control systems to a new level, through a loosely coupled distributed architecture with intelligent capabilities. It provides the resident users with important information to help them reduce their energy consumption, secure their space and monitor and control devices as they see fit. It provides developers with means to plug-in modules and to re-use reasoning and communication mechanisms which are not otherwise available. DoNet steps away from the commonly used script based approaches to a well defined semantic core, opening the door to a multitude of extension possibilities and powerful home applications.
Berlo, A.v., Design Guidelines on Smart Homes, in A COST 219bis Guidebook, P.R.W. Roe, Editor. 2001.
Mekibes, B. How to assess IT in housing? in Conference on IT and Architecture. 2001. Aarhus, Denmark
Rodden, T., et al. Between the dazzle of a new building and its eventual corpse: Assembling the ubiquitous home. in DIS '04: Proceedings of the 2004 conference on Designing interactive systems. 2004. Cambridge, MA. USA: ACM Press.