Ontology2

Ontology: 

Ontology

Overview: 

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

Examples of Ontologies: 

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

Some working definitions: 

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

Allegory of the Cave: 

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

Human Ontologies: 

Human Ontologies What we created/use What we live

Microworlds: 

Microworlds Limited domain Closed set B2B Integration

Some specifics: 

Some specifics

Continuants and Occurrents: 

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

Individuals vs. Collections: 

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.

Some distinct types of individuals: 

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

Collections: 

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

Inheritance from collections: 

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?

Structural relations express common representation patterns: 

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

Genls: 

Genls (genls <sub> <super>) means (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))

Disjointness: 

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

Type constraints on arguments: 

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 Ex: (arg1-isa fluid-connection fluid-path) (arg2-isa fluid-connection container) (arg3-isa fluid-connection container)

Building an Ontology: 

Building an Ontology

Top-Down vs. Bottom-Up: 

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

Ontology and KB Design: 

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

Designing a knowledge base: 

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?

Designing a knowledge base: 

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?

Designing a knowledge base: 

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?

The Cyc Upper Ontology: 

The Cyc Upper Ontology

Example: Part-whole relationships: 

Example: Part-whole relationships

Example: Intangible Things and Individuals: 

Example: Intangible Things and Individuals

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! Common Mistakes

Common Mistakes: 

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.

Common Mistakes: 

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).

Common Mistakes: 

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

Ontology = “What is there?”Answer = “Everything”: 

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