person is ad

8/4/2019 Person is Ad

1/18

PersonisAD: Distributed, Active, Scrutable

Model Framework for Context-Aware Services

Mark Assad, David J. Carmichael, Judy Kay, and Bob Kummerfeld

The University of Sydney, Sydney, Australia{massad,dcarmich,judy,bob}@it.usyd.edu.au

Abstract. PersonisAD, is a framework for building context-aware, ubiq-uitous applications: its defining foundation is a consistent mechanismfor scrutable modelling of people, sensors, devices and places. This pa-per describes the PersonisAD features for supporting distributed models

with active elements which can trigger when relevant events occur. Thisframework makes it possible to quickly create new context-aware appli-cations. We demonstrate the power of the framework by describing howit has been used to create two context aware applications: MusicMixwhich plays music based on the preferences of the people in the room;MyPlace, which informs people of relevant details of the current environ-ment. Major contributions of this work are: the PersonisAD frameworkwhich provides a powerful and consistent means to respond to significantchanges in the models of people, sensors, devices and places; support fordistributed models and associated resource discovery; two applicationsthat illustrate the power of PersonisAD.

1 Introduction

An essential element of the ubiquitous computing vision is that relevant contex-tual information is used to drive the behaviour of systems. This should also takeaccount of the fact that different people have different needs and a single personhas different needs over time, based on a vast array of their own attributes suchas their changing knowledge and current goals. Peoples needs are also driven bythe many and varying elements of their current environment, such as the peoplepresent or nearby and what is happening. So, for example, if Alice enters anunfamiliar building to meet Bob, she needs to know about the relevant peopleand services in that place. Bob is a relevant person since Alices goal is to meetBob. Alices friend Carol is a relevant person if Carol is nearby. A context-awaresystem might model the fact that Alice is unfamiliar with this building, that sheis meeting Bob and that she knows Carol. It may use this and other informationfrom sensors to tell Alice how to make her way to Bob and it may point outCarol is nearby.

There is considerable ubiquitous computing research directed at determininga persons location: indeed, it is arguably the most explored aspect of context-aware applications. There have also been many applications that use location

This research was part funded by the Smart Internet Technology CRC Australia.

A. LaMarca et al. (Eds.): Pervasive 2007, LNCS 4480, pp. 5572, 2007.c Springer-Verlag Berlin Heidelberg 2007


2/18

56 M. Assad et al.

information to customise their actions in some way, for example [13]. By con-trast, there has been far less work that also takes account of factors such as userattributes and preferences.

To move towards the broad vision of timely and useful information availability

and management, we need to maintain models of the significant elements of theubiquitous computing environment. First, and foremost, we need to model peo-ple. A starting point is to model a persons location. However, a rich ubiquitouscomputing future also requires models that capture other relevant informationabout people, such as their knowledge, preferences and goals. A ubiquitous com-puting application needs to make use of these models of people. It also needs tomake use of models of places, sensors, services and devices in the environment.All these models can be implicit, perhaps within the application. However, thereare real advantages in making them explicit, with existence outside any one ap-

plication: we can then use consistent mechanisms to reason about any of theseentities and to transmit information between them.

Since the model of a person is inherently personal information, an importantrequirement on the modelling is to ensure that people can maintain control ofboth what is modelled about them and how it is used. We describe modelsas scrutable, if they are designed so that a person who chooses to investigatethem can determine just what is modelled. This is a foundation for ensuringthe people will be able to control their personal information and its use in aubiquitous computing environment. We envisage that people like Alice in our

scenario should be able to ask questions like: How did the system determine mylocation? Who else can see this information about me? What does the systembelieve that I know about this building? What evidence sources can contributeto the model of my location?

PersonisAD is framework which takes account of these issues. It grows fromour earlier work on scrutable modelling of people [4] and exploration of interfacesthat can support scrutability of user models [5] even when they are large [6]. Werecognised the close relationship between the people in a ubiquitous environmentand the devices, sensors and places [4,7]. In this paper, we describe two important

advances in this work: we have enhanced Personis [4,7] to support modelling thatis both active and distributed.

In Section 2, we describe the PersonisAD architectural framework, explainingthe notions of active and distributed models. Section 3 reports our evaluation ofits power and flexibility in terms of applications built on top of it and analysis oftheir implementation. We then describe related work, and conclude by reviewingthe contributions as well as future work.

2 PersonisAD Overview

We describe the broad architecture of an application based upon the PersonisADframework in terms of Figures 1 and 2. Then we work through a detailed exampleof an application called MusicMix to illustrate how the framework serves as afoundation for building context-aware applications.


3/18

PersonisAD: Distributed, Active, Scrutable Model Framework 57

Fig. 1. Interaction between an application and a model

