Ontology Development 101

Ontology Development 101

One of the first guidelines for the creation of ontologies is the paper Ontology Development 101 [NoMG2000]. Much of this is still valid today. Therefore, our focus is essentially on working out which recent developments have led to the use of other terms. The following sections contain partially redundant requirements and specifications for ontology development.

Page 1: Why develop an ontology?

• "To share common understanding of the structure of information among people or software agents": This is one of the fundamental goals pursued with the Semantic Web.
• "To enable reuse of domain knowledge": We will see later that reusability cannot be used in the same sense as in software development.
• "To make domain assumptions explicit": The point here may be to explicitly model tacit knowledge or knowledge of what is between the lines.
• "To separate domain knowledge from the operational knowledge": It is not clear to us here what exactly the demarcation of the two types of knowledge is supposed to be.
• "To analyze domain knowledge": The most demanding part in knowledge modeling is certainly to transform the knowledge formulated and contained in natural language into the formal knowledge of ontologies.

The term slot is probably borrowed from frame-based systems and is less common today. It has been replaced by data properties (attributes) and object properties (relationship types).

"We suggest starting the development of an ontology by defining its domain and scope. That is, answer several basic questions:

• What is the domain that the ontology will cover?
• For what we are going to use the ontology?
• For what types of questions the information in the ontology should provide answers?
• Who will use and maintain the ontology?

The following steps are meant as part of an iterative modelling process:

• Step 1. Determine the domain and scope of the ontology
• Step 2. Consider reusing existing ontologies
• Step 3. Enumerate important terms in the ontology
• Step 4. Define the classes and the class hierarchy
• Step 5. Define the properties of classes—slots
• Step 6. Define the facets of the slots
• Step 7. Create instances"

The modeling of logic and axioms is not discussed here.

Page 2: "Object-oriented programming centers primarily around methods on classes—a programmer makes design decisions based on the operational properties of a class, whereas an ontology designer makes these decisions based on the structural properties of a class. As a result, a class structure and relations among classes in an ontology are different from the structure for a similar domain in an object-oriented program.".

What is in an Ontology?

The term class is also being called concept. Deviating from today's consistent use of data properties for attributes and object properties for relation types, the authors use the term slot and for restrictions on slots the term facet. It is interesting that the term instances is obviously used differently as we use particulars. The set of particulars form what we describe as the Particulars Layer. However, the authors restrict the term ontology to what we call the schema layer, namely as an explicit description of concepts of the domain of discourse. What we call the knowledge graph is called the knowledge base there. Accordingly, an ontology would not contain any particulars, which we see differently.

Knowledge-Engineering Methodology

We basically agree with the views expressed in Chapter 3: The development of ontologies is an iterative process. There isn't just one correct way to model a domain, there are always alternatives that are justified. It also goes without saying that the modeling is based on nouns and verbs of the application domain.

Already existing ontologies are proposed as candidates for the use

• Ontolingua ontology library
• DAML ontology library

and other publicly available commercial ontologies such as:

• UNSPSC
• RosettaNet
• DMOZ

Defining classes and a class hierarchy

We agree that when defining classes in a class hierarchy, it doesn't matter whether they are defined top-down, bottom-up, or a mix of both. "The combination approach is often the easiest for many ontology developers, since the concepts “in the middle” tend to be the more descriptive concepts in the domain [Rosc1978]".

As a guideline for well-structured ontologies the authors claim that classes have between two and a dozen direct subclasses: "If there are more than a dozen subclasses for a given class then additional intermediate categories may be necessary". As further indications for creating new classes are given: Subclasses have additional properties that the superclass does not have or they have restrictions distinct from the superclass or that participate in other object properties.

An Instance or a Class?

Page 18: "Individual instances are the most specific concepts represented in a knowledge base". Instead of Individual instances we use the term particulars. "If concepts form a natural hierarchy, then we should represent them as classes".

What's in a name?

• Page 3: "We capitalize class names and start slot names with low-case letters". We believe that property names should also start with capital letters if they are nouns.
• Page 21: "Define a naming convention for classes and slots and adhere to it". Our naming conventions meet these requirements and go far beyond them. In particular, we also define which delimiters, prefix and suffix conventions should be used and that the name-bound should be case-insensitive in any case. With few exceptions, the singular form of names should always be used.