A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR

DYNAMIC USER MODELS

Fabian Abel

, Juri Luca De Coi

, Nicola Henze

, Arne Wolf Koesling

, Daniel Krause

and Daniel Olmedilla

Distributed Systems Institute/KBS, University of Hannover, D-30167 Hannover, Germany

L3S Research Center, University of Hannover, D-30167 Hannover, Germany

Peter L. Reichertz Institute for Medical Informatics, Hannover Medical School, D-30625 Hannover, Germany

Telefonica Research & Development, 28043 Madrid, Spain

Keywords:

Policy, RDF, Access Control, User Interface.

Abstract:

A ﬁne-grained user-aware access control to user proﬁle data is the key requirement for sharing user proﬁles

among applications, and hence improving the effort of these systems massively. Policy languages like Protune

can handle access restrictions very well but are too complicated to be used by non-experts. In this paper, we

identify policy templates and embed them into a user interface that enables users to specify powerful access

policies and makes them aware of the current and future consequences of their policies.

1 INTRODUCTION

Personalization encounters more and more attention

as it promises to make programs more user friendly

and content more appropriate. This information ide-

ally should be learned by the system in interaction

with the user and stored in a user proﬁle. While user

proﬁles that ﬁt for one personalization component and

that are implemented in one application have proved

to work well, the beneﬁt of a user proﬁle will even in-

crease if different applications can share its data. Es-

pecially in a service-based environment, where users

invoke many different services and use them only for

a short period of time, it is nearly impossible for a sin-

gle service to generate such a user proﬁle on its own

as there is not enough interaction with the user.

Shared user proﬁles enable applications to uti-

lize additional information that has been collected

by other applications and therefore need a univer-

sal data storage format. The Resource Description

Framework (RDF) provides such a generic format and

hence, is used in the User Modeling Service (UMSer-

vice) which is part of the Personal Reader Framework,

a framework allowing the creation of web service-

based applications. A serious problem of shared user

proﬁles is that applications store sensitive informa-

tion: While a trustful application known by the user

is maybe allowed to access his bank account infor-

mation, another application should not be allowed to

access the same data. Therefore, an access control

system is required that grants applications access to

proﬁle data only after the user has agreed. For this ac-

cess control system, rule-based policy languages can

be used very well as they allow precisely to specify

which application can operate on which data at which

time.

Rule-based policy languages, like Protune (Bon-

atti and Olmedilla, 2005a; Bonatti and Olmedilla,

2005b), can be used to deﬁne in a ﬁne-grained fashion

which web service is allowed to access which data,

which credentials it has to provide and so on. In the

domain of user proﬁle data this problem is shifted to

the task of selecting data from an RDF graph pro-

tected by an access policy. Policy languages can deal

with this task but the resulting policies are usually too

complicated to be speciﬁed by non-experts. A pos-

sible approach is to use predeﬁned policy templates

that can be completed easily by users. However, users

cannot be fully aware about which data is covered by

a policy if they do not have an appropriate user inter-

face.

The contribution of this paper is to present a user

interface that enables non-expert users to control the

access to their RDF-based user proﬁles. Hence, we

deduce access policy templates and embed them into

the user interface. Then, we examine how to imple-

ment these policies in the Protune policy language.

The user interface provides immediate feedback to the

184

Abel F., De Coi J., Henze N., Koesling A., Krause D. and Olmedilla D.

A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR DYNAMIC USER MODELS.

DOI: 10.5220/0001839801840191

In Proceedings of the Fifth International Conference on Web Information Systems and Technologies (WEBIST 2009), page

ISBN: 978-989-8111-81-4

user which includes information about which part of

the RDF data is covered by the policy and additionally

which consequences the speciﬁed policy has.

The paper is structured as follows: In Section 2

we present underlying techniques like the Personal

Reader Framework, the User Modeling Service and

policies. Section 3 introduces the usage of policies for

protecting user proﬁles. A user interface that enables