First consider the model representation and reasoning, as outlined at theright of Figure 1. The first core notion of the model is that it is organisedas a tree of model contexts which contain the components of the model. Thishierarchical structure serves to define namespaces and to collect the informationand associated reasoning elements.

The figure shows the general mechanism of PersonisAD is to collect evidencefor the value of the context attributes (components) and when a value for thecomponent is requested we examine the available evidence using a resolver func-tion to generate a value.

We call this mechanism accretion/resolution and it has many advantages.The value for the component is only calculated when it is required rather thancontinuously as in many systems. For an attribute such as location, where manydata sources (eg GSM, bluetooth, WiFi, GPS) may be consulted to calculate alocation value, it is a waste of resources to calculate a location whenever a newdata point is received. Only when the location value is required should the valuebe calculated.

Another major advantage is that different situations may require differentanswers for the same attribute. For example, the answer to the question Whereis Bob? may need to be a latitude/longitude for one application but anotherapplication may need a detailed symbolic value such as room/building/addresswhile another might just be given the resolved value, at work. This can becatered for by using an appropriate resolver function.

A key problem of context-aware computing is to provide the context informa-tion to an application at the time it becomes relevant. As shown in Figure 1,our system provides for the timely notification of applications when an appro-priate context is present. It does this by associating triggers or rules with com-ponents. We call components that have rules attached, active components andhence active models. A rule is evaluated when new evidence is received for the


4/18

58 M. Assad et al.

component. If the rule succeeds, it can result in evidence being added to any com-ponent or an application being notified. Chains of these rules can be used to gen-erate a sophisticated response to changes in context. The rules take the form:

value pattern : action

where value is a resolved value of a component, pattern is a regular expression.As illustrated at the lower right of Figure 1, the trigger language has two possibleactions: a tell which adds evidence to a component in any model; or a notifywhich can send information to an application.

A major part of our approach is the desire to allow users access to the modelsof them and other entities in order to explain the actions of the system. Weuse the term scrutable to indicate that the model is understandable and thatthe system can generate explanations. We have designed the whole PersonisAD

system with scrutability as a key concern and one of the design goals is todecouple the elements and to achieve simplicity since both of these are criticalfor providing explanations that the user can scrutinise to understand and controltheir personalisation in applications.

The implementation of PersonisAD [4]1, provides a small number of simpleoperations for maintaining the models. The main operations are:

access: Each entity and its associated model has a globally unique ID. Theaccess operation is used to locate the model server and connect to it.

tell: A piece of evidence (value, source, type) is added to a given model com-ponent within a given model context.ask: A value for a model context/component is returned after resolution by a

nominated resolver function.

As shown in the left part of Figure 1, the normal communication betweenapplications and the models is via the ask to request the resolved value of acomponent in the model and the tell to send new evidence to a component.

The next important part of the PersonisAD framework is the support fordistributed models as shown in Figure 2. All interaction with models is based

on the same basic operations just described in Figure 1. To support distributedmodels, these operations (and others for model management) are implementedusing a simple remote procedure call mechanism based on JavaScript ObjectNotation (JSON) with HTTP as the transport protocol. This is shown as thebroken lines from the application to the models in the figure.

The solid line in the figure indicates how PersonisAD locates the server for amodel using the multicast and wide-area Bonjour [8] (Zeroconf) service discoverysystem is used. This allows efficient discovery of model servers both on the localarea network and across the Internet. When models are created they are regis-tered locally with the multicast DNS server, and remotely on the personis.orgdomain name server. Addresses of servers are not directly tied to the name ofthe model, allowing models to be moved from one physical computer to anotherwithout the need to update any dependent models. Even the simple example

1 Personis Pty Ltd.


5/18


Fig. 2. Interaction between an application and model servers

systems described in this paper involve model servers on several machines. Weroutinely move models between machines for convenience with no change re-quired to the applications.

2.1 The MusicMix Application

We now illustrate our PersonisAD approach using one application built upon it:MusicMix is a demonstrator which plays background music, selecting the playlist

according to the music preferences of people who are detected in the listeningarea. So, for example, if Bob is alone in his living room, the MusicMix in thatroom selects music he likes. When a friend, Alice, drops in, MusicMix playsmusic from the combined set of music that they like. We use this example toillustrate how we model peoples location and make use of models of their musicpreferences to drive MusicMix.

MusicMix needs models of the people, the space and the devices involved inplaying the music and determining the current location of the people. The musicplayer needs to be notified when the context changes, that is when a person

enters or leaves the area or an existing person changes their music preferences.Figure 3 gives a simple view of parts of user models for Bob and Alice at the

time when they are both in the lounge room. The first component is location.In the figure its resolved value is loungeRoom for both users.


6/18

60 M. Assad et al.

Bob

location

- loungeRoom

seenby

- btSensor1

Devices/carrying

- bobPhonePreferences/Music/playlist

- http://media.local./bob/track01.mp3

