cardoso j. "semantic web: theory, tools and applications" semantic web service discovery:...

Cardoso J. "Semantic Web: Theory, Tools and Applications"

Semantic Web Service Discovery: Methods, Algorithms and Tools

Chapter 11

Do not put anything here.This area is reserved

for the book cover.

Cardoso J. "Semantic Web: Theory, Tools and Applications" 2

Chapter Outline Introduction

Web Services Semantic Web Services

Web Service Discovery Semantic Web Service Discovery

Architectures Methods/algorithms Tools Open Issues


Web Services (WS) programmatic interfaces for applications (i.e.,

business logic), available over the WWW infrastructure and developed with XML technologies.


Semantic Web Services (SWS) I Semantic Web (SW) [Antoniou, 2004]

Ontologies Rules Languages (e.g., OWL, RDF)

SW + WS = SWS Web services annotated with semantics Annotation includes:

Service description, provider details, service operations, service execution model, service parameters, service data flow, service invocation details, …


Semantic Web Services II

The annotation terms adhere to formal terminologies, a.k.a. ontologies

Service-related SW technologies DAML-S, OWL-S, WSDL-S, SWSO/SWSL,

WSMO/WSML [Cardoso, 2005]


WS Reference Architecture


Architectural Components Service Registry

“yellow pages” for services Matching Algorithm

Implemented in Matching Engine Affects discovery effectiveness

Service Request Captures requestor’s information need

Service Advertisement Describes a service Created by service provider

Assumption:Identical format


WS Description WSDL

XML language for textual service description

UDDI Data model and API for service

publication/searching Contains links to WSDL documents Main elements:

businessEntity, businessService, bindingTemplate, tModel


WS Matchmaking

Standard UDDI Keyword- and category-based search “Find qualifiers” (e.g., wildcards) Manual (Web browsing) or through API

Information Retrieval (IR) techniques similarity measures, clustering, etc.


Pitfalls of WS Discovery (1) Informal description of service

functionality/capabilities Unstructured, natural language descriptions NAICS: Category “Dating Services” does not match

“Personal Relationships Services” Incomplete description of service

functionality/capabilities Providers are not obliged to provide complete service

info Syntactic relevance vs. intentional relevance

Linguistic polysemy and ambiguity are problems Keywords cannot capture operational service

semantics, useful during discovery/composition


Pitfalls of WS Discovery (2) Lack of constraint specifications

Preconditions and other constraints are useful for the entire service lifecycle

Limited expressiveness of domain classification schemes E.g., NAICS, UNSPSC

No support for indirect matching UDDI does not support even simple

compositions


New Architectural Components (1)

Service Annotation Ontologies (SAO) Formal service description models Specify service capabilities OWL-S, WSMO, WSDL-S, SWSO

Domain Ontologies Domain-specific terminologies Substitute keywords and free text in service

descriptions Hierarchies of concepts and relationships Written in OWL, DAML+OIL, RDF(S), …


Example: The OWL-S SAO Service Profile [Martin, 2005]

Human-readable service description and provider’s contact details

Functional parameters Inputs, Outputs, Preconditions, Effects

Non-functional parameters (e.g., QoS) Mostly used in service discovery

Service Model Control and data flow of service execution

Service Grounding Service access and invocation details Link to WSDL description


Example: A Beer domain ontology

http://www.dayf.de/2004/owl/beer_v0.3.owl


Revised “Traditional” Components Service Registry

UDDI is still used but with references to semantic descriptions

Matching Algorithm More complex and “intelligent” Exploits the formal semantics of service descriptions

Service Advertisement Written in a SAO Refers to concepts of a domain ontology

Service Request Usually similar to an advertisement Ontology integration and semantic mediation can be

applied to bridge different request-advertisement specifications


Centralized Architecture ISemantic extension of UDDI

tModels point to semantic descriptions

Translator creates such semantic tModels

Semantic matching is performed in an external engine

Keyword-based matching can still be used

Some extensions to UDDI Inquiry API are needed


Centralized Architecture IIThe matching algorithms themselves are published as WS

Support for diverse SAOs and matching algorithms

Step1: Ad hoc selection of the best matching service

Step2: Invocation of selected service with the request as parameter

Requires minor UDDI API changes

Allows more flexible business models but complicates service composition


Peer-to-Peer ArchitectureP2P suitable (i.e., scalable, efficient) for distributed environments (e.g., Web)Peers may be service requestors or providers

