VIeTE

Enabling Trust Emergence in Service-oriented Collaborative Environments

Florian Skopik, Hong-Linh Truong and Schahram Dustdar

Distributed Systems Group

Information Systems Institute

Vienna University of Technology, Austria

Keywords:

Activity-centric collaboration, Trust, Service-oriented architecture.

Abstract:

In activity-centric environments where people from different companies and disciplines work remotely to-

gether and where new virtual teams are formed and dissolved continuously, how to ﬁnd the most suitable

collaboration partner for a given task and how well one partner is able to collaborate with another one are

challenging research questions. Determining and considering people’s professional competencies, collabora-

tion behavior and relationships is a prerequisite to enhance the overall collaboration performance and success,

because these factors highly impact on the notion of trust used to select and grade partners. In this paper we

analyze these factors and their impact on trust relationships in modern service-oriented collaboration environ-

ments. We present VieTE, a framework for trust emergence therein supporting the analysis of trust between

partners in various contexts and from different views. In contrast to other approaches, which mostly rely on

manual and subjective user feedback, VieTE monitors automatically collaboration efforts and deduces trust

between any two partners based on past collaboration, previous successes, and individual competencies.

1 INTRODUCTION

With the rise of information and communication tech-

nologies, the way people organize and perform their

work has been shifted to a distributed form, where

people located at different sites build loosely coupled

teams and work together to reach common goals. In

such working scenarios, it is difﬁcult for team mem-

bers to establish personal relationships. However, es-

pecially in team oriented environments, one aspect

of interpersonal relationships must not be neglected,

which is trust. High trust between collaboration part-

ners is vital to collaboration processes and thus to

their overall success.

A wide range of systems have been proposed for

establishing trust, such as those described in (Jøsang

et al., 2007), but most of them rely on subjective

user feedback, which is time-consuming for the users

and error-prone due to social inﬂuences or malicious

raters. In order to overcome this user feedback de-

pendency and to automate the rating process, we fol-

low a monitoring-based approach by observing and

analyzing users’ communication and behavior to de-

termine notions of trust during collaborations in ad-

hoc, service-oriented collaboration environments. To

this end, we have developed the Vienna Trust Emer-

gence Framework (VieTE) to support the analysis of

trust between any collaboration partners. By deter-

mining and providing trust values directly from mon-

itoring collaborations, VieTE improves the support

for typical use cases in ad-hoc collaboration scenarios

including selecting a partner or service at run-time,

permitting user recommendation and ranking, allow-

ing trust-based team formation, supporting trustwor-

thy resource access control or enabling evaluation of

team performance; just to mention a few examples.

The remainder of this paper is organized as fol-

lows. Section 2 describes our supporting service-

oriented collaboration environment. Section 3

presents the related work. In Section 4 we deﬁne trust

together with its context and views. We present data

collection and complex interaction metrics for deter-

mining trust in Section 5. Section 6 describes VieTE’s

architecture and functionalities. We discuss illustra-

tive scenarios in Section 7 and conclude the paper in

Section 8.

471

Skopik F., Truong H. and Dustdar S.

VIeTE - Enabling Trust Emergence in Service-oriented Collaborative Environments.

DOI: 10.5220/0001820904710478

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

ISBN: 978-989-8111-81-4

2 SERVICE-ORIENTED

COLLABORATION

ENVIRONMENT

We consider all motivating use cases mentioned in the

introduction, and describe a service-oriented collab-

oration environment which is generic enough to be

used in a wide range of real scenarios. In this en-

vironment humans are organized in teams perform-

ing activities with the support of SOA-based services.

In this regard the term collaboration means that peo-

ple work together in various ways to reach a common

goal. All tasks they perform are organized in activi-

ties, which are structures to help managing and mon-

itoring which humans are jointly performing which

tasks by utilizing which services. Figure 1 shows an

overview of involved entities and their relationships.

belongs to

interact

within A

performs

is assigned to

interact

within A

subordi

-nates

interact

within A

HumansTeamsActivitiesServices

Figure 1: Relationships between entities.

A human is a single person who belongs to one

or more teams at the same time. Every team member

has one or more roles, which describe their respon-

sibilities within a team (e.g. leader, contributor etc.),

interacts with services in context of particular activi-

ties and interacts with other humans of the same team.

