In this section, we will discussion the design of an ontology tool for use with repositories on the Net. First, we will describe the scope of tool's application, Then, we will address the use of our tool. Consequently we will consider the ontology which will be necessary for the application. Following that, a knowledge representation language following our specification will be detailed.
The application is intended to maintain structure of Net repositories that cannot be attained easily otherwise. The repositories in questions are assumed to be representative of a specific domain. For instance, contemporary music, or chemistry. The most important type of conceptualization for this purpose is category and relations. Categories distinguish between kinds of data in the repository. With relations we can build category hierarchies which can be realized as navigation interfaces on the web. Each data object is taken to be an instance. A system may eventually support functions and axioms, however it seems that the first thing to support are category related.
There may be different kinds of indices. While an index may have an HTML page for each category, another may represent all categories (or a number of categories) in a single page. Yet an alternative backend tool may generate print manuals of the ontology from the same representation. The tools must have both CLI and GUI so that they may be automated or run interactively. A desirable extension would be a client/server implementation that works as a standalone CLI/GUI application on the client side.
A general purpose query system answers questions written in a variant of the ontology language; that is with free variables. A solver finds the results to the queries and states them in the ontology language. Multiple front ends may provide differing query interfaces such as a GUI based one or a web interface.
There is a good deal of software available for realizing ontologies, but I have found them inadequate because either
The SHOE is an extension to HTML that may be closest to what we would like, but still it is not a standalone language which would be more preferable because we would like the language to have good readability and writability. We follow SHOE in keeping the features to a minimum.
In the basic SHOE, we observe that the authors have maintained only the most fundamental components of ontology. The language has CATEGORY, RELATION and INSTANCE declarations. Among CATEGORY components, there is an ISA relation defined. Between categories and between entities binary relations can be stated. Entities may be declared to belong to a category .Ontologies can be reused by extending existing ongologies and renaming existing symbols.
SHOE in summary supports a category hierarchy, relations, and classification of instances together with modularity constructs. In our application classification is the most vital capability thus we will be employing categories, subcategories and instances in a similar manner; albeit more general. We will also be making another ontological commitment which is about mereology. In most web repositories, there are entities with physical or logical structure. In that respect a part-of relation is instrumental. For instance, in an ontology of musical works we would probably have Album and Song categories. In that ontology a Song is part-of an Album and an Album is part-of an Artist's Discography. A more typical example is that a wheel is part-of a Car. We will be avoiding most of the metaphysical problems associated with integrity and parts, however committing to part-whole relations as well as subclass relations seem to be essential.
A formal ontology language is, first of all, a logic language because logic is the best understood way to depict knowledge. It has constants and variables in the same sense, and a compositional semantics interpreted by means of a model which gives us a valuation function for sentences in the language. Nevertheless, a plain logic language has too little ontological commitment, in its interpretation only entities and predicates exist.
An ontology language on the other hand defines components of conceptualization which are not explicitly conveyed in predicate logic. Categories, relations, instances are first class constructs in an ontology language: ontology adds to a neutral logic means to denote conceptualization.
One way to think of an ontology language is comparing it to modal and temporal logic which add semantics to ordinary logic accounting for necesssity and time respectively. Indeed ontology languages are usually based on first-order logic. The syntax and semantics of languages like KIF and KM however are quite different from first order logic, they are frame-based languages introducing classes, relations, functions, slots and facets into a logical language. Roughly speaking, a frame issimilar in appearance to a class in programming languages, its task is to bundle together components and present a way to denote components through frame's name. Thus frames are not restricted to categories or classes, a relation or a function is also a frame. A metaclass is a frame, too. Slots are the properties of a frame, and template slots are properties of instances. Slots themselves can be frames. Frames are thus a general construct for abstraction in knowledge representation systems.
A language for ontology description then has to define which conceptual components it shall define and the semantics of those components. Typically, a frame based approach will be used, however the abstraction mechanism may vary.
For our application another concern is amending development. While LISP is favored in the KR community, we anticipate little aggreement among Net developers. Neither will an HTML or XML based language will be adequate, because in general an ontology tool should be more readable and writable and not tied to a particular annotation standard. We think that a special language which has a clean syntax to semantics mapping will increase the likelihood that the language will be actually used. However, a mechanism to support application semantics may be worthwile such as a way to represent URL's. Using literals liberally has proven to be useful in new programming languages such REBOL. However, the mechanism should leave the complete interpretation of special syntax to application specific modules.