ONTOLOGY

MOTIVATIONS, METHODOLOGIES AND

IMPLEMENTATION
By
DADA OLUWASEGUN VICTOR – 217159
YUSUF KEMI JAMILAT - 217461
BAKARE HABIBAT TOWOBOLA - 218008
WHAT IS “ONTOLOGY ENGINEERING”?
Ontology Engineering:
Defining terms in the domain and relations among them
 Defining concepts in the domain (classes)
 Arranging the concepts in a hierarchy (subclass-superclass
hierarchy)
 Defining which attributes and properties (slots) classes can have
and constraints on their values
 Defining individuals(Instances) and filling in slot values
MOTIVATIONS
 People, organisations and software systems must communicate
between and among themselves. However due to different needs
and background contexts, there can be widely varying viewpoints
and assumptions regarding what is essentially the same subject
matter.
 Each uses different jargon; each may have differing, overlapping
and/or mis-matched concepts, structures and methods. The
consequent lack of a shared understanding leads to
 poor communication within and between these people and their
organisations
MOTIVATIONS
Disparate modelling methods, paradigms, languages and software tools severely
limit:
1. Inter-operability
2. The potential for re-use and sharing
3. Much wasted effort re-inventing the wheel
The way to address these problems is to come to a shared understanding which can
function as a unifying framework for the different viewpoints and serve as the basis for
Communication between people with different needs and viewpoints arising from their
differing contexts.
ONTOLOGY: DEFINITIONS
 An “Ontology” describes the common words, concepts and relationships
between concepts used to describe and represent an area of knowledge.
An ontology can range from a
 Taxonomy (knowledge with minimal hierarchy or a parent/child structure) to a
…
 Thesaurus (words and synonyms) to a ….
 Conceptual Model (with more complex knowledge) to a…
 Logical Theory (with very rich, complex, consistent and meaningful
knowledge).
A well-formed ontology is one that is expressed in a well-defined syntax that
has a well-defined machine interpretation consistent with the above ontology
definition
WHAT IS AN ONTOLOGY
 Ontology is the term used to refer to the shared
understanding of some domain of interest which may be used
as a unifying framework to solve problems. An ontology
necessarily entails or embodies some sort of world view with
respect to a given domain.
 The world view is often conceived as a set of concepts e.g.
entities, attributes, processes, their definitions and their inter-
relationships, this is referred to as a conceptualization.
WHAT IS AN ONTOLOGY
 ontology as a formal explicit description of concepts in a
domain of discourse (classes (sometimes called
concepts)), properties of each concept describing various
features and attributes of the concept (slots (sometimes
called roles or properties)), and restrictions on slots
(facets (sometimes called role restrictions)). An ontology
together with a set of individual instances of classes
constitutes a knowledge base.
ONTOLOGY TERMINOLOGIES
 Classes describe concepts in the domain. For example, a
class of CARS represents all CARS. Specific cars (Toyota)
are instances of this class.
 A class can have subclasses that represent concepts that are
more specific than the superclass. For example we can
subdivide cars into: SUVs, Saloon and Sport cars.
 Slots describe properties of classes and instances. E.g. the
car Engine type and Weight are two properties can be
used to classify whether a car is SUV or Saloon Car.
ONTOLOGY TERMINOLOGIES

 Facets/Constraints are values that are allowed for each

Slots identified earlier. It describes:
 Value type - String, Numeric, Boolean or enumerated values
 Number of the values (cardinality) – one or many values allowed in a slot
 Allowed values and
 other features of the values the slot can take
DEVELOPING ONTOLOGIES INCLUDES:
 defining classes in the ontology,
 arranging the classes in a taxonomic (subclass–superclass)
hierarchy,
 defining slots and describing allowed values for these
slots,
 filling in the values for slots for instances.
FUNDAMENTAL RULES IN ONTOLOGY DESIGN
 There is no one correct way to model a domain— there
are always viable alternatives.
 The best solution almost always depends on the application that you have in mind
and the extensions that you anticipate.

 Ontology development is necessarily an iterative process.

 Concepts in the ontology should be close to objects
