coiva: context-aware and ontology-powered information visualization architecture

SOFTWARE – PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2011; 41:403–426Published online 22 September 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.1011

COIVA: context-aware and ontology-powered informationvisualization architecture

Ramon Hervas∗,† and Jose Bravo

Castilla-La Mancha University, Paseo de la Universidad, 13071 Ciudad Real, Spain

SUMMARY

This paper exploits semantics to apply context in run-time adaptation, particularly for services in a user-centered smart environment. Context-sensitive services are usually focused on their own informationwithout interoperation pretensions. It is necessary to enable common context models and systems inorder to make context-aware applications interoperable. Moreover, context management systems need toimplement mechanisms to support the dynamic behavior of the users and their surroundings, includingtechniques to adapt the model to their future needs, to maintain the context information at run-time andto be interoperable with external context models. By adapting web semantic technologies we can enablesmarter and more proactive operation of context management systems. Copyright q 2010 John Wiley &Sons, Ltd.

Received 28 December 2009; Revised 28 July 2010; Accepted 28 July 2010

KEY WORDS: context-awareness; ubiquitous computing; semantic web; knowledge management;ontology

1. INTRODUCTION

Adaptive behavior is a desirable characteristic to be incorporated in computer systems, and it hasbeen studied for many years. Computer systems require models that describe the real world, andthey abstract from the complexity of the real word in order to understand it, at least in part, thusacting more like humans. More recently, context-aware applications offer opportunities for smarterservices on intelligent environments. Only by understanding the world around us applications canbe developed that will be capable of making daily activities easier. In general, we have a similarcommon conception of what the context means. However, it is a broad and ambiguous concept thathas been defined on several occasions. According to the Oxford English Dictionary [1], context isdefined as ‘the circumstances that form the setting for an event, statement, or idea, and in termsof which it can be fully understood’. Based on this idea, this paper is focused on context-awareapplications, i.e. services that use context to adapt their behavior to the users’ situation and theirsurroundings.

Owing to the broad, complex, and ambiguous nature of context, we need models to representthe reality, or more precisely, to characterize the context as a source of information. These modelsdefine the contextual factors that are relevant to the user, his or her environment and situation. It isalso necessary to share this real-world perception between different applications and systems [2].There are multiple approaches for context modeling, for example, the Context Toolkit [3], a set of

∗Correspondence to: Ramon Hervas, Castilla-La Mancha University, Paseo de la Universidad, 13071 Ciudad Real,Spain.

†E-mail: [email protected]

Copyright q 2010 John Wiley & Sons, Ltd.

404 R. HERVAS AND J. BRAVO

widgets and a distributed infrastructure that hosts software components providing applications withaccess to context information while hiding the details of context sensing; the DOG Project [4],a framework that binds applications to users, uses multiple devices simultaneously, and exploitsresource management within the users’ environment that reacts to context and mobility; andthe SoaM Architecture [5], a Web-based environment reactivity model that uses orchestrationmechanisms to coordinate existing smart objects in pervasive scenarios in order to achieve automaticadaptation to user preferences. Furthermore, most context models claim an informal (usually notsuitable for processing) definition of internal and specific elements. These models do not generallyinclude mechanisms for adapting the model to other domains or applications.

In this way, formal knowledge representation techniques can enhance the capabilities of modelcomputational processing, its adaptability, and even achieve massive use. In a simple view, wecan represent contextual concepts using basic modeling languages such as the entity-relationshipmodel. Otherwise, frame-based languages allow us to define concepts and their relationships.The more expressive alternative is to use the logic-based models (e.g. First-order Logic) thatallow us to specify the concepts, relationships, and restrictions. The challenge is the balancebetween expressiveness and computability. Recently, Semantic Web languages have been usedfor this purpose, for example the CONON model [6], focused on representing, manipulating, andaccessing context information, the COBRA Architecture [7], an agent-based infrastructure thatincludes a context broker in order to maintain a shared context model and the Hatala proposals [8],which include a rules-based system to define the behavior of an augmented audio reality system.However, the definition of a context model using formal knowledge representation techniques isnot enough; it is also necessary to enable mechanisms for adapting the model to the specificrequisites in each application domain in order to maintain the context information at run-time andto support interoperability between heterogeneous services. The proposed model and frameworkseek to achieve these objectives.

2. FORMAL KNOWLEDGE REPRESENTATION THROUGH THESEMANTIC WEB INFRASTRUCTURE

The use of ontologies for context-awareness offers several benefits and additional functionalities.However, the usual application of ontologies is for human knowledge sharing, without a formalcomputational representation and management. The ontology formalization is the first step toexploit the benefits of this kind of formal conceptualization.

The Semantic Web provides a common framework that enables people and machines to shareinformation, describing the semantics of concepts and services on the web. The problem withusing the Web data on a large scale is that the data are too large, inexact and include too manyduplicated terms with uncertain values and contradictions. Besides the overloading and vaguenessof data, they are stored in diverse formats and from heterogeneous sources. The Semantic Webhelps to approach these problems (on the web as well as in context-awareness), reducing thehuman cognitive effort required to access the data and facilitating the semantic description toenable machine analysis and interpretation.

The architecture of the Semantic Web is built upon a set of languages and technologies. Thesyntax is provided by XML. The mechanism to represent information about resources is knownas Resource Description Framework (RDF) and the taxonomical organization is enabled usingthe RDF Schema. Web Ontology Language (OWL) extends RDFS by including more expressiveconstructors to describe the semantics of the elements. Finally, SPARQL is a query language toretrieve information from web data sources.

The adaptation of Semantic Web principles to Pervasive Environments offers important benefits,mainly in context modeling. The representation of context, in particular by means of ontologies,will become a substantial part of the design and maintenance of context-aware systems. Thecontext definition expressed in Semantic Web Languages (i.e. RDFS, OWL) can provide a richand unambiguous definition of relevant concepts in the environment domain.

Copyright q 2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:403–426DOI: 10.1002/spe

COIVA 405

In general, there are many benefits associated with the rich expressiveness of modeling languages,such as OWL and RDF and their semantic axioms and standardization. Despite the well-knownbenefits of these languages [9], their design was not initially focused on intelligent environmentmodeling. For this reason, there are some difficulties in modeling contextual information:

• Distinguishing between different sources of information: Because contextual information isthe key aspect, it is certainly important to distinguish among the information provided bysensors, by humans, or by applications. The source may enhance the adaptive capabilities ofa context-aware system, changing its behavior not only according to contextual entities butalso according to the origin of these entities.

• Allowing for inconsistencies: Context information is often incomplete or even contradictory.The model should have mechanisms to flexibly deal with context ambiguity. More precisely,context models should support and manage elements with inconsistent states such as severalvalid values at once, temporal unknown values, accuracy measures, and temporal contradictorystates. These states typically bring on errors in the context management; however, they arecommon situations in context-aware systems, and they should be taken into account in thedesign process.

• Time issues: Existing models usually do not take the temporal aspects of information intoaccount. However, intelligent environments should include information about past and futurestates. For example, we consider a context-aware security application to illustrate the timeissue. This application activates a warning when someone leaves a door open. A sensor detectswhether the door is open; however, the alarm should not be activated whenever this occursbut only when the door is kept open for a significant duration. In this case, timing may bemore important than the context entity itself. In other words, we need to know the state ofthe door as well as the period in which it maintains this state.

• Quality of information: The system should have the ability to make decisions about how touse the context, including the confidence level of the stored information. In other words,the definition and management of quality levels enhance the behavior definition based onthe existence of contextual elements and, also, based on their confidence level. Qualitymanagement enhances the semantics of the context information.

• Information ownership: It is important to store the ownership of certain kinds of information,mainly to guarantee privacy. The owner of a context element can be a user, a system, aservice or, in a general view, any valid entity of the model related with the particular contextelement. For example, the entity that generates, supervises, or is in charge of the element.The information ownership also increases the semantics of context information.

3. CONTEXT-AWARENESS FRAMEWORK COIVA

3.1. General architecture

This architecture, called COIVA, provides the infrastructure to launch context-powered servicesthrough environmental devices, whether personal or public. They share a base of knowledge ofthe context elements and the necessary semantics to identify the needs and habits of users, and tooffer adaptive services anywhere and at any time.

The architecture COIVA (Figure 1) essentially consists of two blocks, the COIVA core and thefunctional engines:

• The COIVA core: It is the main element of the architecture. It holds, in the first place, thecontext model, which is organized into two submodules: the general model and the specificservices model. The general model is divided into four main context elements: users, services,environments, and devices, each described by an ontology. The proposed model has beendesigned by identifying the key elements of typical user-centered intelligent environments.Despite providing a considerable level of detail, it may not be complete enough for use in aparticular environment. This is why specific attention has been paid to avoid the inclusion of



Figure 1. COIVA architecture: functional elements and communications.

elements that are inconsistent in certain application domains (i.e. relationships, constraints,or axioms that are not valid for certain applications). For example, we have found difficultiesin adopting FOAF ontology‡ because of the inclusion of excessively restrictive assumptions.In particular, FOAF defines the property of interest as a document on a topic of interest toa person but not to a group or to an organization. Context models must be applicable to themajority of cases by avoiding restrictive conceptualizations. At this point, COIVA enablesmechanisms needed to extend the model and satisfy new requirements and thus integrates themodel with other ontological models. The second module corresponds to the specific modelof each specific service. In addition, the core also includes a manager that is responsible formaintaining the context repository.

• Functional engines: Several functional engines constitute the second block. There are threemodules supporting the context model. The first one is responsible for collecting and unifyingthe context from various and heterogeneous sources. It is also responsible for implementingthe abstraction criteria to convert the collected data into the context, specifically into validinstances of the elements of the model. The second module provides reasoning for the systemto infer context and avoid inconsistencies. The third module handles the meta-information,that is, any piece of data describing a feature of the context and its relations with otherinformation, it associates knowledge that is not directly related to the domain of study, butdescribes how that piece fits within the model. Information about the context of an instanceof a context model element is called meta-context. The architecture implementation has beendeveloped using C# .NET language as shown in [10].

3.2. The context core

The COIVA Core is the central component although it has been developed so as to minimizeits responsibilities. The core may be defined as the communication interface between the context

‡http://xmlns.com/foaf/spec/.


COIVA 407

model, the functional engines, and the environment context-augmented services (e.g. locationservices, visualization information services, etc.). This discrete approach tries to increase thereusability of the COIVA architecture, attenuating the adaptation requirements in different domainsand assisting different environment services. Moreover, the functional engines have been designedas independent modules in order to reduce the dependencies between them. These functionalmodules (acquisition and abstraction, reasoning and upper-level context management) can bemodified or increased without affecting the rest of the components.

Figure 1 also shows the internal structure of the core. It is composed of three primary modules:the directory broker, the context interpreter, and the security and privacy (S&P) agent. Whenevera context request is performed, the directory broker recovers the structure (i.e. the concepts andrelationships) of the required portion of the model and loads it into memory. The request isinterpreted based on the model semantics and the relevant individuals are loaded from the contextrepository. In general, the context maintenance block, which is a subcomponent of the contextinterpreter, manages operations involving the repository, acting as a facade and handling concurrentrequests. All processes are supervised by the S&P agent, which ensures the fulfillment of thesecurity primitives in any access or modification to the repository information. In the case ofnew context information inclusion through sensed or inferred data, the behavior is similar andagain involves the directory broker, the interpreter, and the S&P agent. The only difference is thatthe meta-context engine also must be notified of the changes in order to update the high-levelabstraction information about each new individual.

Both external applications and functional engines can send requests to the COIVA core, and themechanism is the same for these two cases. Whenever an application or engine requires contextualinformation, ViMos obtains the submodel needed for the concrete request from the COIVA archi-tecture. The submodel includes OWL classes and properties that contain valid individuals. Thesubmodel is refreshed at run-time by deleting elements with individuals that have disappeared andby including elements that have transformed into new individuals after data acquisition. In thisway, the run-time management of the ontologies is optimized. After extracting the submodel,the context broker maintains it and updates it based on the service requirements and situationalchanges that occur when an individual changes its value. Moreover, the context broker keepstemporal references about the requests made by the services. In this way, whenever a servicemakes a request about context information, the context broker offers an incremental response. Morespecifically, it provides newly acquired, modified, or inferred individuals based on the request. Thecommunication between external applications and COIVA is performed through Web Services,and SPARQL-DL [11] is the language used to define the requests of contextual information.

Augmenting the level of detail, the COIVA core has the following responsibilities:

• Being suitable for interfacing with the context model, enabling its interpretation and reducingthe concurrence problems between the functional engines and the external context-poweredservices.

• Abstracting the context-model modifications to the functional engines and services.• Managing the complexity of the distributed storage of the context model. Ontologies mayoften be located on several remote servers.

• Guaranteeing the privacy policies of the context information. The meta-context enginemanages the privacy and owner issues and the COIVA Core has to control the privacy andsecurity primitives.

3.3. Context model

Context is a broad and imprecisely defined concept. Several definitions have been proposed forcontext in the area of computation. However, as Paul Dourish stated [12], it is a concept that keepsto the periphery and slips away when one attempts to define it. The main elements of the contextare neither well defined nor delimited. Dey and Mankoff [13] focusing on the context acquiredthrough sensors, identifies four categories of context information: identity, location, activity, andtime. Gross and Specht [14] propose another classification of four dimensions of context: location,



identity, time, and environment. Thevenin and Coutaz [15], on her part, define three main elements:user, platform, and environment. We propose a user-centered classification consisting of the user,the environment, the devices, and the services. This is a more general classification. The location,identity, activity, and time are properties of our main elements, in an upper-abstraction level (seethe section on meta-context). The platform, system, and application are concepts embedded on theservice element but defined from the user’s point of view. The smart environment offers services tothe users through the devices and, in an invisible way, using one or several applications, platformsand systems. We now examine the four main ontological models. A more detailed analysis isexplained at [16].

3.3.1. User model. The user model has been designed to answer three basic questions: What arethe characteristics of the user? What does the user want to do? and What is the user doing?The answers to these questions belong to the three main parts of the user model. First, the staticcharacteristics of the user are described in the User Profile. It includes the personal data, interests,affiliations, etc. All this information is not invariant but neither does it change frequently. Thesecond part includes the activity planning and is called the User Agenda. Activity granularity is notimposed; fleeting actions as well as long-time activities can be instanced. Finally, the user situationis modeled including the dynamic and circumstantial aspects of the user, e.g. their companions,the user location, the current task and goals, etc.

3.3.2. Devices model. Typically, pervasive environments include hardware and software elementseach offering specific functionalities, and combining to provide a general service. The environmentmust support the spontaneous inclusion of new devices, acquiring their characteristics and upgradingthe global device information. In order to achieve this requirement, it is necessary to establish acommon framework between the general context model and the devices, i.e. an expressive languageto enable their dynamic and automatic communication.

Advances in ontological languages may improve the description of device characteristics, asso-ciating semantics and enabling mechanisms to share profiles. Concretely, formal ontologicallanguages such as OWL allow the hierarchical and independent conceptualization that facilitatesthe reuse and sharing of device information.

Although there are several ontological proposals in device modeling, they are usually focusedon specific kinds of devices. For example, the UAProf§ specification is concerned with capturinginformation for wireless devices and the FIPA Device Ontology¶ aims to be general but offerslow-expressiveness in peripheral device descriptions. There are also examples of generic-devicemodels [5, 17] that include mechanisms for gathering device descriptions. However, these devicemodels include information about location and services, making model reuse or adaptation indifferent domains difficult.

The description of the ontological devices is based on several design principles:

• To offer a generic description and include a sufficient level of detail, avoiding the specificdomain-dependent concepts.

• To define a robust taxonomical organization that makes possible mechanisms to specializethe device model for specific application domains.

• To clearly delimit the borderline between the devices model and the environment, user andservices models.

Following the above-described principles, the device model includes the following features. First,the relationships between the device model and the service/user ontologies are included, main-taining their independency in order to maximize the knowledge sharing with external systems.Second, the device model contains the conceptualization of the device status, defining general prop-erties (e.g. the device availability and its location based on the Environment Model) and enabling

§http://www.mobilemultimedia.be/en/uaprof/.¶http://www.fipa.org/specs/fipa00086/XC00086C.html.


COIVA 409

the specialization of the status depending on the peculiarities of the individual device. Third, itincludes the dependencies and relationships between devices, for example, the compatibility level,devices that delegate to others, linking relationships, etc. Fourth, it has a taxonomical organization:our proposal differentiates between four types of devices: sensors, actuators, autonomous devices,and dependent devices. Finally, the software and hardware profiles explicitly define the generalcharacteristics once again including mechanisms based on OWL that enable the model special-ization. For example, some of our prototypes specialize the device model including the formalmodeling of the taxonomy for multi-person-display ecosystems proposed by Terrenghi et al. [18].

