SOFIA - RDF Recipes for Context Aware Interoperability in Pervasive Systems. NXP

SOFIA - RDF Recipes for Context Aware Interoperability in Pervasive Systems. NXP

• 1.
  RDF Recipes forContext-Aware Interoperability In Pervasive Systems Anna M. Kosek∗ , Aly A. Syed∗ and Jon M. Kerridge† ∗ NXP Semiconductors, Corporate Innovation and Technology/Research High Tech. Campus 32, 5656 AE Eindhoven, The Netherlands {anna.kosek,aly.syed}@nxp.com † Edinburgh Napier University, School of Computing Merchiston Campus, Edinburgh EH10 5DT, United Kingdom [email protected] Abstract—Nowadays home automation systems in- updatable standards are needed. tegrate many devices from security system, heating, ventilation and air conditioning system, lighting system A. Ontologies in Interoperability or audio-video systems. Every time a new device is in- stalled, problems with connecting it to other devices and An ontology is a representation of a set of con- synchronization may appear. The technology trends are cepts, functions and relations between concepts [6]. to build more powerful and functional new autonomous Concepts are classes of entities existing in a do- devices, rather than improve device synchronization, main, functions and relations are respectively one- data and functional distribution and adaptation to to-one and one-to-many properties existing in the changing environment. This paper highlights interoper- ability problems in pervasive computing and presents a environment. An ontology, together with syntax and solution for devices with limited processing capabilities semantics provides a language that is necessary for by use of an ontology for knowledge formulation and proper communication. Building an ontology is a dif- semantic interoperability. ficult task and because domains and language always Index Terms—ontology, semantic interoperability, evolve it is impossible to state that the ontology knowledge representation. describes all possible concepts and relations in a specific domain. Because an ontology can always I. I NTRODUCTION evolve and adapt to an ever-changing domain, it can The number of electronic devices surrounding us be a very flexible and up-to-date description of the increases every day, many devices are already de- domain. Therefore an ontology can play the role of a ployed in the environment and are hidden from flexible standard and can be used to achieve semantic peoples’ sight. Ongoing device miniaturization makes interoperability. it possible to manufacture smaller devices, therefore It has been shown that interoperability can be more of them can be embedded in one space. A achieved by using an ontology in consumer elec- network of many small devices requires a flexible tronics devices [7]. Another project, Sofia (Smart approach to pervasive configuration and management. Objects for Interactive Applications) [8], is targeted A well known problem in pervasive environments to enable and maintain cross-industry interoperabil- is how to achieve interoperability between compo- ity for smart spaces using a core ontology based nents in the system. In distributed systems, there on Dolce [9] and domain ontologies. The approach are three classic interoperability levels: platform, pro- presented in this paper is an extension of both [7] and gramming language and service interoperability [1]. Sofia concepts to create a pervasive environment with Service interoperability divides further in to signa- interoperability at the semantic level and re-usable ture, protocol and semantic levels [1]. The signature knowledge representation based on an ontology. The interoperability problems are associated with the syn- specific environment that this project is considering tax of the interface of the service and are successfully is a network of very small, energy-frugal devices solved by popular language interface specifications with limited processing capability. Services that are like CORBA’s IDL (Interface Definition Language) offered by these devices are simple, therefore it is [2] or WSDL (Web Service Definition Language) possible to represent them using an uncomplicated [3]. Many network interoperability problems (at the knowledgebase drawn from an ontology. protocol level of interoperability) can be addressed by Internet protocols, however these do not solve B. Knowledge Representation and Ontology interoperability problems on a semantic level [4]. In artificial intelligence (AI) domains a key to When considering many multi-vendor devices and building powerful and large systems is capturing components, solutions for semantic interoperability knowledge in a computer-readable form. Represent- based only on standards do not scale [5]; flexible and ing knowledge is a complex and time-consuming