(physical or logical) and relationships in your domain of
interest.
 These are most likely to be nouns (objects) or verbs (relationships) in sentences
that describe your domain.
Requireme
nt
Determine Consider Enumerate Define Define Define Add
and scope reuse terms classes properties constraints Instances
domain
analysis

ONTOLOGY DESIGN
PROCESS
STEP 1: REQUIREMENT ANALYSIS
Performing Requirements, Domain & Use Case Analysis is a critical stage as in
any software engineering design. It allows ontology engineers to ground the
work and prioritize.
The analysis has to elicit and make explicit:
 The nature of the knowledge and the questions (competency questions) that
the ontology (through a reasoner) needs to answer. This process is crucial for
scoping and designing the ontology, and for driving the architecture;
 Architectural issues;
 The effectiveness of using traditional approaches with knowledge intensive
approaches;
STEP 2: DETERMINE THE DOMAIN AND SCOPE OF THE
ONTOLOGY
What is the domain that the ontology will cover?
 E.g. representing an intelligent University space
For what we are going to use the ontology?
 E.g. applications that support roaming students, lecturers and visitors are going to use the
ontology
For what types of questions the information in the ontology should provide answers?
 E.g. to help roaming student print to the nearest printer etc.
 E.g. to help the university intelligent space applications to implement energy conservation
policies etc.
Who will use and maintain the ontology?
 E.g. if it is maintained by someone in MIS unit but needs also to be used by visiting users
etc., then mappings need to be included
COMPETENCY QUESTIONS
One way to determine scope is to list out the questions the knowledge
base based on the ontology should be able to answer For example
 Which rooms have data projectors?
 Is KDL a conference room?
 Is there a conference room near restrooms?
 What is the best choice of room for a student tutorial?

Judging from this list of questions, the ontology will include information
on
 Various room types and characteristics
 Various event types and characteristics
 Classifications of rooms with respect to appropriateness for events
 Classifications of rooms with respect to location
 Classifications of rooms with respect to furniture/equipment
STEP 3: CONSIDER REUSING EXISTING
ONTOLOGIES
 We rarely have to start from scratch when defining an ontology:
 There is almost always an ontology available from a third party
that provides at least a useful starting point for our own
ontology
 Reuse allows to:
 to save the effort
 to interact with the tools that use other ontologies
 to use ontologies that have been validated through use in
applications
STEP 3: CONSIDER REUSING EXISTING
ONTOLOGIES
 Standard vocabularies are available for most domains, many of which are
overlapping
 Identify the set that is most relevant to the problem and application issue
 A component-based approach based on modules facilitates dealing with
overlapping domains:
 Reuse an ontology module as one would reuse a software module
 Standards; complex relationships are defined such that term usage and overlap is
unambiguous and machine interpretable
 Initial brainstorming with domain experts can be highly productive; then
subsequent refinement and iteration lead to the level required by the
application
WHAT TO REUSE?
 Ontology libraries
 DAML ontology library (www.daml.org/ontologies)
 Protégé ontology library (protege.stanford.edu/plugins.html)
 Upper ontologies
 IEEE Standard Upper Ontology (suo.ieee.org)
 Cyc (www.cyc.com)
 General ontologies
 DMOZ (www.dmoz.org)
 WordNet (www.cogsci.princeton.edu/~wn/)
 Domain-specific ontologies
 UMLS Semantic Net
 GO (Gene Ontology) (www.geneontology.org)
STEP 4: ENUMERATE IMPORTANT TERMS IN THE
ONTOLOGY
 Write down in an unstructured list all the relevant terms that are expected to
appear in the ontology
 Nouns form the basis for class names
 Verbs (or verb phrases) form the basis for property names
 Card sorting is often the best way:
 Write down each concept/idea on a card
 Organize them into piles
 Link the piles together
 Do it again, and again
 Works best in a small group
