Integrated Profile and Policy Management for Mobile-oriented Internet Services

Integrated Profile and Policy Management for

Mobile-oriented Internet Services

Technical Report Firb-Web-Minds N. TR-WEBMINDS-04

Alessandra Agostini†, Claudio Bettini†, Nicolo Cesa-Bianchi‡,Dario Maggiorini†, Daniele Riboni†

†Dipartimento di Informatica e Comunicazione‡Dipartimento di Tecnologie dell’Informazione

Universita di Milano, Milan, Italyemail:{agostini, bettini, dario, riboni}@dico.unimi.it, [email protected]

Abstract

In this paper we present a novel framework for a comprehensive adaptation andpersonalization of Internet based services in a mobile environment. The framework isbased on a notion of profile data that goes beyond the representation of user personaldata and preferences by including information on the device, its current status, thenetwork infrastructure, the location, the current context and the content involved inthe service request. The framework offers tools to integrate profile data when providedby different sources, solving possible conflicts. It also allows users and service providersto specify adaptation policies in the form of rules on profile attributes that are receivedand evaluated by a common inference engine. Profile data obtained via this integrationprocess are used by the service provider to properly personalize its responses.

1 Introduction

Internet services rely on profile data for delivering personalized content to users. Profilesprovide a description of the user interacting with the service, where the basic entities in thisdescription are pairs of attributes and values. For example, some of the attributes mightspecify user preferences about the format of the content to be delivered. Ideally, a profileshould include all attributes useful to improve the outcome of the personalization process.

Mobile users are typically described by more attributes than those needed by othercategories of users. Besides personal preferences, a profile should include descriptions of thedevice, of the network infrastructure, of the user location, and possibly of the context inwhich the user is involved. In practice, these attributes are managed by different entities —such as the service provider, the network operator, or the user itself — and so, at present,service providers can provide limited personalization since they are unable to collect all at-tributes relevant for adapting their services. The complete profile should be easily assembledupon each user request by querying the involved entities and by resolving all conflicts in theassignments of values for those attributes managed by more than one entity.

Mobility also emphasizes the need for modeling the dynamics of some of the profileattributes. For example, changes in the supported bandwidth (due, e.g., to a switch toa different mobile device) should correspond to a change in the value of the attributes

1

specifying the desired bitrate for streaming video services. The same need might also occurwith attributes related to user preferences. For example, when the format of messages beingreceived (say, text or voice) is specified depending on the mobile device being used.

A natural approach to the modeling of this dynamics is augmenting the profile attributeswith policies; that is, rules that set or change certain profile attributes based on the currentvalues of other profile attributes. However, the introduction of policies makes it possibleto have, once more, conflicting attribute values. For this reason, the policy evaluationmechanism should also include a conflict resolution technique.

Content adaptation in internet services has been a hot topic for a long time, and severalapproaches have been proposed that take some of the above issues into account. On the onehand, Customer Relationship Management (CRM) systems create and maintain user profilesalso by analyzing logs tracing the user behavior. On the other hand, different technologieshave been developed to enable the personalization of the service with respect to the useragent and the network infrastructure from which the request has been issued.

An important personalization technology for mobile devices is Composite Capabili-ties/Preference Profiles (CC/PP) [Klyne et al., 2003], an RDF/XML-based formalism torepresent device capabilities and user preferences that has been proposed by a W3C work-ing group. UAProf [WAP Forum, 2000] is the most known CC/PP-compliant specificationvocabulary for WAP phones capabilities (see Appendix A for an excerpt of the UAProf vo-cabulary), and UAProf specifications of many phones can be found online (Appendix D showsthe UAProf specification of a cell phone). However, these formalisms do not specify protocolsto exchange the profile data, nor an architecture for managing these data and the dynamicpolicies that may be defined on them. General architectures for managing profile data andperforming adaptation have been proposed in [Efstratiou et al., 2001, Wu and Chao, 2001,Riche and Brebner, 2003] and will be briefly described in Section 5. However, in our opinion,none of them addresses in a satisfactory way all the issues described above.

In this paper we propose a new architecture enabling an integrated representation andhandling of profile information, including user, device, network, and context descriptions aswell as a mechanism to resolve conflicts in static and dynamic descriptions. In particular,our approach is focused on the representation and management of distributed profile dataand on the representation and evaluation of policies to dynamically change these data. Thedistinctive features of our approach are: (i) a notion of “profile data” that goes beyondthe representation of user personal data and preferences by including information on thedevice, its current status, the network infrastructure, the current context and the contentinvolved in the service request; (ii) a formalism to represent user and service provider policiesdescribing the dynamics of profile data; (iii) a mechanism to retrieve and compose profiledata and policies from different sources; (iv) an efficiently implementable strategy to resolveconflicts on policies and profile attributes.

The rest of the paper is structured as follows: In Section 2 we give an overall presentationof the architecture illustrating the role of the main modules. In Section 3 we address theissue of profile data representation, management and integration. In Section 4 we discusspolicy representation and policy evaluation strategies. Section 5 reports on related work.Section 6 concludes the paper.

2 Architecture

In principle, profile data should include any information useful for offering a “better” re-sponse to a request; i.e., the information characterizing the user, the device, the networkinfrastructure, the context and the content involved in a service request. However, as men-tioned in the introduction, these pieces of information are owned by various entities located

2

OPERATOR1 1

3

USER

POLICIES PROFILE

INTERNET SERVER

LOGS CONTENT

APPLICATION LOGICCRM

6

7 7

UPM

IE MERGE

23

4

5

PROFILE POLICIES

OPM

SPPM

PROVIDERSERVICE

Figure 1: Information Flow upon User Request

in different logical and physical places. For example, information about the network is ownedby network operators, while information regarding the battery power is owned by the userdevice. We thus identify three main entities involved in the task of building an integratedprofile: the user, the network operator, and the service provider. Our architecture is appli-cable to a scenario where a set of service providers interact with a set of users, and eachuser may use different devices to request the same services.

Since profile information is generally subject to privacy restrictions — e.g., the userdoes not want untrusted entities to gain access to personal data — in our framework profilemanagement is distributed among three specific profile manager modules, each associatedwith one of the three entities involved in the task. Service providers willing to retrieve thecomplete profile must thus query all the relevant profile managers.

In the rest of this section, we describe the architecture and the functionality of itscomponents.

2.1 Overview

Figure 1 provides a general overview of the proposed architecture. The main modules are theInference Engine, identified by IE, and the profile managers, identified by UPM (User ProfileManager), OPM (Operator Profile Manager), and SPPM (Service Provider Profile Manager).A high-level description of the system behavior is more easily illustrated by mentioning themain steps involved in a typical service request.

1. A user, through his device and the connectivity offered by a network operator, issuesa request to a service provider.

2. The service provider asks its SPPM module to obtain the profile information needed tohandle the request.

3. The SPPM module queries the UPM and the OPM to retrieve remote profiles and policies.

4. The SPPM then handles collected data and local profile data to the IE module whichis in charge of their integration.

5. The IE first merges profile data using priorities to decide among different values forthe same attribute specified by different entities, then evaluates service provider and

3

user policies against the merged profile data, possibly resolving conflicts. The resultingprofile attributes are then returned to the Service Provider.

6. These attribute values are used by the application logic to properly select content andcustomize its presentation.

7. Finally, the formatted content is sent to the user.

In Figure 1, a dashed line from an entity to a profile manager indicates that the entityhas the ability to update the profile data and policies stored by that profile manager. Inparticular:

• the user inserts and updates its private information and policies that are stored at theUPM,

• the network operator inserts and updates data regarding network parameters andconditions that are stored at the OPM,

• the service provider inserts and updates user-related information and internal policiesthat are stored at the SPPM.

As mentioned earlier, profile and policy repositories are distributed mainly based onprivacy concerns, but also taking into account system performances. On the one hand, eachinvolved entity may want to store locally certain pieces of information (e.g., credit cardnumbers or billing details). On the other hand, a centralized approach implies a single pointof failure as well as a performance bottleneck. In fact, each repository should be located asclose as possible to its main user, or at least to the entity in charge of updating the storedinformation. Low update latency is preferable in order to keep the profiles up to date.

