Web Semantics: Science, Services and Agents on the World Wide Web 7 (2009) 11–20

Contents lists available at ScienceDirect

Web Semantics: Science, Services and Agentson the World Wide Web

journa l homepage: www.e lsev ier .com/ locate /websem

Making Web services tradableA policy-based approach for specifying preferences on Web service properties

Sudhir Agarwal, Steffen Lamparter ∗, Rudi StuderInstitute of Applied Informatics and Formal Description Methods (AIFB), University of Karlsruhe (TH), 76128 Karlsruhe, Germany

a r t i c l e i n f o

Article history:Received 15 August 2007Received in revised form29 November 2007Accepted 17 February 2008Available online 18 April 2008

Keywords:Web service policiesPreferences for functional/non-functional

a b s t r a c t

In service-oriented architectures, applications are developed by incorporating services which are oftenprovided by different organizations. Since a service might be offered under different configurations byvarious different organizations, sophisticated service selection and negotiation algorithms are required.Policies capture the conditions under which services are offered or requested and thereby constrain thenegotiation space. However, current policy languages are ill-suited to realize beneficial trade-offs within anegotiation, since they support only Boolean decisions and cannot capture all relevant service information.

Therefore, we present a novel policy language in this work that provides two main contributions: (i)we enable the specification of constraints on functional as well as non-functional properties of Webservices. The functional properties include data objects and the behaviour, whereas the non-functionalproperties include QoS attributes. (ii) Given such constraints, we show how the concept of utility function

properties

Automated negotiations policies can be used to define cardinal preferences over functional as well as non-functional properties.eb sice p

1

tTobcwftEportmpcpt

l(

rttftosmqenottsa

1d

This is required to rank Wnegotiations between serv

. Introduction

Web services are self-contained, modular business applica-ions that have open, Internet-oriented, standards-based interfaces.hey allow flexible and dynamic software integration that isften referred to as the “Find-Bind-Execute”-paradigm. Moreover,y using standard Internet technology, Web services facilitateross-organizational transactions and thus outsourcing of soft-are functionality to external service providers. When moving

rom distributed systems operating within one company to systemshat involve different, independent companies, the “Find-Bind-xecute”-schema describes nothing else than a B2B procurementrocess, where services such as information delivery or executionf calculations are purchased. Thus, service-oriented computingequires an infrastructure that provides a mechanism for coordina-ion between service requesters and providers. This coordination

echanism has to provide a platform where potential business

artners can be discovered, prices can be ascertained, and contractsan be closed. A market, where prices are determined by the inter-lay between supply and demand, can be regarded as a coordina-ion mechanism that efficiently provides these functionalities [19].

∗ Corresponding author. Tel.: +49 721 608 7946.E-mail addresses: agarwal@aifb.uni-karlsruhe.de (S. Agarwal),

amparter@aifb.uni-karlsruhe.de (S. Lamparter), studer@aifb.uni-karlsruhe.deR. Studer).

t

sii

s

570-8268/$ – see front matter © 2008 Elsevier B.V. All rights reserved.oi:10.1016/j.websem.2008.02.001

ervice offers, define their prices, and consequently to realize automatedroviders and requesters.

© 2008 Elsevier B.V. All rights reserved.

In each phase of the market different kind of information isequired. Functional properties are those attributes that are manda-ory to be able to invoke a service and to integrate the results, e.g.he input/output or behaviour of a service. All discovered servicesulfill the desired goal, but may differ in their non-functional proper-ies. These are properties that are not required to invoke the servicer to integrate the results, but they are the decisive factors forervice selection and price determination. For example, price, pay-ent method, security as well as trust properties, and most notably

uality of service properties. Since for each property several differ-nt alternatives can be adopted, sophisticated service selection andegotiation algorithms are required that depend on the preferencesf service providers and requesters. In this entire process one haso make sure that a companies’ policies including business objec-ives, regulative norms, such as Sarbanes-Oxley,1 or IT-Governancetandards (e.g. ISO 200002) are met, while other service propertiesre chosen in an optimal way (e.g. such that costs or the executionime are minimal).

In order to support scenarios, in which Web services consumersearch and bind Web services dynamically without much humanntervention from millions of Web services offered in the market,t is necessary that tasks like service matching, selection and nego-

1 Sarbanes-Oxley Act 2002, available at http://www.legalarchiver.org/soa.htm.2 ISO 20000 IT Service Management Standards, available at http://20000.

tandardsdirect.org/.

1 es and Agents on the World Wide Web 7 (2009) 11–20

tdtFsWtishsagtdl

twbfBtsfptpa

rmfwpcerwmbS

2

taftnhtaQ

2

ofiip

Ftda

mdaro

2

wlttattsabetwatttsWtc

Rtpst

2

mataotb

2 S. Agarwal et al. / Web Semantics: Science, Servic

iation are performed automatically. However, today’s Web serviceescription and policy languages do not support the automation ofhese task since they either lack expressivity or formal semantics.or example, often policy languages are restricted to constraints ontatic properties and cannot express constraints on the behaviour of

eb services. In addition, to support negotiations of service proper-ies a policy language has to support expressing detailed preferencenformation that captures trade-offs between the different pos-ible Web service configurations. Therefore, information beyondard constraints is required. In order to enable interoperability andupport automation of tasks like service matchmaking, negotiationnd selection, it is not enough to have an expressive policy lan-uage, but the language should also have formal semantics, suchhat automatic reasoning procedures for policy evaluation can beeveloped and one can make sure that different agents interpret

anguage constructs in the same way.In this paper we present a formal policy language that enables

he specification of cardinal preferences on arbitrary functional asell as non-functional properties of a Web service. We realize this

y developing a policy ontology that supports the concept of utilityunction policies [23] and thereby captures detailed preferences.y augmenting the ontology with a temporal logic, preferences onhe behaviour of a Web service can be specified, yielding an expres-ive policy language that allows specification of soft constraints onunctional properties including behaviour as well non-functionalroperties. By calculating the utility of a given Web service descrip-ion according to the requester’s policies that include detailedreference information, automatic support for the matchmakingnd negotiation can be enabled.

The paper is organized as follows. In Section 2, we first elabo-ate on the requirements a policy language for Web services shouldeet and then discuss in Section 3 whether these requirements are

ulfilled by existing approaches. In Section 4, a general policy frame-ork is introduced that features the concept of utility functionolicies. By means of customizable matching rules the frameworkan be adapted to arbitrary functional and non-functional prop-rties. The specification of preferences on functional propertiesequires to define constraints on the behaviour of Web services,hich is discussed in Section 5. In Section 6, a prototypical imple-entation of the policy evaluation algorithm is presented that

uilds upon a standard OWL-DL reasoner. Finally, we conclude inection 7 with a brief summary and a short outlook.

. Requirements

In this section, we motivate with examples various requirementshat a Web service policy language should fulfil in order to be suit-ble for dynamic Web service markets. We distinguish betweenunctional and non-functional properties of Web services. Func-ional properties of a Web service are those properties that a clienteed to know in order to be able to embed the Web service inis/her software system. That is, functional properties are invoca-ion related properties. Non-functional properties of a Web servicere the properties that describe credentials of the Web service, e.g.oS attributes.

.1. Requirements concerning functional properties

A Web service operates on resources that can be real world

bjects or information objects. A Web service expects resourcesrom the client and delivers resources to the client. A Web services a process that in general may involve many actors with multiplenteractions among them. An interaction between two actor takeslace in form of a message exchange. Fig. 1 shows the functional

vbpba