In summary, this device ontology does not aim to be universal, but is adequately general byavoiding restrictive constraints and providing a taxonomical organization to aid in specializationfor specific context-aware applications.

3.3.3. Environment model. The environment ontology is related to the rest of the context modelthrough the Entity class, the parent class of the user and device entities. The ontology has beendesigned based on a taxonomical organization of the spaces and following a premise of generalityin order to be applicable to multiple domains. Consequently, the level of detail is low, and it isnecessary to adapt the model to the peculiarities of each environment.

Pervasive environments may support context-awareness systems that endow inanimate objectswith computational significance. Consequently, it is very important to describe objects in thecontext model by associating information to them. Our model, besides modeling the objects, alsodescribes their physical organization.

3.3.4. Service models. The proposed context model has been designed from a generic perspective,including general aspects involved in smart environments. The set of services available is huge, andit is necessary to define an ontological model for each kind of service. The model infrastructureenables the taxonomical organization and the mechanisms to integrate the specific service modelsto the above-described context model. Section 5 describes the framework used for the informationvisualization services that offer adaptive content to the users depending on their profiles and contex-tual situations. Moreover, the design effort required to apply the context-awareness infrastructureto this specific service has been analyzed.

3.3.5. Broad view. For a general view of our context model, we can summarize the principalontologies involved in it:

• User ontology: It describes the user profile, their situation, and their social relationships.• Device ontology: It is the formal description of the relevant devices and their characteristics,associations, and dependencies.

• Physical environment ontology: It defines the space distribution.• Service ontology: It is an abstract ontology that specifies the context model to the particularapplications and services to be offered to users.

The context model design follows the premise of the separation of the four ontologies describedabove. However, these ontologies keep static dependencies that have been defined in a simple,upper-abstraction level model to relate the ontologies. This model defines a superclass called Entityand its specialized classes User and Device. The individuals of the Entity class are located inelements of the Environment ontology and use services defined by the Service ontology. Theselimited dependencies reduce the coupling among the different parts of the context model andensure the cohesion among the ontologies whenever one of them is modified.

3.4. Acquisition and abstraction engine

The context may be acquired from different sources, and consequently a process is requiredto transform the acquired raw data into context information. Usually, this process requires dataabstraction operations, data compositions, and policies to redundancy and ambiguity reductions.



Several authors have identified challenges in context acquisition [3, 19–21]. In what follows,we have compiled, unified, and extended the main difficulties:

• Context is acquired from multiple, diverse, and heterogeneous sources. Usually a significantamount of context is obtained from sensors, but it is also acquired from databases, webrepositories, the Internet, user interactions, etc.

• Context is acquired from non-conventional sources. There is a lack of standards and protocols.• The acquired data usually need to be transformed into high-level abstraction information.For example, a GPS signal has to be abstracted in order to define general locations, e.g. abuilding.

• The context is highly dynamic, and consequently, changes should to be acquired in almost realtime. Users have to perceive the system’s response to significant situation changes wheneverthe context change occurs.

• The context sources, are not only diverse and heterogeneous, but also associated to a widevariety of devices and objects, e.g. mobile devices, vehicles, wearable computers, and so on.

• Typically, the sources work into a concrete administrative domain and are not able to sharethe acquired data with different domains, even if they share a common formal model. Thesources should combine their measures in order to obtain high-level context. For example,sensors that determinate the presence of the user at home and software agents that detect theuser’s activity in the computer may cooperate and infer whenever the user is working at home(combining context sources from different domains, household, and work).

• The increasing development of different context sources, models, and services facilitates asignificant increase in the information flow.

The acquisition and abstraction (A&A) engine has been designed under the premise of generalityin light of the challenges discussed above. In this context, we aim to incorporate ontologicalannotations in order to simplify data acquisition from sensors concretely by transforming senseddata into a semantic-powered object and then, mapping the sensed data to the correspondingcontext model entity. This functional module handles sensing polices, signal filtering as wellas data abstraction and combination in order to transform low-level data into high-level contextinformation. More precisely, once the context model is created, we define how external informationis gathered and matched to each entity of context model. The context data unification submoduleemploys an object instance to represent the communication with a context source. This submodulemaintains as many sensor instances as necessary, depending on the loaded context submodel.Thus, this process is an application-dependent issue. Sensor gathering can work in three ways:(a) push, in which the sensor publishes each measurement; (b) conditional, in which a constantpolling is managed by threats in the data source triggers submodule, where the measurement istransformed into a context model entity based on previously defined conditions (e.g. wheneverit exceeds a certain limit); and (c) on-demand, in which the COIVA core can request updatedmeasurements. Once the sensed value moves through the acquisition phase, it must be convertedto a valid individual (or a set of individuals).

As summary, A&A engine implements the following main functionalities:

• Context data unification: The acquired data have to be unified in common data types. This isnecessary due to the diversity in the data codification.

• Context generation: Acquired data cannot be considered as context until they have undergonean abstraction process. Previously unified data are transformed into well-formed individualsof concepts and relationships defined in the context model. The process includes the disam-biguation of the data (including redundant, ambiguous, incomplete, and erroneous measures),the composition of raw data in order to obtain higher level data, and the final matchingbetween the data and the modeled elements.

• Data source requests: This submodule provides new data measures on demand. The enginemanages the relationships between context-model elements and data sources. This informationis necessary to analyze the requests in the SPARQL language, which are always concernedwith context model elements, and obtain the relevant data sources.


COIVA 411

• Data source triggers: Context-aware systems usually need to know about significant contextchanges at the moment they occur, enabling more proactive and autonomous behavior. Thismodule manages the subscriptions to context elements, and has been designed using theObserver design pattern [22].

3.5. Reasoning engine

From previous works, several techniques and methods have been developed to infer context. Someapplications and architectures adapt RDQL (RDF Data Query Language) including a reasoningengine to endow inference capabilities to this query language. This is the case of CoBrA [7] andSemanticSpace [23]. There are also proposals based on probabilistic models: concretely, ConMotion[24] and Context Management Framework [25] apply Bayesian networks to define the inferenceprimitives. AmbieSense [26] deducts context through Case-Based Reasoning (CBR), inferring newinformation based on similar past situations. Another representative technique is to exploit thesemantics associated to formal languages, as in the GAIA [27] and GAS projects [28].

The reasoning engine is based on description logics in order to endow the context-aware archi-tecture with inference capabilities. Languages based on the description logics foundations allowus to apply the language semantics in order to obtain new information from previous informa-tion. Moreover, it is possible to combine description logics with rule-based systems to improvetheir reasoning capabilities. Furthermore, reasoning techniques enable the definition of consistencyrules, reducing the ambiguity in the context information, and thus maintaining and improving theinformation quality.

The description logics are a family of languages that support the terminological knowledgerepresentation of a specific domain. Description logics may be considered a subset of predicatelogics and an extension to frames and semantic networks, whose design was based on reachinga balance between computability and expressiveness. The formal semantics allow us to applydecidable reasoning, a powerful mechanism to infer new context information. The Web SemanticLanguages, in particular OWL-DL, are syntactic versions of the semantic logics and, as such, theyhave sufficient knowledge representation capabilities and efficient inference mechanisms for ourpurposes.

There are several reasoning tasks associated with the inherent nature of the semantic logics:

• It is possible to determinate whether there exists a model where a certain concept is included.In context-aware systems, there are usually several specialized models defined at differentpoints, incorporating new elements and individuals during the system life cycle. It is necessaryto know, at any time, whether a certain concept is included and which models define it.

• It is possible to determine whether a concept is a part or a particular case of another one.Usually, given an individual, we need to know the most specific class of which individual isan instance in the taxonomical hierarchy.

• The description logic axioms preserve the consistency of the model reducing the ambiguityin the context model.

OWL defines an inherent semantics that enhance the inference capabilities of our system, at thelevel of classes as well as individuals. The semantics is defined through formal classes axioms,descriptions (e.g. UnionOf, intersectionOf, complementOf, etc.), restrictions (e.g. Cardinality), andproperty axioms (e.g. InverseOf, subproperty, etc.)