The IE (Inference Engine) module needs to be a single entity inside our architecture,but we decided to decouple it from the service provider infrastructure. This because itmight be a service provided by a third party, and it is meant to be application-independent.Thus, multiple service providers may use the same IE and customize their behavior usingthe application logic. Policies managed by a IE can also be shared among service providers.For example, a chat service may be offered by a set of providers under a common set ofpolicies. Indeed, the architecture can be mapped to several business models:

• the operator may offer a trusted UPM service to its customers;

• powerful and always-online devices may be offered with their own UPM service on board;

• operator and service provider may be the same business entity;

• service providers offering a common subset of services may share SPPM and IE;

• a fourth entity may run SPPM and IE services.

The architecture may be also easily extended by introducing other profile managers (e.g.,profile managers owning context services) and by extending the per-user UPM model to apeer-to-peer network of UPM modules. Despite the architecture does not explicitly take intoaccount intermediaries in the form of client proxies or transcoding proxies, these elementscan be easily taken care of with little or no modification to the proposed software modules.

In the following sections we first discuss in more detail the profile manager modulesof our architecture and, successively, we concentrate on the management of intra-sessionchanges of profile attributes.

4

2.2 User Profile Manager

The User Profile Manager (UPM in Figure 1) is responsible for managing attributes providedby the user, where the values of these attributes are retrieved from the device of the user orpossibly deduced by analyzing the user behavior (see the Semantic Profile Assistant at theend of this subsection). These data are stored at user side and include, among other things,personal information, interests, and device capabilities. User-related information also

ACLupdates updates

personal data

UPM

USER SPA

POLICIES PROFILE

Figure 2: User Profile Manager Architecture

includes any policies the user may define with respect to the content and the presentationhe wants to receive under particular conditions. For example, during a chat session the usermay prefer to receive speech messages when using his cell phone, and text messages whenusing his PDA.

Since users may not want to grant unlimited access to their complete profile, an AccessControl List (ACL in Figure 2) is set on the UPM to specify who can access which profile data.Access control also applies to user policies in order to make them accessible by trustedservice providers only.

An agent called Semantic Profile Assistant (SPA in Figure 2) is included in our frame-work as an optional component that analyzes user-provided data (such as bookmarks, con-tacts, and logs) with the purpose of suggesting new user policies and default values forcertain attributes. We do not view the SPA as part of a CRM service because it is controlledby the user and not by the service provider.

2.3 Operator Profile Manager

The Operator Profile Manager (OPM in Figure 1) is responsible for managing attributesdescribing the user in the network context (e.g., location, connection profile, and networkstatistics). A service provider may take this information into account to change the contentand/or its presentation. For example, if the user is looking for a restaurant while traveling,his current position should be available in order to select nearby restaurants only.

ACL

PROFILE OPERATOR OPM

updates

Figure 3: Operator Profile Manager Architecture

2.4 Service Provider Profile Manager

The Service Provider Profile Manager (SPPM in Figure 1) is responsible for managing serviceprovider proprietary data that are not intended to be shared with other entities due to

5

privacy (e.g., billing data and credit card number) or business reasons (e.g., user behaviorinformation).

updates

user behaviour

updates

SPPM SERVICEPROVIDER

PROFILE

CRM

Figure 4: Service Provider Profile Manager Architecture

As shown in Figure 4, the SPPM not only receives requests for the update of profileattributes and policy rules from the service provider, but can also receive requests for theupdate of profile attributes from the service provider CRM system. Indeed, CRM rules,usually based on the analysis of users historical behavior, can modify the value of someuser profile attribute handled by the SPPM. Consider the case of an online computer shop.Analyzing the web pages browsed by a user, the CRM can infer that he is especially interestedin laser printers and cellular phones. This information will be useful, for example, whenadvertising to that specific user. The profile attribute storing product interests for that usershould be updated with this information.

2.5 Handling intra-session changes

The dynamic nature of some profile attribute values claims for a mechanism for keepingup-to-date the profile information used by the service provider during a session. Considerthe case of user profile data; while some attributes do not change during a session (e.g.,the user personal data), other information may change depending on device status (e.g.,available memory), user interaction with the device or application (e.g., turning on or off afeature), and user behavior (e.g., change of location). Data owned by the network operatorare, possibly, even more unstable. The service provider should be aware of data changesduring a session in order to adapt the service to the new context. Different mechanisms

USER DEVICE

PROXY

UPM

INTERFACE

MONITOR

TRIGGERS

APPLICATION

LOGIC

SPPM

OPERATOR

OPM

TRIGGERS

UPM

TRIGGERS

r e q u e s t r e q u e s t

UPM triggers; OPM triggers

p r o f i l e u p d a t e s

O P M t r i g g e r s

U P M t r i g g e r s



U P M t r i g g e r s

Figure 5: Trigger mechanism

6

can be adopted to fulfill this requirement, with the usual approaches being either based onpolling techniques or on triggers. Polling, especially when involving properties of the userdevice, poses problems of cost and bandwidth consumption. Our choice is to include in ourarchitecture a trigger mechanism (see Figure 5). Triggers are used to enable asynchronousfeedback on specific events (e.g., available bandwidth dropping below a certain threshold,user location changed by more than 100 metres). Triggers can be defined over attributesmanaged by UPM and OPM. When a trigger fires, the corresponding profile manager sends thenew values of the modified attributes to the SPPM module, which should then re-evaluate theprofile attributes. Referring to the steps of a typical service request illustrated in Section 2.1,this is equivalent to restarting the process from Step 2. Of course, various optimizationsare possible to avoid re-computing those values that are completely independent from thechanged attributes.

To ensure that only useful update information are sent to the content provider, a deepknowledge of the service characteristics and requirements is needed. As a consequence,the conditions upon notifications are set by the content provider’s application logic, andcommunicated (both as a whole at the beginning of the session, and as updates during thesession) to its SPPM module which appropriately forwards them to the UPM and to the OPM.Since most of the events monitored by trigger settings sent to the UPM are generated by theuser device1, our choice is to have the UPM to properly communicate the settings to a servermodule (called Triggers in Figure 5) resident on the device. In order to keep up-to-date theinformation owned by the UPM, every client application must be equipped with an applicationmonitoring the state of the device against the received triggers (called Monitor in Figure5), and a client application (called UPM Interface in Figure 5) that updates the UPM whenthe Monitor notifies that a trigger fired. Each time the UPM receives an update that fires atrigger, it forwards the update to the interested CPPM.

3 Profile Management

In this section we address the issue of defining a common format for profile data storedat different sites and exchanged among different entities, and the issue of how to integratepossibly conflicting data in a single profile.

3.1 Profile representation

As already pointed out, the spectrum of useful profile information is wide, and profile dataare provided by different entities. For this reason, data retrieved from the different sourcesmust be represented using a well defined scheme, providing a mean to understand the se-mantics of the data. A possible approach to the problem of profile representation is the useof XML Schemas. Unfortunately, a standard XML Schema for representing profiles has notbeen developed. For this reason, we chose to adopt the Composite Capabilities/PreferenceProfiles (CC/PP) structure and vocabularies [Klyne et al., 2003].

CC/PP uses the Resource Description Framework (RDF) to create profiles describingdevice capabilities and user preferences. In particular, in CC/PP, the RDF graphs arerepresented through their XML serialization. Let us recall the main characteristics andconstraints imposed by the CC/PP specification on the structure of profiles.

CC/PP profiles are sets of components each one containing various attributes withassociated values. Components and attributes must refer to the CC/PP vocabulary wherethey are formally defined. A CC/PP vocabulary is an RDF Schema that defines CC/PPcomponents and attributes, their semantics, and allowed values.

1The only other entity that can update the UPM is the SPA.

7

