Partner and Service Discovery for Collaboration Establishment with Semantic

Web Services

Michael Stollberg, Uwe Keller, Dieter Fensel DERI – Digital Enterprise Research Institute

3rd International Conference on Web Services (ICWS 2005)

Orlando, Florida, July 12th

2

Content

1. Automated Collaboration on the Semantic Web

2. Semantically Enabled Discovery

3. Partner and Service Discoverer Architecture

4. Findings

5. Conclusions

3

Motivating Example

LM

P D

Agent A(P)Goal:plan[ - med. treatment for M- chauffeur(P) - consistent with calendar(P)]Plan: - check plan from A(L) - if OK, then book else: revise plan

Agent A(L)Goal:plan[ - med. treatment for M- chauffeur(P)] Plan:1) find suitable doctor 2) coordinate chauffeur(P)

med. info service

calendar service

transportinfo serv.

owns owns

O-person O-medicalO-date&timeO-transport

Agent A(D)Goal:offer[ - med. treatment- appointement] Plan:1) find customer2) book appointement

owns

book app. service

doctor information (website)

ontology usage (also for agents, omitted here)

1:need medical treatment2: inform, chaffeur(P)

3a: assign goal

3b: make / find plan

3b: make / find plan

3a: assign goal

Xb: make / find plan

Xa: assign goal

4:find doctor

uses

provides

5:inform, plan

6:revise plan7:book appointment

interactuses8: add plan

4

Conceptual Architecture

Agent B

Goal Instance

Agent A

Goal Instance

has(1,n)

compatible goals = collaboration partners

automated collaboration execution

Domain Knowledge

uses(1,n)

has(1,n)

uses(1,n)

Collaboration Service

Web Service

Goal Template Repository

ServiceRepository

Collaboration Service

Web Service

OwnerOwnergoal assignment

service discovery

owns

Ontology OntologyOntology Ontology

5

Agent Semantic Description

Agentselectronic representative of real world entity that wants to achieve an objective by automated collaboration Class agent hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator owner type owner collaboration type collaboration history type collaboration Class owner hasNonFunctionalProperties type nonFunctionalProperties owner type instance preference type axiom policy type axiom serviceUsagePermission type service Class collaboration hasNonFunctionalProperties type nonFunctionalProperties goal type goal single-valued service type service

6

Goals Semantic Description Goal Templatepredefined schema of user objective, described as WSMO 1.0 goalClass goalTemplate is-a wsmov1.0Goal hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type {ooMediator, ggMediator} hasPostcondition type axiom hasEffect type axiom Goal Instanceconcrete objective assigned to an agent, instantiated Goal Template, client for service usage Class goalInstance sub-Instance goalTemplate hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator hasPostcondition type axiom hasEffect type axiom hasSubmission type instance hasResult type instance goalResolutionStatus type goalResolutionStatus

7

Collaboration Service Description

Collaboration Servicesfacility an agent uses for participating in an automatically executed collaborationinteracts with other agents and utilizes Semantic Web resources via its orchestration Class collaborationService is-a wsmoService hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator hasCapability type capability single-valued hasSharedVariables type sharedVariable hasPrecondition type axiom hasAssumption type axiom hasPostcondition type axiom hasEffect type axiom hasInterface type interface clientInterface type serviceInterfaceDescription orchestration type serviceInterfaceDescriptionClass serviceInterfaceDescription sub-Class wsmoServiceInterface hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator hasVocabulary type concept_in, concept_out, concept_controlled hasState type ontology hasGuardedTransition type if (condition) then update – for client interface if (condition) then operation(CS, R, update) – for orchestration

8

Collaboration Management

Partner Discoverer

Service Discoverer

Orchestration Validator

GI

{GI}

GI

{S}

boolean

{(CS,R)}

Collaboration (preliminary)(A1 (G1, {CS}1), A2 (G2, {CS}2), ..)

Goal InstanceAgent

(A1 (G1, CS1,{R}CS1), A2 (G2, CS2,{R}CS2),..)

Goal Instance…

separately for each GI

each possible service combination

Agent

Collaboration (final)

Collaboration Executor

each collaborationgoal resolution forthe goal of eachcollaboration partner

goal resolution forthe goal of each

collaboration partner

9

Semantically Driven Discovery

find appropriate facility (Web) Service for automatically

resolving a goal as the objective of a requester

Key Word Matching match natural language key words in resource descriptions

Controlled Vocabularyontology-based key word matching

Semantic Matchmaking … what Semantic Web Services aim at

Ease of provision

Possible A

ccuracy

10

Action and Object Knowledge

Knowledge Types Distinction - Action = activity to be performed on object (e.g. buy, sell, ..) - Object = entity that action is performed on (e.g. product,

ticket, …) Action and Object Knowledge is different

- “Action” defines what is to be done; interacting entities need to have compatible actions (e.g. buy <-> sell)

=> Action-Resource Ontology - “Object” defines whereon an action is to be performed;

interacting entities need to have not-contradicting object definitions

=> Set-theoretic Object Matchmaking

Combination is needed (agents / resources might have not-contradicting objects but incompatible actions)

11

Action-Resource Ontologyconcept action compatibleAction symmetric ofType action concept buy subConceptOf action compatibleAction symmetric ofType sell concept sell subConceptOf action compatibleAction symmetric ofType buy

concept resource hasAction ofType set actionconcept goal subConceptOf resource concept service subConceptOf resource

concept buyergoal subConceptOf goal hasAction ofType set buy concept sellerservice subConceptOf service hasAction ofType set sell

Action Taxonomy