Every interaction has a particular purpose, thus we

can distinguish between various types including coor-

dination (e.g. agree on a meeting schedule), commu-

nication (e.g. send instant message or e-mail) or exe-

cution (e.g. execute a service to fulﬁll a task), depen-

dent on which category of service is utilized. In the

described environment we monitor different kinds of

interactions, such as SOAP-based (Web) service calls,

and e-mail and instant messages.

An activity is any kind of basic task (e.g. testing

a software module) performed during work and is ex-

ecuted by exactly one team, however a team can be

assigned to several activities at the same time. Ac-

tivities are hierarchically structured and can have an

arbitrary number of subactivities. Furthermore, activ-

ities have a particular goal and nature, e.g., in a soft-

ware testing activity a ﬁnal goal may be the upload of

a test report to a repository. All interactions between

humans and/or services take place in context of par-

ticular activities.

A service is a resource assigned to an activity pro-

viding support for a team during an activity’s exe-

cution. We are operating in a mixed systems envi-

ronment, where services may be commonly known

software Web services or humans acting as services

(e.g., through human provided services (Schall et al.,

2008)). Such an environment permits supporting

more complex tasks, which cannot be tackled by tra-

ditional Web services, but by humans using common

Web service technologies and widely adopted infras-

tructures. If several services are assigned to the same

activitythey can interact with each other, building ser-

vice compositions to offer extended functionalities.

3 RELATED WORK

In this paper we present a framework, VieTE, to en-

able trust emergence in human collaboration environ-

ments, which are similar to previous activity-centric

approaches, such as IBM’s UAM

presented for ex-

ample in (Moody et al., 2006). Several projects in the

ﬁeld of collaboration are currently performed within

the EU FP7

, partly utilizing the concept of trust.

From the comprehensive surveys of trust in com-

puter science, including (Jøsang et al., 2007), (Ruo-

homaa and Kutvonen, 2005) and (Artz and Gil, 2007),

we select and extend the trust deﬁnitions in (Mui,

2002) and (Grandison and Sloman, 2000) which ﬁt

best to our framework as explained in Section 4.

The overall use of VieTE is related to classic rec-

ommender systems (Resnick and Varian, 1997) and

collaborative ﬁltering approaches (Herlocker et al.,

2004), however,in these ﬁelds the opinion of an entire

community about a single entity is predominantly rec-

ognized while relations between single entities within

a group are often neglected. Our work introduces the

concept of views of trust, which allows to grade an

entity from different perspectives, including from an

http://www.research.ibm.com/uam/

http://cordis.europa.eu/fp7

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

472

entire communiy’s view but also from an individual’s

view. There are many reputation models from the

SOA domain, such as (Maximilien and Singh, 2004) ,

but they are dedicated to Web services only.

In contrast to mentioned reputation systems, in the

domain of social network analysis (Wasserman and

Faust, 1994) the relationships between single entities

are highly researched. From this area we get valuable

input about the composition of typical user communi-

ties, such as (Gomez et al., 2008). Experimental case

studies, including (Massa and Avesani, 2005), offer

insights in human collaboration behavior and enables

us to deﬁne requirements for our framework and a ba-

sic trust model.

The aim of trust models is to abstract the fuzzy

notion of trust and to build a mathematical model to

enable systematic trust calculation and analysis be-

tween any entities. There are several papers deal-

ing with the deﬁnition of trust metrics and models

in general (Ramchurn et al., 2004), (Huynh et al.,

2006), (Theodorakopoulos and Baras, 2006) or fo-

cusing particular aspects such as propagation (Guha

et al., 2004), (Quercia et al., 2007) or mobility (Shand

et al., 2004). For basic trust determination, we utilize

the widely adopted concept of a trust graph where its

nodes represent acting entities and weighted edges re-

ﬂect the relationships among entities.

4 CONTEXT AND VIEWS OF

TRUST

Before discussing the context and views associated

with trust, we deﬁne the notion of trust in our frame-

work. Trust has been deﬁned in several different ways

depending on the research area, such as in (Grandison

and Sloman, 2000) and (Artz and Gil, 2007). A deﬁ-

nition of trust from (Mui, 2002) suitable for the intro-

duced collaboration environmentstates that trust is ”a

subjective expectation an agent has about another’s