users to specify these user proﬁle policies is shown in

Section 4 and 5. The related work can be found in

Section 6. We conclude the paper and give an outlook

to future work in Section 7.

2 THE PERSONAL READER

FRAMEWORK

The Personal Reader Framework (Henze, 2005) al-

lows the creation of modular web service-based ap-

plications (Figure 1). These applications are accessed

by user interfaces (UI for short). Syndication Services

implement the application logic and can be consid-

ered as the core of an application. By means of a

Connector Service all Syndication Services are able

to discover and access Personalization Services dy-

namically, which aggregate domain-speciﬁc informa-

tion in a personalized way. To gather information,

Personalization Services access and process Semantic

Web data sources. An important feature of the Per-

sonal Reader Framework is that new services can be

integrated in a plug-and-play manner, hence no cen-

tralized component has to be modiﬁed and new ser-

vices can be used immediately from all other services

within the framework.

Both Syndication and Personalization Services are

able to access and store user data which is supplied

by a centralized User Modeling Service. Several

applications have been implemented with the Per-

sonal Reader Framework like the Personal Publica-

tion Reader (Abel et al., 2005), the MyEar music rec-

ommender (Henze and Krause, 2006) or the Agent

2.1 The User Modeling Service

The User Modeling Service stores and aggregates

user proﬁle data from various Personalization and

Syndication Services. Because these services, which

can be integrated at runtime and used immediately,

aim on different domains, they also use different on-

tologies to express their knowledge about the user.

For this reason we use RDF statements to store data

domain-independently. A statement contains the user

http://www.personal-reader.de/Agent

as subject, a predicate from the service ontology and

a value as object. Objects can also be more compli-

cated and further RDF statements can be used to de-

scribe the objects in a more detailed way as outlined

in the example scenario in section 2.2.1.

2.1.1 Access Control Layer

The access control layer of the User Modeling Service

has to restrict the access to the data stored in the User

Modeling Service. Therefore, a user should specify

which web services are allowed to access which kind

of data in the user proﬁle and in which way. The envi-

ronment of the access control layer is similar to a ﬁre-

wall: whenever an application tries to access a spe-

ciﬁc port, if an access rule for such application and

port has been speciﬁed, the speciﬁed action (allow or

deny) is performed. Otherwise the ﬁrewall asks the

user how to behave. The ﬁrewall is at no time aware

of which applications or ports exist in a system.

Similarly, as the framework allows to plugin new

services immediately, the access control layer is not

aware of which services will try to access which part

of the user proﬁle. Hence, specifying static access

rules a priori like in other access control systems is

not applicable.

Our access control layer solves this issue by a

deny-by-default behavior. Every service that tries to

access an RDF statement is rejected if no existing pol-

icy is applicable. The service is informed why it was

rejected and will report this to the user. Afterwards,

the user can enter the user interface of the access con-

trol layer to grant or deny access. The user interface

can take the context into account, which contains the

statements a service tried to access, and hence sup-

ports the user in specifying policies by reducing the

choices to the affected statements. By allowing users

to specify also general policies we try to avoid that

the user is overwhelmed by too much interaction with

the access control layer. Keeping user interaction low

enhances usability and at the same time avoids that

users ignore repeatedly displayed conﬁrm messages.

In the rest of the paper, we focus on granting read ac-

cess. A similar approach can be used for write access

requests.

2.2 Policies for Securing Data

Securing RDF data is different from securing usual

datasets. Because RDF datasets can be considered as

graphs we take into account this graph structure in

order to provide a deﬁnition of “security”.

There are many possibilities to secure the data in

the user proﬁle, like black- or whitelisting of services

A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR DYNAMIC USER MODELS

185

Personalization

Service

Personalization

Service

RDF

Connector

Service

...

User Model-

ing Service

User

Syndication

Service

Syndication

Service

Policy

Ecitor

...

access

control

RDF

Figure 1: Personal Reader Architecture.

: (John, phoneNumber, 123)