Currently, CC/PP vocabularies define both the semantics of each attribute and the listof its possible values in human readable text using the <rdfs:comment> resource. On the onehand, this facilitates the readability of vocabularies. On the other hand —due to the lack ofa standard mechanism for specifying the set of valid values— this makes almost impossiblefor a CC/PP validator the retrieval of valid values for an attribute. To expand the set of validvalues of an attribute, it is necessary to redefine the attribute completely whereas it wouldbe useful for service providers to easily add proprietary values to this set in order to performsome specific task. Therefore, this approach leads to a proliferation of multiple versionsof the same vocabulary which are difficult to deal with [Butler and Gilbert, 2003]. Theflexibility of RDF could be exploited for allowing a more dynamic definition of vocabularies.It is our opinion that CC/PP will benefit from including a more sophisticated technique forassociating semantics to CC/PP vocabularies.

Currently, CC/PP is mostly used for representing device capabilities and network char-acteristics. UAProf [WAP Forum, 2000] is one of the most renowned CC/PP-complaintspecifications; it has been proposed by the Open Mobile Alliance [Open Mobile Alliance].UAProf defines components for representing hardware, software, and network capabilitiesof mobile devices. Some components defined within UAProf have been extended with newattributes by Intel [Intel Corporation, 2002]. UAProf and its Intel extension provide an ex-haustive description of device capabilities and network state; see Appendix A and AppendixB for an excerpt of the vocabularies. However, those vocabularies do not take into accountvarious data that are necessary to obtain a wide-ranging adaptation and personalization ofservices. In fact, to reach this goal, vocabularies describing information like user’s interests,content and presentation preferences, session variables, and user’s context are needed.

Even if a complete analysis of information needed as well as the requirements for mod-eling them is out of the scope of the paper, let us discuss it briefly. Some of this informationcan be satisfactorily modeled defining a set of attributes; for instance, personal informationcan be represented defining a vocabulary containing attributes like UserName, PersonalTi-tle, Gender, and so on. For this class of information standard ontologies already exist thatcan be easily translated into CC/PP vocabularies, and therefore adopted in our framework.As an example, the Liberty Alliance’s ID-Personal Profile [Liberty Alliance Project, 2003]represents user personal data through an XML Schema that fulfills the requirements ofmost internet services. However, other types of information are far more difficult to bedescribed using a predefined vocabulary. Consider, for example, the problem of modelingthe user context ([Henricksen et al., 2002], [Indulska et al., 2003], [Chen et al., 2003]). Asatisfactory description of the user context should include attributes describing the activitythe user is performing, his location and the surrounding environment (e.g., light intensity,temperature), the people and the resources he can interact with, etc. The value of theseattibutes are highly dynamic and, more importantly, the set of relevant attributes for therepresentation of the user context is variable. In fact, this set depends on various factorsamong which the activity the user is performing and the tools he is using to perform it.We strongly believe that, for some profile data, it is unfeasible to represent them usinga single omni-comprehensive and fixed set of attributes. However, while the definition ofthis dynamic class of data cannot be easily managed in general terms, they can be definedin an application-dependent way. Along these lines, we have defined a new vocabulary,called ExPro (shown in Appendix C), specifying several components that cannot be foundin the vocabularies cited above. The ExPro vocabulary includes, for example, componentsregarding personal interests, content type, and presentation directives.

It must be observed that different vocabularies can identify different attributes or com-ponents using the same name. In order to avoid ambiguities each attribute must be identifiedby means of its name, its vocabulary, its component, and its component vocabulary. Thus,

8

attributes can be identified using the notation

V ocabulary1.Component/V ocabulary2.Attribute

where: V ocabulary1 refers to the vocabulary the component belongs to; Component is theID of the component containing the attribute; V ocabulary2 refers to the vocabulary theattribute belongs to; and Attribute is the ID of the attribute. Note that a component cancontain attributes declared in vocabularies different from its own. For example, the notation

UAProf.HardwareP latform/IntelPCA.ExternalPower

identifies the ExternalPower attribute defined in the IntelPCA vocabulary. The attributebelongs to the component named HardwareP latform defined within the UAProf vocab-ulary.

In our framework we also introduce shortcuts for identifying groups of attributes. Forexample2, with

UAProf.HardwareP latform/IntelPCA.∗we denote the whole set of the IntelPCA vocabulary attributes that belong to theHardwareP latform component of the UAProf vocabulary.

3.2 Profile integration and conflict resolution

Once the SPPM has obtained profile data from the other profile managers, this information ispassed to the Inference Engine which is in charge of profile integration. Even if neither usernor service provider policies are present, conflicts can arise when different values are given forthe same attribute. For example, the UPM could assign to the Coordinates attribute a certainvalue x (obtained through the GPS of the user’s device), while the OPM could provide for thesame attribute the value y, obtained through triangulation. In literature, the problem ofsolving conflicts due to the presence of different values for the same attribute in the differentparts composing the profile is called profile resolution (see for instance [Butler et al., 2002]).In our architecture, profile resolution is performed by the Merge submodule of the IE. Wehave defined a simple language for allowing service providers to specify resolution rules atthe attribute level. This means that, for instance, a service provider willing to obtain themost accurate value for user’s location can give preference to the value supplied by the UPMwhile keeping the value provided by the OPM just in case the value from the UPM is totallymissing.

Priorities are defined by profile resolution directives which associate to every attributean ordered list of profile managers, using the setPriority statement:

setPriority attributeInstance([pm1[, pm2[, pm3]]])

Furthermore, we decided to differentiate the profile resolution depending on the type ofthe attribute. CC/PP attributes can be either simple (e.g., string, integer) or complex. Acomplex attribute can be either of type Bag (the attribute can contain a set of values) or oftype Seq (the attribute can contain an ordered sequence of values). When the attribute issimple (e.g., integer, string), the value to be assigned to the attribute is the one retrievedfrom the first entity in the list that supplies it. With respect to attributes of type Bag, thevalues to be assigned are the ones retrieved from all entities present in the list. If someduplication occurs, only the first occurrence of the value is taken into account (i.e., we applythe union operation among sets). Finally, if the type of the attribute is Seq, the values to

2In this example and in the following, UAProf and IntelPCA are shortcuts for the actual URI of thevocabularies.

9

be assigned to the attribute are the ones provided by the entities present in the list, orderedaccording to the occurrence of the entity in the list. If some duplication occurs, only thefirst occurrence of the value is taken into account. However, regarding this latter type, thisis just one of the possibilities to handle Seq values. In fact, we are considering of performingresolution selecting only the sequence of values provided by the first entity in the list thatsupplies it.It is worth noting that the entities that can provide attribute values must be explicitlydeclared. In particular, if an entity is not present in the list associated to an attribute, allvalues supplied by the entity for this attribute are discarded. This feature can be usefulwhen a service provider does not trust the values specified by an entity for one or moreattributes, or simply is not interested in considering a value for a certain attribute. InExample 1, we report some possible profile resolution directives. Within the directives,UAProf and ExPro refer respectively to the UAProf vocabulary and to our experimentaland application-dependent vocabulary.

Example 1 Consider the following priority directives:

