OKBC (Open Knowledge Base Connectivity) An API For Knowledge Servers Prof. Richard Fikes CS222 Fall 1998 Computer Science Department Stanford University 10/26/98

An Interoperability Problem Knowledge representation systems provide – Knowledge representation language Knowledge base storage Deductive retrieval Knowledge base construction and analysis tools Problem: KR systems do not interoperate Differing representation formalisms and idioms Differing reasoning capabilities Differing implementation languages Tools are rebuilt for each KR system

Distributed Servers and Clients Knowledge servers Knowledge base storage Deductive retrieval Query answering with selectable level of inference Reformulation Accessed via a knowledge level network API Analogous to data base servers Knowledge clients Operate with any server that supports the API Tools for developing and using knowledge bases Construction, analysis, merging, reformulation, viewing, … Applications that access multi-use knowledge bases

Enablers for Knowledge Sharing Declarative interlingua for expressing knowledge KR system translates KBs into and out of interlingua ...

Interlingua for Multi-Use Knowledge Language 1 Language 2 Language n K I F KB Library . . . Knowledge Interchange Format (KIF) First order predicate logic with set theory Logically comprehensive Model-theoretic semantics

Enablers for Knowledge Sharing Declarative interlingua for expressing knowledge E.g., KIF and Ontolingua KR system translates KBs into and out of interlingua API for accessing and manipulating knowledge Provide operations for: Assertion Deductive retrieval KB creation and manipulation Assumes knowledge is expressed in an interlingua

OKBC: Open Knowledge Base Connectivity An API for knowledge servers Provides knowledge level interoperability Operations for: Assertion and retrieval KB creation and manipulation Client/server network communication Object-oriented view of knowledge source Class-subclass taxonomies, attributes, type constraints, ... Server-side execution of client-specified procedures Enables multiple operations with one network transmission Standard API for DARPA’s HPKB program

OKBC Runtime Architecture Application (client) front end OKBC OKBC Server En(de)code, Dispatch OKBC Wrapper KR System Application (client) front end OKBC KB

OKBC Knowledge Model Implicit interlingua for communicated knowledge Formal object-oriented representation paradigm A simple frame language Class-subclass taxonomies Monotonic inheritance Type and cardinality constraints on attribute values Explicit manipulation of “Frames” Objects representing individuals, classes, and relations KIF sentences Asserted and retrieved via Tell and Ask operations

Dealing with Variation - Names KR systems use different names for common terms E.g., The most general class: Thing, Object, All, Any, … Value restriction: Value-Type, Value-Class, Type, … Applications must portably refer to these common terms OKBC defines standard names :THING, :VALUE-TYPE, :INVERSE, :CARDINALITY, … If (coerce-to-frame :THING) returns a frame, then it must have the standard meaning A KR system need not provide any standard names

Standard Names Class names Slot names Facet names :CLASS :INDIVIDUAL :THING :CLASS :INDIVIDUAL :NUMBER :INTEGER :STRING :SYMBOL :LIST Slot names :DOCUMENTATION Facet names :VALUE-TYPE :MINIMUM-CARDINALITY :NUMERIC-MINIMUM :INVERSE :SAME-VALUES :NUMERIC-MAXIMUM :CARDINALITY :NOT-SAME-VALUES :SOME-VALUES :MAXIMUM-CARDINALITY :SUBSET-OF-VALUES

Ops on KBs, Frames, Classes, Instances Operations on knowledge bases create-kb, open-kb, close-kb, copy-kb, save-kb, find-kb, … Operations on frames create-frame, delete-frame, copy-frame, get-frame-name, get-kb-frames, … Operations on classes create-class, add-class-superclass, remove-class-superclass, class-p, get-class-instances, get-class-subclasses, instance-of-p, subclass-of-p, … Operations on instances add-instance-type, get-instance-types, remove-instance-type, type-of-p, …

Ops on Individuals, Slots, Facets Operations on individuals create-individual, get-kb-individuals, individual-p, … Operations on slots create-slot, delete-slot, add-slot-value, get-slot-values, attach-slot, detach-slot, follow-slot-chain, frame-has-slot-p, get-frame-slots, … Operations on facets create-facet, delete-facet, add-facet-value, get-facet-values, attach-facet, detach-facet, slot-has-facet-p, get-slot-facets, …

Tell and Ask Uses KIF as the “content” language Operations: Tell, Ask, Untell, Tellable, Askable Semantics defined for a set of simple relational sentences Tell Effect (S F V) (add-slot-value F S V :slot-type :own) (instance-of F C) (add-instance-type F C) (class C) (create-class C) (slot-of S F) (attach-slot F S :slot-type :own) (subclass-of C Super) (add-class-superclass C Super) … Ask Effect (C ?x) (get-class-instances C) (S F ?x) (get-slot-values F S) (S ?x V) (get-frames-with-slot-value S V) (class ?x) (get-kb-classes) (subclass-of ?x S) (get-class-subclasses S)

Retrieval Using OKBC KR systems vary widely in their inference ability Simple lookup Taxonomic reasoning Full first order logic theorem proving Forward chaining Inference levels in OKBC Direct – Directly asserted values Taxonomic – Directly asserted plus inherited values All-Inferable – Values inferable by any means Must return at least the values specified

Understanding Results Ops return additional information with values Whether the answer is complete All Universities All Universities I had time to find All Universities I can find If exactly the requested inferences were performed

Enumerators Each “get” op has a corresponding “enumerate” op Enumerates multiple values One at a time In batches Operations on enumerators Next – Get the next value from an enumerator Has-More – Test whether enumerator has more values Fetch – Get a given number of values Prefetch – Caches a given number of values Free – Indicate an enumerator will no longer be used

Dealing With Variation - Behaviors Servers indicate the behaviors they support Value constraint checking Frame representation of entities Defaults Class slot types Collection types Frame names Compliance Facets supported User defined facets Read only Monotonic

OKBC Implementation Architecture Front end (client) The 185 OKBC operations for use by client application Issues calls to a middle end (possibly across network) Middle end Default implementation of OKBC operations In terms of a core set of OKBC operations Object-oriented: 134 ops => 51 ops Sentential: 161 ops => 24 ops For use by front end Issues calls to a back end (possibly across network) Back end (server) Implementation of OKBC operations in a KR system

Example Knowledge Sources Unix file system (a less expressive KR system) Directories => classes Subdirectory relationships => subclass relationships Files => individuals Does not comply with :user-defined-facets May comply with :read-only ATP theorem prover (a more expressive KR system) What’s a frame? All constants considered to be frames Uses the sentential middle end Implementing the inference levels Direct – Only ground facts Taxonomic – Ground facts and taxonomic axioms All-Inferable – Ground facts and all axioms

Implementations Server and client reference implementations Front ends and middle ends in Java, Lisp, & C Example OKBC servers Ontolingua (Stanford KSL) Ocelot (SRI AIC) LOOM (ISI) Cyc (Cycorp) ATP theorem prover (Stanford KSL) Tuple KB (Stanford KSL) Example OKBC clients Generic Knowledge Base Editor (SRI AIC) Java Ontology Tool (JOT)

OKBC Working Group Working group consists of representatives from: Stanford KSL (chair) Cycorp SAIC SRI Teknowledge USC/ISI Responsible for spec and reference implementations Maintains distribution list and Web site Web site: http://www-ksl-svc.stanford.edu/okbc/ To join distribution list: Send a message to majordomo@smi.stanford.edu with the following one line body: subscribe OKBC [your email address]

Next Steps? Extend ASK to return a proof tree for explanations Inference level for full frame system reasoning Include constraint checking from standard facets Standard facets for Bayesian probabilities Using Daphne Koller’s formalism Support n-ary relations Relational data base rather than frames? Provide a semantics for defaults Incorporate standard upper level ontology Add commands for collaborating agents E.g, like KQML’s advertise, broker, forward, monitor, broadcast, ...