• 2.
  task. Therefore knowledgebaseconstruction remains devices [7]. A device can participate in many virtual one of the biggest costs when constructing an AI devices; virtual devices are created for a particular system [10]. Most complicated AI systems require task and can be destroyed if a different configuration building a knowledgebase from scratch. An ontology is requested. A virtual device can be created by a can offer a core structure for representing knowledge user request or some scheduled task. Devices can join and enables reuse of knowledgebases when designing or leave a virtual device at any time; this operation systems in similar domains. Neches [10] points out can influence the behavior of a virtual device. The that a knowledgebase should be constructed from way a virtual device is formed is described in the many levels of knowledge. These layers are increas- knowledgebase by use of a list of actions to perform. ingly specialized, therefore layers’ division begins Devices can use any protocol to form a virtual device, with very general concepts, based on the ontological the protocol specification is described in a device’s model and finishes with very specialized and less knowledgebase. Therefore depending on configura- reusable knowledge [10]. Therefore a branch of an tion, a device will have clear instructions how to react ontology that is used for constructing knowledgebases to a message from a particular protocol. should consist of general (core), domain-specific and device-specific concepts and relations. The knowl- II. K NOWLEDGEBASE S TRUCTURE edgebase in a device or component should consist A knowledgebase consists of layers of knowledge only of necessary concepts, depending on a compo- (Figure 1). Layers are divided into T-Box and A-Box. nent’s functions and domain as described in [7]. The T-Box consists of class taxonomy and property defi- knowledgebase can be extended if new functionalities nitions that we name in this paper ontology models, or services appear. The most specialized part of like Dolce [9] or any other upper ontology, A-Box knowledgebase are instances and data associated with contains instances corresponding to classes described a particular device or component. in T-Box. C. Context-Aware Pervasive System The solution for interoperability and knowledge representation in the pervasive system presented in this paper is based on building a knowledgebase based on an ontology. It is important to fix the ontology model, while the ontology content can be changed when new classes and relationships appear. The ontology can be modified by domain experts and can be kept in a repository accessible by both software and hardware manufacturers. Because of the use of a common language described by an ontology, the interoperability is achieved on a semantic level [7]. Components from Fig. 1. Layered structure of a knowledgebase. the system use concepts that are provided by the ontology, therefore understanding is achieved at a The top level of the knowledgebase is a meta high level of abstraction. This way it is possible model of the core ontology. The meta model of the to build a context-aware system, that can represent ontology has to be fixed, this project is following and share understanding of context. Context can be the Sofia approach by choosing Dolce as a core associated with environment conditions, presence of ontology. Dolce is an upper ontology that addresses particular devices or people, or periods and events very general domains [9]. The next layer in Figure 1 associated with a calendar. Context-aware systems is a domain ontology that is created for a specific benefit from well defined context, and as every device area. For example if the device is a sensor, its or component understands how the context influences domain ontology describes classes and properties that its own domain, the system can produce emergent are associated with sensor domains. This way the behavior. knowledge of the surrounding world is narrowed to In pervasive computing a smart space is understood the domain the device or component belongs to. The as a cloud of devices existing and cooperating in next layer, Application specific ontology model, is a this space. In an architecture described in [7] all model for instances that describes a device’s behavior, configurations between devices are established auto- capabilities and services that the device can provide. matically, data and functionalities are distributed and In the last layer of the knowledgebase, categorized as available for different devices to enable cooperation. an A-Box, contains instances describing a particular Devices can appear or disappear from a particular device according to rules provided by T-Box ontology space at any time, so devices have to be able to work models. Similar devices will have similar T-Box part autonomously or form subnetworks called virtual of the knowledgebase, but different instances in A-