future behavior based on history of their encounters.”.

The point is that inferred from previous collaboration

behavior and experiences a notion of trust is deduced.

Particularly in collaboration scenarios where peo-

ple from different companies and from a wide range

of disciplines work together using services from sev-

eral vendors, they are often unknown to each other,

thus trust cannot rely on personal relationships, but

has to be mostly determined by the success of past

collaborations and the quality of the outcome only.

Hence we argue that one’s trust in another one is

higher, the more efﬁciently both performed in the

same activities and teams respectively. In the de-

scribed collaboration environment success and efﬁ-

ciency basically depend on the competencies of the

acting entities, in detail humans and services. A hu-

man offers competencies such as special skills and ca-

pabilities and a service functionalities and features to

support particular activities. From this perspective,

we adopt the deﬁnition from (Grandison and Sloman,

2000), trust is ”the ﬁrm belief in the competence of an

entity to act dependably, securely, and reliably within

a speciﬁed context”. Based on that, we combine and

extend above deﬁnitions of trust to deﬁne trust in our

collaboration environment as:

a subjective opinion based on previ-

ous collaboration experiences one entity has

about another’s competencies to act depend-

ably, securely, and reliably within a speci-

ﬁed context, determined by performed activ-

ities and involved teams.

4.1 Context of Trust

It is widely agreed (McKnight and Chervany, 1996),

(Marsh, 1994), (Grandison and Sloman, 2000) and an

integral part of the above deﬁnition that trust is con-

text dependent, which means it is determined for par-

ticular entities in particular situations. In contrast to

a wide range of reputation systems (Herlocker et al.,

2004), which calculate only one kind of globally valid

trust value, independent from situation and use case,

we derive trust for certain humans and services with

respect to their context. Particularly in the introduced

collaboration environment context, which reﬂects a

real situation, can be fully described by the notions

of team and activity. The team holds structural in-

formation about which humans work closely together

to reach a common goal and which roles they have,

while the activity describes the goal itself to reach.

Thus, contextual information of an entity includes all

properties available about current and past activities

and teams involved.

4.2 Views of Trust

As mentioned in the related work section, trust has

been widely deﬁned (i) from an individual view in so-

cial networks, where relations between single users

are maintained or (ii) from a global view in reputa-

tion systems or collaborative tagging systems, which

mostly use an aggregation of the individuals’ views.

For typical collaboration scenarios, where humans are

tightly coupled and form teams, we introduce one

level in between by taking a team’s view of trust into

account. This enables us to determine trust of an en-

tire team into another entity, which is a basic demand

VIeTE - Enabling Trust Emergence in Service-oriented Collaborative Environments

473

in collaborativedecisions, such as the selection of fur-

ther team members or services.

In the described collaboration environment we

distinguish between the following views of trust,

which can be created by combining contextual infor-

mation from different individuals:

• individual view: describes trust of one human in

another one or in a service.

• team view: describes trust of an entire team in

one human or service. For determining team trust

previous collaboration encounters from all team

members with a particular entity are aggregated.

• global view: determines trust in a human or ser-

vice from a global point of view, similar to global

reputation systems, where all available informa-

tion within a collaboration scenario is taken into

account.

Figure 2 shows examples of the three views of

trust in a service and lists the inﬂuencing factors for

trust determination.

Individual View

Team View

Global View

Determined by:

- aggregated team views

- further available information

(e.g. QoS attributes)

Determined by:

- individual view of each mem-

ber and their relationships

- each member’s role and

participation in the team

- team’s previous successes

Determined by:

- individual experience with

the service derived from

previous interactions

- experience, derived from the

opinions of well-known colla-

boration partners

Service

Figure 2: Distinguished views of trust in a service.

The differentiation into diverse views of trust com-

bined with the notion of trust context is the basis for

a comprehensive customization of our framework (as

further described in Section 6).

5 COLLECTING DATA FOR

DETERMINING TRUST

To enable VieTE to provide notions of trust from dif-

ferent views and in different contexts, we need an

appropriate data model supporting the described col-

laboration environment, and utilize a number of data

sources to determine trust.

5.1 Data Model

The four main entities of the data model human, team,

activity and service, and their connections as men-

tioned in Section 2, are modeled in Figure 3. Ev-

ery entity is described with further attributes, their