Because context-aware systems are developed for highly dynamic environments, it is almostcertain that each application will require an adaptive and proactive behavior. Context-aware appli-cations need to define their adaptive behavior at two stages: at design-time and at run-time. In ourapproach, design-time changes can be defined according to the definition of the context model,its associated ontological axioms, and its reasoning rules. The run-time adaptation is also enabledusing reasoning rules. In anticipation of this requirement, we decided to refactor the mechanism tomonitor the reasoning rules by dynamic context-event handlers, which are in charge of developinga reaction to a context change. The active rules at run-time are obtained from plain text files, andeach gathered rule is handled independently.



The context-aware applications developed under COIVA define their dynamic behavior usingSWRL [29]. This language extends the semantics of the OWL axioms and follows the antecedent-consequent schema. Both the antecedent and consequent may be formed by a set of atoms that canbe class descriptions, data ranges, and model properties. Moreover, SWRL define several built-inoperators (comparisons, math, booleans, string, and time operations).

In summary, the principal characteristics of the reasoning engine are the following:

• This reasoning engine is based on the description logics and behavior rules in SWRL toendow the architecture with inference capabilities.

• To support the highly dynamic nature of ambient intelligence, COIVA enables adaptivebehavior at two stages, at design-time and at run-time. In anticipation of this requirement,we decided to refactor the mechanism to monitor reasoning rules by dynamic context-eventhandlers, which develop a reaction to context changes.

• The reasoning engine can support the definition of updated or deleted policies thereby keepingthe context model accurate and manageable.

3.6. Meta-context engine

During the past few years, there have been efforts to identify, define, and classify the maincomponents of context. Moreover, there are multiple approaches to define the relevant context atspecific application domains. Furthermore, we often forget to describe the context from a moreabstract perspective, i.e. the context into its own context. Any information about a contextualconcept, and its relationships with the rest of the information, carries certain associated knowledgerelated to their characteristics into the model, but that is not related to the domain in question.It is important to emphasize that the meta-context is related to the model individuals, and not tomodel concepts. We therefore propose this definition:

Meta-context is the information describing the context of each instance in the context model.The meta-context has the following primary functionalities:

• Ambiguity treatment: The context information may be inexact, incomplete, or uncertain. Themeta-context enables the definition of the quality level and may support ambiguity treatmentmechanisms.

• Context information inference: Usually, the inference engine is based on the model languageaxioms and only uses the domain information through model individuals. The meta-contextoffers high-level properties about individuals that enable powerful proactive behaviors forinference engines.

• Learning mechanism: It is important to endow context-aware systems with learning capa-bilities. Most learning techniques analyze the system history in order to adapt their futurebehavior. The meta-context may, among other functionalities, maintain historical data aboutmodel individuals.

• Information management: A common problem in context-aware systems is the existence ofobsolete data. Manual maintenance is unfeasible in complex systems, hence autonomousmechanisms must be included. The meta-context can simplify this process using time-stamps(one of the meta-context elements).

• Privacy management: Context-aware systems typically include privacy and security primitivesbased on global profiles. The meta-context enables the privacy and security management atthe individual level.

• Semantics extension: In general terms, the main functionality of meta-context is to enlargethe semantics of the context model, including high-level abstraction information that usuallyis not taken into account or not uniformly managed in the context-aware system.

The meta-context model (graphically shown in Figure 2) is built upon four main elements:

• Information reliability: The level of trust regarding an instance that can be measured in aqualitative or quantitative way. Most context-aware applications assume the complete validityof the context information. Despite the advances in sensors and modeling techniques, the


COIVA 413

Figure 2. The meta-context model managed by the meta-context engine.

context information is not error-free. Ignoring that ambiguity may be a valid approach forsimple context-aware applications, but it may be a requirement to consider at design time.Some authors propose mediation as an ambiguity treatment mechanism. It can be a powerfulmechanism but requires active interaction with the user. The formal context model can alsoinclude implicit mechanisms to support the ambiguity treatment, for example, delimitingthe range of individuals or defining cardinality parameters (e.g. a user can only be in onelocation at a time). The behavior rules can also identify frequent measurement errors andact accordingly. Either way, the representation of quality measures related to each individualcan enhance the ambiguity treatment. The quality evaluation is a function of the data inseveral phases. The acquisition phase usually involves errors (for example, depending on thesensor reliability). The abstraction process may also involve failures because it is based on acombination of data acquired. The context model, being a generalization and simplificationof the real world can assume facts that are not always correct, as in the case of behavior rules.

• Information owner: The context-aware system may associate any individual to another byowner relationships. Typically, the data owner is a user; however, for higher generality, themeta-context does not restrict the range of values of the owner property, i.e. the owner canbe an individual of any element in the model. Moreover, the meta-context defines severalsubclasses in order to increase the information owner semantics, distinguishing betweenCreator-owner, Supervisor-owner, inCharge-owner, and so on. This meta-context element mayenhance the privacy and security mechanisms. Usually, context-aware applications inherit theprivacy policies from traditional applications, defining access levels and associating themto user profiles. Context-aware applications need to implement more complex mechanismsfor several reasons: (a) the information is distributed and stored by heterogeneous systemsand devices, (b) context information is wide and diverse and requires polices based on more



complex aspects than simply user profiles, (c) the diversity also supposes a higher granularityof definition, hence a policy at the class level is desirable, and (d) it is difficult to determine thepolicies at design time due to the dynamism and context-evolution of context-aware systems.This meta-context element enables the definition of privacy and security polices based oncontext-model elements and, consequently, incrementing the granularity and improving theevolution of the policy. Information owners also enhance the maintenance of the contextualinstances, for example, deleting individuals whenever their owner stops being a valid contextelement in the model.

• Time scope: The time scope is the period in which a contextual individual keeps values withoutsignificant changes, including past states, the current value, or future estimates. It is importantto point out that irrelevant or insignificant changes (for example in sensor measurements)are not taken into account. Sometimes the time-scope is more important than the peculiarindividual value. For example, a service to detect open doors needs to know the period inwhich the open-door property has a true value in order to throw an alert if someone forgotto close the door, but not when a user goes in and closes the door immediately. On theother hand, the time scope enables the definition of inference rules based on the time. It isalso possible to define expiration properties for model individuals, enhancing the system’sautonomy in maintenance. Finally, the time scope is valuable information for learning enginesin context-aware applications, enabling their proactive adaptation based on historical measuresat run-time.

• Domain issues: The context model is usually focused on fixed application domains. However,it may be necessary to import submodels from external domains (for example, by ontologyintegration). The context model has to be able to distinguish the domain or domains where anelement is defined and in which of these domains this element is valid. The meta-context defi-nition includes several kinds of domains: social domains (e.g. workmates, family, friends. . . )activity domains (work, leisure, etc.) and physical domains (the office, the household, roads,etc.). The domain issues may be considered at the concept level; however, this can induceambiguity problems if the same concept is valid in several domains but the individuals arevalid only in a given domain. The meta-context engine includes the domain description at theindividual level, reducing the ambiguity problems.

The meta-context model, as well as the context model, has been described using OWL. Thissimplifies interoperability. The meta-context description is based on a semantic expanse of theowl:Thing superclass. The main meta-context elements have been defined as owl:Thing properties,maintaining the consistency of the full model and enabling future modifications to the meta-contextmodel without affecting the rest of the system. The main elements are reliability, owner, historyand domain, each modeled by a set of owl classes and properties.

The meta-context is highly dependent on the context model, because its elements take valuesfrom valid model instance ranges. In this way we attain interoperability and coherence betweenmeta-context and model classes and individuals. However, the formal definition stand-alone is notenough to ensure the meta-context integration. The meta-context is on a higher level of abstraction,i.e. it describes the common properties of the context elements. Consequently, it is necessary tomanage the context model and the meta-context independently. Another difficulty is the rangetreatment. Some meta-context elements take values from any valid range in the context model,depending on the model class that is being described. For example, the history elements store pastvalues of an individual. The range of the history element is the same as the range of the individualwatched, and it follows that the concrete range cannot be known at design time. The meta-contextmakes a generic definition and a special treatment is required at run-time to disambiguate the range.

Taking into account the above aspects, we can enumerate the following responsibilities of themeta-context engine:

• Model adaptation: Removing the inconsistencies related to the owl:Thing superclass redefi-nition.

• Ambiguity resolution: Disambiguating the value ranges of the meta-context elements.


COIVA 415

• Meta-context maintenance: Functionalities related to the persistent storage of meta-contextindividuals in the repository.

• Interface with the functional engines: Attending requests and providing meta-context informa-tion. The reasoning engine may need any meta-context individual, the learning engine mainlyrequires history elements, and the A&A engine is involved with the reliability submodel.