• 3.
  Box. T-Box canbe automatically generated and used only turn on, turn off and dim to some level. It is when building A-Box for a particular device. impossible for lamp to play music or accept coins because these tasks are beyond a lamp’s physical A. Resource Description Framework capabilities. The knowledgebase structure can be fixed using 3) Context and users: The context describes the RDF (Resource Description Framework) [11] triples. actual situation of the whole system, or part of RDF is a framework for representing information in it. Every device can understand contexts that are the World Wide Web. RDF can describe a simple described in its own knowledgebase. Contexts might graph-based data model [11]. An RDF triple consists be night, lunch time, reading or watching tv and are of subject, predicate and object, where the subject and associated with environment conditions or actions predicate are resources defined by an URI (Uniform performed by users. Understanding context and acting Resource Identifier) while the object is a literal or upon it is one of the most important tasks of the a resource. The structure of the knowledgebase will proposed system. Context is a very broad concept consist of triples: and customization for different users is important. (Subject, P redicate, Object) For example watching tv for Anna means that their personal phone should be off, window blinds shut and For example: light dimmed. The same context can mean something (apple tree, is − a, tree) different to Tomas, he wants his phone in loud mode, lights turned off, blinds closed. Devices participating This triple uses predicate is-a to associate subject ap- in one context can be the same but settings are dif- ple tree with object tree. Ontologies are designed by ferent. Reasons for this are different preferences and domain experts and represent universal and domain- priorities for particular users. The system presented specific truths. in this paper, built on concepts from [7], does not For the purpose of the World Wide Web, ontologies have formal central control, so contexts are saved on are represented by use of a markup scheme like XML. devices that are required to perform some part of the Unfortunately XML adds complexity to database for- function required in a context. Therefore the context mat by introducing tags that need to be interpreted. watching tv for Anna in a lamp or in a TV specify XML is not designed for data storage or efficient totally different actions. retrieval of data [12] the additional time to process data exists due to parsing and text conversion [13]. 4) Configuration and state: The information about For devices with a limited processing capability it is the state and configuration of a device is very im- important to keep any database structure as simple as portant and should be accessible by the device. For possible. Therefore the knowledgebase format is kept example, to work as a group, devices need to be to the simple three field structure of RDF. formed in a virtual device [7]. The configuration RDF for World Wide Web can use many external holds information in which virtual devices the de- files of different ontologies, therefore it is not essen- vice participates and what is the current state of tial to define all concepts in one RDF file. In many the configuration. A device that is a part of a vir- cases referencing by use of URL to external ontology tual device should keep on functioning without any files is not necesarry. Devices from pervasive systems breaks, if a new request arrives a device has to be usually have a well defined functionality and often do able to determine if it should drop its current task not need to connect to the Internet. Therefore entries and respond to the request, by checking its current in a knowledgebase need only reference other entries configuration settings. The state of a device is also in it. included in the knowledgebase. For example a lamp The A-Box part of knowledgebase consists of can store information about its dim level or color in data necessary for the system to make decisions, the knowledgebase where it can be easily accessed. process requests, interpret messages, learn and react 5) Recipes: Recipes are used to describe a pro- to commands. A knowledgebase consists of six parts: cedure for the behavior of every device. Recipes are 1) Device description: Description of the device very detailed and specify the procedure that a device using the ontology. This part of the knowledgebase has to follow for a given context. The idea is to will consist of two parts: a core ontology necessary describe all important steps in a recipe, so the device to characterize the device universally, and a domain only has to read the recipe and act upon it. Recipes specific ontology describing entities and relations that are associated with context, people and request types. are restricted to one type of device (for example: Since devices forming a pervasive systems have lim- lighting, sensors, multimedia devices). ited resources, the number of requests, that a device 2) Device capabilities: The description of device can serve, is also limited. Therefore a device can capabilities that are provided by the device manufac- decide itself if it can execute recipe or not. The turer. For example, capabilities are simple tasks that concept of a recipe is a main subject of this paper a device can physically perform. A simple lamp can and is described in the next section.
• 4.
  B. Recipes an acknowledgment massage back and acts upon Recipes in a knowledgebase are sequential and rep- the instructions provided by this recipe. If a switch resent steps that a device should follow in a particular initiates a virtual device with a lamp, lamp has to virtual device. Every recipe has a header to describe have a recipe that describes, in detail, how to act the recipe’s type, context and other conditions that upon a particular request. A recipe consist of header, are guarding access to this recipe. The recipe shown that describes a recipe and steps that device has to in Figure 2 consists of n steps. Steps contain actions perform. The header consist of recipe type, service that need to be performed in this particular step. If and context that recipe is associated with. A recipe the device fails to finish a step, the recipe is dropped. can be associated with a person and customized for this person. Fig. 2. Recipe structure. Recipes are described using ontology terms, so the concept of a recipe has to be present in the ontology model. Classes and properties associated with a structure of a recipe are described in the T- box part of the knowledgebase in Application specific ontology model layers are shown in Figure 1. Fig. 4. Example of a recipe in knowledgebase, expressed in RDF triples. An example of a recipe for a lamp expressed in RDF format is shown in Figure 4. The recipe1 consists of a header and four steps. Steps in a recipe represents a sequence of actions that the device has to perform. If a device reach the end of a recipe, a task is finished. A device that interprets a knowledgebase needs to be extended with a Semantic Interpretation compo- nent (Figure 5) and use a communication link to receive and send messages necessary to establish Fig. 3. An ontological view of the concept of a recipe in T-box. virtual devices and cooperate with other devices. To influence a device’s functionality, the Semantic A simple example of an ontological model to rep- Interpretation component uses the Device Interface resent recipes combined with Dolce and Sofia models component. is presented in Figure 3. This model is representing recipes and steps as a subclass of Dolce processes. Property hasStart associates recipe with a first step from this recipe, and property hasNext creates a sequence of steps in a recipe. Let’s consider a lamp and a switch that can co- operate when grouped in one virtual device. The mechanism to group and configure these devices requires one device to start a configuration by sending a search message. When a device receives a search Fig. 5. Device’s architecture. message it checks if it desires to participate in a virtual device that the message propagates and if The addition of components specified in Figure 5 it has a recipe that it can use in this particular and a device specific knowledgebase enables seman- configuration. If so, the recipe is executed, informa- tic interoperability between devices in a smart space. tion about the configuration is saved; device sends Recipes are used to inform a device what exact steps
