1

WSML Presentation

Variance in e-Business Service Discovery

Uwe Keller

based on a paper by S. Grimm, B. Motik and C. Preist

(to be published)

and slides by S. Grimm for the SWWS Evaluation Meeting, Lausanne, France, 2004.

2

Motivation …Automation of B2B partner discovery and contract negotiation (Project SWWS)

First step: Identify potential business partners that provide suitable

services by service / request matching Many approaches are based on DLs But sometimes do not produce intuitive results

This paper … Analyzes semantic of service descriptions on intuitive

notions Introduce different kinds of variance in service descriptions Shows how to exploit that in matchmaking phase Maps intuitive notions to constructs in OWL-DL Investigates different inferences and defines semantics of

discovery

3

Service Discovery …A service requester may use a discovery mechanism to locate a set of providers which are potentially able to meet its needs.

A framework for automation service discovery requires:

A language for describing services with formal semantics which matches the intuitive understanding of modellers

Matching algorithms for implementing discovery

In this paper … Following common approaches: Use Description Logics (OWL-DL) Despite common approaches: Stick to the intuitive semantics a

service modeller expects & provide methodological guidelines Focus on the problem of variance (in service descriptions)

4

I. Semantic Description of Services

5

Services & Service Descriptions Widespread meanings of the term „service“

as: Abstract business interaction between two parties as: Computational entity with a WS interface

Proposed model Set-based model Distinguish service instance and abstract service

class Real-world service = instance (Agreed Service)

Represents agreement in all details of a service to be provided between requestor and provider (contract)

Service description = set of (agreed) services = service class

Classes capture variance in provided (and requested) services

6

Service Descriptions (II) Proposed model (cont‘d)

In a B2B scenario, this is natural way for providors/requestors to express their capablities/needs: Both describe the space of possible concrete

service instances / contracts which are acceptable for them

Service descriptions act as templates for contracts induce variance

Service instances can be represented as … directed labeled graph / instance of relational

schema

7

Example … Service instance

Shipping Crate

is-a

is-a

8

Example (II) … Service description

Service instance / contract 1 Service instance / contract 2

Modelsvariance in acceptable contracts

Possible representation: DL concept expression:

Capabilitys ≡

Shipping ⊓∃from.UKCity ⊓∃to.GermanCity ⊓item.Container . . .

9

Service Descriptions (III) Provider and Requestor descriptions are treated in the same

way!

Variance in service models: 2 flavours can occur Variance due to intended diversity in contracts (Service Descr.

as concepts) Variance due to incomplete knowledge (Open-world semantics

of DLs) … and can/should be distinguished (in matchmaking!)

How to reflect variance due to incomplete knowledge? Consider many possible worlds (each one detailing out the

„missing“ information) Withing each possible world: intentended diversity by set

of acceptable contracts

10

Service Descriptions (IV) Different kinds of

variance … Incomplete information is

(fully) detailed out by selecting one possible world

Intended diversity is represented as many alternative contracts within this world

11

Matching for Discovery … Discovery = matching goals and capabilities

checking if goal and capability allow common service instances

If there are common instances, requester and provider can (potentially) do business with each other

(Goal)I  ∩  (Capability)I ≠ Ø

12

II. Operationalize Discovery via Logics: From Intuition to Logics

13

From Intuition to Logics … How to represent the informal elements described before in DL?

Service Description = Set of DL axioms D (using some concept S somewhere)

Domain specific background knowledge = DL knowledge-base KB (containing all relevant facts)

Possible world = Model I of KBD

Contract = Relation structure (Instance with complex properties)

Acceptable contracts = Instances in the extension I(S) of S

Variance due to intended diversity = I(S) is not a singleton set

Variance due to incomplete knowledge = KBD has several models I1, I2, …

Matching = Applying DL-inferences in a procedure match(KB, S-req, S-prov)

14

From Intuition to Logics … How to represent typical informal characteristics of

service properties in DL?

Variety Property is fixed to a specific value i or can range

over a certain class C: r.{i} or r.C Availability

Property can be obligatory or optional: r.T Multiplicity

Property can be multi-valued or single-valued : ≤1r Coverage

