1. Ontology

2. Overview Knowledge bases, ontologies, and axioms
Collections and structural relationships
Basics of ontology design

3. Examples of Ontologies
Domains in databases
Classes in OO programming
Types in AI and Logic

4. Some working definitions
Ontology = a theory of the kinds of things there are and can be (WHAT CAN EXIST)
Manifests in a representation by the vocabulary of predicates and certain relationships between them (often called structural relations)
Knowledge Base = ontology + axioms (WHAT DOES EXIST)
Axioms essential to constraining meaning towards intended models
Domain Theory = KB + control knowledge (HOW TO USE THAT KNOWLEDGE)
Control knowledge makes the KB usable for various tasks

5. Allegory of the Cave
Ontology spans the cave and everything able to be experienced outside
Knowledge Base includes only items that have been experienced
Domain Theory does not allow for direct knowledge transfer. Hence communication is limited

6. Human Ontologies
What we created/use
What we live

7. Microworlds
Limited domain
Closed set
B2B Integration

8. Some specifics

9. Continuants and Occurrents
Stable properties/differentiates
Occurrents
In a state of flux
Attributes may be analogous to prior versions, but they are not the same

10. Individuals vs. Collections
Individuals are things that aren’t sets or collections
TheEiffelTower, NeilArmstrong, Dog32
Collections are natural kinds or classes whose elements share important natural properties, i.e. some common attributes or relational commonalities.
Tower, Astronaut, Dog
Sets (as in the mathematical sense) have elements that might not have anything in common.

11. Some distinct types of individuals
Discrete objects
Cut them up and you get something different
Cars, people
Substances
Cut them up and you get more of the same
Water, sand
Mobs
Like substance, but worth reifying particular elements
Mountains in a range, feathers on a bird
Events
Something happening over time with substructure
Processes
Something happening over time that is internally uniform

12. Collections Collections approximate categories
Dog is the collection of all dogs
The following are equivalent
(Dog Dog32)
(member Dog32 Dog)
(isa Dog32 Dog)
Comparison with psychological notion of category
Typically no compact definition
Organized via taxonomic relationships
But no similarity effects, recognition criteria, exemplar-driven effects

13. Inheritance from collections
Collection membership supports inference
(forall ?x
(=>(elephant ?x)
(exists ?t
(and (elephant-trunk ?t)
(physical-part ?x ?t)))))
Inheritance generally treated as monotonic
(forall ?x(=>(elephant ?x)(grey ?x))
(and (elephant Clyde)(pink Clyde))
What’s This?

14. Structural relations express common representation patterns
Genls
Disjointness and partitions
Type constraints on arguments

15. Genls (genls <sub> <super>) means genls is transitive
(forall ?x(=>(<sub> ?x)(<super> ?y)))
(subset <sub> <super>)
genls is transitive
Attribution/collection membership distributes across genls
(=> (and (elephant Clyde)
(genls elephant mammal)
(genls mammal animal))
(animal Clyde))

16. Disjointness Taxonomic relationships support inference via exclusion
Ex: (elephant Clyde)
& (disjointWith animal plant)
→ (not (plant Clyde))

17. Type constraints on arguments
Restrictions on types of arguments in a predicate are extremely common
Ex:
(forall (?x ?y ?z)
(=> (fluid-connection ?x ?y ?z)
(and (fluid-path ?x) (container ?y) (container ?z))))
Can express compactly by statements about reified collections that make intent clearer
(arg1-isa fluid-connection fluid-path)
(arg2-isa fluid-connection container)
(arg3-isa fluid-connection container)

18. Building an Ontology

19. Top-Down vs. Bottom-Up Philosophers tend toward Top-Down
Programmers tend toward Bottom-Up (sort of)

20. Ontology and KB Design
Motivations for the design and use of an ontology:
Sharing information about the structure of information.
Reuse of domain knowledge
Making domain assumptions explicit and changeable
Separation domain knowledge from operational knowledge
Analysis of domain knowledge

21. Designing a knowledge base
Before you start:
What is the domain you are trying to model?
How will the knowledge base be used? And by whom?
Is there an existing underlying ontology, or do we start from scratch?

22. Designing a knowledge base
Concepts and structure
What are the important concepts of your domain?
How are they related?
Are they individuals, collections? What are the sub- and super-classes for collections?

23. Designing a knowledge base
Axioms
What is important about a particular concept?
What makes it what it is (and not something else)?
What consequences arise from it?

24. The Cyc Upper Ontology

25. Example: Part-whole relationships

26. Example: Intangible Things and Individuals

27. Common Mistakes Don’t confuse individuals with collections:
Car is a collection, Car54 is an individual Depending on the level of detail used in your knowledge base, Car might have subclasses:
Car -> PassengerCar -> Sedan
Avoid cycles in collection hierarchies
Subclasses are transitive:
Sedan is a subclass of Car
Don’t make Car a subclass of Sedan!

28. Common Mistakes Don’t assign too much meaning to concept names
TouristAttractionsInChicagoThatDoNotChargeAdmissionOnTuesdays is a bad concept name
Chair as an isolated concept, without being a sub-or superclass of another concept and without any axioms, does not say anything about chairs.
Concept names and their denotations are not necessarily the same.

29. Common Mistakes Too many/too few subclasses
Don’t squeeze too many subclasses into a concept, don’t stretch the hierarchy unnecessarily.
More than a dozen subclasses might indicate the need for additional intermediate concepts.
A single subclass is a sign of a modeling problem (or simply unnecessary).

30. Common Mistakes Disjoint concepts
Partitioning the ontology via disjoint concepts is useful for reasoning. But be careful!
(disjointWith Dog Thing) is unwise

31. Ontology = “What is there?” Answer = “Everything”
Willard Van Orman Quine