: (John, hasFriend, Friend 1)

: (Friend 1, phoneNumber, 234)

...

m−4

: (John, hasFriend, Friend

)

m−3

: (Friend

, phoneNumber, 345)

m−2

: (John, hasFriend, Mary)

m−1

: (Mary, phoneNumber, 456)

: (John, loves, Mary)

Figure 2: John’s user proﬁle.

for speciﬁc RDF statements by means of access con-

trol lists. We do not want to mark resources as “ac-

cessible” or not in an automatic way, because the user

should keep full control on which resources (not) to

grant access for. But we also want to relieve the user

from marking each resource individually, so we need

a more ﬂexible solution. We think that policies pro-

vide such a ﬂexible solution. In the following we ex-

amine how Protune policies can be applied to RDF

statements and graphs.

2.2.1 Scenario 1 - Sharing Telephone Number

Information

Let assume that John’s user proﬁle contains the RDF

statements illustrated in Figure 2.

John may want to make the phone numbers of his

friends publicly available, but may want to hide state-

ment S

or maybe even statement S

m−1

. The policy

language Protune allows to deﬁne policies protecting

such statements.

3 PROTUNE POLICY

TEMPLATES FOR A USER

MODELING SERVICE

The policies we need must be able to specify in

a declarative way the prerequisites a service has to

fulﬁll in order to access some resource. The pol-

icy language Protune (Bonatti and Olmedilla, 2005a;

Bonatti and Olmedilla, 2005b) allows to formulate

a broad range of policies like access control poli-

cies, privacy policies, reputation-based policies, pro-

visional policies, and business rules. Some languages,

like e.g. KAoS or Rei (Uszok et al., 2003; Ka-

gal et al., 2003) adopt Description Logics (Baader

et al., 2003) as underlying formalism, whereas Pro-

tune, which extends PAPL (Bonatti and Samarati,

2000) and PeerTrust (Gavriloaie et al., 2004), exploits

Logic Programming and its SLDNF-based reasoning

mechanism (Lloyd, 1987).

One of the main differences between Description

Logics-based (DL-based) and Logic Programming-

based (LP-based) policy languages can be found in

the way they deal with negation: Description Log-

ics allow to deﬁne negative information explicitly,

whereas LP-based systems can deduce negative in-

formation by means of the so-called negation as fail-

ure inference rule. Whilst consistency problems may

arise in DL-based systems (since both a statement and

its negation can be asserted), LP-based systems do

not have to deal with consistency issues, since they

only allow the user to specify positive statements.

LP-based policy languages like Protune may decide

whether the user should only specify allow policies

(thereby relying on the negation-as-failure inference

rule) or the other way around. The ﬁrst approach is

usually preferred, since wrongly disclosing private in-

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

186

formation is a more serious issue than not disclosing

information that should be publicly available.

In our framework we need both usual deny poli-

cies and deny-by-default policies: If a deny-by-

default policy applies, the user is directed to the user

interface to specify new policies, if a usual deny pol-

icy occurs the user is not informed since he already

deﬁned a policy. This feature allows us to implement

in a very clean way the algorithm to be executed by

the access control component (cf. ﬁgure 1), namely

if(a deny policy is defined) deny access

else

if(an allow policy is defined) allow access

else

deny access and ask the user

The access control component checks ﬁrst

whether a deny policy is applicable to the current ac-

cess request and, if it is the case, denies access. If not,

the system checks whether an allow policy is appli-

cable. If this is not the case, access is denied and a

message is sent to the user.

The following Protune policy applies to the RDF

statements example given in the previous chapter. Its

intended meaning is to allow services that belong to

the user-deﬁned group trustedServices to access the

telephone numbers of John’s friends, except Mary’s

number.

allow(access(rdfTriple(Y, phoneNumber, X))) :-

requestingService(S),

