NOVEMBER/DECEMBER 2006 1541-1672/06/$20.00 © 2006 IEEE 11Published by the IEEE Computer Society

A g e n t s i n H e a l t h c a r e

Agent-Based SemanticService Discovery for Healthcare: An OrganizationalApproachCésar Cáceres, Alberto Fernández, Sascha Ossowski, and Matteo Vasirani,University Rey Juan Carlos

Information and communication technologies offer great potential for society to

quickly adopt e-services for economic and social development. Healthcare activ-

ities based on these technologies (e-health) are probably the most prominent of these

e-services. However, e-health is evolving into such entities as m-health (mobile) or

u-health (ubiquitous), which focus on applicationsthat provide healthcare to people anywhere, anytimeusing broadband and wireless mobile technologies.

To adapt the technologies to this new scenario, aservice-oriented approach is gaining popularity. Inthis context, services are software entities that canbe described, published, discovered, orchestrated,and invoked by other software entities. A service-oriented approach to e-health must consider seman-tics, because in healthcare, every description musthave a unique, clear meaning. So, defining andmaintaining expressive ontologies for e-health arecrucial.

Healthcare applications are usually based oninteractions between people playing different rolesin diverse organizational contexts. Agent technol-ogy provides the means to capture this structure be-cause it proposes an interaction-oriented way ofdesigning open software systems.1 Current agent-oriented methodologies support this claim by treat-ing organizational abstractions as first-class citi-zens in the design process.2,3 So, a promisingapproach would be to combine Semantic Web ser-vices4 and agent technologies5,6 for advanced e-healthapplications.

Here, we concentrate on dynamic healthcare ser-

vice discovery in open multiagent systems. Most ser-vice discovery techniques aim at Web services andbase their search on the service’s inputs and out-puts.7–9 Some approaches also consider precondi-tions, effects, and other parameters that describe theservice. However, for agent-based service discoverymechanisms to be successful for healthcare, theymust also use the interactions’ contextual informa-tion and, in particular, the underlying organizationalstructure. So, we’ve developed an approach thatextends existing mechanisms by considering thetypes of interactions in which services can be usedand the roles the services play. Using this approach,we’ve built Rowls, a role-based service matchmaker,and integrated it into the software framework devel-oped by the European Information Society Tech-nologies project CASCOM (Context-Aware BusinessApplication Service Coordination in Mobile Com-puting Environments, www.ist-cascom.org).10

Modeling healthcare interactionsA typical healthcare emergency assistance sce-

nario illustrates our approach to interaction model-ing based on organizational abstractions.

Frans, a businessman from Finland, is in Austriawhen he suddenly experiences serious stomach pain.

This semantic-service-

discovery mechanism

considers relevant

parts of the

organizational

context in which

e-health services

are used, to improve

a service-discovery

system’s usability in

medical emergencies.

Frans doesn’t know what to do, so he acti-vates his PDA with the CASCOM mobile-agentsuite installed and contacts an EmergencyMedical Assistance service center in Finlandto ask for advice. (EMA is a Finnish emer-gency healthcare provider.) The EMA oper-ator asks for his symptoms, if necessaryrequesting that he detail them and list themedications he’s taking. The operator thenrecommends that Frans visit the nearesthealthcare center participating in the CASCOM

network. The CASCOM agent installed in theEMA service center can automatically informthe healthcare center that Frans is on his way,to allow for any necessary preparation. Fransreceives a detailed map showing how to get tothe center; his CASCOM agent could even havecalled a taxi for him if he needed one.

After arriving at the healthcare center,Frans uses his PDA during check-in, first toannounce his arrival to the local network sys-tem (login) and then to transfer general (non-sensitive) information to the local hospitalinformation system. This can be either hispersonal data certified by an electronic sig-

nature (certificate) or his social security num-ber, his blood type, and possible allergies.

Shortly after an initial examination, thelocal physician realizes he must access somelaboratory results and ultrasonic images takenbefore the symptoms appeared. Frans’s CAS-COM agent locates the home medical record.After Frans gives permission, the requestedinformation is transferred to his PDA, whichtranslates it and forwards it to the local infor-mation system. Even with this additional in-formation, the physician still isn’t sure aboutthe diagnosis and wants a second opinion. So,using a CASCOM agent at the healthcare center,he finds a cardiologist’s contact informationand establishes a connection. The cardiolo-gist asks the physician for Frans’s symptomsand medical records. After assessing the sit-uation, he recommends that Frans should betransferred soon to a hospital with advancedcardiac life support. All arrangements for thattransfer are also made using the CASCOM

agent, so that Frans receives the proper med-ical care and will hopefully recover soon athome.

Interaction analysis and modelingIn this scenario, persons or organizations

play five main social roles:

