1 CSC 9010 Spring, Paula MatuszekSome slides taken from CS 9010: Knowledge-Based Systems Inference in Description Logics Paula Matuszek Spring, 2011

2 CSC 9010 Spring, Paula MatuszekSome slides taken from Inference in Protégé OWL In CLIPS inference is forward-chaining and rule-based –The antecedent facts of a rule become true –The rule fires –The consequent of the rule is executed, typically making some new facts true. –Repeat until some desired state is reached In Protégé OWL inference is neither forward nor backward-chaining; it’s not rule-based at all It shares with CLIPS a basis in logic and the general idea that we are reasoning about the information we have in order to acquire additional information

3 CSC 9010 Spring, Paula MatuszekSome slides taken from Reasoners: Inference Many Protégé reasoners are used to infer information that is not explicitly contained within the ontology They may also be referred to as classifiers Standard reasoner services are: –Consistency Checking –Subsumption Checking (Automatic Subsumption) –Equivalence Checking –Instantiation Checking Provides a check for the semantic consistency of our ontology Allows us to simplify the ontology

4 CSC 9010 Spring, Paula MatuszekSome slides taken from Why Inference in Protégé? During development as an ontology compiler. A well designed ontology can be compiled to check its meaning is that intended At publish time – so many inferences are already made for the user apps At runtime in applications as a querying mechanism (esp. useful for smaller ontologies)

Lite partially restricted to aid learning curve lite DL = Description Logic Description Logics are a fragment of First Order Logic (FOL) that can be reasoned with DL Full unrestricted use of OWL constructs, but cannot reason Full OWL comes in 3 Flavors

PersonCountry Class (concept) Animal Individual (instance) Belgium Paraguay China Latvia Elvis Hai Holger Kylie S.Claus Rudolph Flipper lives_in has_pet arrow = relationship label = Property has_pet OWL Constructs Overview

Eg Pizza, CheeseTopping, Tree, Person, Company Classes are sets of Individuals aka “Type”, “Concept”, “Category”, “Kind” Membership of a Class is dependent on its logical description, not its name Classes do not have to be named – they can be logical expressions – eg things that have colorcolor Blue. Anonymous classes. OWL Constructs: Classes

Eg hasTopping, isInhabitedBy, isNextTo, occursBefore Properties are used to relate Individuals We often say that Individuals are related along a given property Relationships in OWL are binary: Subject  predicate  Object Individual a  hasProperty  Individual b nick_drummond  givesTalk  owl_overview_talk_Dec_2005 OWL Constructs: Properties

Eg me, you, this talk, this room Individuals are the objects in our domain of interest aka “Instance”, “Object” Individuals may be (and are likely to be) a member of multiple Classes OWL Constructs: Individuals

Describing a Class Hierarchy 2 important things to say about classes: –Where can we put them? –Where can’t we put them? Animal Shark Hot Air Balloon?

Subsumption is the primary axis (relationship) in OWL Superclass/subclass relationship, “isa” All members of a subclass must be members of its superclasses Animal subsumes Shark Animal is a superclass of Shark Shark is a subclass of Animal All Sharks are also Animals owl:Thing superclass of all Classes Shark Animal Subsumption in OWL Where can we put this class?

Where can’t we put this class? Regardless of where they exist in the hierarchy, OWL assumes that classes can overlap Animal Hot Air Balloon = individual By default, an individual could be both an Animal and a Hot Air Balloon at the same time Disjointness in OWL

Where can’t we put this class? Stating that 2 classes are disjoint means Hot Air Balloon = individual Something cannot be both an Animal and a Hot Air Balloon at the same time Animal Disjointness in OWL Hot Air Balloon can never be a subclass of Animal (and vice-versa) This can help us find errors

Types of Class owl:Thing (everything) owl:Nothing (nothing) Animal (primitive named class) hasDangerLevel some Dangerous (anonymous class - restriction) DangerousAnimal (defined named class)

Primitive vs Defined Blue Things Sharks “Smart Class” Acts like a query Describe the necessary features of the members Eg live underwater Like primitive, but also: define necessary conditions that are also sufficient to recognise a member Eg have color Blue “Natural Kinds” “All things that have color blue are members of this class” “All sharks live underwater” but not everything that lives underwater is a shark

