1 / 31

Ontology

Ontology. Overview. Knowledge bases, ontologies, and axioms Collections and structural relationships Basics of ontology design. Examples of Ontologies. Domains in databases Classes in OO programming Types in AI and Logic. Some working definitions.

maloof
Download Presentation

Ontology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Continuant • 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 • (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 • Ex: (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

More Related