• the patient,• healthcare professionals in local health-

care institutions who provide on-site med-ical care for the patient,

• other healthcare professionals who pro-vide additional information or a secondopinion about the patient,

• external emergency assistance organiza-tions, and

• administrators of local healthcare institu-tions.

We’ve identified several possible interac-tions between this scenario’s participants;figure 1 summarizes some of them. The firstpart of the scenario is basically a dialoguebetween Frans and the EMA operator. In thisdialogue, Frans is playing the generic socialrole of Patient, while EMA is playing thegeneric social role of EmergencyAssistanceOrgani-zation. By asking for medical assistance, Frans

A g e n t s i n H e a l t h c a r e

12 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

role::Patient

interaction::InformationExchange<<CommunicativeInteractionType>>

interaction::HealthStatusInfoExchange<<SocialInteractionType>>

role::Informer<<CommunicativeRoleType>>

role::Informee<<CommunicativeRoleType>>

role::HealthStatusInformer<<SocialRoleType>>

role::HealthStatusInformee<<SocialRoleType>>

role::Advisee<<CommunicativeRoleType>>

role::Advisor<<CommunicativeRoleType>>

interaction::Advisement<<CommunicativeInteractionType>>

interaction::MedicalAdvisement<<SocialInteractionType>>

role::MedicalAdvisee<<SocialRoleType>>

role::MedicalAdvisor<<SocialRoleType>>

role::EmergencyAssistanceOrganization

Social interactionor role

Communicativeinteraction or role

Is a subclass ofa generic class

Plays the role of

Figure 1. A UML class diagram of a taxonomy showing the refinement of specific roles and interactions to more general roles and interactions, for an emergency-medical-assistance scenario.

NOVEMBER/DECEMBER 2006 www.computer.org/intelligent 13

is starting a MedicalAdvisement interaction, inwhich he plays the MedicalAdvisee social role andEMA plays the MedicalAdvisor social role. Tosuccessfully complete this interaction andgive a recommendation, EMA needs certaininformation about the patient’s symptoms,medication, and so on. So, EMA starts a newnested interaction, in which it asks for the pa-tient’s health status. In this subinteraction,EMA plays the HealthStatusInformee social roleand Frans plays the HealthStatusInformer socialrole. When this subinteraction finishes (itsprotocol should be modeled after the real pro-tocol that emergency-assistance organizationsfollow in these situations), EMA can adviseFrans about the best course of action—forexample, how to reach the nearest hospital.

To model these interactions, we firstobtain a taxonomy of the social roles andinteractions. The next step is an abstractionprocess that generalizes the social roles andinteractions into communicative roles and in-teractions. This process refines the taxonomyto make it more generic, so that we can reuseindividuated concepts for other scenarios andapplication domains. In our case, MedicalAd-visement is a particular case of an Advisementinteraction, MedicalAdvisee is generalized to theAdvisee role, and MedicalAdvisor is generalized toAdvisor. Similarly, we can generalize HealthSta-tusInfoExchange to InformationExchange, HealthStatus-Informer to Informer, and HealthStatusInformee toInformee. Figure 1 depicts this abstraction.

We can similarly extract additional inter-actions and roles from the scenario. For ex-ample, the second opinion in the scenario isa type of medical advisement, in which aspecialist diagnoses the situation. The re-mote health professional (the cardiologist),before providing his opinion, asks the localphysician for medical information, such assymptoms, medications, and past exams (inthe same way EMA asked Frans about hishealth status before deciding what he shoulddo). Finally, the physician can require anexplanation of the second opinion. So, herewe can isolate three different interactions:two that also occurred in the dialoguebetween EMA and Frans (MedicalAdvisementand HealthStatusInfoExchange) and a new one—SecondOpinionExplanation (see figure 2).

Role and interaction ontologiesOn the basis of our analysis and the appli-

cation of our method to other healthcare sce-narios, we’ve devised a more general ontol-ogy containing a taxonomy of interactiontypes and a taxonomy of the roles in those

interactions. Figure 3 shows a UML class dia-gram of part of the interaction-type ontology.There are two kinds of interactions: social-interaction types are domain interactions(EmergencyMedicalAssistance, MedicalAdvisement, andso on), while communicative-interaction typesare generic reusable interaction patterns. Thelatter constitute abstract communication inter-actions that can be instantiated for differentscenarios. For instance, a MedicalAdvisement is aspecialization, in the medical domain, of thegeneric Advisement interaction type. The UMLdiagram represents generic (communicative)interaction types as interfaces and domain(social) interactions as classes.

The ontology’s top-level concept is Com-munication, which represents the most generic

