Upload
spike
View
19
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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. Motivation …. - PowerPoint PPT Presentation
Citation preview
1
WSML PresentationVariance in e-Business Service
DiscoveryUwe 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).