so called proﬁle data, serving as input for trust de-

termination. These proﬁles describe a collaboration

scenario including its participating entities, and are

available to all entities within the same collaboration

scenario. For example all humans within a team share

their proﬁle data with each other.

Figure 3 depicts our data model. We distinguish

two different kinds of data, which are (i) proﬁle data,

describing an entity’s properties and structural re-

lationships and (ii) interaction data, describing dy-

namic collaboration encounters.

The data model is designed to be generic enough

to handle different forms of collaboration scenarios

with a wide variety of characteristics. If there is, for

instance, no need for a notion of team, all humans can

be assigned to a single team or each human may repre-

sent an own team respectively. The entity’s properties

are selected to be applicable in various contexts.

5.2 Data Sources

Besides information about human proﬁles and team

structures, we store data about current and past activ-

ities as well as service proﬁles. Furthermore, in our

approach we do not rely on subjective user feedback

or reputation, for instance, in form of questionnaires,

but we take into account what can be measured auto-

matically. We use a Web services infrastructure which

enables us to log low level interaction messages by

using Web service handlers and SOAP interceptors.

Hence, we are able to capture (i) human-human in-

teractions as long as they take place via observable

communication services (ii) human-service interac-

tions, (iii) service-service interactions in service com-

positions, (iv) predeﬁned service or application events

in customized logging scenarios (e.g. e-mail trafﬁc

over SMTP or SVN ﬁle accesses), and (v) changes of

team- and activity structures including adding team

members, changing roles or assigning new services to

an activity.

For this measurement approach it is necessary

to determine the success of interactions. Depend-

ing on the type of interactions and participating en-

tities, interaction failures can have manifold reasons,

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

474

Human

id job position

date of hire educational level

Service

id vendor

date of last update category

Team

id humans[ ] with roles[ ]

date of formation size

date of dissolving

Activity

id type

startdate goal

duration assigned team

status/progress assigned services[ ]

belongs to

performs

is assigned to

Interaction

success time

type number of participants

1 1

Interaction

success time

type

Interaction

success time

type

Figure 3: Simpliﬁed data model of proﬁles and interactions.

such as SOAP exceptions if a particular service is

down, application speciﬁc errors due to missing fea-

tures or wrong usage of services, not running in-

stant messengers or e-mail clients, unanswered in-

stant messages, missed read notiﬁcations of e-mails,

interrupted data transfers, invalid communication set-

tings, missed phone calls etc.

5.3 Collaboration Metrics

Data from all mentioned sources is captured and ag-

gregated to more detailed composite metrics and pat-

terns providing meaningful information for a collab-

oration scenario. The calculation process is fully cus-

tomizable and can be set up for different views of

trust.

Table 1: Exemplary metrics for humans.

View Metric Description

Indiv. scores for initiated, accepted, successful and failed

human-to-human/service interactions.

interaction success with a particular human/service.

experience with a particular activity type.

Team human’s average impact on team performance.

human’s interaction participation within a team.

Global metrics for team view can be applied too, but aggre-

gated over all teams.

Table 2: Exemplary metrics for teams.

View Metric Description

Indiv. only proﬁle data is available.

Team average number of members’ interactions with a par-

ticular entity.

interaction distribution among members.

service access distribution (with respect to a particu-

lar or all activities).

Global amount of interactions compared to other teams.

activity participation compared to other teams.

team success compared to other teams.

We elaborate some exemplary metrics in Tables 1

to 4 to show the potential of our approach. The exact

Table 3: Exemplary metrics for activities.

View Metric Description

Indiv. none. Activities are performed by entire teams.

Team collaboration effort compared to other activities.

success of service usage within an activity.

success of executive team within an activity.

success of artifact outcome.

service access distribution within an activity.

activity contribution of every team member.

Global metrics for team view can be applied too, but com-

pared to activities of all teams.

Table 4: Exemplary metrics for services.

View Metric Description

Indiv. scores for initiated, accepted, successful and failed

service-to-service/human interactions.

interaction success with a particular human/service.

Team average number of invocations.

usage factor by a particular team.

service access distribution by a particular team.

Global same metrics as for team view aggregated over all

teams.

deﬁnitions of these metrics depend on available col-

laboration data and thus on the environment, and is

not in scope of this paper, which focuses a high-level