interaction type. Any interaction type is aspecialization of this concept. The first levelof specialization is the ClosedActionPerforminginteraction type, which represents any inter-action that implies performance of an action.The tag Closed means the interaction has afixed number of participants (usually two),unlike OpenActionPerforming, where that numberisn’t predetermined (for example, a call forproposals). Explanation, Advisement, Admission, Assis-tance, and InformationExchange are specializationsof ClosedActionPerforming. For example, in Infor-mationExchange, an Informee asks an Informer toperform the action of informing about a cer-tain fact. We can apply a similar analysis tothe domain-interaction types that specializecommunicative-interaction types into social-interaction types.

Similar to the interaction taxonomy, therole taxonomy includes a hierarchy of theroles participating in the interactions. Eachconcept in the interaction ontology will haveat least two related participant concepts inthe role ontology. For example, InformationEx-

change has Informer and Informee as participants.We use these ontologies, especially theircommunicative part, when extending servicedescriptions and the matchmaking process.

Verifying and extendingthe ontology

We can easily extend our ontology to in-clude new interaction types and roles, mak-ing it more complete and reusable. To illus-trate this, we use another healthcare scenarioinvolving telemonitoring and “e-inclusion”of patients. (E-inclusion means involvingpeople in the benefits of information andcommunication technologies.)

Fred suffers from congestive heart failure.His primary-care physician has equipped himwith a health-monitoring system consisting ofa smart shirt, a sensor embedded in a ring, anaccelerometer, and a PDA for computationand wireless communication. This setupallows unobtrusive monitoring of electrocar-diograms, heart and respiratory rates, bloodpressure, oxygen saturation, and Fred’s mo-tion. The PDA wirelessly communicates withFred’s home automation system to exchangedata. If Fred’s health changes, the system auto-matically notifies his physician and retrievesall important medical data. Additionally, thesystem offers the physician a feedback chan-nel that lets her interact with Fred.

The system also lets healthcare serviceproviders attend large numbers of patientsefficiently. Extending the communicationpattern to one-to-many communication letscaregivers build virtual groups of patientswith similar characteristics. This opens upnew possibilities for medical care, such aspublishing tasks or goals to a group, orinforming patients that they’re part of a groupthat can communicate with each other andshare their experiences if they want.

We can model some of this scenario’sroles and interactions as specializations ofexisting ones; for example, BiomedicalSignalNo-tifier and BiomedicalSignalNotification are derivedfrom the Notifier role and Notification interac-tion. But some new roles, such as Virtual-GroupReceiver, and interactions, such as Virtual-GroupCommunication, have no direct match in theinitial ontology. So, we extend the initial on-tology with a new generic role (Proxy) andinteraction (ProxyPerforming) to consistentlyaccommodate these new elements.

Role-based service descriptionand matching

In a service-oriented architecture, services

The abstraction process

refines the taxonomy to make

it more generic, so that we can

reuse individuated concepts

for other scenarios

and application domains.

A g e n t s i n H e a l t h c a r e

14 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

interaction::InformationExchange<<CommunicativeInteractionType>>

interaction::HealthStatusInfoExchange<<SocialInteractionType>>

role::Informer<<CommunicativeRoleType>>

role::HealthStatusInformer<<SocialRoleType>>

role::Advisee<<CommunicativeRoleType>>

role::Explainer<<CommunicativeRoleType>>

role::SecondOpinionRequester<<SocialRoleType>>

role::Explainee<<CommunicativeRoleType>>

role::MedicalAdvisementExplainer<<SocialRoleType>>

role::MedicalAdvisementExplainee<<SocialRoleType>>

interaction::Advisement<<CommunicativeInteractionType>>

interaction::MedicalAdvisement<<SocialInteractionType>>

interaction::SecondOpinion<<SocialInteractionType>>

interaction::Explanation<<CommunicativeInteractionType>>

role::MedicalAdvisee<<SocialRoleType>>

role::HealthcareProfessional

interaction::SecondOpinionExplanation<<SocialInteractionType>>

Role:SecondOpinionExplainee<<SocialRoleType>>

Role:SecondOpinionExplainer<<SocialRoleType>>

interaction::MedicalAdvisementExplanation<<SocialInteractionType>>

Social interactionor role

Communicativeinteraction or role

Is a subclass ofa generic class

Plays the role of

role::Patient

role::Informee<<CommunicativeRoleType>>

role::HealthStatusInformee<<SocialRoleType>>

role::Advisor<<CommunicativeRoleType>>

role::SecondOpinionRequestee<<SocialRoleType>>

role::MedicalAdvisor<<SocialRoleType>>

Figure 2. A taxonomy of roles and interactions for a second-opinion medical advisement.

NOVEMBER/DECEMBER 2006 www.computer.org/intelligent 15

are described and registered in some kind ofdirectory (also know as yellow pages). Whena service is required, these descriptions areused for service discovery. Here, we showhow we describe services by using their role-based information and show a matching algo-rithm based on that description.

