A Query-based System for Automatic Invocation of Web Services

1. A Query-based System for Automatic Invocation of Web Services Chaitali Gupta, RajdeepBhowmik, Michael R. Head, MadhusudhanGovindaraju, WeiyiMeng Presented By: SiddharthPalaniswami

2. Introduction • Web Services – a software system designed to support interoperable machine-to-machine interaction over a network. • Google Maps API, eBay API • WSDL – Traditional web services use the Web Services Description Language to describe the operations it provides in a machine readable format • XML based. • Defines what are the operations, names, endpoints, input and out parameters.

3. Introduction • Semantic Web – semantics(meaning) of the information and services on the web are defined. • Aids in understanding user/machine requests to use the web content • Ontology – representation of a set of concepts in a domain and relationships between the concepts. • Used to define a domain. • OWL – a language standard for representing ontologies.

4. What is Automatic Invocation • Process user’s query and automatically determine which web services is to be used and which operation is to be performed. • What is the temperature in Charlotte? = getCurrentWeather(28200) • Invoke the chosen operation by passing the input parameters and display the results

5. Why Automatic Invocation • Abstract the complexities of XML based web services from end users • Provide a easy and simple UI • Developers need to understand the operations provided by a web service, parameters, ports ,etc. • WSDL files specify syntax only and not semantics • End users need to fill out complex forms in order to query against web services

6. Problem Definition • Address the problem of users and developers having to understand the operations in web services. • Reduce user interaction with web services • Map user queries to relevant operations in a domain specific web service • Provide simple UI • Hide details of web service specification and implementation from users.

7. Overview • Accepts user query in a free from text box. • Matches user’s query with web service descriptions. • Invokes the relevant web service • Displays results

8. Design and Implementation

9. Components • WSDL Processor • User Query Interface • Query Processor • Lexicon • Spell Checker • Match Processor • Relevance Checker • WS Invocation Preprocessor • WS Invoker • Fallback Invocation Behavior

10. WSDL Processor • WSDL Repository contains WSDL files of web services that the system will use. • The processor will parse these WSDL files and populate the WSDL data structures to store operation names, parameters, endpoints, port types for each file. • Invoked only once, results cached for faster performance.

11. User Query Interface • Simple Interface • No use of domain specific forms • User submits query like submitting queries to popular search engines • Query in the form of English natural language sentences or questions • How to get to New York from Boston?

12. Query Processor • Normalize the user query – • Stop words removal • Common, ‘meaningless’ words like ‘the’, ‘what’ are removed. Saves processing time. • What is the current time (local time) @ NYC? = current time (local time) @ NYC • Replace non-alphanumeric characters • Non-alphanumeric character which have meanings are replaced with corresponding alphanumeric words. • Mapping of such characters are stored. Replaced with space if no match is found. • Example @ is replaced with ‘at’ – current time (local time) at NYC • Words in parenthesis are not removed as they can add context information • Abbreviations are extended - current time (local time) at New York City • Prepositions are not removed(generally considered stopwords) • ‘at’, ‘to’, ‘from’ are retained to help determine the context • Query words stored in Query Words Repository

13. Lexicon • Uses WordNet and JWNL to access WordNet • WordNet is a semantic lexicon for the English language. It groups English words into sets of synonyms called synsets, provides short, general definitions, and records the various semantic relations between these synonym sets. • Used as a dictionary look up as well as a glossary and thesaurus • Used by the Match Processor, Relevance Checker.

14. Spell Checker • Used by Match Processor and Relevance checker to determine the correctness of query words • Used when no match for a query word is found • Accomplished by implementing Soundex and Metaphone algorithms.

15. Match Processor • Tries to match query with web services • Uses the words in the Query Words Repository • Consists of two components • Ontology Matcher • Dictionary Matcher

16. Match Processor – Ontology Matcher • Ontologies for several popular domains defined using OWL Lite and stored in Ontology Repository. • Ontology modeled using Jena framework • Models are statements made of Subject, Predicate, Object

17. Match Processor – Ontology Matcher

18. Match Processor – Ontology Matcher • Query words are searched for in the models • Best price for flight from Los Angeles to San Francisco on Sunday – matches Flight Domain • Matching ontology sentence is stored • Prepositions like ‘at’, ‘from’ are used to identify contexts. • From – identifies Los Angeles as origin, to – identifies destination • Ontology matcher uses Lexicon to help in matching • Direct matching • Synonym, hyponym, hypernym matching • How hot is it right now in Charlotte? – hot is not found in model but related word temperature can be found • Root words are used

19. Match Processor – Ontology Matcher • Matching results are also used for extending ontology models Hot is added to the model

20. Match Processor – Ontology Matcher • If no match is found: • Match against a list of locations • Charlotte is matched with locations • Use web service to check if location • Check if noun by looking for capitalized first letter • Use Spell Checker to check if the word is spelt correctly

21. Match Processor – Dictionary Matcher • Used when ontology matcher does not yield matches • Stop words are removed from operation names in web services – getWeather () – Weather • Query words matched with operation names • Direct Matching • Query word matched directly with operation/stripped operation names • Stripped Matching • Stripped query words are matched with operation/stripped operation names • Dictionary Level Matching • Synonyms, hypernyms and hyponyms of query words matched with operation/stripped operation names.

22. Relevance Checker • Used when Match Processor yields no results • Uses glossary(definitions/meanings) of query words provided by Lexicon. • hot - having a high or higher than desirable temperature or giving off heat or feeling or causing a sensation of heat or burning • Uses input and output parameter of methods. • Uses comments and annotations in WSDL files.

23. WS Invocation Preprocessor • Checks selected WSDL files to determine whether user’s query has sufficient input parameters • The Ontology Matcher helps identify the domain of the query. • The semantics in the WSDL files are matched with the context identified to determine the operation and other parameters • Weather at Detroit – domain weather, input parameter location – matches – getWeather(location) operation • Text matchers are used incase of failure

24. WS Invoker • The selected operation and web service is invoked and the corresponding input parameters are provided. • The results are parsed and displayed to the user.

25. Fallback Invocation Behavior • If no operation can be identified after matching query with WSDL files • User is presented with a form with links to various operations. • User can select the desired operation • Information pre-filled in the form based on user query • If nothing works user asked to refine query.

26. Experimental Results • Set up : 10 varying length queries were submitted as input • Results: Queries that need both Ontology and Dictionary matcher takes longer

27. Experimental Results Longer query strings take longer time due to the Lexicon Block

28. Experimental Results Extending ontologies make subsequent queries faster

29. Related Work • Extends work by Syeda-Mahmood et al. • Adds dynamic learning from previous matches • Add extending ontology vocabulary • Applying knowledge to subsequent queries

30. Conclusions and Future Work • User queries are matched with web services • Self learning to improve efficiency by learning from previous queries • Future Work - • Extend the domains • Extend the ontology models • Try using Metanym Matching • Compare other OWL types

31. Questions for Discussion • What about support for web services without WSDL? • What about queries over multiple domains? • How are the matches ranked? • How are the results displayed to the user? • What if more than one operation satisfy a user’s query?

32. Thank You