- http://media.local./bob/track02.mp3

(a) Bobs user model

Alice

location

- loungeRoom

seenby

- btSensor1

Devices/carrying

- alicePhonePreferences/Music/playlist

- http://media.local./alice/track02.mp3

- http://media.local./alice/track03.mp3

(b) Alices user model

Fig. 3. Examples of simplified user models for Bob and Alice

The next component in Figure 3 is seenby. Its resolved value is the identi-

fier for the sensor that last detected the user. We will return to this when weexplain how a users location is determined in PersonisAD. In this case, this isbtsensor1, a Bluetooth sensor for both users.

Following this, the figure shows the resolved value for the Devices contextscomponent, called carrying which models the devices that the user has. Thishas evidence for each device the user is carrying. Its resolved value is a list of theidentifiers for the models associated with such devices. In Figure 3, both Bob andAlice are carrying their respective Bluetooth phones. To describe PersonisAD,we take the simple case where the only means to locate these users is when

their Bluetooth phones are detected. Our deployed system has other locationsensors.The remaining component in Figure 3 is for the model context for Preferences

and within it, the subcontext for Music preferences and within that the playlistcomponent whose resolved value is the list of the persons preferred music. Inthe figure, this has just two tracks, where one is common to both users.

2.2 Modelling Sensors, Devices, Places

The same accretion/resolution representation is used to model sensors, devicesand places. Figure 4 shows examples of each of these. The Bluetooth sensormodel in Figure 4(a) has a component called location which gives its location,in this case the loungeRoom. It also models the devices it has seen; each timeit detects a device, a piece of evidence is added to this component. The intuitiveinterpretation of this evidence is that recent evidence indicates which deviceswere in the place where that sensor is located.

The device model in Figure 4(b) is for the music player. It has a componentfor location and the current value for this is loungeRoom. The second component

for the player device is listeners and its value is the list of people modelledas listening to it. In the figure, this is Bob and Alice. The currentlyPlayingcomponent has the url of the music that is currently being played and, finally,the component called state indicates that it is playing.


7/18


btSensor1

location

- loungeRoom

present

- bobPhone, alicePhone

seen

- bobPhone 12:33pm

(a) Bluetooth sensor

player1

location

- loungeRoom

listeners

- Bob, Alice

currentlyPlaying

- http://media/trk01.mp3

state

- playing

(b) Audio player

Fig. 4. Examples of models for sensors and devices and places. The bullets indicateactive components.

2.3 Determining Location

We illustrate the PersonisAD approach in determining Bobs location and alsoin determining who is present in a location for the MusicMix system. We gatherevidence from many sensors to infer location but in this example we show ouruse of Bluetooth capable mobile phones. Figure 5 shows the Bluetooth Sensor,and models for the sensor, user, users phone and the lounge room.

There are three main stages in the process illustrated in the diagram. Step 1occurs when Bobs phone is detected by a Bluetooth sensor. This causes the addi-

tion of a piece ofevidence to the models for Bobs phone and for the sensor. Thistriggers Step 2, which causes the addition of evidence indicating that the phoneis in the lounge room and that there has been a change in the devices present atthis sensor. Step 3 adds evidence to the lounge room model indicating that Bob ispresent and to Bobs model indicating he is in the lounge room. We now go throughthis in more detail to illustrate how the PersonisAD approach operates.

Bobs phone, with model bobPhone, is detected by the sensor with modelbtSensor1. The sensor program places evidence into the seen component of thesensor model (btSensor1 in Fig. 5) and the seenby component of the phone

model (bobPhone in Fig. 5) using two tell operations. This is Step 1 in the figure.Both of these components have a rule attached to them, indicated by bullets

next to them.Whenanewpieceofevidence is delivered to the seenby componentthe attached

rule is interpreted. The resolved value of the seenby component is matched with aregular expression that always returns True (since in this case we want to updatethe location when a new piece ofevidence arrives). The action in the rule adds apiece ofevidence containing the location of the sensor to the location componentof the device that had been sensed, in this case the phone of the user.

The action of this rule is labelled 2b in the figure. The solid line represents thetell occurring, and the dotted line shows where another model has been accessedduring evaluation of the rule. For example, in this case, the value of the sensorslocation component is needed to create the evidence indicating that the phone isin the location with model loungeRoom. Expressions within a rule can be nested:in this example one ask is evaluated to form the model id for another ask.


8/18

62 M. Assad et al.

Fig. 5. Updating a users location and the people present in a place: Bluetooth sensorand models for bob, bobPhone, btSensor1 and the room. Solid lines represent tells,with the dashed lines showing the additional models accessed while evaluating therules.

Similarly, there is a rule attached to the location component of the phoneand this has the effect of telling the location of the phone to the model of theperson carrying the phone. This is labelled 3b in the figure.

There is also a rule on the seen component in btSensor1 model. Labelled2a, this causes the recent seen items to be examined to create a list of presentdevices. It only triggers when the resolved value of this component changes. So,although evidence is continuously added to this sensor component, the rule onlyadds evidence to the present component when a new device is detected.

This in turn causes the rule attached to the present component of the modelbtSensor1 to be evaluated. This step is 3a in the figure, and it tells the peoplecomponent of the loungeRoom model who is now present based on the devicesdetected. A similar process has to operate as phones leave an area.

The rules and actions on components of models for sensors, devices, places andpeople provide location information for applications. The system is not limitedto location: it can notify applications when the context changes in any way. Forexample, if a user indicates a change their music preferences a simple activecomponent rule can notify the music player.

3 Evaluation

Since the goal of PersonisAD is to provide a framework for creating new ubiqui-tous applications, we have been evaluating it by using it to create the applications


9/18


that we describe in this section. We first describe the actual applications. Thenwe provide some analysis of the implementation using PersonisAD. This gives anindication of the power and flexibility offered by the PersonisAD framework interms of the amount of effort required to build a new application. In addition to

this, the use of a consistent framework means that we can reuse active models:we illustrate this in the reuse of the first application, which models location, inthe other two applications.

3.1 Location

This basic demonstrator application can help people finding others within ourbuilding. Using the location information, built from evidence collected from thesensors, a live image is generated and displayed on a webpage. Figure 6(a) shows

a detailed display for just one wing of the building at the left. On the right, inFigure 6(b), is the full display for four floors. Each persons location is indicatedby a coloured dot on the map at the place they were last seen. The key forthese is shown at left of Figure 6(b) (anonymised for this paper). The age of thisinformation is indicated by size of the dot on the map. So a person who has notbeen detected for some time has a smaller dot on the map. Each persons modelis asked for that persons current location with a resolver that returns both thelocation and the timestamp indicating when that was last updated. This is usedto provide the input to the map display. People have to subscribe to this service

for their sensor evidence to be used. Users can control which resolver is used andso control the information available to this application.

The raw sensor data comes from two types of sensors; Bluetooth sensors de-tect Bluetooth devices within range, System activity sensors detect mouse andkeyboard activity on a terminal. The Bluetooth activity sensors tell four kindsof evidence messages: on initial detection of a device a Found message is sent;

(a) Detailed view of a single wing (b) Screenshot of the web interface

Fig. 6. An example of a map that plots the location data collected by the ActiveModelson a floorplan of our building. The radius of the circles are proportional to currency ofthe data, with smaller circles indicating older data.


10/18

64 M. Assad et al.

every 5 minutes a Present is sent for each device in range; and a Lost mes-sage is sent when a device moves out of range. When no devices are in rangea Heartbeat message is sent every 5 minutes to inform the system that thesensor is still alive. System activity sensors work in a similar way when detecting

activity of users.

3.2 MusicMix

As described in Section 2.1, MusicMix is a demonstrator application that playsbackground music, generating the playlists based on who is currently in thegeneral area. The application uses the location information provided by the pre-existing models, and combines this with user preferences expressed in terms ofthe individuals playlists. There is an additional model for the player, represent-

ing the physical speaker in the room where the music is to be played.The player model stores the list of the people who are nearby, the current track

being played, and the status of that track. This is the core information neededto support this application. A rule is used to update the player model withthe list of listeners. Whenever the list of people changes, the playlist manageris automatically made aware via a notify rule. It is then able to generate anew playlist by asking the user models for their preferences. A track is selectedand told to the Speaker model. The Speaker Manager application controls theplaying of music tracks: it is made aware of the current track by its own notify

rule. When the track finishes playing, the model is updated again, causing theplaylist manager to select a new track and the process repeats. It should benoted that there is no direct communication between these two applications. Alltheir actions are a direct result of updates to the models: this ensures completedecoupling of application components. (For more technical details please see [9].)

3.3 MyPlace

MyPlace presents people with personalised information about a place. It builds

models of the people so that it can reason about their knowledge of a place, theirlearning needs about it, their preferences for information delivery as well as theirlocation. So, for example, when Alice first visits Bob at his workplace, MyPlaceneeds to give her relevant and timely information about Bobs location. If wesuppose that her friend Carol is also nearby, MyPlace should tell her so. Sincethis papers focus is the PersonisAD support for building applications, we give

just a brief outline of MyPlace.For example, the screenshots in Figure 7 illustrate the different information

that MyPlace would present Alice and Bob. At the top of the screen is an infor-

mation bar. She has selected her status as In transit, where Bob has selectedAvailable. This provides evidence to the user models. Next to the users se-lected status is the location as modelled by the system: Alice is in the Foyerand Bob is in 324, which is his office. The details link provides an expla-nation of how the system models location. The bulk of the display shows items


11/18


modelled as relevant to the user. These are grouped into expandable headings ofDevices at this location, Nearby Devices, Nearby Places, Services/Events, andPeople. If a category contains no items, the heading is not shown.

As a visitor to the building, Alices information needs and therefore user model

are very simple. The stereotype for a visitor states that they are interested inthe devices of the Foyer Noticeboard (for general information) and the Infor-mation Kiosk (for contacting their host on arrival). Thus when Alice is locatedin the Foyer these items are shown in the Devices at this location category.Bobs user model indicates he wants to know about any sensors which maydetect him. Accordingly, the Devices at this location category contains theBluetooth sensor in his office, the system activity sensor in his office, details ofthe airconditioning systems control panel. Alice is shown the location of Bobsoffice in the Nearby Places category. For Bob, the Nearby Places category

is empty and not shown, as he has worked at this location for some time, andthus already knows all the nearby places modelled to be of interest to him. Inthe People category, Alice is shown the location and status of Bob, as he isher host, and Carol, because the system models her as knowing Carol. BobsPeople category contains details of Alice as he has a meeting scheduled withher, and David and Fred, two of his colleagues with whom he is working closelyon a project. At the bottom of both Alices and Bobs displays is a show allitems link which allows them to see all the items which the system has chosennot to show them.

(a) Alice (b) Bob

Fig. 7. Two user views in the MyPlace system, left (a) shows a view for Alice, a Visitor,and right (b) shows a view for Bob, her host

3.4 Analysis of Applications Built with PersonisAD

We now analyse the development of applications that have been built with Per-sonisAD. By looking at the amount of evidence we have collected, the modelsthat have been created, the rules required and the code that has been writtento build them, we show the power, flexibility and utility of the architecture.


12/18

66 M. Assad et al.

Evidence. We have been collecting data for location modelling for 17 months.There are a total of 3,706,237 items of raw sensor data from Bluetooth and systemactivity sensors. Users must register themselves and their Bluetooth devices beforetheir models are built. There are 21 registered users, 23 registered mobile Bluetooth

devices and 22 system activity sensors. There are 12 fixed Bluetooth sensors placedin key locations around the building. Some users have only one system sensor as-sociated with them, while others each have two Bluetooth devices (a phone and alaptop) and system activity sensors running on multiple machines (work desktop,home desktop, laptop, and another communal machine).

Table 1 shows a summary of one months data for four users with diverseevidence sources. The Active column shows the number of data items indicatingactivity on that system. The Heartbeat column has the number of items showingthat no activity has been detected on a mobile system. These messages have been

omitted for system activity sensors whose location is fixed. The columns R1,R2... R12 are Bluetooth sensors around the office building.

Table 1. A summary of one month of location data for four users with diverse evidencesources

User Device Active Heartbeat R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12

Person 1 phone 79 196 33 491 913 64 2 395 256 15 763(academic) laptop 615 117

Desktop 832

Person 2 phone 14 766 55 11 1446 74 85 10(postgraduate) laptop 857 439Person 3 laptop 449 22(postgraduate) phone 2 94 52 1296 1759 471 231 1032 235 71 9 209

desktop 1257Person 4 mobile 10 214 18 541 677 63 55 2071 282 2 111 220

Location Models. In order to provide location data from the raw sensordata, models are required to represent the sensors, users, devices, and locations.Table 2 gives the number of models of each type in the system. In addition the

number of components per model is shown. This indicates the amount of datarequired per model. Finally the number of subscriptions per model shows thecomplexity of the interactions between models and components. The low numberof components per model shows the lack of complexity required to model theseitems using PersonisAD.

Table 2. Number of models, components and subscriptions used in modelling location

Type Models Components per model Subscriptions per model

People 21 5 -Places 66 4 1Devices 23 5 3Bluetooth Sensors 12 4 2System Sensors 22 5 2


13/18


Application Development. This requires writing a number of simple rulesthat link the models together and to external applications. The MusicMix ap-plication required 4 rules to operate. This section describes one of those rules indetail to illustrate the character of the work involved in building systems based

on PersonisAD.

player1:currentlyPlaying

~ ".*" :

NOTIFY http://player:2001/playSong?song=

Fig. 8. The code for the currentlyPlaying component of the player1 model. Whenthe currentlyPlaying component is changed, the notify rule alerts the Speaker Man-ager via the HTTP request, which begins playing the new track.

The rule shown in Figure 8 notifies the Speaker Manager of the address ofthe current music track to play. The player1:currentlyPlaying line showsthat we are adding this subscription to the currentlyPlaying componentof the player1 model. This means that the rule will be examined whenevernew evidence is told to this component. To decide if the rule should be firedthe value will be examined. The match performed isa regular expression, as indicated by the symbol. The expression matchedis ".*", which matches all possible values. In this case the rule will always

fire, performing the action NOTIFY http://player:2001/playSong?song=. This action makes a HTTP GET request with the givenURL and appends the current value of ./currentlyPlaying. The ./ indicatesthat the value comes from the current model. By inserting a model name here,a value could come from any local or remote model.

The simple rule language allows great flexibility in responding to new evidencein the models. Any change on any model can trigger a rule, and the rule canbe triggered conditionally depending on the matching operator. When a rule istriggered, any information that can be obtained from the models can be passed

to an application by varying the notify URL.

Code Effort. By keeping the management of the data within the models, andby describing the relationship between the models with the rules, the specificapplication code that needs to be written is very short. The MusicMix applicationrequired two small Python scripts to run: the Playlist Manager and the SpeakerManager. The Playlist Manager was the longer of the two being 95 lines, theSpeaker Manager only 79 lines. Adding location support to the player modelsrequired adding a single rule. This means that simple applications can be built

simply without limiting the complexity of larger systems.The code for updating the location models based on sensor data is also quite

simple. It consists of a small number of special resolver functions, and a shortpython script to do tells whenever sensor data evidence is received. The archi-tecture allows us to make the location modelling more intelligent by changingthe resolver functions.


14/18

68 M. Assad et al.

4 Related Work

A major contribution of our work is a generalised framework to simplify thecreation of ubiquitous computing applications. There are many existing systems

that already do this, but our PersonisAD provides a unique approach, by storingdata within consistent models associated with people, places, devices and sensors,allowing applications to access these as required. Unlike other systems whereapplications are developed by combining application level building blocks, wefocus on the storage of information about the entities within the environment,and the links between these entities. We review a selection of other systems toillustrate how they differ from PersonisAD; an exhaustive review is beyond thescope of this paper.

The work by Schilit et. al. [10] describes a system that reacts and changes to an

individuals changing context. They have developed context triggered services byfollowing a sequence of IF-THEN rules to decide how applications should adapt.By contrast, the main focus of our work is the modelling of the environment: thefunctionality of our rules is encapsulated by attaching notify rules to componentswhich respond to changing context.

The Context Toolkit [11] allows applications to be built using a variety ofinput and output widgets, which encapsulate common programming tasks. Anapplication controls how the input events map to the output actions. Metaglue[12] provides infrastructure support to embed controlling applications, or agents,

within a wider scale pervasive environment. By contrast, PersonisAD has noconcept of a controlling application. The information is stored within the modelsembedded in the environment and individual applications query this informationto provide services to the user.

The Event Heap [13] is a tuple-based communication message architecturewhich has been extended to a distributed environment [14]. Applications filterthe aggregated data based on subscription-like data requests, as opposed toPersonisAD where this filtering is a combination of the application and themodels.

Another method of providing general ubiquitous computing services is Ac-tivity Zones [15], where location is mapped into a particular geographic zone.Certain rule-based actions are performed based upon the zone they are in. It issimilar to our system in that actions are performed by following rules as evidencearrives, but PersonisAD is able to respond to more than location information.

Liquid [16] provides a framework for persistent queries where results are drawncontinuously from both local and remote sources as events take place. This differsfrom PersonisAD in the way that queries are dynamically processed when a clientapplication makes a request: the PersonisAD rule set results in the models being

constantly kept up to date as new information is provided.An important feature of the PersonisAD approach is that it builds upon the

homogenous modelling of all the entities relevant to supporting ubiquitous ap-plications [7]. Moreover, the underlying accretion/resolution representation sup-ports flexible interpretation of a range of heterogenous sources of evidence about


15/18


the user [17]. This distinguishes the work from the many systems [18] that modellocation using a single class of evidence, such as ultrasonic beacons [19,20], GSMMobile phone networks [21], WiFi beacons [22,23] and Bluetooth sensors [23,24].Each of these produce location evidence at different resolutions and reliability.

Our work has unusual origins for ubiquitous computing research in that Per-sonisAD grows from work on user modelling and personalisation [4,7]. This hasinfluenced the philosophical underpinnings of the design of the accretion / res-olution approach, which models people by collecting evidence about aspects ofthem, in the components of the model. The sources and nature of the evidenceare important and play a role in the interpretation of the evidence by resolvers.Importantly, since user models are essentially repositories of personal informa-tion, the accretion/resolution approach supports scrutability, a notion that hasalso been explored by Cheverst et al [25]. The importance of user control, and

the closely associated issues of privacy, have been recognised in ubiquitous com-puting from its earliest days as well as more recently [26]. One part of this isproviding people with the right amount of information about the invisible sensorsand services in the environment. Another important part is to provide the userwith support to drill down into that information, to scrutinise the details of justwhat information or knowledge is held in the ubiquitous computing environmentand how it is used.

5 Conclusions and Contributions