ig. 1. Model of a Web service concerning functional properties illustrated withhree actors. The dashed lines denote the control flow from left to right and theotted lines denote the data flow from the activity adorned with ‘−’ to the activitydorned with ‘+’.

odel of a Web service that involves three actor A, B and C. Weenote the set of actors involved in a Web service with A. Eachctor A∈A is associated with a resource schema SA, a finite set ofesources RA and a behaviour BA. The resources can be real worldbjects or information objects (refer to Fig. 1).

.1.1. Constraints on resourcesConsider for example a library that maintains a wish list of books

here the library members can enter the ISBN of books they wouldike to have. On the basis of some ranking (e.g. number of membershat wish the book) of the desired books the library system needso place book orders at regular intervals. At the time of designingnd implementing the library system the software engineers needo find book selling Web services. Suitable book selling services arehose that accept an ISBN and deliver a book. Considering the librarycenario a bit deeper, we identify that the software engineers arectually interested in Web services that do not sell just any book,ut exactly the book that is ordered by the library software. In thisxample a suitable Web service is one that delivers a book withhe same ISBN as the one it obtains as input. In realistic scenariose must consider that there are many book selling Web services

vailable and there is no global vocabulary for the domain of bookshat every Web service provider can or wants to use for describinghe resources of his book selling Web service. As a result, we haveo assume that in general Web service providers describe their Webervices with their respective vocabularies independently of other

eb service providers. Similarly, a requester needs a vocabularyhat he understands to be sure that the constraints that he specifiesapture the intended meaning.

equirement 1 (Constraints on resources). It must be possibleo define constraints on the values and types of input and outputarameters of a Web service. The formalism for specifying con-traints on resources must be able to consider mappings amonghe vocabularies while checking the satisfiability of constraints.

.1.2. Constraints on behaviourA suitable Web service for the library system must have the

atching (opposite pole) communication pattern so that the inter-ction between the Web service and the client can take place. Ifhe Web services had only one input activity and only one outputctivity, one may assume that a Web service always perform theutput activity after the input activity. As a consequence matchinghe communication patterns of the client and a Web service woulde trivial. However, in general this is not the case. Even if Web ser-

ices abstract from implementation details, the process triggeredy invoking a Web service may be very complex involving multi-le interactions with the client or other Web services. Consider aook selling Web service that after receiving a book order, sendsconfirmation to the client and expects a back confirmation. Only

S. Agarwal et al. / Web Semantics: Science, Services and Agents on the World Wide Web 7 (2009) 11–20 13

trans

aoitlsmamnc

tcs(vobtat

Rosoi

scmvfi

Rmd

Raidps

Dsacas

imc

tdttwd

2

splvoifap“d

RTtt

2

ascwa

Rsc

2

Fig. 2. From execution model to labeled

fter receiving the back confirmation from the client, it sends therdered book to the client. Even if the Web service receives an ISBNn the first input activity and output the book with the same ISBN inhe last activity, it may not be suitable for the library system, if theibrary system does not foresee to receive an order confirmation andending a back confirmation. In other cases, an opposite situationay occur. That is, a client system is ready to receive a book only

fter it has received an order confirmation and sent a back confir-ation, but the Web service neither sends any order confirmation

or it waits for a back confirmation before sending the book to thelient.

While the above requirement concerns the public communica-ion protocol of the Web services (choreography), there are useases, in which a requester may be interested in specifying con-traints on the internal communication structure of a Web serviceorchestration). Consider, for example a company internal Web ser-ice exposing a complex order process. It may be desired that therdered good must be approved by at least two managers before it isought. In other words, this means that in order to check whetherhe Web service is compliant to company’s policies, one must beble to reason about the information flow and the order of activitieshat transport information.

equirement 2 (Constraints on communication patterns). Inrder to find Web services that can be incorporated in the clientystem it must be possible for the requester to specify constraintsn the public communication pattern (choreography) as well asnternal communication pattern (orchestration) of a Web service.

A Web service execution may cause changes in the knowledgetate of the participants. For example, charging requester’s creditard as a consequence of the order he has placed is performed byeans of an update (setting the available credit amount to a lower

alue) in the database of the corresponding bank. While searchingor desired Web services, a requester may be interested in specify-ng which effects he wishes to take place and which not.

equirement 3 (Constraint on changes of resources). The for-alism for specifying constraints must support specification of

esired and undesired changes in the resources.

Requirements 2: Constraints on communication patterns andequirements 3: Constraints on changes of resources can be seens constraints that specify desired or undesired situations dur-ng the execution of a Web service. Informally, such a situationescribes the knowledge states of the involved actors and theirossible behaviour at a particular point in time. Formally, such aystem can be described as a labeled transition system.

efinition 1 (Labeled transition system). A labeled transition

ystem is a tuple (S, A, S) where S is a set of states, A is a set of actionsnd→⊆ S × A× S is a ternary relation between states and actionsalled transition. If s, s′ ∈ S and a∈A, then (s, a, s′)∈ → representstransition from state s to s′ triggered by action a and is writtena→s′.

idahc

ition system with execution semantics.

A state s∈ S characterizes a system or system component ands usually described by a set of attributes (directly or indirectly)

easured by a sensor. In a current state s a certain set of actions Aan be taken which results in a transition to a new state s′.

Fig. 2 shows on the left-hand side various situations or stateshat may occur during the execution of the example Web serviceepicted in Fig. 1. The right-hand side of the Fig. 2 shows the labeledransition system of the example Web service. ForA = {A1, . . . , An},he sets of resources RA1 , . . . , RAn of the agents A1, . . . , An, togetherith their behaviours BA1 , . . . , BAn at some given point of time,escribe the state of the system at that time.

.2. Requirements concerning non-functional properties

In practical scenarios, a user often selects a service from the set ofervices with same functionality on the basis of its non-functionalroperties. For example, from many book selling Web services, the

ibrary wishes only Web services that offer a customer hotline. Aery important issue concerning non-functional properties is thatf interoperability, since in distributed and open environments, its not realistic to assume a global vocabulary of the names of non-unctional properties. Rather, Web services providers should beble to chose the property names independent of other Web serviceroviders. For example, if a Web service property calls a propertyhotline”, another Web service might want to call it “helpdesk”. Weenote with P the set of all non-functional properties.

equirement 4 (Constraints on non-functional properties).he formalism should allow a requester to specify constraints onhe non-functional properties in an interoperable way to restricthe set of involved actors.

.3. Requirements concerning combination of constraints

Above we have identified that a user should be able to specifyconstraint on functional and non-functional properties of Web

ervices. In practice, often a user wishes to specify more than oneonstraint and combine them logically. For example, a user mayish to search for book selling services that offer customer hotline

nd charge the credit card after the delivery of the ordered book.

equirement 5 (Combination of constraints). The formalismhould allow the specification of complex constraints from simpleronstraints of possibly different types.

.4. Requirements concerning soft-constraints

Until now we considered constraints as knock-out criteria. That

s, if a Web service does not fulfil a constraint, it should not beetected as a match. However, in practice, often a user’s constraintsre not always so hard. Rather a user should be able to specifyis preferences on different alternatives. For example, instead ofompletely ruling out a Web service that does not offer a customer

14 S. Agarwal et al. / Web Semantics: Science, Services and

Table 1Assessment of related work

Requirement

1 2 3 4 5 6

OWL-S [42]√

– – (√

) – –WSMO [39]/WSML [7]

√– –

√– –

B√ √ √

KCB

htatcscvca

Rsa

3

mamt

3

iOitsaarta