Each peer-requestor may use its own matching algorithm

Each peer-provider can directly update the local service advertisements

Result: high flexibility


Degree of Match (DoM) A value that expresses how similar

two entities are, with respect to some similarity metric(s)

Important feature of most SWS matchmaking approaches

Allows for ranking of discovered services

Example DoM set: exact, plugin, subsumes, subsumed-by, fail


Variety of Matchmaking Approaches Direct

Return only single services that match the request

Indirect Compute service compositions (or “chains” in

the simplest case) Logic-based

Description Logics and First Order Logic reasoning

Similarity-based (IR techniques) Linguistic similarity, term frequency, …

Graph matching


Approach I – Semantic Capabilities Matching A pioneering work [Paolucci, 2002a] Main idea

An advertisement A matches a request R when all the outputs of R are matched by the outputs of A, and all the inputs of A are matched by the inputs of R

DL subsumption matching between inputs and outputs Outputs are regarded more significant than inputs

Degree of Match Matching conditions

EXACTIf req.o is equivalent to adv.o, orIf req.o is a direct subclass of adv.o

PLUGIN If adv.o subsumes req.o

SUBSUMES If req.o subsumes adv.o

FAILIf there is no subsumption relationship between req.o and adv.o

The inverse conditions hold for inputs


Approach II – Multi-level Matching

A variant of Approach I Main idea

Both functional and non-functional service data matters

Multi-level matching IOPE attributes, service categories, custom

service parameters (e.g., QoS-related) DoM aggregation

Weighting the DoM of the various levels A very difficult optimization problem


Approach III – DL Matchmaking with Service Profile Ontologies Service Profile Ontology

Concepts are DL expressions of service constraints DL reasoners create the ontology tree A logic-based service registry

DL subsumption matching The DoM set of Approach I is re-defined A new DoM is introduced [Li, 2004]

An advertisement matches a request if their intersection is satisfiable


Approach III - Example

2 Advertisements and a Request Q

The Service Profile Ontology after DL reasoning

DoM(Q,FreeDatingService) = PLUGINDoM(Q,FreeDatingServiceForMovie…) = SUBSUME

*Assumption: PLUGIN is better than SUBSUME


Approach IV – Similarity Measures and Information Retrieval Techniques

Pure Logic-based matching may have counterintuitive results. Example: R input: InterestProfile ⊓ hasInterest.SciFiMovies R output: ContactProfile A input: InterestProfile A output: ChatID

DoM(R,A) = FAIL

Reason: output of R is disjoint with output of Aalthough their inputs are “logically relevant”

PersonalProfilePersonalProfile

InterestProfileInterestProfileChatIDChatIDContactProfileContactProfile

is-a

disjoint-with


Approach IV – Similarity Measures and Information Retrieval Techniques

Solution – Main idea Allow for more “flexible” methods of assessing

service similarity IR and similarity-based methods are perfect

candidates E.g., linguistic semantics (WordNet similarity),

TF-IDF Logic is just one component of “relevance” Such methods capture some other components

A problem remains How much should each method contribute to the

DoM calculation An optimization problem


Approach V – A Graph-based Approach A service is represented as a DAG

Nodes ~ individuals of concepts Arcs ~ roles between individuals

Main idea Structural match: Two service descriptions match if they have the

same structure and the corresponding nodes match Existing graph matching algorithms apply No (obvious) support for DoM


Approach VI – Indirect Graph-based Matching

Indirect matching Complex workflow compositions “Service chains” in the simplest case Service chain creation rules

1) The inputs of each involved service match either the request inputs or the outputs of the previous service in the chain.

2) Each output of the request is matched against an output of the last service in the chain.


Approach VI - ExampleService Inputs Outputs

S1 A, B E

S2 A, B, C F, N

S3 E, C F

S4 F K, M

S5 K, D Z, Y

S6 K D, Z

S7 D Y

Discovered Service Chains

S1, S3, S4, S6, S7S1, S3, S4, S5S2, S4, S6, S7

S2, S4, S5

Request inputs:{A,B,C,D}Request outputs:{Z,Y}

3:

1: Service specifications

2: Servicegraph

Policy-based service chain selection can be applied

(e.g., the shortest)

S1S1

S2S2

S3S3

S4S4

S5S5

S6S6 S7S7