Service advertisementsTo illustrate our approach, we use the sec-

ond-opinion service we mentioned earlier. Inthis example, the service provider (the re-mote healthcare professional) and the re-quester (the local healthcare professional

who asked for a second opinion) engage in aconversation during the medical advisement.The remote healthcare professional plays theAdvisor role. However, to correctly execute theservice, the remote healthcare professionalmust initiate another type of interaction (Infor-mationExchange) to ask the local healthcare pro-fessional for additional information. Thatmeans the provider requires the requester toplay the Informer role.

This situation, also present in many othertypes of conversations, leads us to specify twofields in the service advertisement that arerelated to the interactions in which the ser-

vice provider can engage. First, the providerrole field indicates the role the serviceprovider plays in an interaction—for exam-ple, Advisor in the second-opinion service.

Second, the depending roles field indi-cates the set of roles that the requester mustplay to correctly execute the service. We rep-resent these roles as a logical formula in dis-junctive normal form—that is, a disjunctionof conjunctions of roles. This formulationlets us express, for instance, that to correctlyexecute the service the requester must beable to play an Explainer role or at least an In-former role.

ClosedActionPerforming<<CommunicativeInteractionType>>

OpenActionPerforming<<CommunicativeInteractionType>>

Proposal<<CommunicativeInteractionType>>

Assistance<<CommunicativeInteractionType>>

Admission<<CommunicativeInteractionType>>

MedicalAssistance<<SocialInteractionType>>

Notification<<CommunicativeInteractionType>>

ArrivalNotification<<SocialInteractionType>>

Explanation<<CommunicativeInteractionType>>

Advisement<<CommunicativeInteractionType>>

MedicalAdvisement<<SocialInteractionType>>

InformationExchange<<CommunicativeInteractionType>>

CommunicationCommunicative interactions

Social interactions

EmergencyAssistance<<CommunicativeInteractionType>>

EmergencyMedicalAssistance<<SocialInteractionType>>

Translation<<SocialInteractionType>>

TravelArrangement<<SocialInteractionType>>

TravelSupportNotification<<SocialInteractionType>>

ProfileInformationExchange<<SocialInteractionType>>

EmergencyMedicalAdvisement<<SocialInteractionType>>

SecondOpinion<<SocialInteractionType>>

HealthStatusInfoExchange<<SocialInteractionType>>

MedicalRecordsRepositoryInfoExchange<<SocialInteractionType>>

CostCoverageInfoExchange<<SocialInteractionType>>

MedicalRecordsInfoExchange<<SocialInteractionType>>

MedicalAdvisementExplanation<<SocialInteractionType>>

SecondOpinionExplanation<<SocialInteractionType>>

HospitalLogin<<SocialInteractionType>>

DataFormatTranslation<<SocialInteractionType>>

Social interaction or roleCommunicative interaction or role

Is a subclass of a generic classIs a subclass of

Plays the role of

Figure 3. A partial representation of the interaction-type ontology.

A g e n t s i n H e a l t h c a r e

16 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

These two fields apply to each role the ser-vice provider can play.

We can graphically represent a serviceadvertisement as a table with two columns,one for the provider role and the other for thedepending roles. Each row represents a dif-ferent type of interaction with which theprovider can provide the service. Figure 4ashows a role-based service advertisement forthe second-opinion example.

Service requestsFor a service request, we consider queries

comprising two elements. First, searchedprovider roles are the roles for which the

requester is searching. Although one role willbe enough in most cases, we allow for morecomplex search patterns in which the providercan play more than one role. For example, inthe service request in figure 4b, an agent islooking for a second-opinion provider (the Advi-sor role) that also explains advisements (theExplainer role). As in the case of service adver-tisements, we require an expression in dis-junctive normal form here.

Second, the set of requester capabilityroles define the requester’s capabilities re-garding the roles the requester can play. Thisinformation is important if the providerrequires interaction from the requester. For

example, in figure 4b, the service requestspecifies that the requester can play theInformer and Explainer roles if necessary.

Extending OWL-S with rolesSeveral ontology languages have been

developed during the past few years. The mostpopular is OWL (Web Ontology Language,www.w3.org/2004/OWL), a W3C recom-mendation that’s well supported by commer-cial and free tools, such as editors, parsers,reasoners, and Java libraries.

To describe services, we use OWL-S (www.daml.org/services/owl-s), a service descriptionlanguage based on OWL. An OWL-S servicedescription has three parts:

• The service profile is used for advertisingand discovering services.

• The process model details how the serviceoperates.

• The service grounding provides details onhow to interoperate with the service.