rdfTriple(S, memberOf, ’#trustedServices’),

rdfTriple(’#john’, hasFriend, Y),

not Y = ’#mary’.

Predicate rdfTriple retrieves RDF triples from some

RDF repository, whereas predicate requestingService

accesses runtime data in order to retrieve the value

of the current requesting service. The rule the policy

consists of can be read as a rule of a Logic Program,

i.e., allow(access(. . . )) is satisﬁed if predicate re-

questingService, all literals rdfTriple and the inequal-

ity are satisﬁed. Predicates which represent an action

(i.e., requestingService and rdfTriple) are supposed to

be satisﬁed if the action they represent has been suc-

cessfully executed. The policy can therefore be read

as follows: access to RDF triple (Y, phoneNumber,

X) is allowed if the current requesting service (S) be-

longs to trustedServices and X is the phone number of

someone who is a friend of John different than Mary.

3.1 Policy Templates for an RDF based

User Proﬁle

Since expressive policies become quickly hard to read

for non-technical users we deﬁned some general pur-

pose policies in so-called templates.

3.1.1 Templates

Policy types can be deﬁned in several ways:

1. One may group targets (in our case RDF state-

ments or parts of them), so that the user is enabled

to state, what triples should be accessible. Exam-

ples for such a group of targeted RDF statements

are:

• allow access to some speciﬁc phone numbers

• allow access only to my own phone number

• allow access only to my friends’ phone num-

bers

2. Policies may also be grouped according to the re-

quester, so that the user is enabled to state who

gets access to the triples (i.e. allow access for one

service or a speciﬁc group/category of services).

Protune policies allow the usage of both kind of

policy types to protect speciﬁc RDF statements, a spe-

ciﬁc group of statements or, in general, an arbitrary

part of an RDF graph. So, it is possible to

• specify RDF-predicates anywhere used in the user

proﬁle to be secured by a policy

• specify RDF-object/RDF-subject types anywhere

used in the user proﬁle

• specify RDF statements that contain information

directly related to the user, like (John, loves,

Mary), and not just information indirectly related

to the user, like (Friend

, phoneNumber, xyz)

• specify meta-data predicates like requester or cur-

rent time

Our user interface allows to deﬁne policies pro-

tecting RDF graph patterns. When deﬁning a policy

the user must instantiate such patterns and adapt them

to the given context (see Figure 4).

3.1.2 Effects on the User Interface

If there is no policy deﬁned on an RDF statement, an

incoming request is denied by default and the access-

ing service will point the user to the user interface to

deﬁne a new policy regulating the access to the RDF

statement in the future. On the other hand, no user

feedback is requested if a deny policy applies to the

RDF statement and the current requester. Therefore,

the service needs to distinguish between default de-

nial and policy-based denial. Protune by itself uses

only positive authorizations in order to avoid con-

ﬂicts. For this reason we deﬁned a deny predicate on

top of Protune to enable also the deﬁnition of deny

policies. However, if we allow for both positive and

negative authorizations, conﬂicts can arise: This is the

A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR DYNAMIC USER MODELS

187

case whenever a resource is affected by both an allow

and a deny policy. To avoid such situations we de-

signed our user interface in order to ensure that no

conﬂict situations will arise or that they are solved in

precedence.

When the user deﬁnes an allow policy affecting a

resource that is already covered by a deny policy, the

user interface will show a dialog, notifying the user

that there is a conﬂict.

If the user does not want to allow access to the

resource, the allow policy will still be deﬁned (since

in our framework deny policies have by default higher

priority than allow policies),

otherwise the deny policy will be modiﬁed in or-

der to exclude from its scope the affected resource.

On the other hand when the user deﬁnes a deny pol-

icy affecting a resource that is already covered by an

allow policy, the user interface will show a dialog,

notifying the user that there is a conﬂict. If the user

does not want to allow access to the resource, the deny

policy will simply be added (for the same reason de-

scribed above), otherwise a modiﬁed version of it will

be added, which excludes from its scope the affected

resource.

Finally, if the user model changes, new RDF state-

ments can be automatically covered by existing poli-

cies. But the user has also the option to apply his pol-

icy only to RDF statements existing at policy creation

time.

As soon as a service adds RDF statements, the

user will be asked by the user interface whether his

policy should also apply to the new statements.

4 USER INTERFACE FOR

DEFINING ACCESS POLICIES

The interface that enables users to specify Protune ac-

cess policies is called Policy Editor and operates on

top of the access control layer of the User Model-

ing Service as outlined in Figure 1. If a service at-

tempts to access user data for which no access poli-

cies have been deﬁned yet, then the operation of the

service fails and the user is forwarded to the Policy

Editor. The interface which is shown to the user (see

Figure 3) is adapted to the context of the failed op-

eration. Such a context is given by the RDF state-

ments which the service needed to access. Thus, the

overview is split into a part which outlines these RDF

statements, and a part which allows the speciﬁcation

of corresponding access policies. RDF statements are

colored according to the policies affecting them (e.g.

if a statement is not affected by any policy it may be

colored yellow, green statements indicate that at least

one service is allowed to access, etc.). Next to such

statements the interface additionally shows conﬂict-

ing policies by marking affected policies and RDF

statements.

Warnings make the user aware of critical policies.

In Figure 3 the user wants to allow the access to names

to all instances of a class Contact. But as the user may

not be aware that such a policy would also disclose

all future user proﬁle entries containing a name, he

is explicitly prompted for validation. If the user dis-

agrees, he will be prompted whether the policy should

be reﬁned to cover only those name instances that are

currently stored in the user proﬁle.

In general, policies are edited using the interface

depicted in Figure 4. This interface consists of two

main parts which allow to:

1. deﬁne policies (top frame)

2. dynamically show the effects of the policy (bot-

tom frame)

An expert mode is also available, which allows to di-

rectly input Protune policies. Users that do not use the

expert mode just have to instantiate a template con-

sisting of four steps (see top right in Figure 4):

What. The main task during creation of access poli-

cies is the speciﬁcation of RDF graph patterns

which identify statements that should be accessi-

ble or not. The predeﬁned forms for deﬁning these

patterns are generated on basis of a partial RDF

graph consisting of a certain RDF statement (here:

(#contact1, name, ’Daniel Krause’)) and its rela-

tion to the user (#henze, hasContact, #contact1).

To clarify this fact the RDF graph is presented to

the user on the left hand.

To determine the options within the forms schema

information of domain ontologies is utilized. In

the given example the property name is part of the

statement from which the forms are adapted. As

name is a subproperty of contactDetail both ap-

pear within the opened combo box.

By clicking on add pattern or remove the user

is enabled to add/remove RDF statement patterns

to/from the overall graph pattern.

Allow/Deny. The user can either allow or deny the

access to RDF statements expressly.

Who. The policy has to be assigned to some services

or category of services. For example to Contact-

Info, the service trying to access user data, or to

a category like Address Data Services with which

ContactInfo is associated.

Period of Validity. This parameter permits the tem-

poral restriction of the policy.

According to Figure 4 the resulting Protune policy

would be (without period of validity):

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

188

Figure 3: Deﬁning Policies - Overview.

Figure 4: Editing a policy in a detailed view.

A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR DYNAMIC USER MODELS

189

allow(access(rdfTriple(X, contactDetail, _))) :-

requestingService(S),

rdfTriple(S, memberOf,

’#addressDataServices’),

rdfTriple(’#henze’, hasContact, X).

Thus, Address Data Services are allowed to ac-

cess all statements (X, contactDetail, Y) that match

the RDF graph pattern (#henze, hasContact, X),

(X, contactDetail, Y). This policy overlaps with an-

other policy that denies the access to statements

of the form (X, privateMail, Y) wherefore a warn-

ing is presented to the user. This warning also

lists the statements affected by this conﬂict: As

(#henze, privateMail, ’nicola@home.com’) does not

suit, the pattern speciﬁed in Figure 4 (#contact5,

privateMail, ’juri@home.com’) is the only affected

statement. By clicking on “Yes, overwrite!” the deny

policy would be amended with the exception: not

rdfTriple(#contact5, privateMail, ’juri@home.com’).

Otherwise, by selecting “No, don’t overwrite!” both

policies would overlap. But as deny policies outrank

allow policies (cf. section 3) the affected statement

would still be protected.

Next to such warnings the Policy Editor makes the

user aware of how speciﬁed policies will inﬂuence

the access to RDF statements. As name, email, etc.

are subproperties of contactDetail the above policy

permits access to a big part of the user’s RDF graph

which is consequently shown in green (see bottom of

Figure 4).

5 CURRENT IMPLEMENTATION

AND DISCUSSION

In the current implementation

the user interface for

deﬁning access control policies for RDF data supports

already the core functionality described in Section 4.

We furthermore integrated the prototype into the Per-

sonal Reader framework (cf. Section 2) and applied

AC4RDF (Abel et al., 2007) together with Protune to

enforce the policies deﬁned by the users. AC4RDF

is an access control mechanism for RDF stores. It

rewrites queries so that they respect the access poli-

cies speciﬁed via the user interface, i.e. policies as

presented in Section 3.

Regarding usability issues, the main advantage of

our user interface are:

• Easy-to-use – the users do not need to learn any

policy language, policies are created by specify-

ing simple pattern.

The policy editor user interface is made available via:

http://www.personal-reader.de/wp/projects/policy-editor

• Scrutability – users can inspect the effect of the

policy immediately as the RDF data is colored ei-

ther red (access not allowed) or green (Access Al-

lowed)

• Awareness of Effects – whenever a change in a

policy will disclose data in the future, it is not vi-

sualized in the current graph. Hence, users get

a conﬁrmation message to make the aware of the

effects of the changes.

6 RELATED WORK

Controlling the access to RDF data stores can be real-

ized within the RDF query layer. As outlined above,

we utilize AC4RDF (Abel et al., 2007) together with

Protune in our current implementation to enforce the

policies formulated by the users via the easy-to-use

editor presented in this paper. Another approach to

access control for RDF data is discussed in (Dietzold

and Auer, 2006), where access to RDF data is re-

stricted by deﬁning views, which correspond to RDF

subgraphs an inquirer is allowed to access. However

this approach does not make use of policies and thus,

cannot beneﬁt from their advantages (e. g. negoti-

ation, declarative and intuitive structure, and facility

of ﬁne-grained adjustments) and broad range of tool

support (e. g. upcoming possibilities like formulating

policy rules in natural language

) policy languages

like Protune offer.

Beside the policy language Protune, there exist

other policy languages like e.g. KAoS (Uszok et al.,

2003) or Rei (Kagal et al., 2003) that may be utilized

to secure RDF statements. But we didn’t choose those

languages for protecting RDF graph patterns but Pro-

tune instead, because in our approach we make use of

properties like e.g. recursive deﬁnitions and variables

and we also want to exploit advanced features like ne-

gotiations in the future. For some policy languages

there are policy editors available. Because of their

complexity, most of these editors are difﬁcult to use.

KPAT (Uszok et al., 2004), a policy editor for KAoS,

offers to constrain the creation of policies with forms

to ease the usage. However, none of the editors deals

with the visualization of the policies’ consequences

or takes RDF graph structure into account to deduce

policy templates.

Expressing Protune rules in ACE:

http://attempto.iﬁ.unizh.ch/site/

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

190

7 CONCLUSIONS AND FURTHER

WORK

In this paper we presented a user interface that enables

non-expert users to control the access to their RDF-

based user proﬁles. We used the policy framework

Protune to enforce the underlying access control layer

and outlined how to use policy templates to deﬁne ac-

cess control policies. Furthermore, we discussed how

to deal with conﬂicting policies and how a user inter-

face helps to understand complex and expressive poli-

cies and their consequences. We presented the current

implementation of the proposed user interface. In the

future we will evaluate the user interface by testing its

usability. This includes to check whether a user will

be able to express his intention and whether he can be

made aware of the consequences of his policies.

REFERENCES

Abel, F., Baumgartner, R., Brooks, A., Enzi, C., Gottlob,

G., Henze, N., Herzog, M., Kriesell, M., Nejdl, W.,

and Tomaschewski, K. (2005). The personal publi-

cation reader, semantic web challenge 2005. In 4th

International Semantic Web Conference.

Abel, F., Coi, J. L. D., Henze, N., Koesling, A. W., Krause,

D., and Olmedilla, D. (2007). Enabling advanced and

context-dependent access control in rdf stores. In 6th

International Semantic Web Conference, pages 1–14.

Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D.,

and Patel-Schneider, P. F., editors (2003). The De-

scription Logic Handbook: Theory, Implementation,

and Applications. Cambridge University Press.

Bonatti, P. A. and Olmedilla, D. (2005a). Driving and moni-

toring provisional trust negotiation with metapolicies.

In 6th IEEE International Workshop on Policies for

Distributed Systems and Networks (POLICY 2005),

pages 14–23, Stockholm, Sweden. IEEE Computer

Society.

Bonatti, P. A. and Olmedilla, D. (2005b). Policy language

speciﬁcation. Technical report, Working Group I2, EU

NoE REWERSE.

Bonatti, P. A. and Samarati, P. (2000). Regulating service

access and information release on the web. In ACM

Conference on Computer and Communications Secu-

rity, pages 134–143.

Dietzold, S. and Auer, S. (2006). Access control on rdf

triple stores from a semantic wiki perspective. In

Scripting for the Semantic Web Workshop at 3rd Eu-

ropean Semantic Web Conference (ESWC).

Gavriloaie, R., Nejdl, W., Olmedilla, D., Seamons, K. E.,

and Winslett, M. (2004). No registration needed: How

to use declarative policies and negotiation to access

sensitive resources on the semantic web. In 1st Euro-

pean Semantic Web Symposium (ESWS 2004), volume

3053 of Lecture Notes in Computer Science, Herak-

lion, Crete, Greece. Springer.

Henze, N. (2005). Personalization services for the seman-

tic web: The personal reader framework. In Frame-

work 6 Project Collaboration for the Future Semantic

Web Workshop at European Semantic Web Conference

ESWC 2005, Heraklion, Greece.

Henze, N. and Krause, D. (2006). Personalized access to

web services in the semantic web. In SWUI 2006 - 3rd

International Semantic Web User Interaction Work-

shop, Athens, Georgia, USA.

Kagal, L., Finin, T. W., and Joshi, A. (2003). A pol-

icy language for a pervasive computing environment.

In 4th IEEE International Workshop on Policies for

Distributed Systems and Networks (POLICY), Lake

Como, Italy. IEEE Computer Society.

Lloyd, J. W. (1987). Foundations of Logic Programming,

2nd Edition. Springer.

Uszok, A., Bradshaw, J. M., Jeffers, R., Suri, N., Hayes,

P. J., Breedy, M. R., Bunch, L., Johnson, M., Kulka-

rni, S., and Lott, J. (2003). Kaos policy and do-

main services: Toward a description-logic approach

to policy representation, deconﬂiction, and enforce-

ment. In 4th IEEE International Workshop on Poli-

cies for Distributed Systems and Networks (POLICY),

Lake Como, Italy. IEEE Computer Society.

Uszok, A., Bradshaw, J. M., Johnson, M., Jeffers, R., Tate,

A., Dalton, J., and Aitken, S. (2004). Kaos policy

management for semantic web services. IEEE Intelli-

gent Systems, 19(4):32–41.

A USER INTERFACE TO DEFINE AND ADJUST POLICIES FOR DYNAMIC USER MODELS

191