4. VALIDATION THROUGH PROTOTYPES

4.1. Adaptive information retrieval prototypes

Everyday, we manage and analyze a wide variety of personal information, such as calendars,news, e-mails, and digital documents. In general, many actions and decisions are based on infor-mation we obtain from various heterogeneous sources. In fact, information is a ubiquitous partof our everyday tasks. As a result, advances in the visualization of information may be a greatsupport for the development and acceptance of the Ambient Intelligence paradigm [30]. Users needsupport to get required information anywhere and anytime; therefore, we cannot study advances inAmbient Intelligence and Information Visualization separately, but it is necessary to consider therelevant features for displaying information into intelligent environments. The context-awarenessarchitecture may enable this kind of proactive and adaptive information visualization services.A specific service ontology has been described [31] and several prototypes have been developed: avisualization service to support collaborative activities, a prototype to help conference participantsduring the UCAMI 2008 Symposium‖, and a prototype to offer products and access to servicesat commercial centers. Figure 3 shows the relationship between the COIVA architecture and thevisualization services. These services apply context-awareness to provide adapted information tothe user through embedded devices in the environment.

The displayed views are called mosaics because they are formed by independent and relatedpieces of information compounding a two-dimensional user interface. Initially we have a whole setof information pieces. Analyzing users’ situations (described in the context model) the best piecesare selected. Each piece has several associated characteristics (e.g. optimum size, elasticity, etc.).These characteristics have been described in the visualization information ontology and make thefinal generation process of the mosaic possible. The generation of information mosaics is carriedout by adapting the user interface according to the situation. We can improve, by means of this, thedynamism, the adaptability, and the content quality. The user interactions and the environmentalchanges enable progressive adaptations of the users interfaces. The mosaic generation process isbased on Garret proposals [32] for developing web sites and hypermedia applications by identifyingthe elements of user experience. It is important to remark that Garret proposals are focused ondesign-time development and COIVA helps to generate user interfaces at run-time. However, theprocess includes similar steps in both cases: analysis of the user situation and the visualizationobjectives, content requirements, interaction design, information design and finally, the visualdesign. The COIVA architecture provides the needed information for the generation of the userinterface at run-time.

4.2. The collaborative groups prototype

This scenario involves groups of users that share interests and agendas, working collaboratively witha dynamic information flow. The prototype supports the daily activities of research groups by meansof information visualization, using personal and public displays in the environment. This specificprototype can be applied to similar scenarios that involve people working together, for example,in an office. The main objective of the visualization service is to provide quick and easy accessfor users to share information and to coordinate collaborative activities. Specifically, the prototypeimplements six services: user location and user state, work in progress coordination, document

‖Third Symposium of Ubiquitous Computing and Ambient Intelligence 2008. http://ucami.usal.es.



Figure 3. Relationship between COIVA and visualization services.

recommendation, events and deadlines, meeting support, and group agenda management. Thisprototype explores how particular and independent applications can exploit COIVA functionalities;in particular, our prototypes have been built based on an automatic user interfaces-generationsystem called ViMos, which has been described in previous works [33, 34]. In this paper, we focuson the COIVA framework in terms of context information management.

The prototype environment is equipped with several public displays, including plasma and LCDTVs with a screen size between 32 and 50 inches and touch screens of 21 inches. The interactionwith TVs is mediated through Near Field Communication (NFC) mobile phones; displays wearseveral NFC tags with associated actions that depend on the displayed visualization service atrun-time. Thus, tag functionality changes dynamically. Whenever users touch a tag, their mobiledevice sends the associated information via Bluetooth (if available) or GPRS connection to thecontext server. The visualization service uses two dedicated services, namely, the COIVA serverto manage the context model and the ViMos server to generate user interfaces. The user interfacesare sent using WiFi-VGA extenders that enable the wireless transitions of VGA signals to thepublic displays.

In order to better understand the ViMos system, Figure 4 shows a user interacting with thevisualization service and a personalized user interface. When the users begin interacting with thedisplay (using NFC technology, in this case), the environment recognizes them, analyzes theirsituation and infers their information needs and current tasks. Additionally, COIVA uses userinteractions to update instances of the context model (e.g. by assigning the display location to theuser location property). All of these behaviors and functionalities are defined using SWRL. In thefollowing subsections, we detail how COIVA enhances context-aware functionalities and explainmechanisms that are launched by our framework to generate these visualization services.

4.2.1. Specialized context model. The prototype extends the context-model ontologies thatprimarily emphasize the service ontology in order to conceptualize information-visualizationissues, including perceptive and cognitive issues, graphic attributes, and data properties. Infor-mation visualization is a multi-disciplinary area, hence it is difficult to construct an ontologicalrepresentation of it. For this reason, we have identified the most important concepts and classifiedthem according to criteria for constructing a taxonomy [31] in order to guide the process of devel-oping the corresponding ontology, called Pervasive Information Visualization Ontology (PIVOn).We have organized the ontology elements in terms of: (a) the relationships between information


COIVA 417

Figure 4. A user interacting with the visualization service via NFC with ontologicalindividuals and inferred information.

visualization issues and the relevant context elements; (b) the metaphors, patterns, and the mannerof information presentation to facilitate the rapid compression and synthesis by making use ofdesign principles based on human perception and cognition; (c) the visualization pipeline [35]through which the model represents the main elements involved in the visual mapping; (d) methodsand interaction paradigms, which the model must represent in order to provide mechanisms thatoffer consistent information according to the devices that interact with the environment; (e) thestructure and characteristics of the user-interface view; (f) related social aspects, as visualizationcan be optimized depending on the social groups of its users; (g) data characteristics, includingthe nature of the data so as to provide mechanisms that enhance the visualization process; and(h) scalability issues, including various techniques for information scalability, such as zooming,paging, filtering, latency, and scalability of complexity. Figure 5 shows the main elements of thecontext model, including its adaptation to information visualization services.

4.2.2. Acquisition of context data. Once the context model is specialized, we define how thesensed information is gathered, abstracted, and matched to valid model entities. In this prototype,we are primarily interested in capturing the users location, social situation, the performed task, andany interactions with devices and applications. In particular, we have deployed several interactiontechniques, such as gesture recognition through accelerometers embedded in mobile phones [36],NFC technology [37], and infrared sensors. Table I shows some examples of sensors, the gathereddata, and mappings of valid entities in the context model.

4.2.3. Adaptive behavior through semantic reasoning. The information that is presented to users isselected on the basis of contextual information particularly on the contextual situation of the userscloser to the visualization device and on the behavioral rules defined for the specific visualizationservice. Focusing on this prototype, we present some examples of context-aware mechanisms usedto select the displayed contents.

• Inference by means OWL axioms:

Example 1This example shows the inference behavior through the inverse property. The submodel definesthe Person, Document, and WebPage concepts, related by the webBlog property. The assertionalbox defines an individual MyPersonalBlog as the personal web of the individual Ramon. There are



Figure 5. Principal elements and relationships of the specialized context model.

several inferred deductions: Ramon has a blog called MyPersonalBlog (inverse property), Ramonhas to be a Person, and MyPersonalBlog has to be a Web Page (Figure 6).

Example 2Figure 7 shows the relevant context submodel in this example and the OWL individuals thatinfluence content selection. The context captures the location of users GoyoCasero (line 5) andAlbertMunoz (line 13), in the same place as the display that currently shows the visualizationservice (lines 18–20). All items of content related to these users have been pre-selected and filteredbased on their context. Specifically, GoyoCasero is the user interacting with the display (line 9);thus, his items of content are preferred. Additionally, the context definition shows that GoyoCaserosupervises AlbertMunoz’s work (line 8) and, consequently, AlbertMunoz’s work-in-progress is


COIVA 419

Table I. Examples of data acquired from sensors.

Type of Gathered Generated/updatedsensor data Meaning individuals Work ways

Infrared Hw s:Sensor ID Someone is interacting pivon:interacting Push waysensor a:Application with the ‘a’ application pivon:InteractionMethod

Someone is performing user:Taskthe task associated tosensor ‘s’ in ‘a’

NFC Hw/Sw t:Tag ID User related to ‘b’ is pivon:interacting Conditionalsensor b:Bluetooth interacting with the ‘a’ pivon:InteractionMethod (If interaction

Address application user:Task has ana:Application User related to ‘b’ is user:locatedIn associated

performing a task user:userAvailability action)associated to thesensor ‘t’

Document Software d:document User related to ‘dv’ is pivon:interacting Push waymonitor sensor a:Application interacting with pivon:InteractionMethod On Demand