WvsbveatoasdCardb(

ldts

dasrplaiOmc(cwa

3

scib(miassfiorcIDptomaFsitwbacrot6cls

erardi et al. [4] – – –AoS [45]/REI[20]/Kolovski et al. [27]

√– –

√ √–

ontract languages [15,40,38,36]√

– –√ √ √

ienvenu et al. [5] –√ √

–√

(√

)

otline, a user may wish to specify that he prefers the one with cus-omer hotline to one without customer hotline. In another example,user may wish to specify that he prefers Web services that charge

he credit card after the delivery to those that charge the creditard before the delivery. In order to decide now whether a Webervice that provides a customer hotline and charges the creditard before delivery should be preferred to a Web service that pro-ides no customer hotline but charges the credit card after delivery,ardinal preferences that explicitly specify the trade-off betweenlternatives are required.

equirement 6 (Specification of preferences). The formalismhould allow to specify preferences on different types of constraintsnd constraint combinations.

. Related work

In this section, we review literature with respect to the require-ents for Web service policies identified above. Table 1 provides

n overview and shows whether the approaches fulfill our require-ents (indicated by a check mark). A first set of approaches suggest

o use ontologies for describing Web services.

.1. Web service description

One of the early approaches that present an ontology for describ-ng Web services is OWL-S [42]. The OWL-S Matchmaker usesWL-S Profile for describing Web services. Even if OWL-S Profile

s designed for modeling pre and post-conditions in addition to theypes of input and output parameters of the Web services, there istill no concrete formalism fixed for describing the conditions. Asresult, the constraint specification reduces to the types of input

nd output parameters. So, it neither allows the specification ofelationships between inputs and outputs nor constraints on theemporal structure of a Web service or preferences over functionalnd non-functional service properties.

Another approach to semantic Web service descriptions isSMO (Web service modelling ontology) [39] which is expressed

ia WSML (Web service modelling language) [7]. A WSML goalpecification is identified by the goalkeyword and consists of capa-ilities and interfaces. A capability description consists of sharedariables, pre- and post-conditions as well as assumptions andffects. Due to the availability of shared variables WSML goalsre more expressive than OWL-S Profiles. The interface descrip-ion is used to specify the desired choreography and orchestrationf a Web service. In other words, the WSMO interface used ingoal specifies constraints on the dynamic behaviour of a Web

ervice. However, currently there is no concrete proposal forescribing the choreography and orchestration (Requirements 2:onstraints on communication patterns) and updates of resources

re not supported (Requirements 5: Constraints on changes ofesources). Furthermore, due the separation of capabilities andynamic behaviour already at the conceptual level, one would note able to specify temporal constraints on effects, which contradictsRequirements 6: Combination of constraints). That is, constraints

h[te

Agents on the World Wide Web 7 (2009) 11–20

ike “the action ‘charge credit card’ (effect) should take place afterelivery (choreography)”. Furthermore, the WSMO goal specifica-ion does not capture preferences which are required to rank andelect services (Requirements 6: Specification of preferences).

Perhaps, the work that is closest to our work as far as theescription of Web services is concerned is [4], in which anpproach is presented to characterize Web services with their tran-ition behaviour and their impacts on the real world (modeled aselational databases). In our work, local knowledge bases of thearticipating actors are represented with a decidable description

ogic, which can be helpful in proving decidability of discoverynd composition algorithms. In addition, using description logics also more suitable for the Web since the Web Ontology LanguageWL standardized by W3C is based on description logics. Anotherajor difference is the choice of the logic for specifying temporal

onstraints on Web services. [4] uses propositional dynamics logicPDL) whereas we have used a more expressive logic �-calculus. Inontrast to our work, [4] does restrict their approach to goal policieshich are not sufficient for ranking Web services and negotiating

bout Web service properties.

.2. Policy specification

As discussed above, the state of the art regarding Semantic Webervices currently provides only limited support for expressingonstraints on non-functional service properties. Therefore, pol-cy languages such as KAoS [45], REI [20] and the work presentedy Kolovski et al. [27] can be used to extend the service ontologiese.g. [21]). While KAoS and the approach by Kolovski et al. are based

ainly on OWL-DL, REI uses OWL-Lite only as syntax for exchang-ng policies and performs reasoning based on a logic programmingpproach supporting rights, prohibitions, obligations and dispen-ations. How KAoS policies are used for managing semantic Webervices is outlined in [45]. Since pure OWL-DL is not fully suf-cient to cope with the situation where one value depends onther parts of the ontology, they extend the logic by so calledole-value maps (see also [2]). Recently this issue is addressed byombining description logics and logic programming [35,44,34].n our work, we adhere to such a combination by using OWL-L with DL-safe rules (see Section 4.2.1). The approach to formalolicy languages by Kolovsiki et al. [27] defines the semantics ofhe WS-Policy specification also by means of an OWL-DL ontol-gy. This allows them to use a standard OWL reasoner for policyanagement and enforcement. However, due to the open world

ssumption of OWL their results sometimes are counterintuitive.or our work the open world assumption is currently no problem,ince only subsumption-based matching of attribute values is usedn the policy evaluation process. In case other DL-based reasoningechniques such as satisfiability checking are introduced, the openorld assumption of OWL can become problematic. This issue haseen addressed by the use of non-monotonic logics in [26,14,13]nd by manually closing the ontology. The latter can be realized byhanging axioms in the ontology [10] or by introducing additionalestrictions to the knowledge base [12]. The major disadvantagef the mentioned policy formalisms in our context is their limita-ion in terms of expressing fine-grained preferences (Requirements: Specification of preferences). Using these approaches only hardonstraints can be expressed and policy evaluation thus alwayseads either to true or false, which is insufficient for ranking of Webervice offers.

Several approaches for representing preference informationave been proposed in literature, e.g. based on utility functions46,9,22], fuzzy logics [6,25] or other forms of preference represen-ation like [24,3]. However, they typically do not consider a Webnvironment where preference information is exchanged between

es and

hdatetsa

stublatapabdpdrffuatHap

iacddrtiinpf

4

aetfbb6mo

4

ith

eibtsctWUCaCPtsacbb

DdeTU

∀SiipSsdi

tatti

Evpamc

U

Tti

•

•

S. Agarwal et al. / Web Semantics: Science, Servic

eterogenous agents and matching of attribute values has to beone by considering rich semantic structures. Since service offersnd requests are typically defined on different levels of abstrac-ion (e.g. while a service requester might specify that asymmetricncryption methods are preferred, a service provider might specifyhat only the RSA algorithm is supported), this is not sufficient forpecifying policies for open and heterogenous environments suchs the Web.

More expressivity in this context is provided by rule languages,uch as SweetDeal [15], DR-NEGOTIATE [40,11], RBSLA [38] andhe approach presented by Oldham et al. [36]. While the formerse defeasible reasoning (i.e. Courteous Logic Programs or defeasi-le logic) to specify contract templates (including preferences), the

atter formalizes WS-Agreement and expresses preferences usingproprietary rule language. Similar to our approach they all fea-

ure automatic reasoning based on a formal logic. However, therere some issues regarding the use of a (pure) logic programmingaradigm. Often such languages do not provide full-fledged declar-tive semantics and thus combining rules from different sourcesecomes highly problematic. In fact, manual integration of theifferent logic programs might be required. Since in our setting,olicies have to be integrated from different sources, this is a majorrawback. There are few approaches that combine preference rep-esentation formalisms with techniques for handling informationrom heterogenous sources. For example, Klein et al. [25] combineuzzy concepts with service hierarchies, Lamparter [29] combinestility theory with OWL-based service descriptions, and Felfernig etl. [8] as well as McGuinness et al. [33] combine constraint satisfac-ion problems with descriptions logic-based product descriptions.owever, all these approaches do not consider temporal behaviours required by Requirements 2: Constraints on communicationatterns.