Anonymous Classes Made up of logical expressions –Unions and Intersections (Or, And) –Complements (Not) –Enumerations (specified membership) –Restrictions (related to Property use) The members of an anonymous class are the set of Individuals that satisfy its logical definition

Restrictions Restrictions are a type of anonymous class They describe the relationships that must hold for members (Individuals) of this class

An example Existential restriction on primitive class Shark: necessarily hasMouthPart some Teeth SharkTeeth hasMouthPart “Every member of the Shark class must have at least one mouthpart from the class Teeth”

An example Existential restriction on primitive class Shark: necessarily hasMouthPart some Teeth SharkTeeth hasMouthPart “There can be no member of Shark, that does not have at least one hasMouthPart relationship with an member of class Teeth”

Restriction Types ∃ Existential, someValuesFrom “Some”, “At least one” ∀ Universal, allValuesFrom “Only” ∍ hasValue“equals x”  Cardinality“Exactly n”  Max Cardinality“At most n”  Min Cardinality“At least n”

21 CSC 9010 Spring, Paula MatuszekSome slides taken from Back to Reasoners Reasoners are used to infer information that is not explicitly contained within the ontology Standard reasoner services are: –Consistency Checking –Subsumption Checking (Automatic Subsumption) –Equivalence Checking –Instantiation Checking Restrictions can add a lot of power to a DL reasoner

Consistency Checking Shark (primitive class) Animal and eats some (Person and Seal) Person Seal Inconsistent = cannot contain any individuals Disjoint (Person, Seal) Person and Seal = empty Cannot have some empty

Automatic Classification Trivial example DangerousAnimal (defined class) Animal and hasMouthPart some Teeth Shark (primitive class) Animal and hasMouthPart some Fangs Teeth Fangs

24 CSC 9010 Spring, Paula MatuszekSome slides taken from Using a Reasoner in Protégé The class hierarchy that you create directly in Protégé is known as the asserted class hierarchy. You can invoke a reasoner over this hierarchy from the Reasoner menu item. –Comes up by default with “none”. –As soon as you choose a reasoner, it will be invoked. You can reinvoke it with “Classify” –We will work with Fact++

25 CSC 9010 Spring, Paula MatuszekSome slides taken from Invoking a Reasoner Invoking a classifier in Protégé will immediately do two things: –Create an inferred class hierarchy that parallels the asserted hierarchy but contains any additional classes that can be inferred through subsumption –In the asserted hierarchy, flag any inconsistencies it finds.

26 CSC 9010 Spring, Paula MatuszekSome slides taken from Reasoning About The Pizza Ontology: At the end of exercise 23 we have:

27 CSC 9010 Spring, Paula MatuszekSome slides taken from Finding an Inconsistency in Protégé This ontology includes cheese and vegetable toppings, which are disjoint. Now suppose we deliberately add a class to both. (Such deliberate mistakes are often called probes). When we classify the hierarchy, the probe shows up in the asserted hierarchy in red. If we remove the disjoint statement, there will no longer be an error

28 CSC 9010 Spring, Paula MatuszekSome slides taken from Inconsistent Ontology

29 CSC 9010 Spring, Paula MatuszekSome slides taken from Inferring a classification Back to our exercise 23 ontology. Now suppose we add a class “CheesyPizza” –We add a property under superclass that it has some cheese topping. –So to be a CheesyPizza it must be a Pizza and must have a CheesyTopping. Now we look at AmericanaPizza –It is a pizza –It has cheese on it Is it a CheesyPizza? We don’t know!

30 CSC 9010 Spring, Paula MatuszekSome slides taken from Open World Assumption CLIPS operates with a closed world assumption. The information we have is everything. On the Semantic Web, we want people to be able to extend our models. We assume more information can be added later. We have an Open World Assumption. CLIPS returns false if it doesn’t find some fact. DL reasoners make no assumption about completeness of information given. The reasoner cannot determine something does not hold unless it is explicitly so stated in the model -- no negation by failure. And just because we know a CheesyPizza has to have some cheese, we don’t know whether it also has to have tomato sauce, for instance. Maybe we just haven’t been told. Open world.