ResourceTaxonomy

all resources are defined as instances of resource types

• allows determining action compatibility / equality of agents & resources• supports handling multi-party collaborations

12

Object Matchmaking

Set-Based Resource Descriptions

Information Space all possible instances of used ontologies

Description Notion all possible instances that

satisfy restricted information space

postcondition definedBy exists ?PurchaseItem(?PurchaseItem[ item hasValue ?PurchaseFurniture ] memberOf swfmo:product) and exists ?PurchaseFurniture(?PurchaseFurniture[ material hasValues {wood}, ] memberOf furn:chair) and ?X[ purchaseItem hasValue ?PurchaseItem, buyer hasValue kb:MichaelStollberg, purchasePayment hasValue kb:MSCreditCard ] memberOf swfmo:purchaseContract .

Goal Instance Postcondition- Objective: receive a purchase contract for a wooden chair for Michael Stollberg, payment with credit card

- meta-varibale X (dynamically quantified by matchmaking notion) - restrictions on several ontology notions

- WSML syntax

13

Object Matchmaking

Set Theoretic Matchmaking Notions

1. Exact Match: DQ, DR, O, M ╞ x. (DQ <=> DR)

2. PlugIn Match: DQ, DR, O, M ╞ x. (DQ => DR)

3. Subsumption Match: DQ, DR, O, M ╞ x. (DQ <= DR)

4. Intersection Match: DQ, DR, O, M ╞ x. (DQ DR)

5. Non Match: DQ, DR, O, M ╞ ¬x. (DQ DR)

= DQ = DR

X

14

Realization in VAMPIRE

Theorem Prover- developed at University of Manchester - winner of several CASC competitions

works with TPTP - FOL language, “standardized” - Transformation WSML -> TPTP

without loss of information & “easy”

15

Structure of Proof Obligation

1. Needed Knowledge Resources - include Ontology Theory and Universe - Knowledge Base optionally

2. Resource Description notion to be matched- Request Resource & Result Resource - Only those notions that are to be matched

3. Object Matchmaking notion - Include as specified in the Discovery Request

=> easy to generate dynamically

16

Knowledge Representation

1.Ontology Theory - basic ontological relations (transitive subsumption, etc.) - WSMO ontology meta model (when working on WSMO)

2.Universe all domain ontology knowledge needed- Ontology schemas (allows to work on resource description) - Generic Instances

3.Knowledge Base - pre-defined instances - optional (but very useful)

4.Resource Description - WSMO resource description notions (postcondition, effects,

etc)- only those notions which are needed for object

matchmaking

17

Generic Instance in Universe

Generic Instance definition:- existentially quantified object - complete fact with universally quantified variables as attribute values

forAll ?A, ?B, ?C(exists ?X(?X instanceOf concept[ attributeA hasValue ?A, attributeB hasValue ?B, attributeC hasValue ?C

] ) ) .

18

Generic Instances – Why?

support for Intersection match:- Intersection Matching Notion searches for an existing object

wherefore the request and result predicate do not contradict - If there are Generic Instances for all concepts of all used domain

ontologies, then the existence of an instance of every possible ontology object can be proved by constructing a hypothetical graph wherein for each node there exists a generic instance.

Generic Instance of Ontology Concept

elementary datatype

type of attribute value

not new – same technique in other approaches for realization of intersection match

19

VAMPIRE (+) and (–)

Pro:- Not bound to limited reasoning facilities

supported by existing reasoners => we can create object matchmaking as - Ontology Theory + Universe as the only pre-

defined knowledge resources needed => efficient & easy to handle at runtime

Con:- does not have any built-in functions

o no support for basic datatype processing o no arithmetics

=> everything has to be provided as explicit FOL theories

20

Partner & Service Discovery Components

• run independently, invoked by agents • apply ARO & OMM as defined above• Design Principles:

1. Common Discoverer Architecture 2. Modularized Functionality 3. Layered Architecture (stepwise narrow search

space) 4. Reduction of expensive operations (efficiency)

21

Partner Discoverer Architecture

GIi

Action-Resource Ontology

DiscoveryResultsets of compatible Goal Instances

(2) GG Matcher

Discovery Requestinitiating Goal Instance

GTi(1) Cooperation

Knowledge FilterGTg

GIgGIg

instanceOfinstanceOf,

status = ‘open’

Action Compatibility

22

Service Discoverer Architecture

Discovery RequestGoal Instance

Discovery Resultusable Services

Service Repository

Discovery Result(intermediary)

Service Filter

(2) GIS MatcherGIi

GTi

instanceOf

(1) Pre-Selector

Action Equality

23

Findings

• Functional Correctness approved in use cases – Distinction Action – Object Knowledge needed – Performance (Vampire):

– average 1-2 sec (domain dependent !!) – correctness & scalability more important than celerity

• Goal and Service descriptions are mostly constrained object definitions without complex logical expressions => object matchmaking rather logical reasoning

• Industrial applicability: – “hide logics from users and system developers” – semantic descriptions by Knowledge Engineers – exhaustive tool support required for users and system

developers– abandon logical expressivity if it hampers automation

24

Conclusions

• Framework for Collaboration on the Semantic Web – agents, goals, Web Services – clear separation of partner & service discovery

• Realization of Semantic Discovery – distinction Action-Object Knowledge – semantic discovery techniques

o Action-Resource Ontology (action compatibility / equality) o Set-based Object Matchmaking (not-contradicting objects)

– discoverer architectures (modularized, layered, efficient)

• based on Web Service Modeling Ontology WSMO – semantic element descriptions – set-based object matchmaking