Temporal aspects are addressed by the approach presentedn [5], which allows the specification of temporal constraintsnd shows how qualitative preferences can be attached to theseonstraints. While qualitative preferences are often sufficient toetermine rankings of Web service offers, they are not suitable toefine the trade-offs between different alternatives, which is oftenequired during negotiations. Furthermore, since the best alterna-ive might not be good enough, an absolute measure of suitabilitys required. In our work, we address these problems by introduc-ng a cardinal utility measure. In addition, Bienvenu et al. [5] doot elaborate on the specification of constraints on non-functionalroperties of Web services (Requirements 4: Constraints on non-unctional properties).

. Specification of utility function policies

In this section, we show how utility function policies thatre expressed formally via an ontology can provide the requiredxpressivity to meet Requirements 1–6. We first introduce in Sec-ion 4.1 an abstract policy model that takes up traditional conceptsrom decision theory and shows how preferences can be capturedy means of utility functions. This is important to express trade-offsetween different alternatives and thereby to meet Requirements: Specification of preferences. After introducing the abstract policyodel, we show how this model can be implemented using existing

ntology languages in Section 4.2.

.1. Policy model

As postulated by Requirements 6: Specification of preferences,n order to support the optimal allocation of Web services in a sys-em, the trade-offs between different Web service configurationsave to be explicitly specified. Policy that provide the necessary

•

0

Agents on the World Wide Web 7 (2009) 11–20 15

xpressivity to capture this information are referred to as util-ty function policies [23], which represent the functional relationetween alternatives and their value for the decision maker. Overhe last decades, there has been a broad stream of work aboutpecifying utility functions [46,9,22]. The goal is to provide suffi-ient expressivity for modeling complex decisions, while keepinghe elicitation and computation effort at an admissible level. In a

eb services scenario, a utility function can be defined as a function: C → Rmapping the set of possible Web service configurationsto a real-valued measure reflecting the value a decision maker

ttaches to a certain alternative. The set of possible configurationsis defined as the Cartesian product C = P1 × · · · × Pn, where the

1, . . . , Pn ∈P refers to functional and non-functional attributeshat describe a Web service. The utility is measured on a cardinalcale, which allows making statements about the relative as wells absolute suitability of a configuration. They thus generalize theoncept of goal policies by allowing not only two levels ‘admissi-le’ and ‘not admissible’, but make all configurations comparabley introducing a preference structure over the configurations.

efinition 2 (Preference structure). A preference structure isefined by the complete, transitive, and reflexive relation �. Forxample, the configuration c1 ∈C is preferred to c2 ∈C if c1 � c2.he preference structure can be derived from the utility function(c) by means of the following condition:

ca, cb ∈C : ca � cb ⇔ U(ca) ≥ U(cb) (1)

ince policy-based decision-making approaches are usually appliedn large-scale applications, typically more than one policy is spec-fied in order to regulate a certain decision. Therefore, traditionalolicy languages support conjunctions and disjunctions of policies.ince in this work we focus on the specification and evaluation of aingle policy, introducing primitives for modeling conjunctions andisjunctions goes beyond the scope of this paper and is discussed

n [29, Chap. 6.2].In the context of a service-oriented architecture, utility func-

ions policies can be used on requester-side to specify preferences,ssess the suitability of trading objects and derive a ranking ofrading objects based on these preferences and on provider-sideo specify the reservation price of a provider. The latter case isllustrated by the following example.

xample 1. We take up our initial example and assume a Web ser-ice request where preferences are specified via a utility functionolicy. The policy captures an additive utility function, where valu-tions are given for each attribute separately. This typically requiresutual preferential independency between the attributes [22] and

an be expressed via the following function:

(c) =∑

i∈ [1,n]

�iui(pi) (2)

hat means the willingness to pay of the requester depends onhe configuration and can be defined via functions for each of thendependent attributes uj(pj) as follows:

Functional property ‘Behaviour’: u1(p1) is defined by the pointsP (“payment before delivery”, 0) and P (“payment after delivery”,1).Non-functional property ‘Response Time’: u2(p2) = 1− (1/10)p1with p1 measured in seconds.

Non-functional property ‘Hotline’: u3(p3) is defined by the pointsP (“yes”, 1) and P (“no”, 0.5).

Furthermore, we assume weights of �1 = 0.5, �2 = 0.2, and �3 =.3. For example, given this request a Web service that charges the

1 es and

cp

4

maLiti

4

W(ltm

iupOsoadnFiaaaasbcaakaA

fv[rwit

4

ifttr

tD

dihuatoitarcid

Isimrae

RbaaItt

ofVeta‘

SnFbSfme

6 S. Agarwal et al. / Web Semantics: Science, Servic

redit card before delivery, guarantees a response time of 2 s androvides no hotline would consequently lead to a utility of 0.65.

.2. Policy ontology

Given the abstract policy model above, we now focus on imple-enting this model using existing standards and tools for the open

nd heterogenous Web environment. We use the Web Ontologyanguage OWL [47] together with its rule extension SWRL [18] tomplement our policy model, which allows us to perform sophis-icated matchmaking and ranking of services by means of logicalnferencing.

.2.1. Ontology formalismOWL is an ontology language standardized by the World Wide

eb Consortium (W3C) [47] and is based on the description logicDL) formalism [2]. Due to its close connection to DL it facilitatesogical inferencing and allows to derive conclusions from ontologieshat have not been stated explicitly. We briefly review some of the

odeling constructs of OWL.The main elements of OWL are individuals, properties that relate

ndividuals to each other and classes that group together individ-als which share some common characteristics. Classes as well asroperties can be put into subsumption hierarchies. Furthermore,WL allows for describing classes in terms of complex class con-

tructors that pose restrictions on the properties of a class. Basedn names for concepts (as C, D, . . .), roles (R, S, . . .), and individu-ls (a, b, . . .), OWL provides constructors like negation, conjunction,isjunction, existential quantifier, universal quantifier and qualifiedumber restrictions to build complex concepts from simpler ones.urther, it supports concrete datatypes and there exist correspond-ng axioms for quantifiers and cardinality constraints for roles with

datatype range. Therefore, an OWL knowledge base consists ofset of axioms, which can be distinguished into terminological

xioms (building the so-called TBox T) and assertional axioms orssertions (constituting the ABox A). A TBox consists of a finiteet of concept inclusion axioms C � D, where C and D are eitheroth concepts or relations. The A-Box consists of a finite set ofoncept assertions C(a), role assertions R(a, b), individual equalities= b, and individual inequalities a /= b. Those assertional axioms or

ssertions introduce individuals, i.e. instances of a class, into thenowledge base and relate individuals with each other. For detailsbout the semantics of OWL-DL constructors, T-Box axioms and-Box axioms, we refer to [47,17,2].

For the declarative formulation of policy evaluation process inorm of rules, we require additional modeling primitives not pro-ided by OWL. We use the Semantic Web Rule Language (SWRL)18] which allows us to combine rule approaches with OWL. Weestrict ourselves to a fragment of SWRL called DL-safe rules3[35],hich is more relevant for practical applications due to its tractabil-

ty and support by inference engines such as KAON2.4 For the nota-ion of rules we rely on a standard first-order implication syntax.