1. setPriority *.*/*.* = (SPPM, UPM, OPM)

2. setPriority UAProf.NetworkCharacteristics / *.* =(OPM, UPM,SPPM)

3. setPriority ExPro.UserLocation / ExPro.Coordinates = (UPM, OPM)

4. setPriority ExPro.Interests / *.* = ()

In directive (1), a service provider gives highest priority to its own profile data, anda lower priority to data given by the other entities. It is worth to note that, if the serviceprovider’s profile does not contain –for example– the address attribute, its value is extractedfrom the user profile. The directives (2) and (3) give the highest priority to the operatorfor network-related data and to the user for the single Coordinates attribute. In addition,directive (3) states that the values for the Coordinates attribute specified by the serviceprovider will never be used and therefore can be discarded. In fact, the SPPM is not presentin the list. Finally, directive (4) specifies to ignore attributes related to the user interests.The latter directive can be useful for a provider unable to deliver services related to theseinterests.

4 Policies for Presentation and Content Adaptation

In our framework, service providers can dynamically personalize and adapt their servicesconsidering the profile data. For example, a service provider can choose the appropriateresolution for an image to be sent to the user, depending both on user preferences andon current available bandwidth. Similarly, users can dynamically change their preferencesregarding content and presentation depending on some parameters. For instance, a user,during chat sessions, may prefer to exchange textual messages when working on his palmdevice, while choosing voice messages when using a WAP phone. Our framework allowsboth service providers and users to define appropriate policies that, based on explicit profileattribute values, determine new profile data. The same language can be used by providersand users to specify their policies, even if normally user preferences are less technical andmore general. On the contrary, service providers must define policies allowing to determinethe precise presentation format. For example, while a user can simply state that his preferredmedia for a particular service is ”images”, the service provider must supply the accuratedefinition of the content to be sent, e.g. ”image/gif 72dpi”. In [W3C Working Draft, 2003]

10

those profile attributes defining some aspects of the presentation to be applied in deliveringservices are called presentation characteristics. This class of attributes describes detailedpresentation features that are generally omitted by the user of a generic service. Therefore,we expect that presentation characteristics will be set and modified mainly by the serviceproviders. Indeed, this issue is addressed in our framework by allowing service providers touse specialized CC/PP vocabularies. In addition, each service provider can extend the setof presentation characteristics with attributes regarding its particular services by defining orextending CC/PP vocabularies which are not required to be public. As usual, the choice ofa representation language is a compromise between simplicity, expressiveness, and efficiency.The language must also support the definition of a mechanism for handling conflicts thatcould arise when user and service provider policies determine different values for the sameattribute. These problems are addressed in Section 4.1 and Section 4.2, respectively.

4.1 Policy representation

Our choice for a policy language has privileged simplicity, well-defined semantics and well-known reasoning techniques. Indeed, we assume that our policies are specified as a set oflogical rules forming a Datalog program [Ceri et al., 1990]. Hence, each policy rule is essen-tially a function-free Horn clause, that can be interpreted as a set of conditions on profiledata (interpreted as a conjunction) that determine a new value for a profile attribute whensatisfied. For example, a user may want to express the following preference:

”When I am chatting from my palm device, I want to receive text messages”

This preference can be represented using the following policy (the policy syntax is sim-plified to be more intuitive):

”If ContentType=’chat’ And DeviceType=’palm-device’Then Set PreferredMedia=’text’

Formally, attributes should be referred to using the notation explained in Section 3.2. In ourpolicy language, attributes and associated values are represented using the binary predicate:

AV (Attr, V alue),

where Attr identifies the CC/PP attribute, and V alue is the value assigned to the at-tribute.Hence, using a datalog-like format, the above policy is represented as follows:

AV(ExPro.PresPrefs/ExPro.PreferredMedia, ’text’) ←AV(ExPro.Content/ExPro.ContentType, ’chat’),AV(ExPro.Device/ExPro.DeviceType, ’palm-device’)

A user-friendly GUI can be used to insert and modify policies, leading to the aboveinternal format. Policies may also be taken or adapted from a library of predefined policyrules.

4.2 Policy evaluation

The process of policy evaluation essentially consists in the evaluation of the logic rulesdefining user and service provider policies. Clearly, this evaluation must include a set offacts corresponding to the specific values assigned to attributes in the different profiles.

11

During the evaluation process, new facts will be derived from the firing of rules, with eachfact corresponding to a new value for a profile attribute.

A trivial approach for rule evaluation simply consists in the application of a standardDatalog evaluation algorithm to the set of rules corresponding to the policies together withthe set of facts corresponding to the explicit profile attribute values. However, this approachposes a major problem: it totally ignores conflicting attribute values and policies, i.e., policiesthat derive different values for the same CC/PP attribute. For example, a policy could derivefrom certain facts the value video for the PreferredMedia attribute, while another policycould derive from different facts the value audio for the same attribute.

Conflicts in our case are different from usual inconsistencies in logic programs identified,for example, by the derivation of both→ P (a) and→ ¬P (a). Since we do not allow negationin the policy specification language our set of rules are always formally consistent. Ourconflicts are due to the implicit assumption that each profile attribute can have a singlevalue (even if it could be a composite value). We distinguish two types of conflicts: a)conflicts due to policies and/or explicit attribute values given by the same entity, and b)conflicts due to policies and/or explicit attribute values given by different entities. A simpleexample of a conflict of type a) is the use of policies to override default attribute values whenspecific events occur and/or specific conditions are verified. In this case, a policy given byan entity, deriving a value for an attribute, intuitively has higher priority over an explicitvalue for that attribute given by the same entity.

Conflicts of type a) also include the case of two policies given by the same entity, thatspecify different rules to derive the value of the same attribute. In this case if the conditionsof the two rules are not mutually exclusive we may derive two different values. There is nointuitive way to solve such a conflict, and it is not reasonable to simply disallow each entityto specify more than one policy to derive the value of an attribute. Hence, we assume thatthe specification of these possibly conflicting policies includes an indication of priority, andif this is not given, a default ordering will be used. An example of conflict of type a) is givenbelow:

Example 2 Consider the case of the provider of a chatting service declaring his policiesregarding the notification of incoming messages to the users of the system. The serviceprovider could declare two policies regarding the Notification attribute, specifying to sendaudio notifications when the user is using a PDA, and text notifications when the user isinvolved in an important meeting. If the user is both using his PDA and involved in animportant meeting, both the rules would fire providing conflicting values. For this reason,the service provider has to specify which rule has the highest priority. In this example, it isreasonable for the service provider to give higher priority to the second rule. In this way,when the user is involved in an important meeting the first rule cannot fire because the secondrule has higher priority.

Conflicts of type b) can occur, for instance, when a provider is not able or does notwant to agree with a user policy or explicit preference, and sets up a policy rule to overridethe values explicitly given or derived by the user. Conflicts due to rules and explicit valuesfrom different entities can be taken care of considering the priority rules adopted in Section3.2 for explicit attribute values: if an entity has priority over other ones for the value of aspecific attribute, policies given by that entity to derive values of that attribute have priorityover policies given by other entities. An example of such a conflict and its resolution is givenbelow:

Example 3 Consider the user of an image-based internet service. The user could declare apolicy requiring high-resolution images when using his PDA; The service provider may wantto supply low-resolution images when the available bandwidth drops below a certain threshold.

12

If both the conditions hold the evaluation of policies would generate a conflict. If the serviceprovider has the highest priority for the attribute, the rule of the service provider prevailsover the user’s one, determining the supplying of low resolution images.

4.2.1 Conflict resolution strategies

We can summarize the desired behavior of the system, in the presence of possible conflicts,considering each case as follows:

1. Conflict between explicit values by two different entities and no policy is given for thesame attribute. The priority over entities for that attribute states which value prevails.For example, the priority rule associated with the attribute “Location” states that theinformation coming from the operator should be preferred, if available, to the onefrom the user. This kind of conflict is totally handled by the merge submodule of theInference Engine.

2. Conflict between an explicit attribute value and a policy given by the same entity thatcould derive a different value. The value derived from the policy, if derived, mustprevail.

3. Conflict between an explicit attribute value and a policy given by a different entity thatcould derive a different value. Considering the priority over entities for that attribute,if the entity giving the explicit value has priority over the other, then the policy canbe ignored, otherwise all policies should be evaluated (even considering the explicitvalue) and if a value for the same attribute is derived, it prevails over the explicit one.

4. Conflict between two policies given by two different entities on a specific attributevalue. The priority over entities for that attribute states the priority in firing thecorresponding rule. If a rule fires, no other conflicting rule from different entitiesshould fire.

5. Conflict between two policies given by the same entity on a specific attribute value.The priority over rules for that attribute (given by the entity) is used to decide whichone to fire first. If a rule fires, no other conflicting rule from the same entity shouldfire.

Example 4 illustrates the resolution of a conflict of type 5).

Example 4 Consider the potential conflict between two policies declared by the same entitypresented in Example 2. More formally, we can represent that scenario with the followingset of rules and facts:

P1-cp: AV(Notifications, ’audio’) ← AV(DeviceType, ’palm-device’)P2-cp: AV(Notifications, ’text’) ← AV(Availability,’important-meeting’)AV(DeviceType, ’palm-device’) ←AV(Availability, ’important-meeting’) ←P2-cp > P1-cp

Both rules can fire because of the facts (i.e., attribute values) found in the profiles; however,because of the rule priority given by the service provider, the rule corresponding to policyP2-cp is considered first and when fired P1-cp is disabled.

13

4.2.2 Implementing conflict resolution

The conflict resolution strategies presented in Section 4.2.1 have to be implemented usinga specific automatic mechanism. In the simple case when no policies are given for a certainattribute, conflicts can be easily solved by the Merge submodule as explained above, and theresulting attribute value can be directly passed to the Service Provider’s application logicand CRM. However, when policies are present, the resolution strategies must be integratedin the evaluation of logical rules. For this purpose, before starting the inference phase, theInference Engine preprocessor has to properly modify the rules and facts forming the logicprogram.

Our approach consists in discarding rules on attributes for which a prevailing fact existsaccordingly to the priority rules (see point 3 in Section 4.2.1), and in assigning a weight toeach fact and other rule in the logic program. In order to do this, the AV predicate isextended with a third parameter Weight:

AV (Attr, V alue, Weight).

The weight of a rule is the weight of the AV predicate in its head3. The weights are assignedas specified by Algorithm 1. Intuitively, rules on attributes for which a prevailing fact existsare not assigned any weight (hence, discarded), all facts are given weight 0, and other rulesare assigned increasing weights accordingly to priorities over entities and priorities specifiedby each entity. Algorithm 1 ensures that in the transformed program, there are no ruleshaving as head an AV predicate with the same attribute name and weight.

Algorithm 1 Setting the Weight parameter.Require:

• ({E3{, E2{, E1}}}) is the priority over entities for the attribute Attr.

• Ei is the entity providing the value obtained by the Merge submodule for the at-tribute Attr.

• REj ,Attr (j = 1 . . . 3) is the set of rules declared by Ej whose head modifies theattribute Attr.

• REj ,Attr,k is the kth rule ∈ REj ,Attr in increasing order of priority, according to thechoice of Ej .

{The fact has always the lowest weight}Weight(FactAttr) ⇐ 0w ⇐ 0{Repeat for Ei and for every entity with priority greater than Ei}for j = i to 3 do

Kj ⇐ |REj ,Attr|{Repeat for every rule declared by Ej whose head modifies Attr}for k = 1 to Kj do

w ⇐ w + 1{Weight(REj ,Attr,k) is the weight to be set to the rule REj ,Attr,k}Weight(REj ,Attr,k) ⇐ w

end forend for

Ideally, the evaluation of rules should proceed, for each attribute Attr, starting fromthe rule having the AV predicate on Attr in its head with the highest Weight, and it should

3In this way we avoid the adoption of a compiler for ordered logic programs such asPLP [Delgrande et Al., 2003].

14

proceed considering analogous rules with decreasing weights till one of them fires. If noneof them fires, the value of Attr is the one specified by the fact on Attr, or none if such afact does not exist.

This behavior is obtained by the introduction of an auxiliary predicate

FIRED(Attr,Weight).

Intuitively, this predicate evaluates to True if a value for the attribute Attr has been derivedby a rule with weight Weight.

Formally we introduce in the program the rule:

FIRED(r, t) ← AV (r, s, t)

where r, s, t, are variables, and we transform each rule by adding the terms

not FIRED(Attr,K)

andK > Weight

to the preconditions of the rule. This is done for facts too.This transformation has the effect of disabling a rule with head AV (Attr, V alue, Weight)

if a value can be derived for the attribute Attr by a rule with a weight higher than Weight.Indeed, the evaluation of the FIRED precondition in a rule R by a backward reasoningalgorithm ensures that policies with higher weight are evaluated before letting R fire. Anexample of the preprocessing we perfomr on the logic program is given below:

Example 5 Consider conflicts between an explicit attribute value provided by the opera-tor, two policies given by the same entity (e.g.; the user), and a policy given by the serviceprovider, possibly deriving different values for the same attribute Attr; in this example, theuser declared two policies over the same attribute, and he gave highest priority to the pol-icy user2. Suppose that the priority over entities for the Attr attribute is (SPPM, UPM,OPM). The Inference Engine preprocessor receives in input from the SPPM the followinglogic program:

(op) AV (Attr, a) ←(user) AV (Attr3, b) ←(user1) AV (Attr, x) ← AV (Attr2, x)(user2) AV (Attr, x) ← AV (Attr3, x)(cp) AV (Attr, x) ← AV (Attr4, x)user2 > user1

The fact (op) represents the value provided by the OPM for Attr, The fact (user) repre-sents the value provided by the User for Attr3, the first policy (user1) and the second policy(user2) are declared by the user, and the last policy (cp) is declared by the service provider.Applying the algorithm described in Algorithm 1, the lowest weight (0) is assigned to thefacts. The UPM has higher priority over the OPM, and so the preprocessor, following thepriorities defined by the user over his rules, gives weight 1 to the head of the user policywith lowest priority (user1) and weight 2 to the head of the policy (user2). Finally, thehighest weight (3) is assigned to the head of the policy (cp), as it was declared by the entitywith highest priority (the service provider in this case). Note that, if the OPM had highestpriority than the UPM and SPPM, no rule would have been assigned any weight, and henceall rules would have been discarded.

Hence, the above logic program is modified as follows:

15

(op) AV (Attr, a, 0) ← not FIRED(Attr, z), z > 0(user) AV (Attr3, b, 0) ← not FIRED(Attr3, z), z > 0(user1) AV (Attr, x, 1) ← AV (Attr2, x, ), not FIRED(Attr, z), z > 1(user2) AV (Attr, x, 2) ← AV (Attr3, x, ), not FIRED(Attr, z), z > 2(cp) AV (Attr, x, 3) ← AV (Attr4, x, ), not FIRED(Attr, z), z > 3FIRED(r, t) ← AV (r, s, t)

In this case, the value of Attr is determined as b by the firing of rule (user2).

5 Related Work

There are several projects addressing the problems associated with content selection, for-matting, and delivery in a distributed multi-device environment[W3C Delivery Context Workshop, 2002]. In particular, with respect to the issue of inte-grating multi-source profile data, our proposal goes along the same lines of DELI[Butler et al., 2002]. In DELI Java servlets resolve HTTP requests containing references todifferent profiles, as well as actual profiles (called profile-diffs) and default profiles. DELIadopts the profile resolution approach of UAProf, consisting in associating a resolution ruleto every attribute. Whenever a conflict arises, the resolution rule determines the value tobe assigned to the attribute by considering the order of evaluation of partial profiles. Thiscorresponds to assigning priorities to partial profiles, as opposed to assigning priorities tosingle attributes as we do. Furthermore, since resolution rules in DELI are defined in theCC/PP vocabulary, service providers cannot modify them. Our approach to profile inte-gration (see Section 3.2) overcomes the above mentioned limits providing, in our opinion, amore flexible and powerful integration mechanism.

Intel’s CC/PP SDK proposes another architecture for the management of profile data.The main component of this architecture is the CC/PP Content Customization Module. ThisApache module retrieves partial profiles by analyzing HTTP request headers, and combinesthem obtaining a merged profile that is used to determine the content and its presentation.This framework allows three different mechanisms for personalization. Content Selectionbuilds different representations of the same content; the most appropriate representationis chosen by analyzing profile data. Stylesheet Conversion is used for adapting XML datausing a different XSL stylesheet for various classes of profiles. Finally, Script Processinguses a script language to dynamically build an interface suited to the profile. Our approachis different: via policies users can express personalization preferences and service providerscan delegate part of the application logic to the Inference Engine module, thus simplifyingthe development of personalized services.

The work of [Riche and Brebner, 2003] provides a different approach to profile man-agement implementing a distributed storage system on user devices. The profile data aredistributed and replicated over user devices; the whole set of profile data are retrieved justwhen needed. This approach is useful to preserve the privacy of data. However, the in-termittent connectivity of mobile devices along with their limited CPU, storage and powerresources, makes it difficult to guarantee the availability of profiles, even if sophisticatedtechniques are provided.

A context management system aimed at supporting pervasive computing is described in[Indulska et al., 2003]. The goal of that system is to efficiently model the current status ofthe computing environment in order to support the adaptation of the environment to changeswhich can occur. The notion of context, used to model the environment, is similar to theconcept of profile we illustrated in the previous sections. Context information is composedby data such as the characteristics of devices and applications, the network status, theQuality of Service (QoS), and the users’ preferences. The authors extended the CC/PP

16

framework by defining new vocabularies for representing part of these data. In order toovercome the limitations of the two-layer structure of CC/PP, they declared attributes whichthemselves are components; at present, we intend to strictly follow the CC/PP specification,declaring vocabularies with a two-layer structure. Furthermore, the context model includesconstraints and relationships between the different parts of the environment. In order toexpress such features, the authors enriched the CC/PP framework by introducing additionalrelations. In our architecture, constraints are not represented in the profile, but can beexpressed as policies that model the dynamics of profile data. From an architectural pointof view, the rationale of the proposed system is similar to ours. The major difference isdue to the mechanism of profile updates; while we identified three entities providing profileinformation, in [Indulska et al., 2003] these entities (called Awareness Modules) are spreadover the computing environment and are not identified a priori.

A further architecture for the user-side adaptation of applications in a mobile envi-ronment is described in [Efstratiou et al., 2001]. This architecture contains a single profilemanager which is in charge of discovering context services; i.e., applications providing profiledata. Data retrieved from context services are stored in a context database and are modifiedwhen a context service notifies that an event occurred. The adaptation control module is incharge of evaluating adaptation policies against the profile modifying accordingly the behav-ior of the applications. Users can define policies by specifying priorities among applicationsas well as among resources of their devices. Consequently, the behavior of applications isadapted to obtain the optimal level of service with respect to user requirements. However,it is worth noting that this architecture allows only user side adaptation. In particular, theuser cannot specify preferences regarding the content.

Up to now, we have developed a low level language for policy representation, in order toaccurately control the inference behaviour; For the future we are considering the possibilityto adopt a standard language for representing policies in the architecture. As a matter of fact,in the last years a huge effort has been made for developing standard languages for policyrepresentation. The Policy Core Information Model (PCIM) [IETF and DMTF, 2001] is anobject-oriented information model for the representation of policies developed jointly by theIETF Policy Framework WG and by the Distributed Management Task Force (DMTF). Inthis model, a policy is a rule that specifies actions to be taken when a set of conditionsis met. Two hierarchies of object classes compose this model: structural classes for therepresentation and the control of policies, and association classes for indicating relationshipsbetween instances of the structural classes. In the PCIM model classes are sufficientlygeneric to allow the representation of policies related to different domains. A similar, yetmore security-oriented language for policy representation is Ponder [Damianou et al., 2001],a declarative, object-oriented language which allows actors to be grouped into domains,and rules to be grouped in roles relating to a position in an organization. Since in ourarchitecture profile data are provided by only three actors, we do not need the definition ofdomains and roles for grouping objects and actors.

6 Conclusions

In this paper we presented a framework devoted to support a comprehensive adaptationand personalization of internet based services in a mobile environment. A preliminaryversion of it has been presented in [Agostini et al., 2003]. The extension of the notion ofprofiles coupled with users and service providers’ policies provide us a flexible and powerfulmechanism reaching our goals. In particular, our architecture is flexible enough to supportvarious business models as well as different kinds of applications and services.

Enhancements of our framework are possible in various directions. Considering the UPMmodule, we currently provide only a basic GUI, while it is of paramount importance an

17

accurate design of the interactions with the user for a real adoption and acceptance of thesystem. With similar purposes, we plan to work on the Semantic Profile Assistant, that, inprinciple, should be able to suggest new profile values and policies for the user, and henceminimize his direct involvement in the settings of the UPM. Finally, we are investigating howour framework may support a mechanism for session hand-over both in the case of a userchanging his device and of a change of network bearer.

References

[Agostini et al., 2003] Alessandra Agostini, Claudio Bettini, Nicolo Cesa-Bianchi, DarioMaggiorini, and Daniele Riboni. Integrated Profile Management for Mobile Comput-ing. In Proceedings of AI Moves to IA: Workshop on Artificial Intelligence, InformationAccess, and Mobile Computing (AI2IA03), pages 18-22, in conjunction with IJCAI 2003Conference, Acapulco, Mexico, August 2003.

[Butler et al., 2002] Mark Butler, Fabio Giannetti, Roger Gimson, and Tony Wiley. DeviceIndependence and the Web. IEEE Internet Computing, 6(5):81–86, September-October2002.

[Butler and Gilbert, 2003] Mark Butler and John Gilbert. Using Multiple Namespaces inCC/PP and UAProf. Technical Report, Digital Media Systems Laboratory HP Labora-tories Bristol, February 2003.

[Chen et al., 2003] Harry Chen, Tim Finin, and Anupam Joshi. An Ontology for Context-Aware Pervasive Computing Environments. In Proceedings of Workshop on Ontologiesand Distributed Systems, in conjunction with IJCAI 2003 Conference, Acapulco, Mexico,August 2003.

[Ceri et al., 1990] Stefano Ceri, Georg Gottlob, and Letizia Tanca. Logic Programming andDatabases. Springer-Verlag, June 1990.

[W3C Working Draft, 2003] Markus Lauff, Amy Yu, Editors. Core Presentation Char-acteristics: Requirements and Use Cases. W3C Working Draft, 10 May 2003. http://www.w3.org/TR/2003/WD-cpc-req-20030510/.

[Damianou et al., 2001] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Slo-man. The Ponder Policy Specification Language. In Proceedings of Policy Workshop 2001,pages 18-39, Bristol, UK, January 29-31, 2001.

[Delgrande et Al., 2003] James Delgrande, Torsten Schaub, Hans Tompits. A frameworkfor compiling preferences in logic programs. Theory and Practice of Logic Programming,3(2):129–187, 2003.

[Efstratiou et al., 2001] Christos Efstratiou, Keith Cheverst, Nigel Davies, and Adrian Fri-day. An Architecture for the Effective Support of Adaptive Context-Aware Applica-tions. In Proceedings of the Second International Conference on Mobile Data Management(MDM 2001), pages 15-26, Hong Kong, China, January 8-10, 2001.

[Henricksen et al., 2002] Karen Henricksen, Jadwiga Indulska, and Andry Rakotonirainy.Modeling Context Information in Pervasive Computing Systems. In Proceedings of theFirst International Conference on Pervasive Computing, pages 167-180, Zurich, Switzer-land, August 26-28, 2002.

[IETF and DMTF, 2001] IETF Policy Framework WG, Distributed Management TaskForce (DMTF). Policy Core Information Model - Version 1 Specification. RFC3060,February 2001.

18

[Indulska et al., 2003] Jadwiga Indulska , Ricky Robinson, Andry Rakotonirainy, and KarenHenricksen. Experiences in Using CC/PP in Context-Aware Systems. In Proceedings ofthe 4th International Conference on Mobile Data Management (MDM 2003), pages 247-261, Melbourne, Australia, January 21-24, 2003.

[Intel Corporation, 2002] Intel PCA Device Profile. CC/PP Client Profile for Intel PCADevices. Design Guide, August 2002.

[Klyne et al., 2003] Graham Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto,Johan Hjelm, Mark H. Butler, and Luu Tran (Eds.). Composite Capability/PreferenceProfiles (CC/PP): Structure and Vocabularies 1.0, W3C Proposed Recommendation, Oc-tober 15, 2003. http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/.

[Liberty Alliance Project, 2003] Liberty Alliance. Liberty ID-SIS Personal Profile Service.Specification Version 1.0-29, 2003.

[Open Mobile Alliance] Open Mobile Alliance. http://www.openmobilealliance.org/.

[Riche and Brebner, 2003] Stepanie Riche and Gavin Brebner. Storing and Accessing UserContext. In Proceedings of the 4th International Conference on Mobile Data Management(MDM 2003), pages 1-12, Melbourne, Australia, January 21-24, 2003.

[W3C Delivery Context Workshop, 2002] W3C Delivery Context Workshop. Sophia-Antipolis, France, March 4-5, 2002. http://www.w3.org/2002/02/DIWS/final.html

[WAP Forum, 2000] WAP Forum. User Agent Profile Specification. WAP-248-UAProf.http://www.wapforum.org/.

[Wu and Chao, 2001] Shiow-yang Wu and H. S. Cinatit Chao. Event Engine for AdaptiveMobile Computing. In Proceedings of the Second International Conference on Mobile DataManagement (MDM 2001), pages 27-38, Hong Kong, China, January 8-10, 2001.

Appendix A

An excerpt of the UAProf vocabulary

<?xml version="1.0"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20020710#">

<rdf:Description ID="Component"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/><rdfs:label>Component</rdfs:label><rdfs:comment>

A Component within the CC/PP Schema is a class of related propertiesthat describe the capabilities and preferences information.

</rdfs:comment>

</rdf:Description>

<rdf:Description ID="component">

19

<rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:label>component</rdfs:label><rdfs:comment>

The component attribute links the various components to the root node(profile).

</rdfs:comment></rdf:Description>

<rdf:Description ID="defaults"><rdfs:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="#HardwarePlatform"/><rdfs:domain rdf:resource="#SoftwarePlatform"/><rdfs:domain rdf:resource="#WapCharacteristics"/><rdfs:domain rdf:resource="#BrowserUA"/><rdfs:domain rdf:resource="#NetworkCharacteristics"/><rdfs:domain rdf:resource="#PushCharacteristics"/><rdfs:comment>

An attribute used to identify the default capabilities.</rdfs:comment>

</rdf:Description>



<rdf:Description ID="HardwarePlatform"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: HardwarePlatform</rdfs:label><rdfs:comment>

The HardwarePlatform component contains properties of the device’sHardware, such as display size, supported character sets, etc.


<rdf:Description ID="SoftwarePlatform"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: SoftwarePlatform</rdfs:label><rdfs:comment>

The SoftwarePlatform component contains properties of the device’sapplication environment, operating system, and installed software.


<rdf:Description ID="BrowserUA"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: BrowserUA</rdfs:label><rdfs:comment>

The BrowserUA component contains attributes related to the browseruser agent running on the device.


20

<rdf:Description ID="NetworkCharacteristics"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: NetworkCharacteristics</rdfs:label><rdfs:comment>

The NetworkCharacteristics component contains properties describing thenetwork environment including the supported bearers.


<rdf:Description ID="WapCharacteristics"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: WapCharacteristics</rdfs:label><rdfs:comment>

The WapCharacteristics component contains properties of the WAPenvironment supported by the device.


<rdf:Description ID="PushCharacteristics"><rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/><rdfs:subClassOf rdf:resource="#Component"/><rdfs:label>Component: PushCharacteristics</rdfs:label><rdfs:comment>

The PushCharacteristics component contains properties of the device’spush capabilities, such as supported content mime types.




21

Appendix B

The definition of the attributes belonging to the HardwarePlatformand NetworkCharacteristics components of the Intel PCA vocabu-lary

<?xml version="1.0"?><rdf:RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:uaprof="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#"xmlns:pca="http://developer.intel.com/pca/developernetwork/devsupport/pca_schema/2002_01#">



<rdf:Description rdf:ID="ExternalPower"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Indicates whether the device is currentlyconnected to AC Power or any other power sourcesuch as a cigarette lighter in a car. "Yes" means External Power is ON."No" means External Power is OFF.Type: BooleanResolution: OverrideExamples: "Yes", "No"


<rdf:Description rdf:ID="BatteryChargeStatus"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Gives the current status of the battery asthe percentage of battery charge remaining.

22

Type: NumberResolution: OverrideExamples: "10", 55", "80"


<rdf:Description rdf:ID="BatteryLifetime"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Full lifetime of fully charged battery(in seconds)Type: NumberResolution: OverrideExamples: "28800"


<rdf:Description rdf:ID="BatteryLifetimeRemaining"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Remaining lifetime of battery, in seconds.Type: NumberResolution: OverrideExamples: "1200"


<rdf:Description rdf:ID="BackupBatteryChargeStatus"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Gives the current status of the backupbattery as the percentage of battery charge remaining.Type: NumberResolution: OverrideExamples: "10", 55", "80"


<rdf:Description rdf:ID="BackupBatteryLifetime"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Full lifetime of fully charged backupbattery (in seconds)Type: NumberResolution: OverrideExamples: "28800"


23

<rdf:Description rdf:ID="BackupBatteryLifetimeRemaining"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Remaining lifetime of backup battery, insecondsType: NumberResolution: OverrideExamples: "1600"


<rdf:Description rdf:ID="NumberOfProcessors"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Total number of applications and communicationsprocessors in the device.Type: NumberResolution: LockedExamples: "2 "


<rdf:Description rdf:ID="CPURevision"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Stepping of the Application Processor.The UAProf CPU attribute is to be used tospecify the name and model number of the Applications processor,such as "PXA-250" or "SA-1110".Type: LiteralResolution: LockedExamples: "A0", "A1", "B1"


<rdf:Description rdf:ID="CPUFrequency"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Current core clock frequency of theApplications ProcessorType: LiteralResolution: OverrideExamples: "400", "200", "100"


<rdf:Description rdf:ID="CPUFrequencyMaximum"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/

24

ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Maximum core clock frequency of theApplications ProcessorType: NumberResolution: LockedExamples: "400", "200"


<rdf:Description rdf:ID="CPUVoltage"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Current voltage of the ApplicationsProcessor (in Volts)Type: LiteralResolution: OverrideExamples: "1.5", "1.0"


<rdf:Description rdf:ID="CommProcessor"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Name and model number of the Communicationsprocessor.Type: LiteralResolution: LockedExamples: "PXA 250", "SA 1110"


<rdf:Description rdf:ID="CommProcessorRevision"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Stepping of the Communications Processor.Type: LiteralResolution: LockedExamples: "A0", "A1", "B1"


<rdf:Description rdf:ID="DynamicFrequencyChangeCapable"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Indicates if the platform has DynamicFrequency Management capability or not.Type: BooleanResolution: LockedExamples: "True", "False

25


<rdf:Description rdf:ID="HighConstrastDisplayMode"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Indicates if high contrast display featureis available and on.Type: BooleanResolution: LockedExamples: "Yes", "No"


<rdf:Description rdf:ID="BacklightOn"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Indicates if the display backlight is ON or OFF.Type: BooleanResolution: LockedExamples: "Yes", "No"


<rdf:Description rdf:ID="SIMType"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Type of the Subscriber Identity Module inthe device.Type: LiteralResolution: OverrideExamples: "SIM", "USIM"


<rdf:Description rdf:ID="SIMToolkitVersion"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Version number of the SIM Toolkit installed,if any. A version number of 0 indicatesthat SIM Toolkit is not installed. SIM Toolkit Vendor name can be added,if needed.Type: NumberResolution: OverrideExamples: "0", "2"


<rdf:Description rdf:ID="AvailableExpansionSlots">

26

<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: List the types of expansion slots availablein the device such as PCMCIA, Compact Flashand MultiMedia Card (MMC) sockets.Type: Literal (Bag)Resolution: AppendExamples: "PCMCIA", "Compact Flash", "MMC"


<rdf:Description rdf:ID="ExpansionCardsInserted"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: Identifies the cards currently inserted,such as PCMCIA 802.11, Compact Flash 802.11,PCMCIA GPRS etc.Type: Literal (Bag)Resolution: AppendExamples: "PCMCIA 802.11", "CF 802.11", "CF Memory", "PCMCIA GPRS","MMC"


<rdf:Description rdf:ID="CommunicationPorts"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#HardwarePlatform"/><rdfs:comment>Description: List all the available means for communicationwith a host computer, such as SerialCommunications port, USB and IrDAType: Literal (Bag)Resolution: AppendExamples: "Serial", "USB Host", "USB Client", "IrDA", "Ethernet"




<rdf:Description rdf:ID="CurrentBearerSignalStrength"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The signal strength as a level between 0-100.See UAProf Specification for a description of"CurrentBearerService".Type: LiteralResolution: LockedExamples: "0", "60", "100"

</rdfs:comment>

27

</rdf:Description>

<rdf:Description rdf:ID="CurrentBearerMaximumBitRate"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The maximum bit rate in Kbps for the currentbearer serviceType: LiteralResolution: LockedExamples: "56.6", "10000"


<rdf:Description rdf:ID="CurrentBearerActualBitRate"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The current actual bit rate in Kbps for thecurrent bearer serviceType: LiteralResolution: OverrideExamples: "26.4", "100"


<rdf:Description rdf:ID="SupportedBearerMaximumBitRates"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The maximum reported bit rate in Kbps for eachsupported bearer service. The bearersin this list may or may not have an active connection. See UAProfspecification for a description of SupportedBearers.Type: Literal (Bag)Resolution: OverrideExamples: "56.6", "1600", "28.8"


<rdf:Description rdf:ID="ActiveBearers"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: A list of bearers from "SupportedBearers"that currently have an active connection to a routeror gateway device.Type: Literal (Bag)Resolution: AppendExamples: "GPRS", "SMS", "802.11"


28

<rdf:Description rdf:ID="ActiveBearerAddresses"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The address, for each of the bearers listedin "ActiveBearers" in the appropriate format, IP or UMTS.Type: Literal (Bag)Resolution: AppendExamples: "145.19.22.14", "555-555-6262", "192.168.12.14"


<rdf:Description rdf:ID="ActiveBearerActualBitRates"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: The list of bit rates supported by the bearerslisted in "SupportedBearers", the items should matchone for one with the list given in "ActiveBearers"Type: Literal (Bag)Resolution: AppendExamples: "56.6", "1600", "28.8"


<rdf:Description rdf:ID="ConnectedToHost"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: Indicates if the device is currently connected to a hostcomputer through USB, bluetoothor by any other means.Type: BooleanResolution: OverrideExamples: "Yes", "No"


<rdf:Description rdf:ID="CellID"><rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Property"/><rdfs:domain rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#NetworkCharacteristics"/><rdfs:comment>Description: Identifies the service bearer cell that thedevice is in at the current time.Type: LiteralResolution: OverrideExamples: "2001", "100"


29

Appendix C

The ExPro vocabulary

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [<!ENTITY ns-rdf ’http://www.w3.org/1999/02/22-rdf-syntax-ns#’><!ENTITY ns-rdfs ’http://www.w3.org/2000/01/rdf-schema#’><!ENTITY ns-ccpp ’http://www.w3.org/2002/11/08-ccpp-schema#’><!ENTITY ns-expro ’http://webmind.dico.unimi.it/expro/expro-1.0.xml#’>

]>

<rdf:RDFxmlns:rdf = ’&ns-rdf;’xmlns:rdfs = ’&ns-rdfs;’xmlns:ccpp = ’&ns-ccpp;’xmlns:expro = ’&ns-expro;’>

<ccpp:Component rdf:about=’&ns-expro;Context’><rdfs:label xml:lang="en">Component: Context</rdfs:label><rdfs:comment xml:lang="en">

The Context component contains properties that describe the user’saction-context (e.g. what he’s doing while he’s making the request).

</rdfs:comment></ccpp:Component>

<ccpp:Component rdf:about=’&ns-expro;Presentation’><rdfs:label xml:lang="en">Component: Presentation</rdfs:label><rdfs:comment xml:lang="en">

The Presentation component contains properties that describe thepreferences about the presentation of the content (e.g. no sound,small images).


<ccpp:Component rdf:about=’&ns-expro;Content’><rdfs:label xml:lang="en">Component: Content</rdfs:label><rdfs:comment xml:lang="en">

The Content component contains properties that describe the requestedcontent (e.g. the user wants to watch a movie, or read some text).


<ccpp:Component rdf:about=’&ns-expro;Interests’><rdfs:label xml:lang="en">Component: Interests</rdfs:label><rdfs:comment xml:lang="en">

The Interests component contains properties that describe theuser’s interests.


30

<ccpp:Component rdf:about=’&ns-expro;PersonalInformation’><rdfs:label xml:lang="en">Component: PersonalInformation</rdfs:label><rdfs:comment xml:lang="en">

The PersonalInformation component contains properties that describethe user’s personal data (e.g; name, address, age).

</rdfs:comment></ccpp:Component></rdf:RDF>

Appendix D

The CC/PP profile of Nokia 9290 cell phone

<?xml version="1.0"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">

<rdf:Description rdf:ID="Nokia9290"><prf:component><rdf:Description rdf:ID="HardwarePlatform">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#HardwarePlatform"/><prf:BitsPerPixel>12</prf:BitsPerPixel><prf:ScreenSize>490x165</prf:ScreenSize><prf:ScreenSizeChar>27x9</prf:ScreenSizeChar><prf:StandardFontProportional>Yes</prf:StandardFontProportional><prf:Vendor>Nokia</prf:Vendor><prf:Model>9290</prf:Model><prf:Keyboard>Qwerty</prf:Keyboard><prf:TextInputCapable>Yes</prf:TextInputCapable>

</rdf:Description></prf:component><prf:component><rdf:Description rdf:ID="SoftwarePlatform">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#SoftwarePlatform"/><prf:CcppAccept>

<rdf:Bag><rdf:li>text/vnd.wap.wml</rdf:li><rdf:li>application/vnd.wap.wmlc</rdf:li><rdf:li>application/vnd.wap.wmlscriptc</rdf:li><rdf:li>image/gif</rdf:li><rdf:li>image/jpeg</rdf:li><rdf:li>image/tiff</rdf:li><rdf:li>image/png</rdf:li><rdf:li>image/vnd.wap.wbmp</rdf:li>

</rdf:Bag></prf:CcppAccept><prf:OSVersion>6.0</prf:OSVersion>

31

<prf:RecipientAppAgent>Nokia9290/Symbian-Crystal/6.0 (1.00)</prf:RecipientAppAgent>

</rdf:Description></prf:component><prf:component><rdf:Description rdf:ID="NetworkCharacteristics">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#NetworkCharacteristics"/><prf:SupportedBearers>

<rdf:Bag><rdf:li>CSD</rdf:li><rdf:li>HSCSD</rdf:li><rdf:li>GSM1900</rdf:li>

</rdf:Bag></prf:SupportedBearers>

</rdf:Description></prf:component><prf:component><rdf:Description rdf:ID="BrowserUA">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#BrowserUA"/><prf:BrowserName>Nokia</prf:BrowserName><prf:BrowserVersion>9290/Symbian-Crystal 6.0 (1.00)</prf:BrowserVersion><prf:TablesCapable>Yes</prf:TablesCapable>

</rdf:Description></prf:component><prf:component><rdf:Description rdf:ID="WapCharacteristics">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#WapCharacteristics"/><prf:WapVersion>1.1</prf:WapVersion><prf:WmlDeckSize>65536</prf:WmlDeckSize><prf:WmlScriptVersion>

<rdf:Bag><rdf:li>1.1</rdf:li>

</rdf:Bag></prf:WmlScriptVersion><prf:WmlVersion>

<rdf:Bag><rdf:li>1.1</rdf:li>

</rdf:Bag></prf:WmlVersion>

</rdf:Description></prf:component><prf:component><rdf:Description rdf:ID="PushCharacteristics">

<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#PushCharacteristics"/>

</rdf:Description></prf:component>

</rdf:Description></rdf:RDF>

32

Integrated Profile and Policy Management for Mobile-oriented Internet Services

Documents

Transcript of Integrated Profile and Policy Management for Mobile-oriented Internet Services