We have described PersonisAD, a framework for distributed, active, scrutablemodels as a foundation for building context-aware applications. We have ex-plained how it has enabled us to quickly create a set of such applications. Wehave illustrated how the elements of the accretion/resolution approach, extendedwith active components provides a powerful, flexible framework for supportingubiquitous computing applications. The foundation of the approach is the ac-cretion of evidence from arbitrary sources into the components of the models.

These are structured into an hierarchy ofmodel-contexts

. The access to informa-tion about entities in PersonisAD is controlled at the level of the model-context,the evidence source and type and by the resolver functions which are selectivelyavailable to different applications. This enables different levels of granularity ofvalues to be returned for any component.

The current system operates with models distributed across different ma-chines, but any one entitys model is on a single machine. So, for example oneusers model is entirely on one machine. Future work will move towards dis-tribution of partial models, especially for user models [27] so that subsets of

the user models and some contexts within the model are located on differentmachines. Another future enhancement will support disconnected operation sothat information flows, such as described in Section 2, can be supported evenwhen parts of the system are temporarily disconnected. We are also conducting


16/18

70 M. Assad et al.

experiments to assess several of the dimensions of scalability, similar to testingthe basic accretion/resolution implementation in Personis [7]. A different orderof future work involves the interface design challenge of supporting scrutabilityin a ubiquitous environment. This can build from work on scrutably adaptive

hypertext [28] as well as Cheverst et al [25].The main contribution of PersonisAD is as a framework for context aware

computing, supporting personalised ubiquitous services, integrating the collec-tion of diverse types of evidence about the ubiquitous computing environment,interpreting it flexibly. In this paper, we have focussed on the distributed andactive nature of the models.

The addition of triggers to the models is an important innovation. In contrastto our earlier work with passive models, where the application was responsible forall the control, PersonisAD makes it easier to build context aware applications.

Essentially, this is because it decouples the systems more effectively. Of course, atone level, the notion of triggers is not new, since this class of mechanism has beenpart of many systems, such as the many rule-based systems, from the very earlyubiquitous computing frameworks [10] and including general operating systemsand Active Databases Systems [29]. The important contribution of our work isthat the user model representation and reasoning, with its design for scrutability,has been generalised to modelling the other elements, sensors, devices, servicesand places.

It is this consistent and generalised representation of the context data that

has made it feasible to use a simple mechanism to achieve distributed models.This is an important contribution as it means that the models can be kept in theplaces that make sense for various pragmatic reasons such as user control. ThePersonisAD architecture is based upon a small set of operations for applicationsto interact with the models: access, ask and tell. The service discovery facilitatesdistributing the models across various machines across a network. The appli-cation writer can simply use these, in conjunction with the active models, tobuild applications. The service discovery for the models of a PersonisAD-basedsystem ensures that different models can be dispersed across arbitrary machines

in a network, without burdening the application builder. We have demonstratedthe use of the PersonisAD framework by building the applications described inthis paper. The analysis of this process indicates that the PersonisAD frameworkmakes for low implementation cost with carefully decoupled elements. This is dueto the consistent, simple, flexible and powerful representation of models for eachof the elements in a context aware environment. The representation was initiallymotivated by the goal of building user models that can support scrutability ofthe modelling and personalisation processes. The accretion/resolution represen-tation also supports flexible control of access to the models and the interpretation

of uncertain and noisy evidence. PersonisAD uses this same representation forall the elements in the context-aware environment. This, combined with its care-fully designed, simple but powerful rule language that is specific to the models,and transparent support for distribution of the models, provides a new way tothink about and build context-aware applications.


17/18


References

1. Lamming, M., Flynn, M.: Forget-me-not: intimate computing in support of humanmemory. In: FRIEND21 Symposium on Next Generation Human Interfaces. (1994)

2. Dey, A.K., Abowd, G.D.: Cybreminder: A context-aware system for supportingreminders. In: Intl. Symposium on Handdeld and Ubiquitous Computing. (2000)172186

3. Beigl, M.: MemoClip: A Location-Based Remembrance Appliance. Personal Tech-nologies 4(4) (2000) 230233

4. Kay, J., Kummerfeld, B., Lauder, P.: Personis: A server for user models. In: AH.(2002) 203212

5. Kay, J.: A scrutable user modelling shell for user-adapted interaction. PhD thesis,Basser Department of Computer Science, University of Sydney (1999)

6. Kay, J., Lum, A., Uther, J.: How can users edit and control their models in

ubiquitous computing environments? In Cheverst, K., Carolis, N.d., Kruger, A.,eds.: Workshop on User Modeling in Ubiquitous Computing, 9th InternationalConference on User Modeling, Johnstown, USA (2003)

7. Carmichael, D., Kay, J., Kummerfeld, R.: Consistent modeling of users, devicesand environments in a ubiquitous computing environment. User Modeling andUser-Adapted Interaction 15 (2005) 197234

8. Cheshire S., K.M.: DNS-based service discovery (2005)

9. Assad, M., Carmichael, D.J., Kay, J., Kummerfeld, B.: Active models for context-aware services. Technical Report TR 594, The School of IT, The University ofSydney, Australia (2006)

10. Schilit, B., Adams, N., Want, R.: Context-aware computing applications. In: IEEEWorkshop on Mobile Computing Systems and Applications, Santa Cruz, CA, US(1994)

11. Dey, A.: Providing Architectural Support for Building Context-Aware Applica-tions. PhD thesis (2000)

12. Coen, M., Phillips, B., Warshawsky, N., Weisman, L., Peters, S., Finin, P.: Meetingthe computational needs of intelligent environments: The metaglue system. In:Proceedings of MANSE99, Dublin, Ireland (1999)

13. Johanson, B., Fox, A.: The event heap: A coordination infrastructure for interactive

workspaces. In: WMCSA, IEEE Computer Society (2002) 839314. Storz, O., Friday, A., Davies, N.: Supporting ordering and consistency in a dis-

tributed event heap for ubiquitous computing. In: Second Workshop on SystemSupport for Ubiquitous Computing Workshop (Ubisys 2004) in association withSixth International Conference on Ubiquitous Computing (online proceedings),Nottingham, England (2004)

15. Koile, K., Tollmar, K., Demirdjian, D., Shrobe, H.E., Darrell, T.: Activity zonesfor context-aware computing. [30] 90106

16. Heer, J., Newberger, A., Beckmann, C., Hong, J.I.: liquid: Context-Aware Distrib-uted Queries. [30] 140148

17. Kay, J.: The um toolkit for cooperative user modelling. User Modeling and User-Adapted Interaction 4 (1995) 149196.

18. Hightower, J., Borriello, G.: A survey and taxonomy of location systems for ubiq-uitous computing. Extended paper from Computer 34(8) (2001) 5766

19. Harter, A., Hopper, A., Steggles, P., Ward, A., Webster, P.: The anatomy of acontext-aware application. In: Mobile Computing and Networking. (1999) 5968


18/18

72 M. Assad et al.

20. Minami, M., Fukuju, Y., Hirasawa, K., Yokoyama, S., Mizumachi, M., Morikawa,H., Aoyama, T.: Dolphin: A practical approach for implementing a fully distributedindoor ultrasonic positioning system. In Davies, N., Mynatt, E.D., Siio, I., eds.:Ubicomp. Volume 3205 of Lecture Notes in Computer Science., Springer (2004)347365

21. Otsason, V., Varshavsky, A., LaMarca, A., de Lara, E.: Accurate GSM IndoorLocalization. [31] 141158

22. LaMarca, A., Hightower, J., Smith, I.E., Consolvo, S.: Self-mapping in 802.11location systems. [31] 87104

23. Hightower, J., Consolvo, S., LaMarca, A., Smith, I.E., Hughes, J.: Learning andrecognizing the places we go. [31] 159176

24. Madhavapeddy, A., Tse, A.: A study of bluetooth propagation using accurateindoor location mapping. [31] 105122

25. Cheverst, K., Byun, H.E., Fitton, D., Sas, C., Kray, C., Villar, N.: Exploring

issues of user model transparency and proactive behaviour in an office environmentcontrol system. User Modeling and User-Adapted Interaction 15(3-4) (2005) 235273

26. Rehman, K., Stajano, F., Coulouris, G.: Visually interactive location-aware com-puting. [31] 177194

27. Brar, A., Kay, D.J.: Privacy and security in ubiquitous personalized applications.Technical report, The School of IT, The University of Sydney, Australia (2004)

28. Czarkowski, M., Kay, J.: Giving learners a real sense of control over adaptivity,even if they are not quite ready for it yet. In: Advances In Web-Based Education.Information Science Publishing (2006) 93126

29. Paton, N.W., Daz, O.: Active database systems. ACM Computing Surveys 31(1)(1999) 63103

30. Dey, A.K., Schmidt, A., McCarthy, J.F., eds.: UbiComp 2003: Ubiquitous Com-puting, 5th International Conference, Seattle, WA, USA, October 12-15, 2003,Proceedings. In Dey, A.K., Schmidt, A., McCarthy, J.F., eds.: Ubicomp. Volume2864 of Lecture Notes in Computer Science., Springer (2003)

31. Beigl, M., Intille, S.S., Rekimoto, J., Tokuda, H., eds.: UbiComp 2005: UbiquitousComputing, 7th International Conference, UbiComp 2005, Tokyo, Japan, Septem-ber 11-14, 2005, Proceedings. In Beigl, M., Intille, S.S., Rekimoto, J., Tokuda,H., eds.: Ubicomp. Volume 3660 of Lecture Notes in Computer Science., Springer

(2005)

person is ad

Documents