• 5.
  it should undertakein a particular context or when Use of JCSP enables simulating a network of many receiving data from different devices. Since devices devices running in parallel and communicating by may have many recipe , choice on which recipe to sending messages. run is made by the device using the content of the received message. If there are more than one recipes that are usable in a certain situation, the the message content is used to further refine a recipe choice. This is done by matching RDF triples of the recipe to fields of the message. This way we can make conditional choices on which recipe to run and there by achieve different device behavior. III. I MPLEMENTATION The smart lighting system chosen to illustrate a context-aware distributed system consists of a light switch, different kinds of light sources and sensors Fig. 7. Proposed scenario. (Figure 6). The switch has a User Interface (UI) and it can accept requests from the user. Light sources are The scenario chosen to describe the system is different types of lamps, with different light emission presented on Figure 7, which shows a model of a source types. There can be many sensors present room that is used as an office. The space is equipped in the space: light sensors, motion sensors, devices with a light switch with UI, ceiling lamps, lamp on recognizing users’ identity (for example RFID read- a desk, automatic blinds on the window, mirror used ers) and any other sensors that can be beneficial for to reflect daylight to illuminate the room, light and the system. As shown on Figure 6 the system has motion sensors. The user is the center of attention and no central control. The request comes from the UI can set preferences manually in the UI. The user can embedded in light switch, but this does not make the set lights manually or choose a context available in light switch a controller, it takes the role of a request a particular space. When the user indicates a need to center. All messages sent in the system are broadcast control light levels or the context changes, the switch messages, every device receives the message and performs a search for devices that provide service: decides if it should accept or discard it. lighting for this user. All the lamps, blinds and mirror responds to this request, because all of them are able to provide light for the space. The other task that the proposed set-up can perform is to keep the light at the same level in the whole room, when the outside light conditions change. This configuration uses communication between light and sensors to use as much natural light as it is possible, while attaining a stable level of light in the room. Fig. 6. The lighting system architecture. IV. R ESULTS AND C ONCLUSIONS A complex system consisting of sensors and ac- Any device that can increase or reduce light level tuators was designed and implemented. The system in the room may consider itself as a provider of a controlling a space consists of autonomous devices lighting service. Therefore lamps are not the only collaborating to achieve lighting conditions desired source of the illumination in a space but also window by the user. There are sixteen ceiling lamps, two blinds that can block light from outside or a mirror light sensors, light switch, mirror and user defined that reflects exterior light onto the ceiling are also contexts. The context plays a crucial role in the light sources. The idea is to integrate and engage all system, as it influences behavior of devices to suit of those elements of the system that can influence different users needs. illumination in a particular space. Applying this ap- The simulation is run on PC with Intel Core2 CPU proach can save energy by using natural light, rather [email protected], 1GB RAM and Windows XP OS. than using only light sources. Java code with JCSP libraries is run to simulate de- The simulation was implemented in JCSP (Com- vices working in parallel, knowledgebases are binary municating Sequential Processes for Java) [14]. This files containing RDF triples. language supports concurrent programming, it is use- There are two available contexts in the system: ful when simulating devices running simultaneously. reading and meeting, devices have different recipes Devices are presented as CSP processes and commu- for different contexts.A lamp in a simulation con- nication links are implemented using CSP channels. sists of Semantic Interoperability and Communication
