Panel on Knowledge Repositories Organizer: Chitta Baral Panel members: Michael Gelfond Vladimir Lifschitz

What do I mean by a knowledge repository? A collection of knowledge modules. –That can be used by knowledge base developers. Similar to Java or C++ libraries. But building a knowledge repository –poses a lot more challenges; to be discussed in later slides. –and will be much larger in size.

Why do we need knowledge repositories? Reasoning with Knowledge and learning knowledge is the essence of AI. –Evident from the meaning of “intelligence” in a dictionary Lot of progress in Knowledge Representation. Especially with respect to AnsProlog (logic programming with answer set semantics) –A core language with many suggested extensions –A large body of theoretical results –Many implementations –Many applications

But we need to … Go beyond –Writing knowledge axioms from scratch –Small knowledge bases Be able to build large knowledge bases without starting from scratch. Make it easier to build knowledge bases. Reuse knowledge modules developed by others. Make knowledge bases part of most AI systems.

Applications and Impacts of Knowledge Repositories Question answering systems –Text: John took a flight from Rome to Paris 6 hours ago? –Question: Where is John now? Where is his wife who saw him off at the airport? Any system that needs to use common-sense reasoning. Any system that needs to reason with knowledge in one or many domains.

Is this a blue sky dream? Not really? Wordnet ( –An electronic repository of words and their meanings has been very useful. It took a lot of work to get built. A knowledge repository will need a lot more work.

What does building a Knowledge Repository involve? A large body of Knowledge modules possibly grouped in packages –Common sense modules –Domain specific modules –High level modules: actions, time, space, etc. Methodology to facilitate building modules –Inheritance, encapsulation, modeling languages, etc. Interface mechanisms similar (in functionality) to interface mechanisms in Java, C++ etc.

Existing efforts: CYC CYC: a pioneer Possible IP and legal issues. – subsets (ResearchCYC) need signing of a lot of legal documents. CYC’ s language is proprietary and untested outside of CYC. (mostly unpublished outside). But if this can be overcome, then it could be a good starting or reference point.

Existing efforts: CYC CYC : our effort :: Celera effort : Open Genomics effort We would like the whole community to be involved in building. Openmind: collects NL knowledge over the web.

Existing effort: SUMO and MILO SUMO and MILO are freely available SUMO – akee/KBs/Merge.kif?rev=1.3http://cvs.sourceforge.net/viewcvs.py/*checkout*/sigm akee/KBs/Merge.kif?rev=1.3 MILO – akee/KBs/Mid-level-ontology.kif?rev=1.2http://cvs.sourceforge.net/viewcvs.py/*checkout*/sigm akee/KBs/Mid-level-ontology.kif?rev=1.2

SUMO SUMO (Suggested Upper Merged Ontology) Based on first-order logic. It incorporates –elements of John Sowa's upper ontology –Russell and Norvig's ontology –PSL (Process Specification Language), –Casati and Varzi's theory of holes, –Allen's temporal axioms, etc. It has a nice browsing and editing tools, and Inference and Ontology management system –

MILO (MId-Level Ontology) Aim is to be a bridge between the abstract content of the SUMO and the rich detail of the various domain ontologies. In progress, incomplete. Contains a Description Logic Knowledge base –Class-subclass –Class-instances –Relations

Going beyond SUMO and MILO? Why? –Both SUMO and MILO are based on first- order logic. –Need ways to express defaults and exceptions, –need ways to express problem solving queries, such as planning, diagnosis, etc. –…

Recall: What do we need? A large body of Knowledge modules possibly grouped in packages –Common sense modules –Domain specific modules –High level modules: actions, time, space, etc. Methodology to facilitate building modules –Inheritance, encapsulation, modeling languages, etc. Interface mechanisms similar (in functionality) to interface mechanisms in Java, C++ etc.

Coupling modules and inference mechanism AnsProlog versus ASP –AnsProlog -- Programming in logic with answer sets –ASP – seems to be focused on the generate and test problem solving Need modules of various kinds –Is ancestor(john,mary)? (Prolog style) –Find a plan (ASP style) –Find a schedule (CLP) Different kinds of modules may need different inference mechanisms

Next Steps, challenges Lets look at the AAAI’06 Spring Symposium CFP.

AAAI’06 Spring symposium Title: Formalizing and Compiling Background Knowledge and its applications to Knowledge Representation and Question Answering. Organizing Committee: –Chitta Baral –Alfredo Gabaldon –Michael Gelfond –Joohyung Lee –Vladimir Lifschitz –Steve Maiorano –Sheila McIlraith –Leora Morgenstern

CFP: Requests contributions that are A: formalizations (knowledge modules) of background knowledge in specific domains as well as, B: papers addressing general challenges such as formalizing background knowledge for use by multiple users on multiple reasoning tasks. –Interface issues, reuse, etc.

A: Knowledge module papers No restriction on the domain to be formalized or on the level of specificity Suggested common format –A knowledge base (KB) written in English. – Examples of informal consequences of KB, preferably accompanied by some explanations, including defaults and other commonsense knowledge not directly mentioned in KB but needed to produce the desired consequence.

A: Knowledge module papers (cont.) –Information about which logic/language is used in formalizing it. (Syntax, semantics, and where the reasoning system is available.) –The formalization –Short description on how the formalization can be tested using the reasoning system.

Existing knowledge encoded in AnsProlog Small AnsProlog programs (not quite modules – don’t have modular interface) –Knowledge Representation, Reasoning and Declarative Problem Solving. Baral –Various surveys: Niemela et al.; Gelfond and Leone. Etc. Larger programs –RCS-USA Advisor ( – –Vladimir is collecting a list of ASP applications.

Further ideas for submissions of type A. At various abstractions –Actions, time, space, etc. Various domains –Travel, terrorism, etc. Further collections and catalogues of existing encoded knowledge.

B: Interface and Engineering issues How to call a module from another module: interface syntax and semantics Object oriented issues –Encapsulation –Classes, sub-classes, Inheritance –Polymorphism Modeling language

Some initial steps on Interface issues –Towards an Integration of Answer Set and Constraint Solving. Baselice, Bonatti and Gelfond. ICLP’05 –A language for modular ASP. Tari, Baral, & Anwar. ASP’05. –Enhancing ASP with templates. Ianni et al. NMR’2004. –Personal communication. Lifschitz. –F-logic papers. Kifer et al.

Challenges vis-à-vis C++ and Java libraries Number of modules could be much larger and much varied than classes and methods in Java libraries Multiple AnsProlog sub-languages, each with a different reasoning mechanism Various sources of knowledge – some would be learned Initially a smaller number of developers Language is still evolving (core is there)

More info on the symposium Symposium Dates: –March AAAI site: – 06.pdf Symposium cite – Deadlines: –Submission: October 7, 2005 (extended to October 21st) –Response: November 4, 2005 –Camera ready due at AAAI: January 27, 2006 –Symposium date: March

Thank You