The discipline of philosophy is the study of the general and fundamental nature of reality, existence, knowledge, values, reason, mind and language. The Ancient Greek word
φιλοσοφία (philosophia) literally means love of wisdom. Traditionally, philosophy has been divided into epistemology, logic, metaphysics, ethics, and aesthetics.
Metaphysics is the study of reality and includes the fields of cosmology and ontology. Ontology is the study of being or what there is. It seeks to understand
the fundemental questions of what is existence? and what is the nature of existence?
According to the Stanford Encyclopedia of Philosophy ontology has four distinct parts:
(O1) the study of ontological commitment, i.e. what we or others are committed to,
(O2) the study of what there is,
(O3) the study of the most general features of what there is, and how the things there are relate to each other in the metaphysically most general ways,
(O4) the study of meta-ontology, i.e. saying what task it is that the discipline of ontology should aim to accomplish, if any, how the questions it aims to answer
should be understood, and with what methodology they can be answered.
These parts can be assigned to specific criteria for distinguishing different types of objects (concrete and abstract, existent and nonexistent, real and ideal, independent and dependent)
and their ties (relations, dependencies and predication) as formal, descriptive and formalized ontologies.
Formal ontology is the study of being using eidetic reduction coupled with the method of categorial intuition. Descriptive ontology concerns the collection of
information about the list of objects that can be dependent or independent items (real or ideal). Finally, formalized ontology attempts to constructs a formal codification for the
results descriptively acquired at the preceding levels. Ontology, as a philosophical practice, is an academic endeavor that is tied to each philosopher's epistemology or method of thought.
Ontology has a practical use in the development and implementation of knowledge management.
When used to support information technology, an ontology provides a common vocabulary to share information in a generalized or specific domain of interest. An ontology can be used to:
share a common understanding of information or data structure,
enable the reuse of domain knowledge,
make specific and generalized domain assumptions explicit,
separate domain knowledge from the operational knowledge,
analyze the nature and form of domain knowledge.
It is critical, in an enterprise environment, that sharing a common understanding of the structure of information and data between individuals or software utilities. A central effort of
ontological development is to enable the reuse of domain knowledge both within a specified ontological structure and external ontologies. Through explicit domain assumptions it is possible
to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming-language code makes these assumptions not only hard to
find and understand but also hard to change, in particular for someone without programming expertise. In addition, explicit specifications of domain knowledge are useful for new users who
must learn the terms within a domain. Separating the domain knowledge from the operational knowledge configuring components according to a required specification and implement a program that
does this configuration independently. Finally, analyzing domain knowledge requires a declarative specification of the terms. Formal analysis of terms is extremely valuable when both attempting
to reuse existing ontologies and extending them. Often an ontology of the domain is not a goal in itself. Developing an ontology is akin to defining a set of data and their structure for other
programs to use. Problem-solving methods, domain-independent applications, and software agents use ontologies and knowledge bases built from ontologies as data.
A Knowledge Engineering Methodology
There is no one correct methodology for developing an ontology. However, there are some general rules:
There is no one correct way to model a domain, there are always viable alternatives. The best solution depends on the application targeted for use and anticipated extensions.
Ontology development is necessarily an iterative process.
Concepts should be close to objects (physical or logical) and relationships in the domain of interest.
The initiation of ontology development is the first pass at the ontology. It is then refined and revised to fill gaps in detail. The ontologist needs to make clear specifications of the domain
defining the pros, cons, and implications of different ontological solutions. The ontologist must decide the use of the ontology and the level of detail required to build the structure.
These decisions will guide many of the modeling decisions during the evolution. These alternatives will need to be assessed to determine viability, which will be more intuitive, more
extensible, and more maintainable. The ontologist must remember that an ontology is a model of reality, the concepts in the ontology must reflect this reality. The initial version is then
evaluated and revised again until the ontology meets the requirements throughout the lifecycle of the ontology.
There is a basic process developed by Natalya F. Noy and Deborah L. McGuinness from
Stanford University, that should form the foundation of all ontology development projects.
Ontology Scope
The development of an ontology begins by defining the information domain and the specific scope of the domain. There are several basic questions:
What is the domain that the ontology will cover?
What is the use of the ontology?
What types of questions will the ontology answer?
Who will use and maintain the ontology?
The answers to these questions may change during the ontology design process, but will help limit the scope of the model.
Ontology Reuse
Always consider existing ontologies for a particular domain and task. Reusing existing ontologies may be a requirement if the system needs to interact with other applications
that have already committed to particular ontologies or controlled vocabularies. Many ontologies are already available in electronic form and can be imported into an ontology
development environment that you are using. The formalism in which an ontology is expressed often does not matter, since many knowledge-representation systems can import and
export ontologies. Even if a knowledge-representation system cannot work directly with a particular formalism, the task of translating an ontology from one formalism to another
is usually not a difficult one.
It is useful to write down a list of all terms that are part of the domain. It is crucial that we ask the questions:
What are the terms that comprise the domain of interest?
What properties do those terms have?
What are the specific and general characteristics of these terms?
Initially, it is important to get a comprehensive list of terms without worrying about overlap between concepts they represent, relations among the terms, or any properties that the
concepts may have, or whether the concepts are classes or instances.
Class and Hierarchy
There are several possible approaches in developing a class hierarchy, none inherently better than the others.
A top-down development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts.
A bottom-up development process starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these
classes into more general concepts.
A combination development process is a combination of the top-down and bottom-up approaches: We define the more salient concepts first and then generalize
and specialize them appropriately.
If the ontologist has a systematic top-down view of the domain, then it may be easier to use the top-down approach. The combination approach is often the easiest
for many ontologist, since the concepts “in the middle” tend to be the more descriptive concepts in the domain.
Whichever approach selected, it is commonly accepted to start development by defining classes. Select the terms that describe objects having independent existence rather
than terms that describe these objects. These terms will be classes in the ontology and will become anchors in the class hierarchy. Organizing the classes into a hierarchical
structure is conducted by determining if one class could be an instance of another class, the object will necessarily (i.e., by definition) be an instance of some other class.
If a class A is a superclass of class B, then every instance of B is also an instance of A, e.g the class B represents a concept that is a “kind of” A.
Property Definition
The classes alone will not provide enough information to answer the competency questions from Step 1. Once defined, some of the classes have associated internal concepts.
We have already selected classes from the list of terms created in Step 3. Most of the remaining terms are likely to be properties of these classes. In general, there are
several types of object properties associated with an ontology:
intrinsic properties,
extrinsic properties,
parts if the object is structured; these can be both physical and abstract parts
relationships to other individuals; these are the relationships between individual members of the class and other items.
A object properties should be attached to the most general class that can have that property.
Facet Definition
Object properties can have different facets describing the value type, allowed values, the number of the values (cardinality), and other features.
Cardinality
Cardinality defines how many values an object property can have. Some systems distinguish only between single cardinality (allowing at most one value) and multiple cardinality
(allowing any number of values). Some systems allow specification of a minimum and maximum cardinality to describe the number of object property values more precisely. Minimum cardinality
of N means that a object property must have at least N values. Maximum cardinality of M means that a object property can have at most M values. Sometimes it may be useful to set the
maximum cardinality to 0. This setting would indicate that the slot cannot have any values for a particular subclass.
Property-value Type
A value-type facet describes what types of values can fill in the object property.
String is the simplest value type which is used for object property such as name: the value is a simple string
Number (such as Float and Integer ) describes object property with numeric values.
Boolean object properties are yes–no terms, the value is “true” (“yes”) if the value is “false” (“no”)
Enumerated object properties specify a list of specific allowed values for the slot.
Instance-type object properties allow definition of relationships between individuals defining a list of allowed classes from which the instances can come.
Domain and Range
The allowed classes for an object property, of the Instance type are often called a range. Some systems allow restricting the range for a particular class. The classes
are called the domain of the object property. In the systems where we attach object properties to classes, the classes to which the object properties is attached usually
constitute the domain of that object properties. There is no need to specify the domain separately.
The basic rules for determining a domain and a range of a object properties are similar: When defining a domain or a range for a object properties, find the most general classes
or class that can be respectively the domain or the range for the object property. Conversely, do not define a domain and range that is overly general: all the classes in the
domain of a slot should be described by the object property and instances of all the classes in the range of a object properties should be potential fillers for the object property.
An overly general class for range (i.e., one would not want to make the range THING) but one would want to choose a class that will cover all fillers. In more specific terms:
If a list of classes defining a range or a domain of an object property includes a class and its subclass, remove the subclass.
If a list of classes defining a range or a domain of a object property contains all subclasses of a class A, but not the class A itself, the range should contain only the
class A and not the subclasses.
If a list of classes defining a range or a domain of a object property contains all but a few subclasses of a class A, consider if the class A would make a more appropriate range definition.
Instance Creation
The last step is creating individual instances of classes in the hierarchy. Defining an individual instance of a class requires (1) choosing a class, (2) creating an individual instance
of that class, and (3) filling in the object property values.