1 WSML Presentation Variance in e-Business Service Discovery Uwe Keller based on a paper by S. Grimm, B. Motik and C. Preist and slides by S. Grimm for the SWWS Evaluation Meeting, Lausanne, France, With very minor modifications by R. Möller

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 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 ShippingCrate is-a

8 Example (II) …  Service description Service instance / contract 1Service instance / contract 2 Model variance in acceptable contracts Possible representation: DL concept expression: Capability s ≡ 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 KB  D 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 = KB  D 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 Conclusions …  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.