overview of the whole approach. In complex collab-

oration scenarios more metrics, especially aggregated

from simpler ones, are possible. Currently we focus

on basic metrics which mostly depend on interaction

data, such as interaction scores and success rates.

6 VIeTE ARCHITECTURE

To support trust in the described collaboration envi-

ronment VieTE consists of (i) tools for managing hu-

mans, teams, activities and services, utilizing services

in the back-end, (ii) sensors and logging mechanisms

to monitor interactions at run-time, and (iii) a trust

determination service to deal with activity structures,

VIeTE - Enabling Trust Emergence in Service-oriented Collaborative Environments

475

service information, human and team proﬁles, and in-

teraction logs, to calculate metrics, and ultimately to

determine trust between any interacting entities. Fig-

ure 4 depicts the architecture of VieTE.

6.1 Determining Trust

In collaboration scenarios, humans use several tools

to manage their activities, to search for suitable part-

ners or services and to formate teams. VieTE pro-

vides trust-aware support for these tasks. To this end,

we monitor collaborations of humans with other hu-

mans and services to collect data for trust determina-

tion. We describe the mainly involved components in

the following:

Interaction Sensors and Logging. Interactions

between and among humans and services are captured

by sensors. We have developed mechanisms to in-

tercept SOAP calls to services, e-mail trafﬁc, instant

messages over XMPP

and SVN document repository

accesses, however this can be extended by sensors for

a various range of open or proprietary communica-

tion protocols, including voice calls or ﬁle sharing.

The logged entries contain at least the type of interac-

tion, sender-id, receiver-id and a timestamp; further-

more, dependent on interacting entities, the endpoint

interface, invoked operation, parametersetc. All com-

munication and application errors are logged as well,

e.g., SOAP exceptions or access denials.

Collaboration Metrics Calculation. Based on

collected interaction data and information from col-

laboration management services this component cal-

culates context dependent metrics for humans, teams,

services and activities, as described before.

Trust Model. This component implements a

directed graph, where the nodes represent humans

and services and the links reﬂect their trust relation-

ships. These relationships depend on the metrics cal-

culated in discrete time steps according to the con-

text described by activities and teams. The realization

of these functionalities depends on the utilized trust

model, but currently we build trust using weighted

averages of preselected metrics. The model is cus-

tomized by user speciﬁed policies, which control the

metrics to be used and how these metrics are com-

bined, i.e. the weighting factors, to deduce a notion

of trust.

Trust Provider and API. The provider extracts

data from the trust model and creates context depen-

dent views according to API parameters. Collabo-

ration Management Tools can access the trust model

data through the Trust API. The following excerpt of

http://www.xmpp.org/

this interface shows the signature of the methods pro-

vided to obtain the trust relationship from an entity

trustor

to an entity

trustee

restricted to a context

ctx

. The view of trust is derived from the type of the

entity trustor, which may be either individual, team or

global.

int getTrust(Entity trustor, Entity trustee, Ctx ctx);

List<Entity> getTrustors(Entity trustee, Ctx ctx);

List<Entity> getTrustees(Entity trustor, Ctx ctx);

...

6.2 Prototype Implementation

The VieTE portal consists of a Liferay Enterprise

Open Source Portal

in which tools run as JSR-168

compatible portlets. We use portlets for visualizing

and processing user inputs only, while the main part

of the business logic is encapsulated in Web services.

In the back-end, we use a Tomcat server with a

deployed Axis2 for hosting Web services. We utilize

existing, earlier developed services for registering and

managing humans, teams, activities and services, and

for interaction logging; and develop new services for

all tasks concerning trust determination and manage-

ment. Communication between portlets and services

is realized with a SOAP based Web service stack. All

relevant data is stored in a IBM DB2.

For the implementation of the trust model and ap-

plying basic graph algorithms we utilize the Java Uni-

versal Network/Graph Framework

7 ILLUSTRATIVE SCENARIOS

We set up a collaboration scenario in the ﬁeld of soft-

ware development which consists of two teams as

shown in Figure 5, where trust values ∈ [0, 1], rang-

ing from no to full trust, are calculated between any

two entities, humans or services which directly in-

teract. These values are derived from the types and

amount of successful interactions compared to the to-

tal amount of interactions between two particular en-

tities.

For the sake of simplicity, we assume each team