We include the role and interaction infor-mation in the service profile. Because theservice profile describes what the servicedoes, it’s an adequate location for role de-scriptions. A service profile basically in-cludes information about inputs, outputs,preconditions, and effects, as well as theservice category and a set of service para-meters. However, it doesn’t include a spe-cific field for describing organizationalinformation such as roles or interactions,so we must incorporate that information inthe available fields. We include the roledescription as a service parameter calledServiceRoles for service advertisements andone called QueryRoles for service requests.Figure 5 illustrates a partial OWL-S de-scription of the second-opinion serviceadvertisement in figure 4a.

A role-based service-matchingalgorithm

We’ve developed a role-based matchingalgorithm that takes as inputs a service request(R) and a service advertisement (S) and returnsthe degree of match (dom) between them,which is a real number between 0 and 1. Es-sentially, the algorithm searches for the rolein S that best matches the one in R.

Figure 6 shows pseudocode for the Matchfunction. As we described before, the ser-vice request might include not only a rolebut also an expression (a disjunction of con-junction of roles). The loops in lines 4 and

Figure 4. A role-based (a) service advertisement and (b) service request for a second-opinion service.

Provider role Depending rolesInteraction type 1 Advisor Explainer ∨ InformerInteraction type 2 ExplainerInteraction type 3 Informer(a)

Searched provider roles: Advisor ∧ ExplainerRequester capacity roles: Informer, Explainer(b)

Figure 5. A partial OWL-S description of the second-opinion service advertisement infigure 4a.

<profile:ServiceParameter rdf:ID=”SERVICE_ROLES”><profile:sParameter>

<roles:ServiceRoles rdf:ID=”ROLE_DESCRIPTION_LIST”><roles:interactiveRole>

<roles:InteractiveRoleDescription rdf:ID=”INTERACTIVE_ROLE_1”><roles:providerRole rdf:resource=”http://.../roles.owl#AdvisorRole”/><roles:dependingRoles rdf:resource=”#DEPENDING_ROLES_1”/>

</roles:InteractiveRoleDescription></roles:interactiveRole><roles:interactiveRole>

<roles:InteractiveRoleDescription rdf:ID=”INTERACTIVE_ROLE_2”><roles:providerRole rdf:resource=”http://.../roles.owl#ExplainerRole”/>

</roles:InteractiveRoleDescription></roles:interactiveRole><roles:interactiveRole>

<roles:InteractiveRoleDescription rdf:ID=”INTERACTIVE_ROLE_3”><roles:providerRole rdf:resource=”http://.../roles.owl#InformerRole”/>

</roles:InteractiveRoleDescription></roles:interactiveRole>

</roles:ServiceRoles></profile:sParameter>

</profile:ServiceParameter><roles:RoleExpression rdf:ID=”DEPENDING_ROLES_1”>

<roles:item><roles:ConjunctiveRoleList rdf:ID=”CONJUNCTIVE_ROLE_LIST_1_2”>

<roles:roleEntry rdf:resource=”http://.../roles.owl#InformerRole”/></roles:ConjunctiveRoleList>

</roles:item></roles:RoleExpression>

NOVEMBER/DECEMBER 2006 www.computer.org/intelligent 17

6 decompose that expression, using theminimum as a combination function for thevalues in a conjunction and the maximumfor disjunctions.

MatchAtomicRequest returns the degree ofmatch between a role in the service requestand in a service advertisement, given therequester’s set of capabilities. It comparesthe requested role with every other givenrole and returns the maximum degree ofmatch. For each role in the advertisement,the algorithm makes the match with theprovider roles; it also makes the matchbetween the depending roles and the re-quester’s capabilities. The degree of matchis the minimum of both values. Again, werepresent the depending roles as a logicalexpression, which the algorithm must eval-uate by decomposing it within the MatchRole-Expr function.

The algorithm calculates the degree ofmatch between roles on the basis of the roleontology. For this, we use the four classesof degrees of match that Massimo Paolucciand his colleagues proposed: exact, plug-in, subsumes, and fail.9 For determining thedegree of match between an advertisementrole rA and a query role rQ, we use thesedefinitions:

• Exact match: rA = rQ; dom(rA, rQ ) = 1• Plug-in match: rA is a subclass of rQ;

dom(rA, rQ ) � [0.5, 1)• Subsumes match: rQ is a subclass of rA;

dom(rA, rQ ) � (0, 0.5)• Fail: no subclass relation exists between

rA and rQ; dom(rA, rQ ) = 0

Furthermore, we want a dom that’s inde-pendent of the ontology tree’s overalldepth but takes into account the semanticdistance ||rA, rQ|| between rA and rQ in therole ontology. The following equationdescribes an intuitive function that fulfillsour requirements:

With this dom function, the smaller the dis-tance between concepts (either in the case ofa plug-in or subsumes match), the moreinfluence a change of distance in the degreeof match will have.

