The Knowledge Model of Protégé-2000: Combining Interoperability and Flexibility (original) (raw)
Related papers
The Knowledge Model of Prot�g�-2000: Combining Interoperability and Flexibility
Ekaw, 2000
Knowledge-based systems have become ubiquitous in recent years. The World-Wide Web consortium is developing the Resource Description Framework (RDF)-a system for annotating even Web pages with knowledge elements. Knowledge-base developers need to be able to share and reuse knowledge bases that they build. Therefore, interoperability among different knowledge-representation systems is essential. The Open Knowledge-Base Connectivity protocol (OKBC) is a common query and construction interface for frame-based systems that facilitates this interoperability. Protégé-2000 is an OKBC-compatible knowledge-base-editing environment developed in our laboratory. Protégé-2000 has an easy-to-use and configurable interface. We describe its OKBCcompatible knowledge model that makes the import and export of knowledge bases from and to other knowledge-base servers easy. We discuss how the requirements of being usable and configurable knowledge-acquisition tool affected our decisions in the knowledge-model design. Protégé-2000 also has a flexible metaclass architecture which provides configurable templates for new classes in the knowledge base. The use of metaclasses makes Protégé-2000 easily extensible and enables its use with other knowledge models. For example, we demonstrate that we can resolve many of the differences between the knowledge models of Protégé-2000 and RDF by defining a new metaclass set. Resolving the differences between the knowledge models in declarative way enables easy adaptation of Protégé-2000 as an editor for other knowledgerepresentation systems.
OKBC: A Programmatic Foundation for Knowledge Base Interoperability
1998
The technology for building large knowledge bases (KBs) is yet to witness a breakthrough so that a KB can be constructed by the assembly of prefabricated knowledge components. Knowledge components include both pieces of domain knowledge (for example, theories of economics or fault diagnosis) and KB tools (for example, editors and theorem provers). Most of the current KB development tools can only manipulate knowledge residing in the knowledge representation system (KRS) for which the tools were originally developed. Open Knowledge Base Connectivity (OKBC) is an application programming interface for accessing KRSs, and was developed to enable the construction of reusable KB tools. OKBC improves upon its predecessor, the Generic Frame Protocol (GFP), in several significant ways. OKBC can be used with a much larger range of systems because its knowledge model supports an assertional view of a KRS. OKBC provides an explicit treatment of entities that are not frames, and it has a much better way of controlling inference and specifying default values. OKBC can be used on practically any platform because it supports network transparency and has implementations for multiple programming languages. In this paper, we discuss technical design issues faced in the development of OKBC, highlight how OKBC improves upon GFP, and report on practical experiences in using it.
The evolution of Protégé: an environment for knowledge-based systems development
International Journal of Human-Computer Studies, 2003
The Protégé project has come a long way since Mark Musen first built the Protégé metatool for knowledge-based systems in 1987. The original tool was a small application, aimed at building knowledge-acquisition tools for a few specialized programs in medical planning. From this initial tool, the Protégé system has evolved into a durable, extensible platform for knowledge-based systems development and research. The current version, Protégé-2000, can be run on a variety of platforms, supports customized user-interface extensions, incorporates the Open Knowledge Base Connectivity (OKBC) knowledge model, interacts with standard storage formats such as relational databases, XML, and RDF, and has been used by hundreds of individuals and research groups. In this paper, we follow the evolution of the Protégé project through 3 distinct re-implementations. We describe our overall methodology, our design decisions, and the lessons we have learned over the duration of the project.. We believe that our success is one of infrastructure: Protégé is a flexible, well-supported, and robust development environment. Using Protégé, developers and domain experts can easily build effective knowledge-based systems, and researchers can explore ideas in a variety of knowledge-based domains.
Open Knowledge Base Connectivity 2.0.31 — Proposed
Brokers (Contract Number N66001-96-C-8622-P00004) and Large-Scale Repositories of Highly Expressive Reusable Knowledge (Contract Number N66001-97-C-8554). At SRI International, it was supported by a Rome Laboratory contract titled Reusable Tools for Knowledge Base and Ontology Development (Contract Number F30602-96-C-0332), a DARPA contract entitled Ontology Construction Toolkit, and NIH Grant R29-LM-05413-01A1. 2 CHAPTER 1. INTRODUCTION put−slot−values put−slot−values put−slot−values put−slot−values put−slot−values method dispatch Generic function Back−end method Ontolingua Ocelot Classic Loom Figure 1.1: The architecture of the Common Lisp implementation of OKBC. 1.2 Overview of the Protocol OKBC specifies a knowledge model of KRSs (with KBs, classes, individuals, slots, and facets). It also specifies a set of operations based on this model (e.g., find a frame matching a name, enumerate the slots of a frame, delete a frame). An application uses these operations to access and modify knowledge stored in a OKBC-compliant KRS. The current implementations of OKBC is object-oriented: methods in the appropriate object-oriented programming language for an application are used to implement OKBC operations. We refer to the set of methods that implement the protocol for a particular KRS as a back end. Many OKBC operations have default implementations written in terms of other OKBC operations; therefore, the programmer need define only a core subset of all OKBC operations in order to implement a compliant back end. These OKBC operations are called mandatory, and they comprise the OKBC kernel. The default implementations can be overridden within a given back end to improve efficiency. 1.3 Design Objectives The design objectives for OKBC are as follows. Simplicity: It is important to have a relatively simple specification that can be implemented quickly, even if that means sacrificing theoretical considerations or support for idiosyncrasies of a particular KRS. Generality: The protocol should apply to many KRSs, and support all the most common KRS features. For example, it should support all the knowledge access and modification functionality that will be required by a graphical KB editor. No legislation: The protocol should not require numerous changes to an KRS for which the protocol is implemented. That is, the protocol should not legislate the behavior of an underlying KRS, but should serve as an interface between an existing KRS and an application. Performance: Inserting the protocol between an application and a KRS should not introduce a significant performance cost. Consistency: The protocol should exhibit consistent behavior across different KRSs. That is, a given sequence of operations within the protocol should yield semantically equivalent results over a range of KRSs. 1.4. ON TERMINOLOGY 3 Precision: The specification of the protocol should be as precise and unambiguous as possible. Extensibility: The protocol must support the variability in capabilities of KRSs, and the need to add new KRS features over time without penalizing users of less powerful systems. Keywords All keywords that appear in the OKBC specification are defined as the values of global variables prefixed by 'key '. For example, the :all keyword is the value of key all. Because C does not allow for dynamically allocated structures to be included in compiled code or header files, the function okbc init must be called prior to referencing any keywords at runtime. Data Structures Every OKBC object is implemented as a Okbc Node struct. Return Values Each OKBC operation returns a struct okbc node * if it is single valued, a struct values * is returned if it is multi-valued, or void * if it returns no values. C does not support multiple return values from functions. Operations returning multiple values return a pointer to a values struct. Functions on values include nth value, first value, and length. Exceptions Every OKBC operation clears an error flag before executing, and sets it if an error occurs. It is the responsibility of the application to detect and handle errors. For the specific error flags, consult the header file for the C implementation. Language Specific Declarations and prototypes are defined in the file okbc.h. The function okbc init must be called prior to executing any OKBC operation or referencing any keyword at runtime. 3.6.3 Java Binding Naming Each OKBC operation that takes a KB argument is defined as a method of the class OkbcKb. Dashes are replaced by underscores, and the name is all in lower case. For example, get-slot-values would be called kb.get slot values(...), where kb is an instance of the class OkbcKb. Arguments Java allows for arguments to be defaulted from right to left. The Java binding provides default values for the rightmost arguments that have simple defaults. Check the method definitions in the OkbcKb class to verify argument defaulting. Data structures The Node class is the root class for all OKBC objects. Subclasses of Node include Symbol, Kb, etc. All methods implementing OKBC operations return either a Node or a Values object or are void methods. Return Values Each OKBC operation returns a Node object if it is single valued, a Values object if it is multi-valued, or void if it returns no values. Java does not support multiple return values from methods. Operations returning multiple values return a Values object, which supports the methods nthValue, firstValue, and length. Keywords All keywords that appear in the OKBC specification are defined as public static final members on the Node class. The name of each keyword is prefixed by 'key '. For example, the :all keyword is the value of Node.key all.
Formalizing Knowledge by Ontologies: OWL and KIF
During the last years, the activities of knowledge formalization and sharing useful to allow for semantically enabled management of information have been attracting growing attention, expecially in distributed environments like the Web. In this report, after a general introduction about the basis of knowledge abstraction and its formalization through ontologies, we briefly present a list of relevant formal languages used to represent knowledge: CycL, F-Logic, LOOM, KIF, Ontolingua, RDF(S) and OWL. Then we focus our attention on the Web Ontology Language (OWL) and the Knowledge Interchange Format (KIF). OWL is the main language used to describe and share ontologies over the Web: there are three OWL sublanguages with a growing degree of expressiveness. We describe its structure as well as the way it is used in order to reasons over asserted knowledge. Moreover we briefly present three relevant OWL ontology editors: Protégé, SWOOP and Ontotrack and two important OWL reasoners: Pellet and FACT++. KIF is mainly a standard to describe knowledge among different computer systems so as to facilitate its exchange. We describe the main elements of KIF syntax; we also consider Sigma, an environment for creating, testing, modifying, and performing inference with KIF ontologies. We comment some meaningful example of both OWL and KIF ontologies and, in conclusion, we compare their main expresive features.
Enabling knowledge representation on the Web by extending RDF Schema
Computer Networks, 2002
Recently, there has been a wide interest in using ontologies on the Web. As a basis for this, RDF Schema (RDFS) provides means to define vocabulary, structure and constraints for expressing metadata about Web resources. However, formal semantics are not provided, and the expressivity of it is not enough for full-fledged ontological modeling and reasoning. In this paper, we will show how RDFS can be extended in such a way that a full knowledge representation (KR) language can be expressed in it, thus enriching it with the required additional expressivity and the semantics of this language. We do this by describing the ontology language OIL as an extension of RDFS. An important advantage of our approach is a maximal backward compatability with RDFS: any meta-data in OIL format can still be partially interpreted by any RDFS-only-processor. The OIL extension of RDFS has been carefully engineered so that such a partial interpretation of OIL meta-data is still correct under the intended semantics of RDFS: simply ignoring the OIL specific portions of an OIL document yields a correct RDF(S) document whose intended RDFS semantics is precisely a subset of the semantics of the full OIL statements. In this way, our approach ensures maximal sharing of meta-data on the Web: even partial interpretation of meta-data by less semantically aware processors will yield a correct partial interpretation of the metadata. We conclude that our method of extending is equally applicable to other KR formalisms.
Lecture Notes in Computer Science, 2003
Recently, the development of knowledge bases is considered to be a process of extending an ontology with specific knowledge of a particular application. Reuse of pre-existing knowledge sources gives rise to knowledge bases endowed with a common and standard terminology. But, reuse often requires an enormous effort, so few knowledge-based applications have arisen following this approach. In this paper, we analyze some problems that make reuse difficult, as well as types of activities and current available resources that may contribute to improve this process.
Knowledge modeling at the millennium
1999
It has been 13 years since the first version of Protégé was run. The original tool was a small application, aimed mainly at building knowledge-acquisition tools for a few very specialized programs (it grew out of the ONCOCIN project and the subsequent attempts to build expert systems for protocol-based therapy planning). The most recent version, Protégé-2000, incorporates the Open Knowledge Base Connectivity (OKBC) knowledge model, is written to run across a wide variety of platforms, supports customized user-interface extensions, and has been used by over 300 individuals and research groups, most of whom are only peripherally interested in medical informatics. Researchers not directly involved in the project might well wonder how Protégé evolved, what are the reasons for the repeated reimplementations, and how to tell the various versions apart. In this paper, we give an overview of the evolution of Protégé, examining the methodological assumptions underlying the original Protégé system and discussing the ways in which the methodology has changed over time. We conclude with an overview of the latest version of Protégé, Protégé-2000.