is predominantly involved in only one type of activ-

ity, which is software implementation for team

, H

} and software testing for team

, H

}. Each human has a particular

role (developer, assistant, trainee) in a team. H

member of both teams, thus has two roles. For the

http://www.liferay.com

http://jcp.org/aboutJava/communityprocess/ﬁnal/jsr168/

http://jung.sourceforge.net/

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

476

Service

Interaction

Scenario

Collaboration Metrics Calculation

Activity

Management

Service

Management

Interaction

Logging

Human/Team

Management

Trust Model

Trust Provider

Trust Query API

Service

Team A

Team B

Trust Determination

Service

interaction

event

Partner

Team

Formation

Activity

Management

Service

trust enabled

traditional human/team/service/activity

search and management

Portal Tools for Collaboration Management

Collaboration Management Services Monitoring

humans using

portal tools

activity

structures

interaction

logs

service

info

services supporting

collaboration management

human and

team profiles

Figure 4: Architectural overview of the framework.

Activities of Team

(software implementation) (software testing)

0.9

0.6

0.8

0.9

0.6

0.8

0.6

0.2

1.0

0.6

0.9

0.6

1.0

0.9

0.2

0.4

0.3

0.6

Code Generation

Service S

(dev,15%,

dev,10%)

(trainee,5%)

(dev,60%)

(trainee,5%)

(dev,20%)

(dev,50%)

(assistant,15%)

0.2

Figure 5: Experimental setup with humans having different

roles and interaction participation within teams (in %).

creation of global and team views we built the aver-

age of the involved individuals’ trust values weighted

by their interaction participation. Interaction partici-

pation refers to the amount of successful interactions

performed by one human expressed in percent of all

successful interactions within a team.

Scenario 1: Trust Determination. H

wants to

know if it is worth using service S

, however, because

never used it in the past, H

has to rely on others’

notions of trust. Table 5 shows the calculated trust

values of different trustors according to their contexts.

Which one is best applicable depends on the purpose

for which H

intends to use S

. If H

wants to uti-

lize S

for software implementation, relying more on

team

’s view, especially the view of its developers is

wiser. For software testing the situation is different

and S

is less trusted than for implementation activi-

ties. Furthermore, it is obvious that trainees trust S

less than developers, because high experience is re-

quired to operate S

properly and thus S

has not been

used with high success by unexperienced trainees in

the past.

Table 5: Different trustors’ trust values in service S1 de-

pending on view and context.

Trustor View Contextual Restrictions Value

all global 0.667

all global activity.type=swimpl. 0.859

all global activity.type=swtest 0.489

all devs global human.role=dev 0.733

all trainees global human.role=trainee 0.25

teamA team 0.859

teamA’s devs team human.role=dev 0.9

indiv. unknown

Scenario 2: Partner Recommendation. In this

scenario we use VieTE to ﬁnd suitable collabora-

tion partners for H

. For the global and team views

the trust relationships of all entities and all members

within a team respectively are considered, as in com-

mon reputation systems, and the results are not ded-

icated to H

only. However, for the individual view

only direct relationships from H

to others are con-

sidered.

Table 6 shows a list of trustees, ordered descend-

ing by trust values calculated for particular contexts.

From the global view result generally well trusted

partners, however from H

’s individual view VieTE

suggests only partners, with which H

personally in-

VIeTE - Enabling Trust Emergence in Service-oriented Collaborative Environments

477

Table 6: H

’s trustees depending on view and context.

View Contextual Restriction Trustees

global H4,H7,H1,H2,H6,H3,H5

global activity.type=swimpl. H1,H2,H3

global human.role=dev H4,H7,H1,H2

team human.team=team

H1,H2,H3

indiv. human.team=team

H2,H1,H3

teracted in the past, while others are out of scope.

Note that the order of trustees for H

’s individual view

and team

’s team view are different, though contex-

tual restrictions are set to take into account only hu-

mans from team

in both cases. This is due to the

fact that H

’s trust in H

is quite high (0.9), while the

trust of other team members in H

is only medium

(0.6 on average), thus on team

’s view H

is ranked

lower than H

8 CONCLUSIONS AND FUTURE

WORK

In this paper we have discussed the role of trust and

related concepts in service-oriented collaboration en-

vironments. We deﬁned a collaboration model com-