Open World Assumption hasMouthPart some Do sharks have a trunk? Can sharks fly hot air balloons?

Closure hasMouthPart some hasMouthPart only Sharks definitely cannot have trunks (as long as Trunks are MouthParts disjoint from Teeth) But someone could still extend our description to say that Sharks can fly Hot Air Balloons

33 CSC 9010 Spring, Paula MatuszekSome slides taken from Necessary and Sufficient CheesyPizza is a Primitive class, not a Defined class. But in fact, we do think that this is a sufficient specification of a CheesyPizza. We can tell Protégé this under the Edit menu: Convert to Defined Class. Now if we classify our ontology, we will find that all of our named pizzas are inferred to be members of CheesyPizza, because they all have the necessary and sufficient condition that they have CheeseTopping. An automated classifier will normally only infer membership in defined classes.

34 CSC 9010 Spring, Paula MatuszekSome slides taken from Inferred Hierarchy

35 CSC 9010 Spring, Paula MatuszekSome slides taken from Closure Axiom Back to end of exercise 23. We have stated that a Margherita pizza must have mozzarella and tomato toppings. That does not actually accurately model our English comment, which says that it has only mozzarella and tomato toppings. We want to add a “closure axiom”, which basically says we have told you all of the possible toppings.

36 CSC 9010 Spring, Paula MatuszekSome slides taken from Universal Restriction We have already said that it has some cheese topping and some tomato topping. We want to add a restriction that says that those are the only toppings it has. The is the universal or only restriction: –hasTopping only (MozzarellaTopping or TomatoTopping) Now our set of restrictions actually matches our English comment.

37 CSC 9010 Spring, Paula MatuszekSome slides taken from Automated classification using closure Now we create a new class, VegetarianPizza, and specify that it has only CheesyTopping or VegetableTopping and is a defined class. Text Note that this is not an XOR.

38 CSC 9010 Spring, Paula MatuszekSome slides taken from Yet more class inference Because we have now closed the definition of MargheritaPizza toppings, the reasoner can infer that a MargheritaPizza is a VegetarianPizza. Note that MargheritaPizza is still a primitive class. We still don’t know, for instance, whether a MargheritaPizza also has to be square. So we can’t infer anything about membership of other classes in the class MargheritaPizza.

39 CSC 9010 Spring, Paula MatuszekSome slides taken from And Yet More Some other kinds of restrictions also support subsumption checking. For instance, a cardinality restriction specifies how many fillers there must be. If we create a defined class “InterestingPizza”that has at least three toppings, all except Margherita of our named pizzas should be automatically classified here. Note that we do not need a closure axiom for this inference.

40 CSC 9010 Spring, Paula MatuszekSome slides taken from Datatype Properties All of these have been Object Properties. Datatype Properties have values as fillers, rather than other classes For instance: –Pizza could have a datatype property hasCalories, which must be an integer. –Subclasses of Pizza include HighCaloriePizza, with the datatype property hasCalories restricted further to an integer > 400, and LowCaloriePizza, restricted to <400. –Since any given pizza can have exactly one calorie value, we also make this property functional.

41 CSC 9010 Spring, Paula MatuszekSome slides taken from Instantiation Checking Now suppose we create some individual pizzas, which have, among other things, a calorie count. We have instantiated the pizza class. When we classify the hierarchy, the reasoner will assign individual pizzas (instantiations) to either the HighCaloriePizza class or the LowCaloriePizza class. Note that if we had defined our restriction differently, we could end up with pizzas assigned to both classes. This is an error iff the classes are disjoint. Also note that if we have a pizza which has 400 calories it will not be assigned to either. Not an inconsistency, but probably not what we want!

42 CSC 9010 Spring, Paula MatuszekSome slides taken from Beyond Simple DL Classifiers There are other kinds of inference tools available for Protégé, either via plugins or taking an ontology as input Some examples: –Many plugins for Protégé 3. Rule-based: Algernon, JessTab Querying: Racer, Flora Bayesian Network –Pizza finder: