Ontology-enhanced retrieval (and Ontology-enhanced applications)

1. Ontology-enhanced retrieval (and Ontology-enhanced applications) Deborah L. McGuinness Associate Director and Senior Research Scientist Knowledge Systems Laboratory Stanford University Stanford, CA 94305 650-723-9770 dlm@ksl.stanford.edu (FindUR,CLASSIC,PROSE work supported by AT&T Labs Research, Florham Park, NJ, OntoBuilder work supported by VerticalNet, Chimaera, Ontolingua, JTP supported by DARPA)

2. One Conceptual Search • Input is in a natural query language (forms, English, ER diagram …) • Query may be transformed (behind the scenes) into a precise query language with defined semantics • Information is at least semi-structured with DL-like markup and also “exists” in more naturalformats and is interoperable • Answers returned that are not just the explicit answer to question (but also the implicit answer to question) • Answers return the portion of the content that is of use (not an entire page of content) • Answers may be summarized, abstracted, pruned • “Answers” may be services that can take action • Interface is interactive and helps users reformulate “unsuccessful” queries • Customizable, extensible, …

3. Human Human Today: Rich Information Source for Human Manipulation/Interpretation

4. “I know what was input” • Global documents and terms indexed and available for search • Search engine interfaces • Entire documents retrieved according to relevance (instead of answers) • Human input, review, assimilation, integration, action, etc. • Special purpose interfaces required for user friendly applications The web knows what was input but does little interpretation, manipulation, integration, and action

5. Information Discovery… but not much more • Human intensive (requiring input reformulation and interpretation) • Display intensive (requiring filtering) • Not interoperable • Not agent-operational • Not adaptive • Limited context • Limited service Analogous to a new assistant who is thorough yet lacks common sense, context, and adaptability

6. Human Agent Agent Future: Rich Information Source for Agent Manipulation/Interpretation

7. “I know what was meant” • Understand term meaning and user background • Interoperable (can translate between applications) • Programmable (thus agent operational) • Explainable (thus maintains context and can adapt) • Capable of filtering (thus limiting display and human intervention requirements) • Capable of executing services

8. One Approach… start simple from embedded bases • Recognize the vast amount of information in textual forms… • Enhance “standard” information retrieval by adding some semantics • Use background ontology to do query expansion • Exploit ontology to add some structure to IR search • Move to parametric search • Move to include inference (in e-commerce setting moving towards interoperable solutions and configuration

9. FindUR Challenges/Benefits • Retrieve documents otherwise missed - Recall • More appropriately organize documents according to relevance (useful for large number of retrievals) • Browsing support (navigation, highlighting) • Simple User Query building and refinement • Full Query Logging and Trace • Facilitate use of advanced search functions without requiring knowledge of a search language • Automatically search the right knowledgesources according to information about the context of the query

10. FindUR Architecture P-CHIP Research Site Technical Memorandum Calendars (Summit 2005, Research) Yellow Pages (Directory Westfield) Newspapers (Leader) AT&T Solutions Worldnet Customer Care ( Content (Web Pages, Documents, Databases) Content to Search: Content Classification Search and Representation Technology: Search Engine Classic Collaborative Topic Building Tool Domain Knowledge User Interface: Search Parameters Query Input Verity Topic Sets Verity SearchScript, Javascript, HTML, CGI Results (std. format) Results (domain spec.)

15. OntologyBuilder

16. Configuration http://www.research.att.com/sw/tools/classic/tm/ijcai-95-with-scenario.html

17. Ontology Creation and Maintenance Environment Needs • Semi-automatic generation input • Diagnostics/Explanation (Chimaera, CLASSIC,…) • Merging and Difference (Chimaera, Prompt, Ontolingua, …) • Translators/Dumping (Ontolingua, …) • Distributed Multi-User Collaboration (OntologyBuilder,…) • Versioning (OntologyBuilder,…) • Scalability. Reliability, Performance, Availability (Shoe,OntologyBuilder,…) • Security (viewing, updates, abstraction, authoritative sources…) • Ontology Library systems (Ontolingua,…) • Business needs – internationalization, compatibility with standards (XML,…)

18. Conclusion With background ontologies and the appropriate environments, we can move from simple ontology-enhanced applications to the next generation web

19. Pointers • FindUR: www.research.att.com/~dlm/findur • OntoBuilder/OntoServer: http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html • Deborah McGuinness: www.ksl.stanford.edu/people/dlm • CLASSIC: www.research.att.com/sw/tools/classic • Chimaera: www.ksl.stanford.edu/software/chimaera/