Consider, for instance, the service adver-tisement in figure 4a and a service requestthat specifies the searched provider role Sec-ondOpinionRequestee and the requester capabil-ity role Informer. (That is, an agent is lookingfor a second-opinion provider and can playthe Informer role if the provider requires it.)Assuming that the semantic distance betweenthe advertisement and the query role is thelength of the path between both concepts inthe ontology tree, we calculate the degree ofmatch between both services as follows: Onthe basis of the ontology in figure 3, for inter-action type 1, the match between the providerrole Advisor and the searched role SecondOpin-ionRequestee is

Furthermore, the provider declares thedepending role Explainer ∨ Informer, and therequester includes that role in its capability, sothere’s an exact match (dom = max(dom(Ex-plainer,Advisor),dom(Advisor,Advisor)) = max(0, 1) = 1) for the depending-roles section. Asthe matching algorithm (see figure 6) states, thedegrees of match of the provider and depend-ing roles sections are combined by the mini-mum. So, in our example, interaction type 1’sdegree of match is min(0.5677, 1) = 0.5677.

Advisor SecondOpinionRequestee

dom Adviso

, = 2

( rr SecondOpinionRequestee

e

, )

.

=

+∗

=12

12

0 56772

dom r r

r r

er

A Q

A Q

r r AA Q

( , )

* || , ||

=

=

+

1

12

12

if

if isaasubclassof

if isasubclass

r

e r

Q

r rQA Q

12

* || , || oof

otherwise

rA

0

⎧

⎨

⎪⎪⎪

⎩

⎪⎪⎪

Figure 6. The main function of a role-based service-matching algorithm. This functionreturns the degree of match between a request R and a service advertisement S.

01 Match(R: service request, S: service advertisement)02 {03 dom = 004 FOR ALL CRLi IN R.ProviderRole {05 dom’ = inf06 FOR ALL rj IN CRLi {07 dom’ = min(dom’,MatchAtomicRequest(rj,R.RequesterCapabilities,S))08 }09 dom = max(dom, dom’)10 }11 return dom12 }13 MatchAtomicRequest(role: Role, RequesterCapabilities: SET OF ROLES,14 S: service advertisement)15 {16 dom = 017 FOR ALL IRDi IN S.InteractiveRoleDescription {18 dom1 = MatchRole(role,IRDi.ProviderRole)19 dom2 = MatchRoleExpr(IRDi.RoleExpression, RequesterCapabilities)20 dom = max(dom, min(dom1,dom2))21 }22 return dom23 }24 MatchRoleExpr(RExpression: SET OF ConjunctiveRoleList,25 RequesterCapabilities: SET OF Roles)26 {27 dom = 028 FOR ALL CRLi IN RExpression {29 dom’ = inf30 FOR ALL rj IN CRLi {31 dom’ = min(dom’,MatchRoleInList(rj, RequesterCapabilities))32 }33 dom = max(dom, dom’)34 }35 return dom36 }37 MatchRoleInList(role: Role, RL: SET OF Roles)38 {39 dom = 040 FOR ALL ri IN RL {41 dom = max(dom, MatchRole(role,ri))42 }43 return dom44 }

A g e n t s i n H e a l t h c a r e

18 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

The same reasoning holds for the other twointeraction types of the advertised service. Inthese cases, no subsumption relation existsbetween the provider role (Explainer and Informer,respectively) and the searched role (Advisor), sothe degree of match is 0. Finally, the degreeof match between both services is the best(maximum) of the three possible interactions,which is 0.5677.

Implementing role-based service discovery

As we mentioned before, we’ve imple-mented our approach in the Rowls match-maker, which we integrated into the CASCOM

software framework.

Implementing the ontologyTo create our role ontology (see figure 7),