EXAMPLE: ANIMALS & PLANTS ONTOLOGY
• Dog • Carnivore • Dangerous
• Cat • Plant • Pet
• Cow • Animal • Domestic
• Person • Fur Animal
• Tree • Child • Farm animal
• Grass • Parent • Draft animal
• Herbivore • Mother • Food animal
• Male • Father • Fish
• Female • Carp
• Goldfish
STEP 5: DEFINE THE CLASSES AND THE CLASS
HIERARCHY
 A class is a concept in the domain:
 Animal (cow, cat, fish)

 A class of properties (father, mother)

 A class is a collection of elements with similar properties

 A class contains necessary conditions for membership (type of food,
dwelling)
 Instances of classes
 A particular farm animal, a particular person

 Tweety the penguin

 ORGANIZE THE CONCEPTS
EXAMPLE: ANIMALS & PLANTS
 Dog • Carnivore  Healthy
 Cat • Plant  Pet
 Cow • Animal  Domestic Animal
 Person • Fur  Farm animal
 Tree • Child  Draft animal
 Grass • Parent  Food animal
 Herbivore • Mother  Fish
 Male • Father  Carp
 Female  Goldfish
22
EXTEND THE CONCEPTS: “LADDERING”
 Take a group of things and ask what they have in common
 Then what other ‘siblings’ there might be
 e.g.
 Plant, Animal  Living Thing
 Might add Bacteria and Fungi but not now
 Cat, Dog, Cow, Person  Mammal
 Others might be Goat, Sheep, Horse, Rabbit,…
 Cow, Goat, Sheep, Horse  Hoofed animal (“Ungulate”)
 What others are there? Do they divide amongst themselves?
 Wild, Domestic  Domestication 23

 What other states – “Feral” (domestic returned to wild)

CHOOSE SOME MAIN AXES
 Add abstractions where needed
 e.g. “Living thing”
 identify relations (this feeds into the next step)
 e.g. “eats”, “owns”, “parent of”
 Identify definable things
 e.g. “child”, “parent”, “Mother”, “Father”
 Things where you can say clearly what it means
 Try to define a dog precisely – very difficult
 A “natural kind”
 make names explicit
24
 EXAMPLE
 Relations
 Living Thing  Modifiers
 eats
 Animal  domestic
 pet  owns
 Mammal
 Farmed  parent-of
 Cat  Draft
 Dog  Food  …
 Cow  Wild  Definable
 Person  Health  Carnivore
 Fish  healthy  Herbivore
 Carp  sick
 Child
 Goldfish  Sex
 Male
 Parent
 Plant
 Female  Mother
 Tree
 Age  Father
 Grass  Adult  Food Animal 25

 Fruit  Child
 Draft Animal
IDENTIFY SELF-STANDING ENTITIES

 Things that can exist on there own

 People, animals, houses, actions, processes, …
 Roughly nouns
 Modifiers
 Things that modify (“inhere”) in other things
 Roughly adjectives and adverbs

26
REORGANIZE EVERYTHING BUT “DEFINABLE”
THINGS INTO PURE TREES – THESE WILL BE THE
“PRIMITIVES”
 Self_standing  Modifiers  Relations
 Living Thing  Domestication  eats
 Animal  Domestic
 owns
 Wild
 Mammal
 parent-of
 Cat
 Use
 Draft  …
 Dog
 Food
 Cow
 pet
 Definables
 Person
 Risk  Carnivore
 Pig
 Dangerous  Herbivore
 Fish  Safe  Child
 Carp  Sex
 Parent
 Goldfish  Male
 Plant  Female
 Mother
 Tree  Age  Father
 Grass
 Adult  Food Animal 27

 Child  Draft Animal

 Fruit
 CLASS INHERITANCE
 Classes are organized into subclass-superclass (or generalization-
specialization)
Hierarchies:
 Classes are “is-a” related if an instance of the subclass is an instance of