• 6.
  components, device functionalityand knowledgebase R EFERENCES binary file. A lamp has 214 triples in its knowledge- [1] T. Strang and C. Linnhoff-Popien, “Service interoperability base and 5 recipes that are responsible for different on context level in ubiquitous computing environments,” actions. During configuration of a virtual device for L’Aquila, Italy, 2003. [2] R. Orfali, D. Harkey, and J. Edwards, The context reading, the knowledgebase in the lamp is essential distributed objects survival guide. John accessed 305 times and local memory, used to keep Wiley and Sons, Inc., 1995. [Online]. Available: temporary data, is accessed 806 times. http://portal.acm.org/citation.cfm?id=210712 [3] E. Christensen, F. Curbera, F. Curbera, G. Meredith, and The simulated scenario consisting on 20 devices S. Weerawarana. runs 148 Java threads. Average number of messages [4] N. Georgantas, “Semantics-based interoperability for perva- sive computing systems,” 2008. sent per configuration is 53 and messages received by [5] D. O’Sullivan and D. Lewis, “Semantically driven service a device is 954. All messages are broadcast, every interoperability for pervasive computing,” in Proceedings of device receives all messages, but most of them are the 3rd ACM international workshop on Data engineering for wireless and mobile access. San Diego, CA, USA: ACM, dropped and do not trigger any actions. 2003, pp. 17–24. The simulation presented in this paper runs in real [6] T. Gruber, “Ontolingua: A mechanism to support portable time in a users perception. The goal of this simulation ontologies,” Stanford University, Knowledge Systems Labo- ratory, Tech. Rep., 1992. is is to show functional behavior of a distributed [7] A. A. Syed, J. Lukkien, and R. Frunza, “An ad hoc system using RDF based recipes. The numbers men- networking architecture for pervasive systems based on tioned here should be treated as a reference. we do distributed knowledge,” in Proceedings of Date2010, Dresden, 2010. [Online]. Available: http://www.date- not attempt to to compare these numbers to another conference.com/proceedings/PAPERS/2010 implementation. [8] Sofia, “Smart objects for intelligent applications,” 2009. The simulation is a proof of concept that a per- [Online]. Available: http://www.sofia-project.eu [9] C. Masolo, S. Borgo, A. Gangemi, N. Guarino, and A. Oltra- vasive system can be constructed out of autonomous mari, “WonderWeb deliverable d18,” 2001. devices without any central control. Recipes are de- [10] R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator, scribed in previous sections and in [7] can made in and W. Swartout, “Enabling technology for knowledge shar- ing,” AI Magazine, vol. 12, no. 3, pp. 36–56, August 1991. RDF format and influence the device’s functionality [11] O. Lassila and R. R. Swick, “Resource description framework and behavior. The interoperability is achieved at a (rdf) model and syntax specification,” 1998. semantic level by the use of ontologies. Ontologies [12] L. Khan and Y. Rao, “A performance evaluation of storing XML data in relational database management are also used to construct a knowledgebase that can systems,” in Proceedings of the 3rd international workshop be reused or transferred and understood in different on Web information and data management. Atlanta, devices. Georgia, USA: ACM, 2001, pp. 31–38. [Online]. Available: http://portal.acm.org/citation.cfm?id=502939 [13] R. Bourret, “XML and databases,” 2005. [Online]. Available: http://www.rpbourret.com/xml/XMLAndDatabases.htm V. F URTHER WORK [14] P. Welch and N. Brown, “Communicating sequential pro- cesses for java (jcsp),” 2009. Recipes are built according to a model taken from common ontology, therefore devices can process any recipe following these rules. The next step in devel- oping the architecture is to include an extension that allows new recipes to be added to existing knowl- edgebase in devices from newly installed devices. Adding recipes enables updatability, both forward and backward. When a new device is added to a network, it can update existing devices with a recipe that will guide devices how to use a new device or component. The adaptation to a changing environment, set of devices in a network and user’s needs can be done by adding a new recipe to a knowledgebase. More sophisticated technique can update and adapt recipes themselves, learning to adjust devices behavior de- pending on situation and improving recipes that are in device’s memory. ACKNOWLEDGMENT The authors would like to acknowledge Perada, EU network of Excellence, for supporting knowledge exchange. This work is being carried out in the Sofia project [8].