.2.2. Representation and evaluation of policiesIn this section, we show now how the policy model introduced

n Section 4.1 can be implemented using the standard ontology

ormalisms introduced above. Fig. 3 sketches the policy ontologyhat enables the representation of Web service policies based onhe concept of utility function policies. In our ontology this iseflected by the concepts Web Service Policy that, on the one hand,

3 DL-safety restricts the application of rules to individuals that are explicitly men-ioned in the ontology. However, this restriction does not affect the suitability ofL-safe rules in our scenario.4 http://kaon2.semanticweb.org/.

daaectiobt

Agents on the World Wide Web 7 (2009) 11–20

escribes the technical aspects of a Web service such as the phys-cal address captured by the concept Service and, on the otherand, enables the specification of functions that assign certain val-ations to service properties. This requires to express functions indeclarative way using the ontology formalism at hand. We realize

his by specializing the concept Utility Function. Approachesn how functions are expressed via an ontology are discussedn [31,32]. There are mainly three techniques for modeling func-ions: Point-based Functions, Piecewise Linear Functionsnd Pattern-based Functions. While the former approach isestricted to discrete functions, the latter two approaches are appli-able to arbitrary continuous functions. To illustrate the basicdea, the concept Point-based Function is introduced in moreetail.

A Point-based Function can be used for discrete properties.n this context the utility function ul(pl) is modeled by specifyingets of Points that explicitly map a Property Value referred ton a Property Value Pair to a utility measure. Based on this

odel the following rule can be used to evaluate the policy p withespect to a given configuration c. A Configuration is modeleds a concept that has exactly one (datatype or object) property forach service property.

evaluatePolicy (p, c, u)← Policy(p),Configuration(c),

∧i=1,...,n(defines(p, fi)),

PointBased(fi),constitutedBy(fi, pti),propertyValue(pti, pvi),utility(pti, ui),hasPropertyi(c, pri),match((pvi, pri)),SWRLB:add(u, u1, . . . , un)

(3)

ule 3 basically captures the additive utility function given in Eq. 2y comparing each property of the configuration with the appropri-te Points in the definition of the Point-based Function and bydding up the utility values belonging to matching property values.n order to determine whether property values match each other,he match-predicate is applied. In the following, we discuss howhis predicate is defined.

The way property values are modelled in the ontology dependsn the type of the property. For instance, in case of the non-unctional properties ‘Response Time’ and ‘Hotline’ the Propertyalue can be directly represented as literals in the ontology. In thevaluation process such property values can be compared by opera-ors such as ‘=’, ‘<’, etc. We thus define matching rules to specify howcertain property should be matched. For example, the property

Hotline’ should be matched by a ‘=’-operator:

match(x, y)← hasProperty(x,‘ Hotline’ ),hasValue(x, v1),SWRLB:equals(v1, y)

(4)

ince there are settings in which all possible property values can-ot be enumerated or are not known, this approach is not sufficient.or example, assume the property ‘Encryption’ that defines possi-le encryption algorithm which are supported by a Web service.ince enumerating all possible encryption algorithms might not beeasible, an alternative approach is required. Therefore, we use a

eta-modeling approach in which instances of the concept Prop-rty Value in our policy ontology are considered as concepts in aomain ontology. For example, for the service property ‘Encryption’concrete Property Value could be ‘Asymmetric’ identifying

ll possible asymmetric encryption algorithms as defined in thencryption ontology (see Fig. 3). However, the matching of suchoncept-based property values has to be done differently compared

o the instance-based property values specified above. To real-ze the concept-based matching, we build on well-known notionsf matching for Semantic Web services, such as subsumption-ased ‘plugin’ or ‘exact’ matches [37]. For the property ‘Encryption’his means that we could use the following matching rule to

S. Agarwal et al. / Web Semantics: Science, Services and Agents on the World Wide Web 7 (2009) 11–20 17

licy o

imtc

Wbcslpa

5W

oloTooifsoaalcsft

toaia

5

LXcbp

Dt→for the atomic propositions. We often write s

a→t for (s, a, t)∈ →.

Given a structure T and an interpretation V : Var→ P(S) of thevariables, the set [[�]]� of states satisfying a formula � is definedin column three of Table 2.

Table 2� Syntax and Semantics

Name Syntax Semantics

True true SFalse fals ∅Atomic proposition P �Props(P)Conjunction �1 ∧ �2 [[�1]]� ∩ [[�2]]�Universal quantifier [a]� {s|∀t s

a→t ⇒ t ∈ [[�]]}

Fig. 3. Po

ndicate that a certain utility should be associated with all asym-etric encryption algorithms. The built-in subsumes implements

he algorithm that checks for subsumption between two OWLoncepts:

match(x, y)← hasProperty(x,‘ Encryption’ ),hasValue(x, v1),subsumes(v1, y)

(5)

hile policies on non-functional properties can be specified purelyased on the ontology languages OWL-DL and DL-safe rules, poli-ies on functional properties require statements about the temporaltructure of actions, which cannot be expressed using descriptionogics. Therefore, we discuss in the next section how we can incor-orate a temporal logic into our framework and show how theppropriate matching rule is defined.

. Specification of constraints on functional properties ofeb services

In this section, we present a formalism to specify constraintsn behaviour of Web services. The main aim of a goal specificationanguage is to provide a syntax and semantics to restrict the setf states in such a labeled transition system (refer to Definition 1).hat is, by specifying constraints, a user should be able to fix the setf states that may/should occur in the execution of a Web servicer a Web service composition. Note, that our view of Web servicess not restricted to “black-box” like Web services with interfacesor one input and one output. As illustrated in Figs. 1 and 2, a Webervice may involve multiple actors and multiple interactions (notnly with the client). So, the only difference between a Web servicend a Web service composition is that the composition is more likebusiness process, the description of which is at first available only

ocally to the client that has composed the business process. If thelient wishes to offer the business process as a Web service, he orhe needs to compile the description of the Web service suitableor publishing by hiding internal information while still not losinghe semantics of the Web service.

NMD

EM

ntology.

We will first introduce � calculus and show how it can be usedo specify constraints on a labeled transition system. � calculus isne of the most expressive temporal logics while still being decid-ble [28]. Then we will add a facility to specify constraints on thenvolved resources by giving structure to � calculus propositionsnd actions.

.1. Specifying constraints on behaviour with �calculus

� calculus, as it is mostly used today was first introduced in [28].et Var be an (infinite) set of variables names, typically indicated by, Y, Z . . .; let Prop be a set of atomic propositions, typically indi-ated by P, Q, . . .; and let A be a set of actions typically indicatedy a, b, . . .. The syntax of formulae with respect to (Var,Prop,A) isresented in column two of Table 2.

efinition 3 (Structure). A structure T (over Prop, A) is a labeledransition systems, namely a set S of states and a transition relation⊆ S× A× S, together with an interpretation VProp : Prop→ P(S)

egation ¬� S \ [[�]]�inimal fixpoint �Z · � ∩{S ⊆ S|S ⊆ [[�]]�[Z := S]}isjunction �1 ∧ �2 [[�1]]v ∪ [[�2]]v

xistential quantifier 〈a〉� {s|∃t sa→t ∧ t ∈ [[�]]v}

aximal fixpoint �Z� ∪{S|S ⊆ [[�]]v[Z := S]}

1 es and

oo�rpT

5O

toaaa

pcs

sop+atusap