we used Protégé (http://protege.stanford.edu), a free, open source ontology editor andknowledge base framework. Protégé ontolo-gies can be exported into a variety of formatsincluding OWL, and Protégé is supported bya strong community of developers and acad-emic, government, and corporate users. Fur-thermore, Protégé has several extensions,including an OWL-S plug-in.

Implementing RowlsOur role-based matchmaker

• reads user queries and service descriptions,

• extracts role information from the serviceprofiles,

• accesses the role ontology to performmatching between queries and servicedescriptions, and

• returns service descriptions ordered by thedegree of match.

The basic requirements include parsingOWL-S service descriptions and managingthe role ontology, with some reasoning sup-port. For this purpose, we chose the Mind-swap Java library (www.mindswap.org/~mhgrove/kowari), developed by the Univer-sity of Maryland’s Semantic Web ResearchGroup. For managing OWL ontologies, weopted for the well-known Jena (http://jena.sourceforge.net) framework for buildingSemantic Web applications. Jena provides aprogramming environment for RDF, RDFSchema, and OWL; a SPARQL (www.w3.org/TR/rdf-sparql-query) query engine; and arule-based inference engine. Furthermore,Jena is used also by the Mindswap OWL-Slibrary, letting us reduce our reliance onadditional external libraries.

The matchmaker takes an OWL-S serviceprofile as a query, and returns an ordered setof relevant services that match the query,each annotated with its match degree.Because the role ontology’s generic part issupposed to be rather static over time, weprovide the option of using a matchingmatrix that stores the degree of matchbetween every pair of roles as new matchesare performed.

When asked to perform a match, thematchmaker receives a list of URIs (uniformresource identifiers) of service advertise-ments (usually from a service directory) anda full-text OWL-S service profile represent-ing the query. It first reads the service adver-tisement at every URI and extracts the rolestructure. It then extracts the query’s rolestructure and applies the matching algorithmagainst the services stored in the engine. Fig-ure 8 shows a screenshot of the matchmakerGUI, matching a query with three services.

Integrating and validating RowlsIn CASCOM, the Service Matchmaking

Agent provides extended matchmaking func-tionality. The SMA performs a match be-tween the set of OWL-S service profilesretrieved from distributed directories and theuser query, which is also an OWL-S serviceprofile. The SMA has three main compo-nents, which focus on different parts ofOWL-S service profiles:

• OWLS-MX performs a hybrid syntactic andsemantic match of inputs and outputs.7

• Rowls looks for similarities between theroles of a query and service advertisement.

• PcEM (Preconditions and Effects Match-maker) analyzes the logical expressions inthe precondition and the effects parts ofthe OWL-S service profile.

You can combine the three componentsin several ways. Because they offer similarinterfaces, besides the trivial standalone

Figure 7. A screenshot of the role ontology developed with Protégé.

Figure 8. The matchmaker GUI, matching a query with three services.

configurations, we’ve considered two inter-esting setups. First, we’ve used the threecomponents sequentially, where the firsttwo act as prefilters. Figure 9a shows sucha configuration, where Rowls possiblyreduces the number of input services toOWLS-MX, which in turn possibly reducesthe number of input services to PcEM.

The second setup runs the three match-makers with the same set of services andthen combines the returned degrees ofmatch with an aggregation function (see fig-ure 9b).

The only capability the SMA offers toother CASCOM agents is getMatchingServices. Thiscapability requires as parameters a URI orfull-text OWL-S service profile as a query(service request) and one or more serviceprofiles (services). It can also take anoptional parameter defining the type ofrequested match (exact, plug-in, subsumes,or fail). If getMatchingServices executes success-fully, the SMA returns a ranked set of ser-vices for a query.

For basic evaluation of the algorithm,we’ve developed a test collection of

approximately 300 OWL-S Semantic Webservice descriptions, annotated with roles.Our results confirm that the algorithm canobtain ranked matching results in negligible

response time (less than 1 second). In addi-tion, we’re quantitatively evaluating thematchmaker’s performance as part of theSMA, using the different matchmaker com-binations we described earlier. Furthermore,the matchmaker, as part of the overall CAS-COM infrastructure, is being validated in afield trial concerning real-world medical-emergency assistance, supported by the Aus-trian Tyrolean Hospital Consortium andEMA.

We plan to vary several aspects of our algo-rithm to improve its precision. In particular,we’ll study how the matchmaker behaves ifwe substitute our aggregation functions withmore complex triangular norms and conormsfrom fuzzy logic theory.

We also plan to explore how compatibleour approach is with the WSMO (Web Ser-vice Modeling Ontology) service descriptionapproach.

AcknowledgmentsThis work has been partially supported by the

European Commission under grant FP6-IST-511632 (CASCOM) and by the Spanish Ministry ofEducation and Science, project TIC2003-08763-C02-02.

References

1. M. Luck et al., eds., Agent Technology: Com-puting as Interaction (A Roadmap for AgentBased Computing), AgentLink, 2005; www.agentlink.org/roadmap/al3rm.pdf.

2. S.A. DeLoach, M.F. Wood, and C.H. Spark-man, “Multiagent Systems Engineering,” Int’lJ. Software Eng. and Knowledge Eng., vol.11, no. 3, 2001, pp. 231–258.

3. M. Wooldridge, N.R. Jennings, and D. Kinny,“The Gaia Methodology for Agent-OrientedAnalysis and Design,” Autonomous Agentsand Multi-Agent Systems, vol. 3, no. 3, 2000,pp. 285–312.

4. M. Burstein et al., “A Semantic Web ServicesArchitecture,” IEEE Internet Computing, vol.9, no. 5, 2005, pp. 72–81.

5. M. Huhns et al., “Research Directions for Ser-vice-Oriented Multiagent Systems,” IEEEInternet Computing, vol. 9, no. 5, 2005, pp.65–70.

6. L. Cavedon et al., Extending Web ServicesTechnologies: The Use of Multi-AgentApproaches, Springer, 2004.

7. M. Klusch, B. Fries, and K. Sycara, “Auto-mated Semantic Web Service Discovery withOWLS-MX,” Proc. 5th Int’l Conf.Autonomous Agents and Multi-Agent Systems(AAMAS 06), ACM Press. 2006, pp.915–922.

8. L. Li and I. Horrock, “A Software Frameworkfor Matchmaking Based on Semantic Web

NOVEMBER/DECEMBER 2006 www.computer.org/intelligent 19

Threshold

Nservices

M servicesM <= N

Rowls

OWLS-MX

Threshold

PcEM

N sortedservices

P sortedservices

P servicesP <= M

M sortedservices

Nservices

Rowls

OWLS-MX

PceM

PcEM = Preconditions and Effects Matchmaker

N sorted services

N sorted services

N sorted services

N sortedservices

F(X, Y)

ServiceMatchmaking Agent

ServiceMatchmaking Agent

(b)(a)

Figure 9. Two matchmaker agent configurations: (a) using each component sequentially; (b) using each component simultaneously.

Technology,” Proc. 12th Int’l World Wide WebConf. Workshop E-Services and the SemanticWeb (ESSW 03), ACM Press, 2003, pp.331–339.

9. M. Paolucci et al., “Semantic Matching ofWeb Services Capabilities,” Proc. 1st Int’lSemantic Web Conf. (ISWC 02), Springer,2002, pp. 333–347.

10. C. Cáceres, A. Fernández, and S. Ossowski,“CASCOM—Context-Aware Health-Care Ser-vice Coordination in Mobile ComputingEnvironments,” ERCIM News, no. 60, 2005, pp.77–78.

T h e A u t h o r sCésar Cáceres is an assistant professor of computer science at the Univer-sity Rey Juan Carlos. He’s completing his PhD thesis in e-health, where hisprimary interests are disease modeling and evaluating how telemedicineaffects the care of chronic patients. He obtained his MSc in telecommunica-tions engineering from the Technical University of Madrid. Contact him atEscuela Superior de Ciencias Experimentales y Tecnología (ESCET), Univ.Rey Juan Carlos, C/ Tulipán, s/n. 28933 Mostoles, Madrid, Spain; cesar.caceres@urjc.es.

Alberto Fernández is an assistant professor of computer science at the Uni-versity Rey Juan Carlos and is finishing his PhD thesis at the university. Hismain research interests are multiagent systems and service coordination. Heobtained his MSc in informatics from the Technical University of Madrid.Contact him at Escuela Superior de Ciencias Experimentales y Tecnología(ESCET), Univ. Rey Juan Carlos, C/ Tulipán, s/n. 28933 Mostoles, Madrid,Spain; alberto.fernandez@urjc.es.

Sascha Ossowski is associate professor of computer science at the Uni-versity Rey Juan Carlos, where he leads the Artificial Intelligence ResearchGroup. His main research interests include Web intelligence and agent sys-tems. He obtained his PhD in AI from the Technical University of Madrid.Contact him at Escuela Superior de Ciencias Experimentales y Tecnología(ESCET), Univ. Rey Juan Carlos, C/ Tulipán, s/n. 28933 Mostoles, Madrid,Spain; sascha.ossowski@urjc.es.

Matteo Vasirani is a PhD student at the University Rey Juan Carlos and amember of the university’s Artificial Intelligence Research Group. Heobtained his MSc in informatics from the University of Modena. Contact himat Escuela Superior de Ciencias Experimentales y Tecnología (ESCET), Univ.Rey Juan Carlos, C/ Tulipán, s/n. 28933 Mostoles, Madrid, Spain; matteo.vasirani@urjc.es.

IEEEDistributed

Systems Onlinebrings you peer-reviewed

articles, detailed tutorials,

expert-managed topic areas,

and diverse departments

covering the latest news and

developments in this fast-

growing field.

Log on for free accessto such topic areas as

Grid Computing • Middleware

Cluster Computing • Security

Peer-to-Peer • Operating

Systems • Web Systems

Parallel Processing • Mobile

& Pervasive • and More!

To receive monthly updates, emaildsonline@computer.org

http://dsonline.computer.org

THE IEEE’S 1ST ONLINE-ONLY MAGAZINE

NEW CALENDAROF AI EVENTS

See www.computer.org/

portal/pages/intelligent/

content/calendar.html

Visit us on the Web at

www.computer.org/intelligent

IEE

E

20 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

A g e n t s i n H e a l t h c a r e