prising of humans and services, and proposed an ap-

proach and a framework to automate trust determi-

nation based on monitoring interactions and utilizing

proﬁle information.

Currently we focus on trust metrics and models

and extend the existing prototype to make it feasible

for supporting real world scenarios in the area of net-

worked enterprises. The challenge is the deﬁnition

of suitable metrics which are able to reﬂect real trust

relationships. After that, the next step will be to per-

form an empirical evaluation and to prove that the se-

lected metrics and models appropriately address the

challenges in automatic trust inference.

ACKNOWLEDGEMENTS

This work is mainly supported by the EuropeanUnion

through the IP project COIN (FP7-216256).

REFERENCES

Artz, D. and Gil, Y. (2007). A survey of trust in computer

science and the semantic web. J. Web Sem., 5(2):58–

71.

Gomez, V., Kaltenbrunner, A., and Lopez, V. (2008). Sta-

tistical analysis of the social network and discussion

threads in slashdot. In WWW, pages 645–654. ACM.

Grandison, T. and Sloman, M. (2000). A survey of trust in

internet applications. IEEE Communications Surveys

and Tutorials, 3(4).

Guha, R., Kumar, R., Raghavan, P., and Tomkins, A.

(2004). Propagation of trust and distrust. In WWW,

pages 403–412, New York, NY, USA. ACM.

Herlocker, J. L., Konstan, J. A., Terveen, L. G., and Riedl,

J. T. (2004). Evaluating collaborative ﬁltering recom-

mender systems. ACM Trans. Inf. Syst., 22(1):5–53.

Huynh, T. D., Jennings, N. R., and Shadbolt, N. R. (2006).

An integrated trust and reputation model for open

multi-agent systems. Autonomous Agents and Multi-

Agent Systems, 13(2):119–154.

Jøsang, A., Ismail, R., and Boyd, C. (2007). A survey of

trust and reputation systems for online service provi-

sion. Decision Support Systems, 43(2):618–644.

Marsh, S. P. (1994). Formalising trust as a computational

concept. PhD thesis, University of Stirling.

Massa, P. and Avesani, P. (2005). Controversial users de-

mand local trust metrics: An experimental study on

epinions.com community. In AAAI, pages 121–126.

Maximilien, E. M. and Singh, M. P. (2004). Toward au-

tonomic web services trust and selection. In ICSOC,

pages 212–221. ACM.

McKnight, D. H. and Chervany, N.L. (1996). The meanings

of trust. Technical report.

Moody, P., Gruen, D., Muller, M. J., Tang, J. C., and Moran,

T. P. (2006). Business activity patterns: A new model

for collaborative business applications. IBM Systems

Journal, 45(4):683–694.

Mui, L. (2002). Computational models of trust and rep-

utation: Agents, evolutionary games, and social net-

works. PhD thesis, Massachusetts Institute of Tech-

nology.

Quercia, D., Hailes, S., and Capra, L. (2007). Lightweight

distributed trust propagation. In ICDM, pages 282–

291. IEEE Computer Society.

Ramchurn, S. D., Jennings, N. R., Sierra, C., and Godo,

L. (2004). Devising a trust model for multi-agent in-

teractions using conﬁdence and reputation. Applied

Artiﬁcial Intelligence, 18(9-10):833–852.

Resnick, P. and Varian, H. R. (1997). Recommender sys-

tems. Communications of the ACM, 40(3):56–58.

Ruohomaa, S. and Kutvonen, L. (2005). Trust management

survey. In iTrust, volume 3477 of Lecture Notes in

Computer Science, pages 77–92. Springer.

Schall, D., Truong, H.-L., and Dustdar, S. (2008). Unifying

human and software services in web-scale collabora-

tions. IEEE Internet Computing, 12(3):62–68.

Shand, B., Dimmock, N., and Bacon, J. (2004). Trust for

ubiquitous, transparent collaboration. Wireless Net-

works, 10(6):711–721.

Theodorakopoulos, G. and Baras, J. S. (2006). On trust

models and trust evaluation metrics for ad hoc net-

works. IEEE Journal on Selected Areas in Commu-

nications, 24(2):318–328.

Wasserman, S. and Faust, K. (1994). Social network analy-

sis: Methods and applications. Cambridge University

Press.

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

478