lh+itvpIlmt[Rbprb

5

WwtTdsitwma

fttaslmcnlmm

5

ccomsfsuoaa

E‘am

¬Tpsc

¬Nwpnp

oppis

Eac((p

8 S. Agarwal et al. / Web Semantics: Science, Servic

With fixed point operators, one can define all known constraintsn the temporal behaviour. In the following, we give examplesf some most widely known temporal operators. The formulaX · (�2 ∨ (�1 ∧ 〈−〉true[−]X)) describes �1 until �2, as it can be

ead as: either �2 holds in the current state or sooner or later therocess reaches a state in which �2 holds and until then �1 holds.he modality eventually� can be easily defined as true until�.

.2. Adding structure to � calculus propositions and actions withWL-DL

� calculus in its pure form abstracts from the meaning and struc-ure of the propositions. In our formal model, the set of propositionsf an actor correspond to the facts in the knowledge base of thector. The facts (explicit or derived) in the knowledge base of anctor at some point of time represent the set of propositions thatre true at that point of time.

We use a OWL-DL description D in place of � calculus atomicropositions (denoted by P in Table 2), which is true if the OWL-DLoncept D has some instances in the knowledge base of the Webervice.

For actions (see � calculus formulas 〈a〉� and [a]�), we makeimilar structural extensions. We differentiate between input andutput actions by using the sign ‘+’ or ‘−’ for input and out-ut actions, respectively. We give an input action a the structure(P, A, v1 : T1, . . . , vm : Tm), which means a Web service performsn input action that can receive m values of types T1, . . . , Tm, respec-ively, over a channel of protocol P at the address A. Similarly, wese −(P, A, Q1, . . . , Qm) for an output action, which means a Webervice performs an output action that sends m values which arenswers of the queries Q1, . . . , Qm, respectively, over a channel withrotocol P and address A.

Having introduced our goal specification language, we nowook back to the requirements identified in Section 2 and discussow our language covers the requirements. In an input formula(P, A, v1 : T1, . . . , vm : Tm), T1, . . . , Tn are desired input types and

n an output formula −(P, A, Q1, . . . , Qm), Q1, . . . , Qm are descrip-ion logic queries. The queries Q1 . . . , Qm can use the processariables, e.g. those in an input formula. This way it becomesossible to establish relationships between inputs and outputs.

nteroperability is covered by the fact that we use descriptionogic OWL-DL for specifying constraints on terminologies. Simple

appings between terminologies can be expressed via subsump-ion relationship, whereas complex mappings with DL-safe rules16]. So, the Requirements 1: Constraints on resources is fulfilled.equirements 2: Constraint on communication patterns is coveredy formula types [a]� and 〈a〉�. By using OWL-DL descriptions asropositions we fulfill Requirements 3: Constraints on changes ofesources. Requirements 5: Combination of constraints is fulfilledy the logical connectors available in the language.

.3. Evaluating constraint satisfaction

Having a language for specifying constraints on the behaviour ofeb services, we now turn our attention to the problem of checkinghether a Web service behaviour fulfils a given constraint. Recall

hat formally we view a Web service as a labeled transition system.here are approaches like OWL-S, in which a Web service process isescribed. Such a process model can be converted to a labeled tran-ition system with an appropriate execution semantics (Fig. 2). So,

n any case we have a labeled transition system of a Web service andhe states of the LTS are annotated with the formulas of the languagee presented above [41] first introduced a set of tableau rules forodel checking � calculus formulas. We use these tableaux rules asbasis and modify them as required by our structural extensions

wa

Agents on the World Wide Web 7 (2009) 11–20

or atomic propositions and actions. An approach for calculatinghe LTS for a Web service online, which is not beforehand but at theime of checking the constraint satisfaction, is presented in [1]. Itlso shows that the time complexity of checking, whether a Webervice with n states fulfills a constraint represented by a formula ofength m is O(n ·m). In practical scenarios, m, the length of the for-

ula, is typically not very large. If the Web service process is veryomplex, containing many concurrently acting parties, then n, theumber of states in the Web service process can become relatively

arge. However, note that automatic verification of such processesakes even more sense in case of complex processes, since theanual verification will be slower and error-prone.

.4. Integrating constraints on Web services

In the previous section, we have seen how utility function poli-ies can be specified by defining utilities for different Web serviceonfigurations. Thereby, the configurations are described by valuesf Web service properties. In this section, we have developed a for-alism for specifying constraints on functional properties of Web

ervices. We obtain the complete policy framework by viewing aormula of the constraint specification language developed in thisection as a property value for which a utility can be specified. It isp to the user whether he specifies one formula that defines valuesf all desired properties or he specifies more than one formulae,ssigns a utility to each formula and determines the function forggregating the various utilities.

xample 2. In Example 1, there is a functional propertyBehaviour’ with values “payment before delivery” and “paymentfter delivery”. With the formalism developed in this section, “pay-ent before delivery” can be specified as

〈delivery〉 trueuntil payment ∧ 〈delivery〉 true.

he above formula says that there should not be any delivery beforeayment and there should be a delivery, which is equivalent toaying that the delivery should take place after the payment. Theonstraint “payment after delivery” can be specified as

payment until 〈delivery〉 true.

ote, that the formula actually specifies that the client does notish to pay before delivery and leaves open whether he wishes toay after delivery or not. So, the services that are free (client doesot have to pay at all) as well the services where the client has toay after the delivery will satisfy the formula.

Though the above example already shows the added value ofur formalism to the existing work, it is still rather simple as com-ared to those needed in real practical scenarios. In this contextarticularly constraints involving service behaviour (as described

n Example 2) and resources are highly relevant. An example foruch a constraint is given in the following.

xample 3. Considering the book selling Web service scenariobit more deeply, we observe that a requester, in addition to the

onstraint from the above example, also wishes to makes sure that1) the service delivers not just any book but the book that he orders2) the amount the credit card is charged for should be equal to therice of the book. These constraints can be formulated as follows:

[+order(ob,cc)]isbn(ob,obISBN) ∧ price(ob,obPrice)∧eventually〈−delivery(db)〉isbn(ob,dbISBN)∧

equals(obISBN,dbISBN) ∧ charged(cc,amount)∧equals(obPrice,amount)

(6)

here ob, db and cc represent the ordered book, the delivered booknd the credit card, respectively. The names of the rest of the param-

es and

eabeosc

hTfei

6

sf

WoeSva

rbtcvcTrrt

pvopctbrcdccuemstbap

