Chapter 8
Agent-Based Context-Aware Service in a Smart Space
Wan-rong Jih, Jane Yung-jen Hsu
Department of Computer Science and Information Engineering, National Taiwan University, 10617 Taipei, Taiwan
jih@agents.csie.ntu.edu.tw, yjhsu@csie.ntu.edu.tw
Abstract
Technologies of ubiquitous computing play a key role for providing contextual information and de- livering context-aware services to a smart space. Sensors deployed in smart space can reflect the changes of the environment and provide contextual information to context-aware systems. Moreover, it is desirable that services should react to the rapid change of contextual information and all the inner computing operations have to be hidden behind the users.
We propose a Context-aware Service Platform, implemented in JADE agent platform, and utilize Semantic Web technologies to analyze the ambient contexts and deliver services. We integrated ontology and rule-based reasoning to automatically infer high-level contexts and deduce a goal of context-aware services. An AI planner decomposes complex services and establishes the execution plan and agents perform the specified task to accomplish the services. A Smart Alarm Clock scenario demonstrates the detail functions of each agent and shows how these agents incorporate with each others.
8.1 Introduction
It’s obvious that mobile devices, such as smart phone, personal digital assistants (PDAs), and wireless sensors, are increasingly popular. Moreover, many tiny, battery-powered, and wireless-enabled de- vices have been deployed in smart spaces for collecting contextual information of the residents. The Aware Home [Abowd et al. (2000)], Place Lab [Intille (2002)], EasyMeeting [Chen et al. (2004b,c)], and smart vehicles [Look and Shrobe (2004)] provide intelligent and adaptive services environment for assisting the users to concentrate on their specific tasks. Apparently, services in a smart space should have the abilities to react and adapt the dynamic change of context.
Context-awareness is the essential characteristic of a smart space and using the technologies to achieve context-awareness is a type of intelligent computing. Within a richly equipped, networked environment, users need not carry any devices with them; instead, the applications have to adapt the
131
available resources for delivering services to vicinity of the users, as well as tracking the location of users. Cyberguide [Long et al. (1996); Abowd et al. (1997)] uses the users’ locations to provide an interactive map service. Active Badge [Want et al. (1992)] was originally developed at Olivetti Research Laboratory. In this system, every user wears a small infrared device, which generates a unique signal and can be used to identify the user. Xerox PARCTab [Want et al. (1995)] is a personal digital assistant that uses an infrared cellular network for communication. Bat Teleporting [Harter et al. (2002)] is an ultrasound indoor location system. PARCTab and Teleporting are similar to Active Badge; they are deployed to determine user identity and location by interpreting distinct signals from the sensors.
Context-aware systems involve not only multiple devices and services, but also software agents.
Agent-based architectures can dynamically adapt in rapidly change environment and hence can sup- port context-aware systems. The Context Toolkit [Salber et al. (1999a)] introduces context widgets that provide applications with access to contextual information while hiding the details of context sensing. Each widget is a software component, a simple agent that designates to handle the context acquisition. Chen et al. (2004a) proposes CoBrA architecture, contains a broker can maintain con- text knowledge and infer high-level context. E-Wallet [Gandon and Sadeh (2003)] is an agent-based environment for providing context-aware mobile services.
Researchers believe that successful smart spaces must draw computers into our natural world of human daily activities [Hanssens et al. (2002)]. However, many challenges have been encountered while building a context-aware system [Want and Pering (2005)]. In a smart space, augmented appli- ances, stationary computers, and mobile sensors can be used to capture raw contextual information (e.g. temperature, spatial data, network measurement, and environmental factor), and consequently a context-aware system need to understand the meaning of a context. Therefore, a model to represent contextual information is the first issue of developing context-aware systems. Context-aware services require the high-level description about the user’s states and the environment situations. However, high-level context cannot not be directly acquired from sensors. Capability to entail high-level con- texts from the existing knowledge is required in context-aware systems. Consequently, how to derive hight-level contexts is the second issue. As we know that people may move to anywhere at anytime, it is increasingly important that computers develop a sense of location and context in order to appro- priately respond to the user’s needs. How to deliver the right services to the right places at the right time will be the third issue.
In this research, we leverage multi-agent and semantic web technologies that providing the means to express context and using abstract representations to derive usable context for proactively deliver context-aware service to the users. We deal with the issues of building context-aware systems and explore the roles of intelligent sensing, mobile and ubiquitous computing in smart home services. In- teractions between the users and services are through a wide variety of devices. Meanwhile, context- aware services deliver multimedia messages or contents through the smart home devices for assisting users.
8.2 Background technology
8.2.1 Context models
A context model is needed to define and store contextual information, which includes temporal re- lations, geo-spatial entities and relations, user profiles, personal schedule, and actions taken by the people. Develop a model to represent the wide range of contexts is a challenging task. Strang and Linnhoff-popien (2004) summarized the most influential context modeling approaches according to the data structures for representing and sharing contextual information in context-aware systems.
The key-value model is the most simple context model, contextual information is represented
as data structures or class objects using programming languages [Schilit et al. (1994); Coen (1998);
Dey (2000)]. Such hard-coding representation is intuitive, but lacks expressiveness and extensibil- ity. Using a meta-language (e.g. Extensible Markup Language (XML1)) to represent contextual information [Capra et al. (2003)] can gain more extensive, but it only provides a syntax level of representation. And consequently the markup scheme models unable to provide adequate supports for semantic representation and interrelation, which is essential to knowledge abstraction and con- text reasoning [Chen et al. (2005)]. The logic-based context models [McCarthy (1993); Akman and Surav (1996)] are based on, modeling the contextual information as situations and formulating the changes of contextual information as actions that are applicable to certain situations. In other words, just like the situation calculus [McCarthy and Hayes (1969)], the changes of contextual information can be formulated as a series of situations with a result of various actions being performed. Though the logic-based models have the reasoning capabilities, it is hard to formulate complex logical ex- pressions while the situations are complicated.
Strang and Linnhoff-popien (2004) concluded that the ontologies are the most expressive mod- els. Gruber (1993) defines ontology as an “explicit specification of a conceptualization”. Ontology is developed to capture the conceptual understanding of the domain in a generic way and provide a semantic basis for grounding the fine-grained knowledge. The COBRA-ONT [Chen et al. (2003)]
provides the key requirements for modeling context in a smart meeting application. It defines con- cepts and relations of physical locations, time, people, software agents, mobile devices, and meeting events. The SOUPA [Chen et al. (2004d)] (Standard Ontology for Ubiquitous and Pervasive Ap- plications) is proposed for supporting pervasive computing applications. SOUPA uses some other standard domain ontologies, such as FOAF2(Friend of A Friend), OpenGIS3, the spatial relations in OpenCyc4, ISO 8601 date and time formats5, and DAML time ontology [Hobbs and Pan (2004)].
Strang et al. (2003) introduce CoOL, a context ontology language for enabling context interoperabil- ity and context-awareness during service discovery and execution. Rom´an et al. (2002) develop Gaia, a distributed middleware platform for smart space that uses ontologies to define the structures and properties of contextual information; furthermore, it can handle various context reasoning. Clearly, these ontologies provide not only a rich context representation, but also make use of the abilities of reasoning and sharing knowledge.
8.2.2 Context reasoning
The processes of context reasoning can infer new contexts from the existing contexts. In a smart space, if the systems unable to reason and share context, the intelligence of context-aware systems will be limited and the users will abandon the systems that unable to deliver the services or meet the requirements.
Design and implementation of context reasoning can vary depending on the types of contextual information that are involved. The early context-aware systems [Coen (1997); Wu et al. (2002);
Capra et al. (2003)] are tightly coded the logics of context reasoning into the behavior of the systems.
Implementation for understanding the contextual information is bound into the programs for guiding the context-aware behavior of the systems, therefore, the developed applications often have rigid implementations and are difficult to maintain [Salber et al. (1999b)].
Rule-based logical inference can help to develop flexible context-aware systems by separating high-level context reasoning from low-level system behaviors. However, context modeling languages
1http://www.w3.org/XML/
2http://xmlns.com/foaf/spec/
3http://www.opengeospatial.org/standards
4http://www.cyc.com/cycdoc/vocab/spatial-vocab.html
5http://www.w3.org/TR/NOTE-datetime
are used to represent contextual information and the rule languages are used to enable context reaso- ning. Accordingly, in most cases, these two types of languages have different syntax and semantic representations; it is a challenge that effectively integrates these distinctive languages to support context-aware systems. A mechanism to convert between contextual modeling and reasoning lan- guages is one of the solutions for this challenge. Gandon and Sadeh (2003, 2004) propose e-Wallet that implements ontologies as context repositories and uses a rule engine Jess [Friedman Hill (2003)]
to invoke the corresponding access control rules. The e-Wallet using RDF6triples to represent con- textual information and OWL7to define context ontology. Contextual information is loaded into the e-Wallet by using a set of XSLT8stylesheets to translate OWL input files into Jess assertions and rules.
Ontology models can represent contextual information and specify concepts, subconcepts, re- lations, and properties, and facts in a smart space. Moreover, ontologies reasoning can use these relations to infer the facts that are not explicitly stated in the knowledge base. Ranganathan et al.
(2004) propose that ontologies can make it easier to develop programs for reasoning about context.
Chen (2004) proposes that the OWL language can provide a uniformed solution for context repre- sentation and reasoning, knowledge sharing, and meta-language definitions. Anagnostopoulos et al.
(2007) adopt the Description Logic [Baader et al. (2003)] as the most useful language for expressing and reasoning contextual knowledge. The OWL DL was designed to support the existing Description Logic business segment and has desirable computational properties for reasoning systems. Typi- cal ontology-based context-aware application is EasyMeeting that uses OWL to define the SOUPA ontology and OWL DL to support context reasoning. Gu et al. (2004); Wang et al. (2004) pro- pose an OWL encoded context ontology CONON in Service Orientated Context Aware Middleware (SOCAM). CONON consists two layers of ontologies, an upper ontology that focuses on capturing general concepts and a domain specific ontology. EasyMeeting and SOCAM are use an OWL DL reasoning engine to check the consistency of contextual information and provide further reasoning over low-level context to derive high-level context.
8.3 Smart space infrastructure
Fig. 8.1 shows the infrastructure of a Context-aware Service Platform in a smart space. Context re- sources can be obtained from the computing softwares, such as personal calendar, weather forecasts, location tracking system, personal friend list, and shopping list, as well as raw sensor data. Context Collection Agents obtain raw contexts from softwares and hardware sensors, and raw data are con- verted into a semantic representation. A Context-aware Service Platform is continuously collecting these contexts and infers appropriate Service Applications, and then it automatically and proactively delivers the services to the users.
A Context-aware Service Platform contains the following components:
Message Transportation provides a well-defined protocol for maintaining a set of communicative acts. Moreover, a common message structure is defined to exchange messages over the Context- aware Service Platform. Common message structure contains sender, receiver, the type of the communicative act, message content, and description of content. In this platform, each compo- nent communicates with each other through message passing.
Life Cycle Management maintains a White Pages and states of services to control over access to and use of the services. A service can be in one of the following states: initiated, active, waiting,
6http://www.w3.org/TR/rdf-concepts/
7http://www.w3.org/TR/owl-features/
8http://www.w3.org/TR/xslt
Fig. 8.1 A Smart Space Infrastructure
suspended, and deleted state. Life Cycle Management reflects the state changes and controls the state transitions. Consequently, every component is controlled by life cycle management.
Rule-based Engine uses IF-THEN rule statements, which are simply patterns and the inference engine performs the process of matching the new or existing facts against rules. Similar to OWL DL reasoner, rule engines can also deduce high-level contexts from low-level contexts;
the major difference is, rule engines can handle massive and complex reasoning while the OWL DL reasoner can not. The derived high-level contexts are asserted into Context Knowledge Base which serves as a persistent storage for context information. Rules for which and when the appropriate service can be invoked are defined as the knowledge of service invocation rules for the Rule-based Engine.
Ontologies are loaded into the OWL DL reasoner to deduce high-level context from low-level context. OWL DL reasoner provides the inference services to ensure the ontology does not contain contradictory facts. The class hierarchy of an ontology can be used to answer queries by checking the subclass relations between classes. Moreover, computes the direct types of every ontology instance can support to find the specific class that an instance belongs to.
Yellow Pages Service provides the functions for service registration and discovery. New services register their services to Yellow Pages Service. Service Deliverer and other services can search the desired services and get the results.
AI Planner generates a service composition plan sequence which satisfies a given goal. Service Deliverer chooses a service to execution from the service candidate list which returns from Yellow Pages Service.
8.4 Context-aware service platform
The Foundation for Intelligent Physical Agents (FIPA9) develops computer software standards to promote the interoperation of heterogeneous agents and the services that they can represent. The Java Agent DEvelopment Framework (JADE10) is a FIPA-compliant software framework for multi- agent systems, implemented in Java and comprised serval agents. An Agent Management System (AMS) controls agents’ life cycle and plays the role of white pages service, Directory Facilitator (DF) provides yellow pages service to other agents, an Agent Communication Channel (ACC) is the agent which can provide the path for basic contact between agents, and an Agent Communication Language (ACL) has been specified for setting out the message formats, consists of encoding, semantics, and parameters.
Design of the Context-aware Service Platform shows in Fig. 8.2. The top block depicts a smart
Fig. 8.2 Functional Flow of Context-aware Service Platform
space environment. Context Resource can be collected by Context Collection Agents that receive sensors or software data and will be delivered to Context-aware Reasoning model. Context Collection Agents are device dependent agents; each agent will be associated with different types of devices for providing raw sensor data. Ontology Agent and Context Reasoner can infer high-level context to provide goals for Service Planning. Context information and service description are stored in Context Knowledge Base. After perform service composition, discovery, and delivery, a context-aware service will be delivered to the specified Service Applications.
9http://www.fipa.org/
10http://jade.tilab.com/
8.4.1 Context-awarereasoning
We deploy Jess11in our Context-aware Service Platform. Jess is a forward-chaining rule engine used Rete algorithm [Forgy (1982)] to process rules, which is a very efficient algorithm for solving the difficult many-to-many matching problem. We use an open-source OWL Description Logics (OWL DL) reasoner Pellet12that developed by Mindswap Lab at University of Maryland, to infer high-level contexts. Moreover, Jena13is a Java framework for building Semantic Web applications, is used for providing a programmatic environment for RDF, RDFS, and OWL.
8.4.1.1 Context aggregator
Initialization : A configuration file declares the type of context, which Context Aggregator will received, and subscribe the context to its corresponding Context Collection Agent (refer to Fig. 8.1).
Input message : There are two types of input contexts: (1) Raw context refers to data obtained directly from context sensors or software, such as bed sensor data and forecast data, can be delivered from a bed sensor and weather API respectively. Senders of the these low-level contexts are called Context Collection Agents and the data will be wrapped as RDF-triple in message content. (2) High-level context is the information inferred from raw context, such as “location of a furniture” and “activity who currently participate in”, can be inferred from ontology reasoner and rule-based reasoner respectively.
Process : Value of a context can be changed at anytime and anywhere. Consequently, Context Aggregator must collect contexts and maintain the consistency of current context. Either raw or high-level context has an unique type identity and value. The associated value will be replaced when new context is arrived.
Output message : While raw contexts received from Context Collection Agents, the new con- text is immediately stored in Context Repository and a set of current context is delivered to Ontology Agent.
8.4.1.2 Ontology agent
Initialization : An OWL context ontology describes structure and relation between contexts that will be loaded and parsed into RDF triples by Jena API. It also subscribes to Context Aggregator for the contexts that has been declared in the context ontology. In addition to ontology loading, it has to start an OWL DL reasoner for supporting ontology query.
Input message : Context Aggregator sends the current state of contexts when any subscribed context has been changed.
Process : There are two types of ontology reasoning that perform in Ontology Agent, so they can provide high-level context. The first is inferred by Jena API that deduces high-level context from the object property of context, such as “bed sensor is attached to a bed” and “bed is placed in a bedroom”. Relationships between the instances of context object are defined in context ontology. An OWL DL reasoner, i.e. Pellet, deduces the inferred superclasses of a class and decides whether or not one class is subsumed by another, for example, “living room is an indoor location”.
11http://herzberg.ca.sandia.gov/
12http://pellet.owldl.com/
13http://jena.sourceforge.net/
Output message : If there is no high-level context to be derived, the input message of current contexts will be redirected to Context Reasoner. Otherwise, the new high-level contexts must be delivered to Context Aggregator.
8.4.1.3 Context reasoner
Initialization : The Jess API provides packages to load a rule-based engine when Context Rea- soner is started up.
Input message : A set of current context, which is the same as input message of Ontology Agent.
Process : The input context must be wrapped as Jess rule format and assert into the rule-based engine, and may trigger the execution of rules that can infer new contexts or derive a goal of service.
Output message : New high-level contexts are sent to Context Aggregator, whereas the service goal is delivered to Service Composition Agent.
8.4.2 Service planning
The modern trend of software is to build a platform-independent architecture that distributes soft- ware components on the Internet. New services and functionalities can be automatically achieved by selecting and combining a set of available software components.
A service functionality contains a semantic annotation of what it does and a functional annotation of how it behaves. (OWL-S14)(formerly DAML-S15, DARPA Agent Markup Language for Web Service) is an ontology for services, and it provides three essential types of knowledge about a service:
service profile, process model, and service grounding. An OWL-S service profile illustrates the preconditions required by the service and the expected effects that result from the execution of the service. A process model describes how services interact and how the functionalities offer that can be exploited to solve the goals. The role of service grounding is to provide concrete details of message formats and protocols.
According to these semantic annotations, AI planning has been investigated for composing ser- vices. Graphplan [Blum and Furst (1997)] is a general purpose graph-based planner. The state transition is defined by operators consists of preconditions and effects. Given initial states, goals, and operations, a planning system returns a service execution plan, which is a sequence of actions that starts from the initial states and accomplishes the given goals.
8.4.2.1 Service composition agent
Initialization : An OWL-S service ontology represents all available services and the service profile describes service goal, preconditions, and effects for AI planner, i.e. Graphplan. Conse- quently, the service ontology must be parsed and transferred into Graphplan operations.
Input message : A service goal is sent by Context Reasoner.
Process : According to the service operations, Graphplan creates a sequence of operation to achieve the goal.
Output message : When a operation represents a composite service, the corresponding service model will be delivered to Service Discovery Agent. If the execution plan has been generated, it
14http://www.w3.org/Submission/OWL-S/
15http://www.daml.org/services/daml-s/0.7/
delivers a sequence of service to Service Execution Agent.
8.4.2.2 Service discovery agent
Initialization : According to the description of the service model in service ontology, informa- tion of every atomic service will be kept in this agent.
Input message : A composite service model receives from Service Composition Agent.
Process : Given the composite service, Service Discovery Agent searches the atomic processes that are available and can carry out the composite service.
Output message : The atomic services, which can accomplish the given composite service, must be delivered to Service Composition Agent.
8.4.2.3 Service execution agent
Initialization : Service ontology consists of the description of service grounding, which speci- fies the details of how an agent can access a service.
Input message : A service list is sent by Service Composition Agent.
Process : Following the control sequence of services, the corresponding device agents will be invoked for providing atomic service.
Output message : The input parameters, invoking atomic service, must be passed to the device agent.
8.4.3 Context knowledge base 8.4.3.1 Context repository
Context Repository contains a consistency of context, includeing location, time, person, and activity information. A RDF-triple represents contexts of the repository, like a subject, a predicate, and an object. Subject is a resource named by a URI with an optional anchor identity. The predicate is a property of the resource, and the object is the value of the property for the resource. The following triple represents “Peter is sleeping”.
<http://...#Peter>
<http://...#participatesIn>
<http://...#sleeping>
WherePeter represents subject, participatesIn is a predicate, and object sleeping is an activ- ity. According to the elements of RDF-triple, we use subject and predicate as the compound key of Context Repository.
8.4.3.2 Ontologies
An ontology is a data model that represents a domain and is used to reason about the objects in that domain and their relations. We define a context ontology depicts in Fig. 8.3 as a representation of common concepts about the smart space environment. Context information are collected from real- world classes (Person, Location, Sensor, Time, HomeEntity), and a conceptual class Activity. The class hierarchy represents anis-a relation; an arrow points from a subclass to another superclass.
A class can have subclasses that represent the concepts more specific than their superclass. For example, we can divide the classes of all locations into indoor and outdoor locations, that is, Indoor
Fig. 8.3 A Context Ontology
Location and Outdoor Location are two disjoint classes and both of them belong to Location class.
In addition, the subclass relation is transitive, therefore, the Livingroom is a subclass of Location class because Livingroom is a subclass of Indoor and Indoor is a subclass of Location.
The relationship between classes is illustrated in Fig. 8.4. The solid arrows describe relation between subject resources and object resources. For example, isLocatedIn describes the relation between the instances of Person and Location while the instances of Person is the subject resources and instances of Location is the object resources.
A service ontology defined by OWL-S is for describing available services that comprises service profile, service model, and service grounding, which has been stated in Section 8.4.2
8.4.3.3 Rules
Rules of a rule-based system serve as IF-THEN statements. Context rules can be triggered to infer high-level context. According to the description of Fig. 8.4, a rule for detecting the location of a user is showed as follows:
[Person_Location:
(?person isIdentifiedBy ?tag) (?tag isMoveTo ?room)
->
(?person isLocatedIn ?room ) ]
Fig. 8.4 Context Relationship
Patterns before -> are the conditions, matched by a specific rule, called left hand side (LHS) of the rule. On the other hand, patterns after the-> are the statements that may be fired, called right hand side (RHS) of the rule. If all the LHS conditions are matched, then the actions of RHS will be executed. The RHS statement can be either asserted new high-level contexts or delivered a service goal.
Given?person is an instance of class Person, ?tag is an instance of MovableSensor, and ?room is an instance of Room, rulePerson Location declares that if any person ?person is identified by a movable sensor?tag and this movable sensor is move to a room ?room, we can deduce that ?person is located in?room.
8.5 Demonstration scenario
We use a simple examples to illustrate detailed picture of Context-aware Service Platform.
In a smart space, a Smart Alarm Clock can check Peter’s schedule and set the alarm one hour prior to the daily first task. If Peter does not wake up within 5-minute period after the alarm is sent, send another sound of alarm and increases its volume. If Peter wake up early then the alarm time, there will be no more alarm.
On the other hand, when the first task event is approaching and the sensors detect that Peter remains sleeping, an exceptional control should deal with such situation.
In addition to set the alarm through traditional alarm clock, the alarm service can deliver to the devices that in Peter’s bedroom, such as radio, stereo, speaker, or personal mobile device.
8.5.1 Context-aware reasoning
In order to archive Smart Alarm Clock, we have to collect Peter’s schedule to decide the alarm time and should reasoning whether Peter is awake or not. Google Calendar Data API supports on-line schedule information and position-aware sensors, bed pressure sensors, etc., can detect whether user on the bed or not. RFID technologies [Lin and Hsu (2006)] can be used to recognize and identify the activities of Peter while a wireless-based indoor location tracking system can determine Peter’s location with room-level precision [You et al. (2006)].
In order to know whether Peter is sleeping or not, all the related instances form an ontology in- stance network, shows in Fig. 8.5. Dashed line indicates the connection of a class and its instance.
Fig. 8.5 Instance Network for Detecting Sleeping Activity
Word in the box depicts a instance of its corresponding class, for example, bed is an instance of Furniture class. Each solid arrow reflects the direction of owl:ObjectProperty relationship, from domain to range and a inverse property can be declared while specifies the domain and range classes.
For example, a sensor bed sensor is attached to (isAttachedTo) furniture bed, and the inverse prop- erty ishasSensor. A boolean data type property isOn is associated with Sensor class for detecting whether the instances of class is on or off.
If someone is on the bed and the sensor bed sensor is on, then the value of isOn istrue. On the other hand, when nobody touches the bed, the value of isOn has to befalse and it infers that Peter is awake. Therefore, the system is not necessary to deliver the alarm service.
Suppose that calendar agent reports the first event of the day will be held at 8:00am, therefore, the alarm is set to 7:00am. When the time is up, given the location of Peter and the status of bed sensor, the ruleUser is sleeping in Section 8.4.3.3 can deduce that whether Peter is sleeping or not. Assume that there is another rule reflects that “if Peter is sleeping, then deliver smart alarm service”. Consequently, the service goal of Smart Alarm Clock can be derived and deliver to Service Composition Agent.
If Peter does not wake up for the task, according to the owner and importance of this task, an
exceptional handling rules will be triggered for deciding whether to postpone or cancel this coming task. For instance, Peter has to host a meeting at 8:00am and hence the task is a high priority event.
Consequently, a rule will be triggered to postpone the meeting, and an emergency message will be sent to the corresponding participants for informing the situation. On the contrary, if this task is “watch TV show at 8:00am” with low priority, then the context-aware reasoning infers that this scheduled task should be canceled and a video recording event will be invoked.
8.5.2 Service planning
Operations for planner can be derived from service profile, which gives a brief description about the service and consists of service name, preconditions, effects, inputs, and outputs of the service. The following OWL-S statements indicates the profile of Smart Alarm Clock.
<profile:Profile rdf:ID="alarm">
<profile:serviceName
rdf:datatype="http://www.w3.org/...#string">
smart alarm
</profile:serviceName>
<profile:hasPrecondition
rdf:resource="#alarm_precond"/>
<profile:hasInput>
<process:Input rdf:ID="message_stream">
<process:parameterType rdf:datatype=
"http://www.w3.org/...#anyURI">
http://...#MessageStream
</process:parameterType>
</process:Input>
</profile:hasInput>
....
</profile:Profile>
This example shows a service namedsmart alarm has precondition alarm precond and its input parameter belongs toMessageStream class.
Service model gives detailed description of the service and each service is modeled as process.
There are three types of process: atomic process is the primary process without any subprocess, sim- ple process are used as elements of abstraction, it can either represents as atomic process or composite process, and composite process consists of subprocesses. A composite process can be decomposed by using control operators such assequence, split, split+join, choice, any order, if-then, iterate, repeat-until, and repeat-while. Figure 8.6 is the control flow for Smart Alarm Clock, it uses operatorchoice to compose the process. TextMessageProcess, VideoPlayerProcess, andAudioPlayerProcess are atomic process, and Smart Alarm Clock can be served by using one of the three atomic processes. An example ofAudioPlayerProcess shows as follows.
<process:AtomicProcess rdf:ID="AudioPlayerProcess">
<process:hasInput>
<process:Input rdf:ID="audio_stream">
<process:parameterType
rdf:datatype="http://...#anyURI">
http://...#AudioStream
</process:parameterType>
</process:Input>
Fig. 8.6 Process Graph of Smart Alarm Clock
</process:hasInput>
<process:hasPrecondition>
<expr:KIF-Condition rdf:ID="alarm_precond">
<expr:VariableBinding
rdf:ID="isSleepVariablebinding">
<expr:theObject
rdf:resource="http://...#sleeping"/>
<expr:theVariable rdf:datatype=
"http://...#boolean"> true
</expr:theVariable>
</expr:VariableBinding>
<expr:expressionData
rdf:datatype="http://...#string">
precondition of smart alarm
</expr:expressionData>
</expr:KIF-Condition>
</process:hasPrecondition>
<process:hasResult>
<process:Result rdf:ID="alarm_done"/>
</process:hasResult>
...
</process:AtomicProcess>
Descriptions of atomic process are similar with that of profile, except the service model describes process in more details. For example the input data type ofAudioPlayer Process is belong to AudioStream class, whereas the alarm service profile only gives an upper-level data type Message Stream. Moreover, atomic process describes detailed expression of preconditions, for instance, it binds an instancesleeping of Activity class to a boolean variable.
Service grounding specifies the details of the way to access the service, and deals with the con- crete level of specification. Both OWL-S and WSDL are XML-based languages, therefore, the OWL- S service is easy to bind with WSDL service, for example:
<grounding:WsdlGrounding
rdf:ID="AudioPlayerWSDLgrounding">
<service:supportedBy
rdf:resource="#AudioPlayer"/>
<grounding:hasAtomicProcessGrounding>
<grounding:WsdlAtomicProcessGrounding rdf:ID="WsdlAtomicProcessGrounding">
<grounding:owlsProcess
rdf:resource="#AudioPlayerProcess"/>
<grounding:wsdlOperation>
<grounding:operation
rdf:datatype="http://...#anyURI">
play
</grounding:operation>
<grounding:portType
rdf:datatype="http://...#anyURI">
audio player port type
</grounding:portType>
</grounding:wsdlOperation>
</grounding:WsdlAtomicProcessGrounding>
</grounding:hasAtomicProcessGrounding>
...
</grounding:WsdlGrounding>
A WSDL service has construction of type, message, operation, port type, binding, and service. The AudioPlayerWSDL grounding briefly shows that OWL-S has provided operation and portType mapping. Besides, the XSLT can help the transformation from WSDL descriptions to OWL-S parameters.
8.6 Related work
Smart spaces can be the houses, workplaces, cities, vehicles, and the spaces deploy embedded sen- sors, augmented appliances, stationary computers, and mobile devices to gather contexts of the user.
Each place has different challenges, but similar technologies and design strategies can be applied. In order to make the space have capabilities to respond to the complexities of life, researchers explore new technologies, materials, and strategies to make the idea possible.
Department of Architecture research group at Massachusetts Institute of Technology proposes the House n16research, which includes a “living laboratory” residential home research facility called the PlaceLab [Intille (2002)]. Hundreds of sensing components are installed in nearly every part of the house. Interior conditions of the house can be captured by using these sensors, such as temperature, light, humidity, pressure, electrical current, water flow, and gas flow sensors. Eighty wired switches can detect the opening of the refrigerator, the shutting of the linen closet, or the lighting of a stovetop burner events. Cameras and microphones are embedded in the house for recording the resident’s movement. Twenty computers collects all the data streams from these devices and sensors to provide multi-disciplinary research, for example, monitoring the resident’s behavior, activity recognition, and dietary status. The Aware Home17[Abowd et al. (2000)] was proposed by the Future Computing Environments Group at Georgia Institute of Technology. In this house, multi-discipline sensors have
16http://architecture.mit.edu/house_n/
17http://www.awarehome.gatech.edu/
been constructed for monitoring the activities of the resident.
These smart space projects didn’t organize the huge sensing data in a formal structured format.
An independently developed application can’t easily interpret contexts that have no explicitly rep- resented structure. We use the Semantic Web standards Resource Description Framework (RDF) and Web Ontology Language (OWL) to define context ontologies which provide a context model for supporting information exchange and interpret contexts. By using the Semantic Web technologies to represent context knowledge, we introduced an infrastructure for inferring higher-level contexts and provide adaptive service to the user.
8.7 Conclusion
This research presents a context-aware service platform, a prototype system designs to provide context-aware services in a smart space. It integrates several modern technologies, include context- aware technologies, semantic web, AI planning, and web service. In addition, reasoning approaches for deriving new contexts and services are adopted in this system.
Ontologies for contexts and services provide information sharing and make the platform integrat- ing services. Contexts are represented as RDF-triple for exchanging information between agents and deducing new high-level contexts. Moreover, the service planner obtains a goal from context-aware reasoner, such that it makes the services operated adaptively.
The current design assumed that all the context resources provide consistent contexts and no conflict information to disturb the process of Context-aware Service Platform. We should consider the fault tolerance problems but allow some minor errors happened.
As the real-world environment has huge number of contexts and the required tasks are much more complex, the rule engine and task planner should have capabilities to provide solutions in reasonable time. Consequently, the concept of clock timer can be adopted to the reasoning and planning components. In order to provide a possible solution from the partial results, an anytime algorithm should be taken into account.
We provide a simple scenario to demonstrate the idea of the context-aware service platform.
However, this simple case does not show the power of automated service composition by using AI planning. Designing other scenarios that can explain and evaluate the needs of service composition is one of our future direction. Applying this platform to other Web Service composition benchmark test is another way to evaluate the performance of this platform.