application ‘a’ user:Taskdv:device User related to ‘dv’ is user:locatedIn

editing/reviewing foaf:documentdocument ‘d’

Document Repository d:document User logged in as ‘u’ pivon:interacting Push wayrepository u:user ID is interacting with pivon:InteractionMethod On Demand

application ‘a’ user:TaskUser logged in as user:locatedIn‘u’ is interesting in foaf:interestdocument ‘d’

Figure 6. Concepts and properties involved in Example 1 and relationships inferred by the OWL axioms.

Figure 7. Individuals and submodels involved in scenario-information retrieval.



Figure 8. Ontological concepts and properties involved in the example rules 3, 4, and 5.

selected. Finally, the context framework keeps information about the last content accessed by theuser (line 11) independent of his/her location. This information determines the most importantcontent that is shown in the main area of the mosaic.

• Inference by means OWL axioms: The following are some example rules generated for theprototypes and the ontological elements involved (Figure 8):

// Rule Example3Publication(?p) & author(?p, ?y) & author(?p, ?z) R© collaboratesWith(?y, ?z)

//Rule Example4Mosaic (?m) & Content (?c) & has (?m, ?c) & VideoChat (?v) & abstractType (?c, ?v) & connect-edUser (?v, ?user1) & Super (?user2, ?user1) & interacting (?user2, ?m) R© userState (?user2,#busy)

//Rule Example5User (?u) & Contact(?p) & mail(?p, ?email) & hasContact (?p, ?iduser) & swrlb:endsWith(?email,”@uclm.es”) R© workmate(?u, ?iduser)

Listing 1: Example behavior rules on SWRL.

Example 3The figure models the facts that users can be authors of a given document and several authorscan collaborate. The reasoning rule can generate collaboratesWith individuals based on the authorproperty, i.e. whenever two users are authors of the same document, the system assumes that theseusers collaborate between themselves.

Example 4The model subset represents the fact that the user can be interacting with visualization services(called Mosaics) and these services may include several types of contents, for example, VideoChats. A second rule defines the user availability as busy whenever he/she is in a videoconferencewith his/her boss.

Example 5The figure shows a model subset that represents the social relationship workmate and the e-mailproperty in the User domain. The built-in operations in SWRL enable more powerful behaviordefinitions. The rule determines that two users whose e-mails end with ‘uclm.es’ can be consideredas workmates.


COIVA 421

Figure 9. Number of elements and axioms/rules (left) and number of individuals at run-time (right).

4.3. Evaluation

The evaluation of software architectures is notoriously difficult in academic journals, hence wehave analyzed the foremost contributions of previous studies and have identified their functionalproblems and solutions in the context of COIVA architecture. In this section, we have focused ourevaluation on the quantitative measures regarding the context element at run-time. We have analyzedthe number of elements (concepts and properties), behavior rules, and generated individuals duringfour run-time periods: the launch point, one, two, and three weeks later. Moreover, we distinguishfour contextual information sets: (a) the isolated context model that includes the user, the device,and the environment ontology; (b) the basic context model and the external ontologies that havebeen integrated, concretely, the FOAF ontology to describe the user profile and the W3C TimeOntology∗∗ ; (c) the basic context model, the external ontologies and the model that describe theinformation visualization service, forming the full context model; and finally (d) the full contextmodel together with the meta-context information. Figure 9 (left) shows the number of elementsand behavior rules in each set of contextual information. Figure 9 (right) represents the quantityof contextual individuals managed by the framework in each run-time period and for each set ofcontextual information. The experiment reveals some useful lessons:

The external ontologies involve an important increment in elements, increasing the amount ofknowledge represented in the context model; however, they do not entail a significant increase inthe number of individuals, as they are elements with a limited scope and very specific domains(profile and time) and new context information have not been generated based on these elements.

The visualization service model causes a significant increase in the context information beingmanaged, increasing the number of elements as well as the number of individuals generated. Thekey is the high number of inference rules that define the behavior of the visualization serviceand enable the massive generation of inferred context. Finally, as may be expected, the meta-context information hugely increases the number of individuals managed. However, the inclusionof individual deletion policies moderates the increase in the number of individuals.

As a secondary evaluation, we have also analyzed the inference assumptions and usability issueswith respect to this method. In order to evaluate the general aspects of usability, we have adaptedand extended the heuristics developed by Nielsen [38] and the MoBiS-Q questionnaire [39]; wehave also designed an opinion poll with 16 questions adapted to the visualization characteristics ofthe mosaics in order to evaluate the experience of users with information visualization. Figure 10shows the evaluation and the results. The average agreement was 81%.

As a third test, we have evaluated the adaptability of content according to context information.The prototype considers the situation, user’s profile, and their specific needs among other consider-ations. Users have tested the prototypes and have expressed their agreement or disagreement withthe displayed contents. We have applied basic statistical classification to evaluate the relevance

∗∗http://www.w3.org/TR/owl-time/.



Figure 10. Summarized results on user experiences with ViMos.

of the offered contents; concretely, precision and recall measures [40]. In our system, Precisionrepresents the number of items of relevant content retrieved in a mosaic view divided by the totalnumber of items retrieved for a particular situation. Recall is the number of relevant documentsretrieved in a mosaic view divided by the total number of existing relevant content items in thesystem. Additionally we include two well-known measures: the Fall-out, that is, the proportion ofoffered irrelevant items out of all irrelevant items available in the system, and the F-score as ameasure that combines precision and recall. The total number of content items in the repositorieswas 189. Adding the different users’ tests, out of a total of 188 items to return to the differentusers, 163 were adequate for them. These results give us a precision of 86.7%, a recall average of86.2%, a fall-out of only 0.7%, and an F-score up to 86%.

5. BACKGROUND LITERATURE AND CONTRIBUTIONS

There are three general categories of research relevant to our work, namely, studies on contextmodels, architecture-based frameworks for context-awareness, and meta-information related tocontext. We provide an overview of the most relevant findings in these areas and summarize thedifferences between them and our work, including the principal contributions of our approach.

Previous works have investigated the design and use of context. Model-driven approaches enablethe handling of context by defining domain-specific modeling languages. For example, UnifiedModeling Language (UML) has been widely used for this objective [41–43]. Rule-based reasoningapproaches have also been used and usually combine knowledge-management systems with anumber of rules and activation conditions that generate and manage context [44–46]. A commonproblem in these context models is that the definition of context aspects may lack semantic cohesion.In addition to this problem, traditional user modeling has been lumped together with applicationdesign, making it difficult to distinguish between user and application concepts. In most cases,the goal of these studies has been to improve user models rather than improve reusability andgeneralization. The problem appears when this kind of a system is accessed from diverse andheterogeneous applications; because they are not designed as a model server [47], issues appear withrespect to redundancy, concurrent access, security, and consistency. Some proposals have focusedon the interoperability and exchange of user-model data. For example, Gumo [48] is a generalOWL ontology for uniform interpretation of distributed user models. Kim et al. [49] propose anOWL-based model designed to understand user goals as well as to guide users while they performcomplicated tasks. A common goal of these approaches and our proposal is addressing the need toshare given the context model across applications independent of the application domain; however,each application requires a different context model, a requirement that is not always consid-ered. A general model that encompasses any application domain requires a complex structure.Our strategy is to isolate the principal elements in every user-centered context-aware applica-tion and provide mechanisms to rapidly specialize the context model and prototype applications.COIVA includes a set of independent ontologies according to a context-awareness perspective.This approach provides mechanisms to formalize the conceptualization of context aspects, therebyenhancing semantic cohesion and knowledge-representation capabilities. Moreover, we provide


COIVA 423

a high-level abstraction model that relates the ontologies. This taxonomical organization enablesexchange between adaptive services and specialization in particular domains.

