1 CSC 9010 Spring, 2011. Paula MatuszekSome slides taken from...

1CSC 9010 Spring, 2011. Paula Matuszek Some slides taken from www.cs.man.ac.uk/~drummond/.../IntroductionToOWL50mins.ppt

CS 9010: Knowledge-Based Systems

Inference in Description Logics

Paula Matuszek

Spring, 2011

http://www.cs.man.ac.uk/~drummond/.../IntroductionToOWL50mins.ppt


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



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



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)


Litepartially restricted to aid learning curve

lite

DL = Description LogicDescription Logics are a fragment of First Order Logic (FOL) that can be reasoned with

DLFullunrestricted use of OWL constructs, but cannot reason

Full

OWL comes in 3 Flavors

Person Country

Class (concept)

Animal

Individual (instance)

Belgium

Paraguay

China

Latvia

Elvis

Hai

Holger

Kylie

S.Claus

Rudolph

Flipper

lives_in

lives_in

lives_in

has_pet

has_pet

arrow = relationship

label = Propertyhas_

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 bnick_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 OWLWhere 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 Classowl:Thing (everything)

owl:Nothing(nothing)

Animal (primitive named class)

hasDangerLevel some Dangerous(anonymous class - restriction)

DangerousAnimal (defined named class)

Primitive vs Defined

Blue ThingsSharks“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

memberEg 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 exampleExistential restriction on primitive class Shark:

necessarily hasMouthPart some Teeth

Shark Teeth

hasMouthPart

hasMouthPart

hasMouthPart

“Every member of the Shark class must have at least one mouthpart from the class Teeth”

An exampleExistential restriction on primitive class Shark:

necessarily hasMouthPart some Teeth

Shark Teeth

hasMouthPart

hasMouthPart

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, 2011. Paula Matuszek Some slides taken from www.cs.man.ac.uk/~drummond/.../IntroductionToOWL50mins.ppt

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 andeats some (Person and Seal)

Person Seal

Inconsistent = cannot contain any individuals

Disjoint (Person, Seal)Person and Seal = emptyCannot have some empty

Automatic ClassificationTrivial example

DangerousAnimal (defined class)Animal andhasMouthPart some Teeth

Shark (primitive class)Animal andhasMouthPart some Fangs

Teeth

Fangs

24


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


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


Reasoning About The Pizza Ontology: At the end of exercise 23 we have:


27


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


Inconsistent Ontology


29


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


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


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


Inferred Hierarchy


35


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


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


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


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


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


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


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


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: http://www.co-ode.org/downloads/pizzafinder/


1 CSC 9010 Spring, 2011. Paula MatuszekSome slides taken from...

Documents

Transcript of 1 CSC 9010 Spring, 2011. Paula MatuszekSome slides taken from...