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
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
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)
I. Semantic Description of
Services
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
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
Example …
Service instance
Shipping Crate
is-a
is-a
Example (II) …
Service description
Service instance / contract 1Service instance / contract 2
Model
variance in acceptable contracts
Possible representation: DL concept expression:
Capabilitys≡ Shipping ⊓
∃from.UKCity ⊓
∃to.GermanCity ⊓
item.Container . . .
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
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
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
(Goal)
I∩ (Capability)
I≠ Ø
II. Operationalize Discovery via Logics:
From Intuition to Logics
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
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
Example …
III. Matching Service
Descriptions
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
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
Inferences for Matching
(1) Satisfiability of concept conjunction
Weakest check that can be applied (along the 2 dimensions)
One possible world
One common instance
Inferences for Matching
Example
Match(KB, Dr, Dpa) : yes!
Match(KB, Dr, Dpb) : yes! (since
UKCity ⊓ USCity ⋢ ⊥ is not specified in KB
strange!)
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)
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)
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
Inferences for Matching
Example
Match(KB, Dr, Dpa) : yes!
Match(KB, Dr, Dpb) : no! (Plymouth not in US)
Intuitive expected result is achieved!
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 Not expressible in DL
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.