With respect to the architectures and frameworks used to manage context, we consider one ofthe milestones in the history of context-aware architectures: Dey’s Context Toolkit [3], which isbriefly summarized in the introduction of this paper. This work encapsulates aspects of sensors andcommunication mechanisms using widgets that simplify interactions with software components.Vazquez [50] presents a framework for intelligent and global context-awareness, and serendipitouscollaboration even with remote objects and services. In [51] Pederson et al. present a three-tieredcontext-modeling architecture in which lower level, medium-level, and higher level context modelsare distinguished. In addition, Aura [52] is an architectural system for ubiquitous computing witha special focus on context awareness, including context switching based on user mobility. Anotherremarkable and related system is the MIMOSA framework [53], which couples an intermediaryarchitecture for Web transcoding with middleware for context awareness. We have found manyinteresting similarities between this study and our approach, especially with respect to the needfor and the requirements of ubiquitous access to context entities. However, we have a differentvision with regard to the physical organization of the context-aware framework and the formalconceptualization of the model. In fact, a common problem across the above-described architecturesand frameworks is that there is no explicit notion of what constitutes a context model or anyattempt to define context aspects; instead these aspects are grouped together in a general modelwithout any semantic cohesion. In addition, these approaches derive context elements from sensorsaccording to a button-up perspective. COIVA employs the inverse approach. First, the contextmodel is specialized and, later, context elements are linked to context sources, such as hardwaresensors, software sensors, and repositories. This approach reduces the designed effort and enhancestechnological independence and, consequently, facilitates adaptation to future requirements.

Context-aware architectures are typically layered and incorporate a component to support theprocessing of context values and the triggering of adaptive changes. An important feature ofCOIVA is the decoupling of modules to support scalability; this method also provides a way toanticipate future changes. For example, our approach separates the context model from behavioralmechanisms; Fortier et al. [54] and Lu et al. [55] studied in detail this requirement for context-aware architectures. In general, the separation of the knowledge base from the inference engineis desirable from at least two standpoints. First, it is possible to represent knowledge in a morenatural fashion and, second, the knowledge base can be updated and changed without changingthe inference-engine implementation [56]. Moreover, this approach enhances interoperability withexternal applications that can, in turn, exploit the whole framework or employ their own functionalmodules. For example, the A&A module may be replaced by another external component thataccomplishes the A&A module’s functionalities, realizing prerequisites for supporting SPARQLlanguage and serializing sensorial data in OWL-XML syntax.

Meta-information on context is also related to our work. We can analyze context-aware systemswith respect to the kind of upper-abstraction level elements they describe in terms of low-abstractionlevel elements. Although the concept of meta-context has not yet been explicitly defined, severalauthors have highlighted the need to identify the general attributes of context. The main aim ofthese attributes is to make high abstraction level context (HAL context) automatically availableto ubiquitous systems, thereby integrating conceptualizations into the given context from differentsources and thus enabling mechanisms to enhance model trust [57]. Several authors have remarkedon the importance of context attributes, including Zimmer [58], Wrona and Gomez [59], Fujinamiet al. [60], and Lopez-De-Ipina et al. [61]. In this paper, we have presented an ontological model inorder to formally define the primary meta-context elements and their properties and relationships.Moreover, we seek to provide meta-context management with independent mechanisms as wellas its own context model that enables higher granular control of context information. It is veryimportant to define a set of attributes with adequate levels of generality and independence withrespect to the different abstraction levels of the context model. The meta-context model and thefunctional engine contribute to identify and use context attributes to enhance common requirementssuch as privacy, quality of context, maintenance, and interoperation.



6. CONCLUSIONS

The model is intended to provide a generic form of context description focused on intelligent anduser-centered environments. More detailed models are usually dependent on specific applicationdomains, and inconsistencies may appear in future domain adaptations. The present work providesa sufficient level of detail to reduce the adaptation efforts required and makes available mecha-nisms to include more detailed concepts through standard knowledge representation languages andinfrastructures, concretely, the Semantic Web technologies.

The proposed architecture, in addition to providing a specialization mechanism, supports thedynamic maintenance of the context information. The reasoning engine reduces the start-up process,enabling the automatic generation of context individuals. Moreover, context-aware architecturestend to generate excessive context information at run-time. The reasoning engine (in conjunctionwith the meta-context information) can support the definition of updating or deleting policies,keeping the context model accurate and manageable.

Finally, an important contribution of this work is the meta-context infrastructure. High-levelcontext information is usually forgotten or applied at a general level. The OWL meta-contextdescription through the redefinition of the owl:thing and the associated functionalities implemented,enable higher-granularity control of the context information. The prototypes, as expected, show asignificant increase in the number of context individuals related to the meta-context. However, theadditional functionalities and the improved control over the growth justify this increase.

In summary, the main requirements for user-centered context-aware environments have beenanalyzed and implemented through a unified and extensible framework, exploring the use of WebSemantic principles outside the Web.

ACKNOWLEDGEMENTS

This work has been financed by PII1I09-0123-27 project from Junta de Comunidades de Castilla-LaMancha (Spain).

REFERENCES

1. Abate FR (ed.). The Oxford American Dictionary of Current English: New American Edition. Oxford UniversityPress: New York, 1999.

2. Henricksen K, Indulska J, Rakotonirainy A. Modeling context information in pervasive computing systems.Proceedings of the First International Conference, Pervasive, Zurich, 2002; 79–117.

3. Dey AK, Abowd G. The Context Toolkit: Aiding the development of context-aware applications. Proceedings ofthe Workshop on Software Engineering for Wearable and Pervasive Computing, Limerick, 2002.

4. Roman M. An application framework for active space applications. Ph.D. Thesis, University of Illinois atUrbana-Champaign, Illinois, 2003; 31–40.

5. Vazquez JI, Lopez de Ipina D, Sedano I. SoaM: A web-powered architecture for designing and deployingpervasive semantic devices. International Journal of Web Information Systems 2006; 2(3–4):212–224.

6. Gu T, Wang XH, Pung HK, Zhang DQ. An ontology-based context model in intelligent environments. Proceedingsof the Communication Networks and Distributed Systems Modeling and Simulation, San Diego, U.S.A., 2004.

7. Chen H, Finin T, Joshi A. Semantic Web in a pervasive context-aware architecture. Proceedings of the Workshopon Ontologies and Distributed Systems. IJCAI: Acapulco, Mexico, 2003.

8. Hatala K, Wakkary R, Kalantari L. Ontologies and rules in support of real-time ubiquitous application. Journalof Web Semantics, Special Issue on Rules and Ontologies for Semantic Web 2005; 3(1):5–22.

9. Buriano L, Marchetti M, Carmagnola F, Cena F, Gena C, Torre I. The role of ontologies in context-awarerecommender system. Proceedings of the Seventh International Conference on Mobile Data Management, Nara,2006.

10. Hervas R. Simplified COIVA class diagram. Available at: http://mami.uclm.es/rhervas/Repo/tesis/AnexoOut1-DiagramaClasesCOIVA.pdf [10 December 2009].

11. Sirin E, Parsia B. SPARQL-DL: SPARQL query for OWL-DL. Proceedings of the Workshop on OWL: Experiencesand Directions, Innsbruck, Austria, 2007.

12. Dourish P. What we talk about when we talk about context. Personal and Ubiquitous Computing 2004; 8(1):19–30.13. Dey AK, Mankoff J. Designing mediation for context-aware applications. ACM Transactions on Computer-Human

Interaction 2005; 12(1):53–80.14. Gross T, Specht M. Awareness in context-aware information systems. Mensch and Computer 2001; 5(8):173–182.


COIVA 425

15. Thevenin D, Coutaz J. Plasticity of user interfaces: Framework and research agenda. Proceedings of the Interact,Edinburgh, 1999.

16. Hervas R, Bravo J, Fontecha J. A context model based on ontological languages, a proposal for informationvisualization. Journal of Universal Computer Science 2010; DOI: 10.3217/jucs-0616-12.

17. Bandara A, Payne TR, Roure D, Clemo G. An ontological framework for semantic description of devices.Proceedings of the Semantic Web, Hiroshima, Japan, 2004.

18. Terrenghi L, Quigley A, Dix A. A taxonomy for and analysis of multi-person-display ecosystems. Personal andUbiquitous Computing 2009; 13(8):583–598.

19. Stephens T. A Passion for Metadata—An interview with Todd Stephens of BellSouth. Wilshire Conference,Los Angeles, 2004.

20. Zhdanova AV, Zoric J, Marengo M, Van Kranenburg H, Snoeck N, Sutterer M, Rack C, Droegehorn O,Arbanowski S. Context acquisition, representation and employment in mobile service platforms. Proceedings ofthe Workshop on Capturing Context and Context Aware Systems and Platforms, Mykonos, 2006.

21. Bravo J, Hervas R, Chavira G, Nava SW. Mosaics of visualization: An approach to embedded interaction throughidentification process. Proceedings of the Third International Conference on Cooperative Design, Visualizationand Engineering (Lecture Notes in Compute Science, vol. 4101). Springer: Mallorca, Spain, 2006.