iasApwatt[

7

santptW

tsmcstf

eciatsWta

swWwppaavvaap

R

S. Agarwal et al. / Web Semantics: Science, Servic

ters of the actions and predicates are self explaining. Roughly thebove formula says, that for all orders for a book ob that shoulde paid with the credit card cc, there should eventually be a deliv-ry of a book db, the ISBN number of which is equal to that of therdered book and the amount charged from the credit card (theame credit card that was entered while ordering and not any creditard), should be equal to the price of the ordered book.

In order to specify how the values of the property ‘Behaviour’ave to be matched, the following rule is added to the ontology.he predicate satisfied-by implements a model checking algorithmor verifying the desired behavioural properties [1, Chap. 7] andnables the integration of temporal reasoning into our overall pol-cy framework presented in Section 4.

match(x, y) ← hasProperty(x,‘ Behaviour’ ),hasValue(x, v1),satisfied-by(v1, y)

(7)

. Implementation

We have implemented a prototype for the policy framework pre-ented in the previous sections. In the following, we describe theunctionalities of the main components of the prototype.

First, we provide a repository that maintains a large number ofeb services offers. This repository is maintained by the KAON25

ntology management framework. The ontologies needed for mod-ling service offers and utility function policies as presented inection 4 are known to the repository. The individual Web ser-ice offers including provider policies are saved in the repositorys instances of the appropriate concepts of the ontologies.

Second, a client sided tool also allows users to specify theirequests and send them to the server. In this context, policies cane specified by choosing one of the predefined utility function pat-erns and adjusting the corresponding parameters. New patternsan be added as long as their semantics can be captured by the pro-ided SWRL built-ins [18] or by already existing patterns. In thisase the new rule is transferred to the server along with the query.he server performs the matchmaking and evaluates the offers withespect to the request by comparing the corresponding policies. Theanked list of matches is sent back to the client tool, which showshe matches to the user.

First evaluations have shown that the use of utility functionolices allows us to increase efficiency of representing Web ser-ice offers and requests, while keeping matching and ranking offfers and requests computationally tractable. Given an additivereference structure (as specified in Eq. 2) the worst case spaceomplexity for storing n service offers with m possible configura-ions each decreases from O(nm) in case of traditional enumerationased approaches to O(n+ log(m)). For example, in a scenario withandomly generated 1000 offers with 100 configurations each, wean reduce the size of the knowledge base from 77 MB to 24 MB. Aetailed discussion of this results can be found in [32]. In terms ofomputational tractability, two problems can be distinguished: theomplexity of policy evaluation itself and the complexity of eval-ating the matching rules for each attribute. As discussed in [30],valuation of utility function policies can be reduced to a traditionalixed integer programming formulation, which can be efficiently

olved using the well-known simplex algorithm. Our experimen-al results for example show that the degree of satisfiability cane calculated within 16 ms in case of 100 possible configurationsnd within 161 ms in case of 500 possible configurations. The com-lexity of matching attribute values depends on the predicate that

5 http://kaon2.semanticweb.org.

Agents on the World Wide Web 7 (2009) 11–20 19

s assigned to a certain attribute. While executing predicates suchs SWRLB:equals is very fast, more complex predicates like sub-umes or satisfied-by can be computationally more demanding.s an example, consider the subsumes-predicate used in Rule 5. Theredicate tests for subsumption between two concepts in OWL-DL,hich is shown to be NExpTime-hard [43, Corollary 4.13]. Evalu-

ting temporal constraints using the satisfies-by-predicate has theime complexity O(n ·m) where n denotes the number of states inhe LTS of the Web service process and m the length of the formula1, Chap. 7].

. Conclusion and outlook

In this paper, we have studied the problem of specifying Webervice policies with the aim of facilitating automated discoverynd selection of services. We have argued that on one side it isecessary to specify policies on functional properties (beyond theypes of input and output parameters) as well as on non-functionalroperties, and on the other side that these policies should enablehe specification of hard as well as soft constraints on properties of

eb services.We have first presented a general policy framework that allows

he assignment of utilities to various types of Web service con-traints in a flexible way. In case of Web service offers, such a utilityeasure can be used to represent prices of a concrete Web service

onfiguration, whereas in case of a Web service request, it repre-ents how much a particular Web service configuration is worth forhe user. The general policy framework, that can actually be usedor products other than Web services as well.

We then turned our attention to the Web service specific prop-rties and presented a formalism that allows the specificationonstraints on the types and values of the objects involved dur-ng the execution of a Web service as well as on the behaviour ofWeb service. Then we showed how the constraints on the func-

ional properties can be integrated in the overall policy framework,uch that they can be considered while calculating the utility of a

eb service. Finally, we have presented the main components ofhe prototypical implementation of our policy framework as wells some evaluation results.

In this paper, we have presented an expressive formalism forpecifying policies on Web service properties. We have not dealtith the problem of policy elicitation. That is, the problem of howeb service providers and requesters know which policies theyant to specify and how they can be supported in identifying theirolicies automatically or semi-automatically. Another interestingroblem for future research is service execution monitoring. Afterrequester has selected a Web service on the basis his own as wells the Web service provider’s policies, he executes the Web ser-ice a few times. Execution monitoring deals with recording thealues of various properties during an execution and supportingrequester automatically or semi-automatically while identifying

ny non-compliance to the values promised by the Web servicerovider in his policy.

eferences

[1] S. Agarwal, Formal description of Web services for expressive matchmaking,Ph.D. Thesis, University of Karlsruhe (TH), May 2007.

[2] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, P.F. Patel-Schneider (Eds.), TheDescription Logic Handbook: Theory Implemenation and Applications, Cam-bridge University Press, 2003.

[3] F. Bacchus, A. Grove, Graphical models for preference and utility, in: P. Besnard,S. Hanks (Eds.), Proceedings of the 11th Conference on Uncertainty in ArtificialIntelligence, Morgan Kaufmann, Montreal, Quebec, Canada, 1995.

[4] D. Berardi, D. Calvanese, G.D. Giacomo, R. Hull, M. Mecella, Automatic compo-sition of transition-based semantic Web services with messaging, in: K. Bohm,C.S. Jensen, L.M. Haas, M.L. Kersten, P.-A. Larson, B.C. Ooi (Eds.), VLDB’05: Pro-

2 es and

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

[

0 S. Agarwal et al. / Web Semantics: Science, Servic

ceedings of the 31st International Conference on Very Large Databases, ACM,Trondheim, Norway, 2005.

[5] M. Bienvenu, C. Fritz, S.A. McIlraith, Planning with qualitative temporal pref-erences, in: P. Doherty, J. Mylopoulos, C.A. Welty (Eds.), Proceedings of the10th International Conference on Principles of Knowledge Representation andReasoning, AAAI Press, Lake District of the United Kingdom, 2006.

[6] P. Bosc, E. Damiani, M. Fugini, Fuzzy service selection in a distributed object-oriented environment, IEEE Trans. Fuzzy Syst. 9 (2001) 682–698.

[7] J. de Bruijn, H. Lausen, R. Krummenacher, A. Polleres, L. Predoiu, M. Kifer, D.Fensel, The Web Service Modeling Language WSML, WSML Final Draft WSMODeliverable D16, DERI, http://www.wsmo.org/TR/d16/d16.1(October 2005).

[8] A. Felfernig, G. Friedrich, D. Jannach, M. Stumptner, M. Zanker, Configurationknowledge representations for semantic Web applications, Artif. Intell. Eng.Des. Anal. Manuf. 17 (1) (2003) 31–50.

[9] P.C. Fishburn, Utility Theory for Decision Making, Wiley, New York, 1970.10] R. Garcıa, R. Gil, An OWL copyright ontology for semantic digital rights man-

agement, in: OTM, Workshops 2006: Workshop on Reliability in DecentralizedDistributed Systems (RDDS), vol. 4278 of Lecture Notes in Computer Science,Springer, Montpellier, France, 2006.

11] G. Governatori, Representing business contracts in RuleML, Int. J. Cooper.Inform. Syst. 14 (2005) 181–216.

12] S. Grimm, Intersection-based matchmaking for semantic Web service discov-ery, in: Proceedings of the Second International Conference on Internet andWeb Applications and Services (ICIW’07), IEEE Computer Society, Mauritius,2007.

13] S. Grimm, P. Hitzler, Semantic matchmaking of resources with local closed-world reasoning, J. Electron. Commerce 12 (2), 89–126.

14] S. Grimm, B. Motik, C. Preist, Matching semantic service descriptions withlocal closed-world reasoning, in: Proceedings of the Third European SemanticWeb Conference (ESWC 2006), vol. 4011 of Lecture Notes in Computer Science,Springer, Budva, Montenegro, 2006.