the superclass
 Classes may be viewed as sets
 Subclasses of a class are comprised of a subset of the superset
 Examples
 Mammal is a subclass of Animal
 Every penguin is a bird or every instance of a penguin (like Tweety is
an instance of bird
 Draft animal is a subclass of Animal
LEVELS IN THE CLASS HIERARCHY
 Different modes of development
 Top-down - define the most general concepts first and then specialize them
 Bottom-up - define the most specific concepts and then organize them in more
general classes
 Combination (typical – breadth at the top level and depth along a few branches to
test design)
 Class inheritance is Transitive
– A is a subclass of B
– B is a subclass of C
– therefore A is a subclass of C
LEVELS IN THE CLASS HIERARCHY
Top
level

Middle
level

Bottom
level
STEP 6: DEFINE THE PROPERTIES OF CLASSES -
SLOTS
 Often interleaved with the previous step
 Properties (or roles in DL) describe the attributes of the
members of a class
 The semantics of subClassOf demands that whenever A is
a subclass of B, every property statement that holds for
instances of B must also apply to instances of A
 It makes sense to attach properties to the highest class in
the hierarchy to which they apply
DEFINE PROPERTIES
 Types of properties
– “intrinsic” properties: flavor and color of wine
– “extrinsic” properties: name and price of wine
– parts: ingredients in a dish
– relations to other objects: producer of wine (winery)
 They are represented by data and object properties
– simple (datatype) contain primitive values (strings, numbers)
– complex properties contain other objects (e.g., a winery instance)
 IDENTIFY THE DOMAIN AND RANGE CONSTRAINTS
FOR PROPERTIES
 Animal eats Living_thing
 eats domain: Animal;
range: Living_thing
 Person owns Living_thing except person
 owns domain: Person
range: Living_thing & not Person
 Living_thing parent_of Living_thing
 parent_of: domain: Living_thing
range: Living_thing 33
 FOR DEFINABLE THINGS
 Paraphrase and formalise the definitions in terms of the primitives, relations and other
definables.

 Note any assumptions to be represented elsewhere.

 Add as comments when implementing

 “A ‘Parent’ is an animal that is the parent of some other animal” (Ignore plants for now)
 Parent =
Animal and parent_of some Animal

 “A ‘Herbivore’ is an animal that eats only plants”

(NB All animals eat some living thing)
 Herbivore=
Animal and eats only Plant

 “An ‘omnivore’ is an animal that eats both plants and animals”

 Omnivore= 34
Animal and eats some Animal and eats some Plant
 WHICH PROPERTIES CAN BE FILLED IN
AT THE CLASS LEVEL NOW?

 What can we say about all members of a class?

 eats
 All cows eat some plants

 All cats eat some animals

 All pigs eat some animals &
eat some plants

35
FILL IN THE DETAILS
(CAN USE PROPERTY MATRIX WIZARD)

36
CHECK WITH CLASSIFIER
 Cows should be Herbivores
 Are they? why not?
 What have we said?
 Cows are animals and, amongst other things,
eat some grass and
eat some leafy_plants
 What do we need to say:
Closure axiom
 Cows are animals and, amongst other things,
eat some plants and eat only plants
37
CLOSURE AXIOM
Cows are animals and, amongst other things,
eat some plants and eat only plants

Closure
Axiom

38
STEP 7: DEFINE THE FACETS OF EACH SLOT
Facet: Describes a restriction on a slot
 Slot cardinality e.g. one or many values allowed in slot
 Slot value type, e.g. String, Integer, Boolean, Enummerated, Instance
STEP 7: DEFINE THE FACETS OF EACH SLOT (IN
PROTÉGÉ)

 Blue rectangle means

property defined on this
class
 Round brackets around
rectangle means
property inherited
STEP 8: (OPTIONALLY) CREATE INSTANCES

 Filling the ontologies with such instances is a separate step

 Number of instances >> number of classes
 Thus populating an ontology with instances is not done manually
 Retrieved from legacy data sources (DBs)
 Extracted automatically from a text corpus
RECAP (EIGHT STEPS TO DESIGNING AN
ONTOLOGY)
1. Requirement Analysis
2. Determine scope and domain of ontology
3. Consider reusing existing ontologies
4. Enumerate important terms in the ontology
5. Define the classes and class hierarchy
6. Define the properties of classes – slots
 Properties, relationships

6. Define the facets of slots

 Value type (String, Number, Boolean, Enumerated, Instance)
 Value cardinality
7. Define the instances
THANK YOU FOR LISTENING