22. Gamma E, Helm R, Johnson R, Vlissides J. Design patterns. Elements of Reusable Object-Oriented Software.Addison-Wesley Professional Computing Series. Addison-Wesley: Reading, MA, 1995.

23. Wang X, Zhang D, Dong JS, Chin C. Semantic space: A semantic web-based infrastructure for smart spaces.Pervasive Computing 2004; 3(3):32–39.

24. Marmasse N, Schmandt C. Location-aware information delivery with ComMotion. Proceedings of the SecondInternational Symposium on Handheld and Ubiquitous Computing, Bristol, 2000.

25. Toninelli A, Montanari R, Kagal L, Lassila O. A semantic context-aware access control framework for securecollaborations in pervasive computing environments. Proceedings of the Fifth International Semantic WebConference, Athens, 2000.

26. Kofod-Petersen A, Mikalsen M. Representing and reasoning about context in a mobile environment. Revued’Intelligence Artificielle 2005; 19(3):479–498.

27. Roman M, Hess C, Cerqueira R, Ranganathan A, Campbell RH, Nahrstedt C. Gaia: A Middleware platform foractive spaces. SIGMOBILE, ACM Mobile Computing and Communications Review 2002; 6(4):65–67.

28. Christopoulou E, Kameas A. GAS ontology: An ontology for collaboration among ubiquitous computing devices.International Journal of Human-Computer Studies 2005; 62(5):664–685.

29. Horrocks I, Patel-Schneider PF, Boley H, Tabet S, Grosof B, Dean M. SWRL: A Semantic Web Rule Languagecombining OWL and RuleML. W3C, 2004. Available at: http://www.w3.org/Submission/SWRL/ [17 November2009].

30. ISTAG. Scenarios for Ambient Intelligence in 2010. Available at: http://www.cordis.lu/ist/istag.htm [12 February2008].

31. Hervas R, Nava SW, Chavira G, Villarreal V, Bravo J, PIViTa: Taxonomy for displaying information in pervasiveand collaborative environments. Proceedings of the Third Symposium of Ubiquitous Computing and AmbientIntelligence. Advances in Soft Computing. Springer: Salamanca, 2008.

32. Garrett JJ. The elements of user experience. User-centered Design for the Web. New Riders Publishing: ThousandOaks, CA, U.S.A., 2002.

33. Hervas R, Nava SW, Fontecha J, Casero G, Laguna J, Bravo J. Exploring context semantics for proactivecooperative visualization. Proceedings of the Sixth International Conference on Cooperative Design, Visualizationand Engineering (Lecture Notes in Computer Science, vol. 5738). Springer: Luxembourg, 2009.

34. Bravo J, Hervas R, Sanchez I, Chavira G, Nava SW. Visualization services in a conference context: An approachby RFID technology. Journal of Universal Computer Science 2006; 12(3):270–283.

35. Card SK, Robertson GG, Mackinley JD. The information visualizer: An information workspace. Proceedings ofthe ACM Conference on Human Factors in Computing Systems, New York, U.S.A., 1991.

36. Raso I, Hervas R, Bravo J. m-Physio: Personalized accelerometer-based physical rehabilitation platform.Proceedings of the Fourth International Conference on Mobile Ubiquitous Computing, Systems, Services andTechnologies. Florence, Italy, 2010.

37. Bravo J, Lopez-De-Ipina D, Fuentes C, Hervas R, Pena R, Vergara M, Casero G. Enabling NFC technology forsupporting chronic diseases: A proposal for Alzheimer caregivers. Proceedings of the European Conference onAmbient Intelligence (Lecture Notes in Computer Science, vol. 5355). Springer: Nuremberg, Germany, 2008.

38. Nielsen J. Usability Engineering. Academic Press: Boston, U.S.A., 1993.39. Vuolle M, Tiainen M, Kallio T, Vainio T, Kulju M, Wigelius H. Developing a questionnaire for measuring mobile

business service experience. Proceedings of the International Conference on Human Computer Interaction withMobile Devices and Services, New York, NY, U.S.A., 2008.

40. van Rijsbergen K. The Geometry of Information Retrieval. Cambridge Press: Cambridge, U.K., 2004.41. Grassi V, Sindico A. Towards model driven design of service-based context-aware applications. Proceedings of

the Workshop on Engineering of Software Services for Pervasive Environments, Dubrovnik, Croatia, 2007.42. Sheng QZ, Benatallah B. ContextUML: A UML-based modeling language for model-driven development of

context-aware web services. Proceedings of the International Conference on Mobile Business. Sydney, Australia,2005.



43. Desmet B, Vallejos J, Costanza P, Meuter WD, D’Hondt T. Context-oriented domain analysis. Proceedings ofthe International and Interdisciplinary Conference on Modeling and Using Context, Roskilde, Denmark, 2007.

44. D’Hondt M, Jonckers V. Hybrid aspects for weaving object-oriented functionality and rule-based knowledge.Proceedings of the International Conference on Aspect-oriented Software Development, Lancaster, U.K. 2004.

45. Daniele L, Dockhorn Costa P, Ferreira Pires L. Towards a rule-based approach for context-aware applications.Proceedings of the Open European Summer School and IFIP TC6.6 Workshop, Twente, the Netherlands, 2007.

46. Giner P, Cetina C, Fons J, Pelechano V. Developing mobile workflow support in the internet of things. IEEEPervasive Computing 2010; 9(2):18–26.

47. Kobsa A. Generic user modeling systems. User Modeling and User-Adaptation 2001; 11(1&2):49–63.48. Heckmann D, Schwartz T, Brandherm B, Schmitz M, von Wilamowitz-Moellendorff M. Gumo—The General

User Model Ontology. User Modeling. Springer: Berlin, 2005.49. Kim G, Han M, Park J, Park H, Park S, Kim L, Ha S. An OWL-based knowledge model for combined-process-

and-location aware service. Human Interface and the Management of Information, Information and Interaction.Springer: Berlin, 2009.

50. Vazquez JI, Lopez de Ipina D. Social devices: Autonomous artifacts that communicate on the Internet. Proceedingsof the First Conference on Internet of Things, Zurich, Switzerland, 2008.

51. Pederson T, Ardito C, Bottoni P, Costabile MF, A general-purpose context modeling architecture for adaptivemobile services. Proceedings of the ER 2008 Workshops on Advances in Conceptual Modeling: Challenges andOpportunities, Barcelona, Spain, 2008.

52. Sousa JP, Garlan D. Aura: An architectural framework for user mobility in ubiquitous computing environments.Software Architecture: System Design, Development, and Maintenance. Kluwer Academic Publishers: Dordrecht,2002.

53. Malandrino D, Mazzoni F, Riboni D, Bettini C, Colajanni M, Scarano V. MIMOSA: Context-aware adaptationfor ubiquitous web access. Personal and Ubiquitous Computing 2010; 14(4):301–320.

54. Fortier A, Rossi G, Gordillo SE, Challiol C. Dealing with variability in context-aware mobile software. Journalof Systems and Software 2010; 83(6):915–936.

55. Lu H, Chan WK, Tse TH. Testing pervasive software in the presence of context inconsistency resolution services.Proceedings of the 30th International Conference on Software Engineering. ACM: New York, NY, U.S.A., 2008.

56. Luger GF, Stubblefield WA. Artificial Intelligence, Structures and Strategies for Complex Problem Solving.Addison Wesley, Longman: MA, U.S.A., 1998.

57. Wang Z, Shi J. A Model for urban distribution system under disruptions of vehicle travel time delay. Proceedingsof the Intelligent Computation Technology and Automation, Zhangjiajie, China, 2009.

58. Zimmer T. Towards a better understanding of context attributes. Proceedings of the Second IEEE AnnualConference on Pervasive Computing and Communications Workshops, PERCOMW, Washington, DC, U.S.A.,2004.

59. Wrona K, Gomez L. Context-aware security and secure context-awareness in ubiquitous computing environments.Proceedings of the Autumn Meeting of Polish Information Processing Society, Wisla, Poland 2005.

60. Fujinami K, Yamabe T, Nakajima T. Take me with you!: A case study of context-aware application integratingcyber and physical spaces. Proceedings of the Symposium on Applied computing, Nicosia, Cyprus, 2004.

61. Lopez-De-Ipina D, Vazquez JI, Abaitua J. A context-aware mobile mash-up platform for ubiquitous web.Proceedings of the Intelligent Environments, Ulm, Germany, 2007.


coiva: context-aware and ontology-powered information visualization architecture

Documents