15] B. Grosof, T.C. Poon, SweetDeal: representing agent contracts with exceptionsusing XML rules, ontologies, and process descriptions, in: Proceedings of the12th World Wide Web Conference, Budapest, Hungary, 2003.

16] P. Haase, B. Motik, A mapping system for the integration of OWL-DL ontologies,in: A. Hahn, S. Abels, L. Haak (Eds.), IHIS 05: Proceedings of the First Interna-tional Workshop on Interoperability of Heterogeneous Information Systems,ACM Press, Bremen, Germany, 2005.

17] I. Horrocks, P.F. Patel-Schneider, A Proposal for an OWL rules language, in:WWW ’04: Proceedings of the 13th International Conference on World WideWeb, ACM Press, New York, NY, USA, 2004.

18] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: ASemantic Web Rule Language Combining OWL and RuleML, W3C Submission,Available at http://www.w3.org/Submission/SWRL (May 2004).

19] L. Hurwicz, The design of mechanisms for resource allocation, Am. Econ. Rev.63 (2) (1973) 1–30.

20] L. Kagal, A policy-based approach to governing autonomous behavior in dis-tributed environments, Ph.D. Thesis, University of Maryland Baltimore County,Baltimore, MD, November 2004.

21] L. Kagal, T. Finin, A. Joshi, Declarative policies for describing Web service capa-bilities and constraints, in: W3C, Workshop on Constraints, Capabilities for Webservices, W3C, Oracle Conference Center, Redwood Shores, CA, USA, 2004.

22] R.L. Keeney, H. Raiffa, Decisions with Multiple Objectives: Preferences and ValueTradeoffs, John Wiley, New York, 1976.

23] J.O. Kephart, W.E. Walsh, An artificial intelligence perspective on autonomiccomputing policies, in: Proceedings of the Fifth IEEE International Workshopon Policies for Distributed Systems and Networks, New York, USA, 2004.

24] W. Kiessling, Foundations of preferences in database systems, in: Proceedingsof the 28th International Conference on Very Large Data Bases (VLDB’02), Hong

Kong, China, 2002.

25] M. Klein, B. Konig-Ries, Integrating preferences into service requests to auto-mate service usage, in: Proceedings of the First AKT Workshop on SemanticWeb Services, Milton Keynes, UK, 2004.

26] V. Kolovski, B. Parsia, WS-policy and beyond: application of owl defaults toWeb service policies, in: Proceedings of the Second International Semantic Web

[

[

[

Agents on the World Wide Web 7 (2009) 11–20

Policy Workshop (SWPW’06) at the 5th International Semantic Web Conference(ISWC), Athens, GA, USA, 2006.

27] V. Kolovski, B. Parsia, Y. Katz, J.A. Hendler, Representing Web service policies inOWL-DL, in: Y. Gil, E. Motta, V.R. Benjamins M.A. Musen (Eds.), The SemanticWeb-ISWC 2005, Fourth International Semantic Web Conference (ISWC 2005),vol. 3729 of Lecture Notes in Computer Science, Springer, Galway, Ireland, 2005.

28] D. Kozen, Results on the propositional mu-calculus, Theor. Comput. Sci. 27(1983) 333–354.

29] S. Lamparter, Policy-based contracting in semantic Web service markets, Ph.D.Thesis, University of Karlsruhe (TH), July 2007.

30] S. Lamparter, A. Ankolekar, S. Grimm, R. Studer, Preference-based selection ofhighly configurable Web services, in: Proceedings of the 16th InternationalWorld Wide Web Conference (WWW’07), Banff, Canada, 2007.

31] S. Lamparter, A. Ankolekar, D. Oberle, R. Studer, C. Weinhardt, A policy frame-work for trading configurable goods and services in open electronic markets,in: Proceedings of the Eighth International Conference on Electronic Commerce(ICEC’06), New Brunswick, Frederiction, Canada, 2006.

32] S. Lamparter, A. Ankolekar, D. Oberle, R. Studer, C. Weinhardt, Semantic specifi-cation and evaluation of bids in Web-based markets, Electron. Commerce Res.Appl. (ECRA) 8 (1), 2009.

33] D.L. McGuinness, C. Isbell, M. Parker, P. Patel-Schneider, L.A. Resnick, C. Welty,A Description logic-based Configurator on the Web, SIGART Bull. 9 (2) (1998)20–22.

34] B. Motik, R. Rosati, A faithful integration of description logics with logicprogramming, in: Proceedings of the 20th International Joint Conference onArtificial Intelligence (IJCAI 2007), Morgan Kaufmann Publishers, Hyderabad,India, 2007.

35] B. Motik, U. Sattler, R. Studer, Query answering for OWL-DL with rules, J. WebSemant.: Sci. Serv. Agents World Wide Web 3 (1) (2005) 41–60.

36] N. Oldham, K. Verma, A. Sheth, F. Hakimpour, Semantic WS-agreement partnerselection, in: WWW ’06: Proceedings of the 15th International Conference onWorld Wide Web, ACM Press, Edinburgh, Scotland, 2006.

37] M. Paolucci, T. Kawamura, T.R. Payne, K.P. Sycara, Semantic matching of Webservices capabilities, in: I. Horrocks, J.A. Hendler (Eds.), The Semantic Web-ISWC 2002, First International Semantic Web Conference, vol. 2342 of LNCS,Springer, Sardinia, Italy, 2002.

38] A. Paschke, Verification, validation and integrity of distributed and inter-changed rule based policies and contracts in the semantic Web, in: InternationalSemantic Web and Policy Workshop (SWPW’06) at ISWC’06, Athens, Georgia,USA, 2006.

39] D. Roman, U. Keller, H. Lausen, J. de Bruijn, R. Lara, M. Stollberg, A. Pollers, C.Feier, C. Bussler, D. Fensel, Web service modeling ontology, Appl. Ontol. 1 (1)(2005) 77–106.

40] T. Skylogiannis, G. Antoniou, N. Bassiliades, G. Governatori, DR-NEGOTIATE—asystem for automated agent negotiation with defeasible logic-based strate-gies, in: EEE ’05: Proceedings of the 2005 IEEE International Conference one-Technology, e-Commerce and e-Service (EEE’05), IEEE Computer Society,Washington, DC, USA, 2005.

41] C. Stirling, D. Walker, Local model checking in the modal mu-calculus, Theor.Comput. Sci. 89 (1) (1991) 161–177.

42] K. Sycara, M. Paolucci, A. Ankolekar, N. Srinivasan, Automated discovery, inter-action and composition of semantic Web services, J. Web Semant. 1 (1) (2003)27–46.

43] S. Tobies, The complexity of reasoning with cardinality restrictions and nomi-nals in expressive description logics, J. Artif. Intell. Res. (JAIR) 12 (2000) 199–217.

44] A. Toninelli, J. Bradshaw, L. Kagal, R. Montanari, Rule-based and ontology-basedpolicies: toward a hybrid approach to control agents in pervasive environments,in: Proceedings of the Semantic Web and Policy Workshop at ISWC’05, Galway,Ireland, 2005.

45] A. Uszok, J.M. Bradshaw, M. Johnson, R. Jeffers, A. Tate, J. Dalton, S. Aitken, KAoSpolicy management for semantic Web services, IEEE Intell. Syst. 19 (4) (2004)32–41.

46] J. von Neumann, O. Morgenstern, Theory of Games and Economics Behavior,Princeton University Press, Princeton, NJ, 1947.

47] W3C, Web Ontology Language (OWL), http://www.w3.org/2004/OWL/, 2004.