Approach VII – Indirect Backward Chaining Matching A similar approach for discovery of complex

service workflows… but implemented through logic resolution

Main idea: backward-chaining goal-driven reasoning procedure starting from services that match the request

outputs (but not its inputs), we recursively try to link them with other services until we find a service with all its inputs matched to the inputs given by the request

Inherent support by logic programming tools (Prolog)


Synopsis of ApproachesCharacteristics

Approach Matching elements Support for DoM Indirect matching Algorithm

I IO Yes No Logic

IIIO, service category,custom parameters

Yes No Logic

III Service profile Yes No Logic

IVTextual descriptions,

IOPEYes No

Logic+ Similarity

V Service profile No NoLogic+ graphs

VI IO No YesHybrid+ graphs

VII IO No Yes Logic


OWL-S/UDDI Matchmaker (OWL-S/UDDIM) OWL-S services OWL domain ontologies DL subsumption-based matchmaking Standalone and Web-based versions Standalone version has a client API Open source (Java) Intelligent Software Agents Group, Carnegie

Mellon University http://projects.semwebcentral.org/projects/

owl-s-uddi-mm/


IBM Semantic Tools for Web Services (STWS)

WSDL-S services OWL domain ontologies Applies AI planning techniques to find

composite services that match the request

Eclipse plug-in Exploits the WordNet lexicon http://

www.alphaworks.ibm.com/tech/wssem


Hybrid OWL-S Web Service Matchmaker (OWLS-MX)

OWL-S services OWL domain ontologies Logic-based matching + syntactic token-

based similarity metrics A service test collection is also available Open source (Java) German Research Center for Artificial

Intelligence, DFKI Saarbruecken http://www.dfki.de/~klusch/owls-mx/


METEOR-S Web Service Discovery Infrastructure (MWSDI) - Lumina WSDL-S services OWL domain ontologies Adds semantic to the whole service lifecycle METEOR-S discovery API used by the

graphical tool Lumina (Eclipse plug-in) Open source (Java) Large Scale Distributed Information Systems

(LSDIS) Lab, University of Georgia http://lsdis.cs.uga.edu/projects/meteor-s/illu

mina/


TUB OWL-S Matcher (OWLSM) OWL-S services OWL domain ontologies DL subsumption-based weighted matching

over many service parameters Open source (Java) Technical University of Berlin http://kbs.cs.tu-berlin.de/ivs/Projekte/owlsm

atcher/index.html


WSMX Discovery Component

WSMO services WSML domain ontologies Part of the WSMO reference

implementation Open source (Java) WSMX working group, European

Semantic Systems cluster initiative http://www.wsmx.org/


Evaluation of Discovery Evaluation of efficiency (e.g., scalability,

service retrieval times) is not enough Retrieval effectiveness must be assessed Several obstacles exist

Lack of SWS test sets and evaluation testbeds OWL-S Test Collection (TC) is a good start

[Klusch, 2005]

Lack of appropriate evaluation metrics Standard IR metrics (precision, recall) may not

apply as-is


Semantic Interoperability/Mediation

In practice, service requestors and service providers will use different SAO and/or domain ontologies

A mediation layer will be necessary Provision of ontology matching and alignment Translation from natural language requests to

formal ontology-based WSMO discovery heavily relies on

mediators [Roman, 2005]


Maturity of Discovery Tools/Engines

Tools are not limited to discovery frameworks, but also include: Registries Annotation tools Service editors

No stable, fully-documented tools currently exist

Interoperability between research efforts is a major issue


Fuzziness in Discovery Soft Computing concepts may give added

value to SWS discovery through approximate matching

Human information needs may not be completely represented by ontologies which are rather crisp KR tools

Even reasoning over concrete domains may be insufficient in practice

Researchers are already pursue fuzzification of ontologies and matchmaking


Conclusion SWS provide new opportunities for

effective service discovery Most existing solutions exploit DL

reasoning services IR and knowledge discovery techniques

seem to be applicable There are interesting tools but only at a

research-level However, many open issues still exist


Conclusion

See Appendix I for a mini-tutorial on a SWS discovery tool

See Appendix II for a DL primer p-comp web site

http://p-comp.di.uoa.gr

cardoso j. "semantic web: theory, tools and applications" semantic web service discovery:...

Documents

semantic web services

sws web services

semantic web sw antoniou

service publicationsearching

service operations

service parameters

service advertisement

tools chapter