Property can be range covering: In every possible world, for any value in the range C, there is an acceptable contract with this property value: C r-.S

15

Example …

16

III. Matching Service Descriptions

17

Matching Service Descriptions Treating Variance due to Incomplete Knowledge

Reflected by multiple models I of KB* Two ways to reason with

Is there a way of resolving unspecified issues (i.e. possible world) such that the two service descriptions accept a common contract Satisfaction check KB*{Match(Sr,Sp)}

Regardless of how to resolve unspecified issues, requestor and provider have common contracts in every possible world Check entailment of Match(Sr,Sp) by KB*

18

Matching Service Descriptions Treating Variance due to Intended Diversity

Reflected by multiple alternate contracts within a single model I of KB*

Three ways to reason with

Is there a common contract for both parties Match(Sr,Sp) := Sr ⊓ Sp ⋢ ⊥

Requested service is more specific Match(Sr,Sp) := Sr ⊑ Sp

Requested service is more general Match(Sr,Sp) := Sp ⊑ Sr

19

Inferences for Matching (1) Satisfiability of concept conjunction

Weakest check that can be applied (along the 2 dimensions) One possible world One common instance

20

Inferences for Matching Example

Match(KB, Dr, Dpa) : yes! Match(KB, Dr, Dpb) : yes! (since UKCity ⊓

USCity ⋢ ⊥ is not specified in KB strange!)

21

Inferences for Matching (2) Entailment of concept subsumption

Very strong check (in comparison to (1) ) Regardless of possible worlds (in any of them) All instances of one service description is a subset of the

other service description (provider/requestor)

22

Inferences for Matching Example

Match(KB, Dr, Dpa) : no! (Dublin not in the UK) Match(KB, Dr, Dpb) : no! (Plymouth not in US) To strong for the general case (Dpa should

match)

23

Inferences for Matching (3) Entailment of concept non-disjointness

Overcomes deficiencies of (1) and (2) Regardless of possible worlds (in any of them) Checks for a common contract in each possible world Stronger than (1), weaker than (2)

24

Inferences for Matching Example

Match(KB, Dr, Dpa) : yes! Match(KB, Dr, Dpb) : no! (Plymouth not in US) Intuitive expected result is achieved!

25

Open issues … „Standard“-Notion which captures intuition

Entailment of Concept Non-Disjointness But: Requires modellers to seperate out possible worlds in

which some of their intended accepted contracts are missing (All of them have to be captured)

Can be achieved by Range-Covering property restrictions

However: DL has only restricted expressiveness when several properties are involved at the same time Requires coverage of all possible combinations of

values

Not expressible in DL

But perhaps with DL+Rules ?

26

IV. Conclusions & Relation to WSMO

27

Conclusions … Paper descriped a Service Discovery Framework for the e-

Business setting based on DL Provided semantics to formal service descriptions in an

intuitive way Indentified two dimensions of variance in formal service

descriptions Mapped intuitive notions to formal representatives in DL Introduced a set of attributes by which properties can be

restricted (and how this is done in DL) -> Methodology! Discussed several inference that can be used for matchmaking

along the two dimensions of variation Proposes Entailment of Concept Non-Disjointness to overcome

some deficiencies of the notions that have been proposed in the DL-literature so far.

Proposed new ranking scheme (omitted in this presentation)

28

Relevance to WSMO … Model close to parts of D5.1 (WSMO Discovery)

Distinguish service and web service Discovery != finding a real-world service Descriptions on the level of simple semantics annotations (Action-

Object-Model) Does not cover the mediation problem

Investigates a specific model for simple semantic annotations by means of an example Action-Object model Gives a set of attributes for restricting properties (of a contract) for

simpler modelling (Availability, Muliplicity, …) Variance due to incomplete information is treated in D5.1 only in

one way (independence of incomplete information, not sure whether the other alternative is actually useful)

29

Relevance to WSMO (II) … Fixes a standard notion (for B2B scenario)

In D5.1 we don‘t do that by purpose Range coverage and related problems

Is needed for us as well with the intersection match (= materializing the universe at a logical level) We can deal with that if we use a expressive language like

WSML-FOL (thought this might be more complex if the service (action-object-model) would be more complex).