Semantic Web Service Discovery: Methods, Algorithms and Tools

Semantic Web Service Discovery: Methods, Algorithms and Tools Do not put anything here. This area is reserved for the book cover. Chapter 11 Cardoso J. "Semantic Web: Theory, Tools and Applications"

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 I • Semantic 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 II • The 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 Architecture • P2P 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 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) = PLUGIN DoM(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 PersonalProfile DoM(R,A) =FAIL Reason: output of R is disjoint with output of A although their inputs are “logically relevant” is-a ChatID ContactProfile InterestProfile 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.

Request inputs:{A,B,C,D} Request outputs:{Z,Y} 3: Approach VI - Example 1: Service specifications Discovered Service Chains S1, S3, S4, S6, S7 S1, S3, S4, S5 S2, S4, S6, S7 S2, S4, S5 S1 S3 S5 2: Service graph S2 S4 S6 S7 Policy-based service chain selection can be applied (e.g., the shortest)

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 Approaches

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/illumina/

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/owlsmatcher/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

Semantic Web Service Discovery: Methods, Algorithms and Tools