Ontology engineering
Valentina Tamma
Based on slides by A. Gomez Perez, N. Noy, D. McGuinness,
E. Kendal, A. Rector and O. Corcho
Content
•
•
•
•
•
Background on ontology;
Ontology and ontological commitment;
Logic as a form of representation;
Ontology development phases;
Modelling problems and patterns
– N-ary relationships
– Part whole relationships
What Is “Ontology Engineering”?
Ontology Engineering:
Defining terms in the domain and relations among them
– Defining concepts in the domain (classes)
– Arranging the concepts in a hierarchy (subclass-superclass
hierarchy)
– Defining which attributes and properties (slots) classes can
have and constraints on their values
– Defining individuals and filling in slot values
Methodological Questions
– How can tools and techniques best be applied?
– Which languages and tools should be used in which
circumstances, and in which order?
– What about issues of quality control and resource
management?
• Many of these questions for ontology engineering have been
studied in other contexts
– E.g. software engineering, object-oriented design, and
knowledge engineering
Historical context
Philosophy
Ontology
Artificial
Intelligence
Knowledge
Representation
and logic
Philosophical roots
• Socrates questions of being, Plato’s studies of
epistemology:
– the nature of knowledge
• Aristotle’s classifications of things in the world
and contribution to syllogism and inductive
inference:
– logic as a precise method for reasoning about
knowledge
• Anselm of Canterbury and ontological arguments
deriving the existence of God
• Descartes, Leibniz, …
In computer science…
• Cross-disciplinary field with historical roots in
philosophy, linguistics, computer science, and
cognitive science
• The goal is to provide an unambiguous
description of the concepts and relationships
that can exist for an agent or a community of
agent, so they can understand, share, and use
this description to accomplish some task on
behalf of users
So what is an ontology then?
An ontology is a (formal), explicit specification of a shared conceptualisation
formal: an ontology
should be machinereadable
shared: an ontology
captures consensual
knowledge, that is not
private to some
individual, but
accepted by a group
explicit: the types of
concepts used, and the
constraints on their use
are explicitly defined
conceptualisation: an abstract
model of some phenomenon in
the world which identifies the
relevant concepts of that
phenomenon
T. Gruber, 1993; R. Studer, V. R. Benjamins, and D.
Fensel, 1998
What is a conceptualisation
• Conceptualisation: the formal structure of reality as perceived
and organized by an agent, independently of:
– the vocabulary used (i.e., the language used)
– the actual occurrence of a specific situation
• Different situations involving the same objects, described by
different vocabularies, may share the same conceptualisation.
apple
mela
Logic as a representation formalism
• Predicate logic is more precise than natural
language, but it is harder to read:
– “Every trailer truck has 18 wheels”
(x)((truck(x)(y)(trailer(y)(hasPart(x,y)))
(s)(set(s)(count(s,18))
(w)(member(w,s) (wheel(w)hasPart(x,w)))))
From John F. Sowa: Knowledge Representation: Logical,
Philosophical, and Computational Foundations,
Brooks/Cole, 2000.
Logic as a representation formalism
• Logic is a simple language with few basic
symbols.
• The granularity of representation depends on
the choice of predicates – i.e. an ontology of
the relevant concepts in the domain.
• Different choices of predicates (with different
interpretations) represent different
ontological commitments.
From John F. Sowa: Knowledge Representation: Logical,
Philosophical, and Computational Foundations,
Brooks/Cole, 2000.
Ontological commitment
Agreement on the meaning of the vocabulary used to share
knowledge.
We need a
pipe
A pipe ?!?
Knowledge engineering
• Knowledge engineering is the application of
logic and ontology to the task of building
computable models of some domain for some
purpose. – John Sowa
Level of Granularity
An ontology specifies a rich description of the:
• Terminology, concepts, vocabulary
• Properties explicitly describing concepts
• Relations among concepts
• Rules distinguishing concepts, refining definitions and
relations (constraints, restrictions, regular expressions)
relevant to a particular domain or area of interest.
Based on the AAAI’99 Ontology
Panel – McGuinness, Welty,
Uschold, Gruninger, Lehman
Ontology based information systems
• Ontologies provide a common vocabulary and
definition of rules defining the use of the
ontologies by independently developed
resources, processes, services
• Agreements among companies, organizations
sharing common services can be achieved
with regard to their usage and the meaning of
relevant concepts can be expressed
unambiguously
Ontology based information systems
• By composing component ontologies,
mapping ontologies to one another and
mediating terminology among participating
resources and services, independently
developed systems, agents and services can
work together to share information and
processes consistently, accurately, and
completely.
Ontology based information systems
• Ontologies also facilitate conversations among
agents to collect, process, merge, and
exchange information.
• Improve search accuracy by enabling
contextual search through the use of concept
definitions and relations among them.
• Used instead of/in addition to statistical
relevance of keywords.
Ontology design process
Requirement
and domain
analysis
Determine
scope
Consider
reuse
Enumerate
terms
Define
classes
Define
properties
Define
constraints
Really more like…
Add
Instances
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Requirement analysis
Performing Requirements, Domain & Use Case Analysis is a
critical stage as in any software engineering design. It allows
ontology engineers to ground the work and prioritise.
The analysis has to elicit and make explicit:
• The nature of the knowledge and the questions
(competency questions) that the ontology (through a
reasoner) needs to answer. This process is crucial for scoping
and designing the ontology, and for driving the architecture;
• Architectural issues;
• The effectiveness of using traditional approaches with
knowledge intensive approaches;
Aim:
The main goal of this phase is to support the application in dealing with:
– Changing assumptions
– Hypothesis generation (analogy)
– System evolution, or dynamic knowledge evolution - where time
and situations change necessitating re-evaluation of assumptions
– Support for interoperation with other (potentially legacy) systems
− Generation of explanation for dialogue generation – facilitate
interface with users
− Standardization of terminology: to reflect the engineers different
backgrounds
Separation of concerns is crucial when dealing with knowledge
• Declarative domain knowledge (what?) needs to be treated differently
from procedural knowledge (how?)
– Ontologies vs Problem solving methods
• Background (unchanging) knowledge from changing information
• Provenance and level of trust of knowledge
Application requirements
Application requirements can be acquired by:
• Identifying any controlled vocabulary used in the application;
• Identifying hierarchical or taxonomic structures intrinsic in the domain
that might be used for query expansion:
– Vegetarian pizza such as: margherita, funghi, grilled vegetables
pizza
• Analysing structured queries and the knowledge they require
• Expressive power required: Efficient inference (requiring limited
expressive power) vs. increased expressivity (requiring expensive or
resource bounded computation)
• Ad-hoc reasoning to deal with particular domain requirements:
– temporal relations, geospatial, process-specific, conditional
operations
• Computational tractability
• Need for Explanations, Traces, Provenance
Domain requirements
• Take into account heterogeneity, distribution, and autonomy needs
– software agents based applications;
• Open vs. Closed World (does lack of information imply negative
information?)
• Static vs dynamic ontology processes:
– Evolution, alignment
• Limited or incomplete knowledge
• Knowledge evolution over time
• Analysis and consistency checking of instance data
• Use Case analysis should facilitate the understanding of:
– The information that is likely to be available
– The questions that are likely to be asked
– Types and roles of users
Conceptual modelling
“A data model describes data, or database schemas – an ontology
describes the world”
Adam Farquhar, “Ontology 101”, Stanford University, 1997
•
Resources and their relationships are described from an objective
standpoint, and they do not reflect the definitions in databases, or
the views of programmers.
– Experts from different backgrounds with significant domain knowledge –
will classify knowledge differently from someone interested in
optimization of algorithms, or forcing information into an existing
framework, or legacy applications
• Shortcuts at the top levels do not help; automation and mapping
among ontologies and terminology at lower levels provides significant
benefit
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Determine ontology scope
Addresses straight forward questions such as:
• What is the ontology going to be used for
• How is the ontology ultimately going to be
used by the software implementation?
• What do we want the ontology to be aware of,
and what is the scope of the knowledge we
want to have in the ontology?
Competency Questions
• Which investigations were done with a high-fatdiet study?
• Which study employs microarray in combination
with metabolomics technologies?
• List those studies in which the fasting phase had
as duration one day.
• What is a vegetarian pizza?
• What type of wine can accompany seafood?
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Consider Reuse
• We rarely have to start from scratch when
defining an ontology:
– There is almost always an ontology available from a
third party that provides at least a useful starting
point for our own ontology
• Reuse allows to:
– to save the effort
– to interact with the tools that use other ontologies
– to use ontologies that have been validated through
use in applications
Consider Reuse
• Standard vocabularies are available for most domains,
many of which are overlapping
• Identify the set that is most relevant to the problem and
application issue
• A component-based approach based on modules facilitates
dealing with overlapping domains:
– Reuse an ontology module as one would reuse a software
module
– Standards; complex relationships are defined such that term
usage and overlap is unambiguous and machine interpretable
• Initial brainstorming with domain experts can be highly
productive; then subsequent refinement and iteration lead
to the level required by the application
What to Reuse?
• Ontology libraries
– DAML ontology library (www.daml.org/ontologies)
– Protégé ontology library (protege.stanford.edu/plugins.html)
• Upper ontologies
– IEEE Standard Upper Ontology (suo.ieee.org)
– Cyc (www.cyc.com)
• General ontologies
– DMOZ (www.dmoz.org)
– WordNet (www.cogsci.princeton.edu/~wn/)
• Domain-specific ontologies
– UMLS Semantic Net
– GO (Gene Ontology) (www.geneontology.org)
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Enumerate terms
• Write down in an unstructured list all the relevant
terms that are expected to appear in the ontology
– Nouns form the basis for class names
– Verbs (or verb phrases) form the basis for property
names
• Card sorting is often the best way:
–
–
–
–
–
Write down each concept/idea on a card
Organise them into piles
Link the piles together
Do it again, and again
Works best in a small group
Example: animals & plants ontology
•
•
•
•
•
•
•
•
•
Dog
Cat
Cow
Person
Tree
Grass
Herbivore
Male
Female
•
•
•
•
•
•
•
•
Carnivore
Plant
Animal
Fur
Child
Parent
Mother
Father
•
•
•
•
•
•
•
•
•
Dangerous
Pet
Domestic Animal
Farm animal
Draft animal
Food animal
Fish
Carp
Goldfish
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Define classes and their taxonomy
•
•
•
•
A class is a concept in the domain:
– Animal (cow, cat, fish)
– A class of properties (father, mother)
A class is a collection of elements with similar
properties
A class contains necessary conditions for
membership (type of food, dwelling)
Instances of classes
– A particular farm animal, a particular person
– Tweety the penguin
Organise the concepts
Example: Animals & Plants
•
•
•
•
•
•
•
•
•
Dog
Cat
Cow
Person
Tree
Grass
Herbivore
Male
Female
•
•
•
•
•
•
•
•
Carnivore
Plant
Animal
Fur
Child
Parent
Mother
Father
•
•
•
•
•
•
•
•
•
Healthy
Pet
Domestic Animal
Farm animal
Draft animal
Food animal
Fish
Carp
Goldfish
38
Extend the concepts: “Laddering”
• Take a group of things and ask what they have in
common
– Then what other ‘siblings’ there might be
• e.g.
– Plant, Animal  Living Thing
• Might add Bacteria and Fungi but not now
– Cat, Dog, Cow, Person  Mammal
• Others might be Goat, Sheep, Horse, Rabbit,…
– Cow, Goat, Sheep, Horse  Hoofed animal (“Ungulate”)
• What others are there? Do they divide amongst themselves?
– Wild, Domestic  Domestication
• What other states – “Feral” (domestic returned to wild)
39
Choose some main axes
• Add abstractions where needed
– e.g. “Living thing”
• identify relations (this feeds into the next
step)
– e.g. “eats”, “owns”, “parent of”
• Identify definable things
– e.g. “child”, “parent”, “Mother”, “Father”
• Things where you can say clearly what it means
– Try to define a dog precisely – very difficult
» A “natural kind”
• make names explicit
40
Example
• Living Thing
– Animal
• Mammal
–
–
–
–
Cat
Dog
Cow
Person
• Fish
– Carp
– Goldfish
– Plant
• Tree
• Grass
• Fruit
•

Modifiers
– domestic
• pet
• Farmed
– Draft
– Food
– Wild
– Health
• healthy
• sick
– Sex
• Male
• Female
– Age
• Adult
• Child

Relations
 eats
 owns
 parent-of
 …
Definable








Carinvore
Herbivore
Child
Parent
Mother
Father
Food Animal
Draft Animal
41
Identify self-standing entities
• Things that can exist on there own
– People, animals, houses, actions, processes, …
• Roughly nouns
• Modifiers
– Things that modify (“inhere”) in other things
• Roughly adjectives and adverbs
42
Reorganise everything but “definable” things into
pure trees – these will be the “primitives”
•
• Self_standing
• Animal
– Mammal
Cat
Dog
Cow
Person
Pig
– Fish
» Carp
Goldfish
• Plant
– Tree
– Grass
– Fruit

Relations
 eats
 owns
 parent-of
 …

Definables
– Domestication
– Living Thing
»
»
»
»
»
Modifiers
• Domestic
• Wild
– Use
• Draft
• Food
• pet
– Risk
• Dangerous
• Safe
– Sex
• Male
• Female
– Age
• Adult
• Child








Carnivore
Herbivore
Child
Parent
Mother
Father
Food Animal
Draft Animal
43
Comments can help to clarify
• Self_standing
– Living Thing
– Abstract ancestor concept including all living
things – restrict to plants and animals for now
• Animal
– Mammal
»
»
»
»
»
Cat
Dog
Cow
Person
Pig
– Fish
» Carp
Goldfish
• Plant
– Tree
– Grass
– Fruit
44
Class inheritance
• Classes are organized into subclass-superclass (or generalizationspecialization)
Hierarchies:
• Classes are “is-a” related if an instance of the subclass is an
instance of the superclass
– Classes may be viewed as sets
– Subclasses of a class are comprised of a subset of the superset
• Examples
– Mammal is a subclass of Animal
– Every penguin is a bird or every instance of a penguin (like Tweety is an
instance of bird
– Draft animal is a subclass of Animal
Levels in the class hierarchy
• Different modes of development
– Top-down - define the most general concepts first
and then specialize them
– Bottom-up - define the most specific concepts and then
organize them in more general classes
– Combination (typical – breadth at the top level and depth
along a few branches to test design)
• Class inheritance is Transitive
– A is a subclass of B
– B is a subclass of C
– therefore A is a subclass of C
Levels in the class hierarchy
Top
level
Middle
level
Bottom
level
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Define properties
• Often interleaved with the previous step
• Properties (or roles in DL) describe the
attributes of the members of a class
• The semantics of subClassOf demands that
whenever A is a subclass of B, every property
statement that holds for instances of B must
also apply to instances of A
– It makes sense to attach properties to the highest
class in the hierarchy to which they apply
Define properties
• Types of properties
– “intrinsic” properties: flavor and color of wine
– “extrinsic” properties: name and price of wine
– parts: ingredients in a dish
– relations to other objects: producer of wine (winery)
• They are represented by data and object properties
– simple (datatype) contain primitive values (strings,
numbers)
– complex properties contain other objects (e.g., a
winery instance)
Modifiers and relations
•
Modifiers
– Domestication
• Domestic
• Wild
– Use
• Draft
• Food
• pet

Relations
 eats
 owns
 parent-of
 …
– Risk
• Dangerous
• Safe
– Sex
• Male
• Female
– Age
• Adult
• Child
51
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Identify the domain and range
constraints for properties
• Animal eats Living_thing
– eats domain: Animal;
range: Living_thing
• Person owns Living_thing except person
– owns domain: Person
range: Living_thing & not Person
• Living_thing parent_of Living_thing
– parent_of: domain: Living_thing
range: Living_thing
53
If anything is used in a special way,
add a text comment
• Animal eats Living_thing
– eats domain: Animal;
range: Living_thing
—
ignore difference between
parts of living things
and living things
also derived from living
things
54
For definable things
• Paraphrase and formalise the definitions in terms of the
primitives, relations and other definables.
• Note any assumptions to be represented elsewhere.
– Add as comments when implementing
• “A ‘Parent’ is an animal that is the parent of some other animal”
(Ignore plants for now)
– Parent =
Animal and parent_of some Animal
• “A ‘Herbivore’ is an animal that eats only plants”
(NB All animals eat some living thing)
– Herbivore=
Animal and eats only Plant
• “An ‘omnivore’ is an animal that eats both plants and animals”
– Omnivore=
Animal and eats some Animal and eats some Plant
55
Which properties can be filled in
at the class level now?
• What can we say about all members of a
class?
– eats
• All cows eat some plants
• All cats eat some animals
• All pigs eat some animals &
eat some plants
56
Fill in the details
(can use property matrix wizard)
57
Check with classifier
• Cows should be Herbivores
– Are they? why not?
• What have we said?
– Cows are animals and, amongst other things,
eat some grass and
eat some leafy_plants
• What do we need to say:
Closure axiom
– Cows are animals and, amongst other things,
eat some plants and eat only plants
58
Closure Axiom
Cows are animals and, amongst other things,
eat some plants and eat only plants
Closure
Axiom
59
In the tool
• Right mouse button
short cut for closure
axioms
– for any existential
restriction
adds closure
axiom
60
Open vs Closed World reasoning
• Open world reasoning
– Negation as contradiction
• Anything might be true unless it can be proven false
– Reasoning about any world consistent with this one
• Closed world reasoning
– Negation as failure
• Anything that cannot be found is false
– Reasoning about this world
• Ontologies are not databases
61
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Creating instances
• Create an instance of a class
– The class becomes a direct type of the instance
– Any superclass of the direct type is a type of the
instance
• Assign slot values for the instance frame
– Slot values should conform to the facet constraints
– Knowledge-acquisition tools often check that
constraints are satisfied
Creating instances
• Filling the ontologies with such instances is a
separate step
• Number of instances >> number of classes
• Thus populating an ontology with instances is
not done manually
– Retrieved from legacy data sources (DBs)
– Extracted automatically from a text corpus
Ontology design process
Requirement
and domain
analysis
Determine
scope
Add Instances
Define
constraints
Consider reuse
Define
properties
Enumerate
terms
Define classes
Ontology editors
Help with:
• Initial conceptual modelling
• Use of Description Logic to represent classes,
properties, and restrictions.
– Error detection and consistency checking while
writing an ontology
Several editors now available, we use Protégé 4
Remember DL?
Protégé 4
It’s not easy…
• Even those domains that seem simple and
uncomplicated require a careful analysis and
their modelling requires careful consideration
• Common problems have been addressed by
W3C SWBP cookbook style documents and
the definition of ontology patterns
• Some useful hints follow
Normalisation and Untangling
Let the reasoner do multiple classification
• Tree
– Everything has just one parent
• A ‘strict hierarchy’
• Directed Acyclic Graph (DAG)
– Things can have multiple parents
• A ‘Polyhierarchy’
• Normalisation
– Separate primitives into disjoint trees
– Link the trees with definitions & restrictions
• Fill in the values
– Let the classifier produce the DAG
70
Tables are easier to manage than
DAGs / Polyhierarchies
…and get the benefit of inference:
Grass and Leafy_plants are both kinds of Plant
71
Remember to add any closure
axioms
Closure
Axiom
Then let the reasoner do the work
72
Normalisation:
From Trees to DAGs

Before classification

A tree

After classification

A DAG

Directed Acyclic Graph
73
Common traps of restrictions
• ‘Some’ does not imply only
‘Only’ does not imply some’
• Trivial satisfaction of universal restrictions
• Domain and Range Constraints
• What to do when it all turns red
– Don’t panic!
74
someValuesFrom means “some”
• someValuesFrom means “some”
– means “at least 1”
• Dog_owner complete:
Person and hasPet someValuesFrom Dog
– means:
A Pet_owner is any person who has as a pet some (i.e.
at least 1) dog
• Dog_owner partial
Person and hasPet someValuesFrom Dog
– means
All Pet_owners are people and have as a pet some
(i.e. at least 1) dog.
75
allValuesFrom means “only”
• allValuesFrom means “only”
– means “no values except”
• First_class_lounge complete
Lounge and hasOccupants allValuesFrom
FirstClassPassengers
– Means
“A ‘first class lounge’ is any lounge where the
occupants are only first class passengers” or
“A first ‘class lounge’ is any lounge where there are
no occupants except first class passengers”
76
allValuesFrom means “only”
• First_class_lounge partial
Lounge and hasOccupants allValuesFrom
FirstClassPassengers
– Means
“All first class lounges have only occupants who are
first class passengers”
“All first class lounges have no occupants except
first class passengers”
“All first class lounges have no occupants who are
not first class passengers”
77
“Some” does not mean “only”
• A “dog owner” might also own cats, and turtles, and parrots,
and…
– It is an open world, if we want a closed world we must add a
closure restriction or axiom
• Dog_only_owner complete
Person and hasPet someValuesFrom Dog and
hasPet allValuesFrom Dog
• A “closure restriction” or “closure axiom”
– The problem in making margherita pizza a veggie pizza
– Closure axioms use ‘or’ (disjunction)
– dog_and_cat_only_owner complete
hasPet someValuesFrom Dog and
hasPet someValuesFrom Cat and
78
hasPet allValuesFrom (Dog or Cat)
“Only” does not mean “some”
• There might be nobody in the first class lounge
– That would still satisfy the definition
– It would not violate the rules
• A pizza with no toppings satisfies the definition of a
vegetarian pizza
– Pizza & has_topping_ingredient allValuesFrom
Vegetarian_topping
• It has no toppings which are meat
– It has not toppings which are not vegetables
» It has no toppings which aren’t fish…
79
“Only” does not mean “some”
•
– Analogous to the empty set is a subset of all
sets
• One reason for a surprising subsumption
is that you have made it impossible for
there to be any toppings
–allValuesFrom (cheese and tomato)
80
Trivial Satisfiability
• A universal (‘only’) restriction with an
unsatisfiable filler is “trivially satisfiable”
– i.e. it can be satisfied by the case where there
is no filler
• If there is an existential or min-cardinality
restriction, inferred or explicit, then the
class will be unsatisfiable
–Can cause surprising ‘late’ bugs
81
Domain & Range Constraints
• Domain and range constraints are axioms too
– Property P range( RangeClass)
means
• owl:Thing
restriction(P allValuesFrom
RangeClass)
– Property P domain( DomainClass )
means
• owl:Thing
restriction(inverse(P) allValuesFrom
DomainClass)
82
What happens if violated
• Property eats range( LivingThing)
means
– owl:Thing
restriction(P allValuesFrom LivingThing)
• Bird eats some Rock
– All StoneEater eats some rocks
• What does this imply about rocks?
– Some rocks are living things
– because only living things can be eaten
– What does this say about “all rocks”?
83
Domain & Range Constraints
• Property eats domain( LivingThing )
means
– owl:Thing
restriction(inverse(eats) allValuesFrom LivingThing)
– “Only living things eat anything”
• StoneEater eats some Stone
– All StoneEaters eat some Stone
• Therefore All StoneEaters are living things
– If StoneEaters are not already classified as living
things, the classifier will reclassify (‘coerce’) them
– If StoneEaters is disjoint from LivingThing it will be
found disjoint
84
Example of Coercion by Domain violation
• has_topping: domain(Pizza) range(Pizza_topping)
class Ice_cream_cone
has_topping some Ice_cream
If Ice_cream_cone and Pizza are not disjoint:
– Ice_cream_cone is classified as a kind of Pizza
…but: Ice_cream is not classified as a kind of
Pizza_topping
– Have shown that:
all Ice_cream_cones are a
kinds of Pizzas,
but only that:
some Ice_cream is a kind of
Pizza_topping
85
Reminder
Subsumption means necessary implication
• “B is a kind of A”
means
“All Bs are As”
– “Ice_cream_cone is a kind of Pizza”
means
“All ice_cream_cones are pizzas”
– From “Some Bs are As” we can deduce very little of
interest in DL terms
» “some ice_creams are pizza_toppings”
says nothing about “all ice creams”
86
Summary:Domain & Range Constraints
Non-Obvious Consequences
• Range constraint violations – unsatisfiable or ignored
– If filler and RangeClass are disjoint: unsatisfiable
– Otherwise nothing happens!
• Domain constraint violations – unsatisfiable or coerced
– If subject and DomainClass are disjoint: unsatisfiable
– Otherwise, subject reclassified (coerced) to kind of DomainClass!
• Furthermore cannot be fully checked before classification
– although tools can issue warnings.
87
What to do when “Its all turned red”
Don’t Panic!
• Unsatisfiability propagates – so trace it to its source
– Any class with an unsatisfiable filler in a someValuesFor
(existential) restriction is unsatisfiable
– Any subclass of an unsatisfiable class is unsatisfiable
– Therefore errors propagate, trace them back to their
source
• Only a few possible sources
– Violation of disjoint axioms
– Unsatisfiable expressions in some restrictions
• Confusion of “and” and “or”
– Violation of a universal (allValuesFrom) constraint
(including range and domain constraints)
• Unsatisfiable domain or range constraints
88
Saying something about a restriction
• Not just
– that an animal is dangerous,
– but why
– And how dangerous
– And how to avoid
• But can say nothing about properties
– except special thing
• Super and subproperties
• Functional, transitive, symmetric
89
Re-representing properties as classes
• To say something about a property it must be rerepresented as a class
– property:has_danger  Class: Risk
• plus property: Thing has_quality Risk
• plus properties: Risk has_reason
has_risk_type
has_avoidance_measure
– Sometimes called “reification”
• But “reification” is used differently in different
communities
90
Re-representing the property has_danger as
the class Risk
Animal
Animal
has_danger
has_Quality
Risk
Dangerous
has_seriousness
Seriousness
Avoidance
91
Lions are dangerous
• All lions pose a deadly risk of physical attack
that can be avoided by physical separation
• All lions have the quality risk that is
– of type some physical attack
– of seriousness some deadly
– has avoidance means some physical separation
92
Can add a second definition of
Dangerous Animal
• A dangerous animal is any animal that has the quality Risk
that is Deadly
– or
• Dangerous_animal =
– Animal
has_quality some
(Risk AND has_seriousness some Deadly )
– [NB: “that” paraphrases as “AND”]
93
In the tool
• Dangerous_animal =
– Animal
has_quality some
(Risk AND has_seriousness some Deadly )
94
This says that
• Any animal that is Dangerous
is also
An animal that has the quality Risk
with the seriousness Deadly
95
Anopheles Mosquitos now count as
dangerous
– Because they have a deadly risk of carrying
disease
96
Multiple definitions are dangerous
• Better to use one way or the other
– Otherwise keeping the two ways consistent is
difficult
– … but ontologies often evolve so that
simple Properties are re-represented
as Qualities
• Then throw away the simple property
97
Often have to re-analyse
• What do we mean by “Dangerous”
– How serious the danger?
– How probable the danger?
– Whether from individuals (Lions) or the presence or
many (Mosquitos)?
• Moves to serious questions of “ontology”
– The information we really want to convey
• Often a sign that we have gone to far
– So we will stop
98
More Patterns:
N-ary relations
99
N-ary relations
from http://www.w3.org/TR/swbp-n-aryRelations/
•
•
•
In OWL a property is a binary relation: instances of properties link two
individuals (or an individual and a value)
However, sometimes the most intuitive way to represent certain concepts is
to use relations to link an individual to more than just one individual or
value. Such relations are called n-ary relations.
Some issues:
– If property instances can link only two individuals, how do we deal with
cases where we need to describe the instances of relations ?
– If instances of properties can link only two individuals, how do we
represent relations among more than two individuals? ("n-ary
relations")
Pattern 1
– If instances of properties can link only two individuals, how do we
represent relations in which one of the participants is an ordered list of
individuals rather than a single individual? Pattern 2
Examples
•
•
•
•
Christine has breast tumor with high probability
– A relation initially thought to be binary, needs a further argument
Steve has temperature, which is high, but falling
– Two binary properties turn out to always go together and should be
represented as one n-ary relation
John buys a "Lenny the Lion" book from books.example.com for $15 as a
birthday gift
– From the beginning the relation is really amongst several things
United Airlines flight 3177 visits the following airports: LAX, DFW, and JFK
– One or more of the arguments is fundamentally a sequence rather than
a single individual
Can you think of some more examples?
Pattern 1, N-ary relations
•
•
•
Represent the relation as a class rather than a property
– Individual instances of such classes correspond to instances of
the relation
– Additional properties provide binary links to each argument of
the relation
Basic idea: create a new class and new properties to represent an nary relation; then an instance of the relation linking the n individuals
is then an instance of this class.
The classes created in this way are often called "reified relations"
Pattern 1 case 1
Additional attributes describing a relation:
• In this case we need to represent an additional
attribute that represents a relation instance
– Ex: Christine has breast tumor with high probability
• The solution is to create an individual that represents
the relation instance itself, with links from the subject
of the relation to this instance, and with links from this
instance to all participants that represent additional
information about this instance
Pattern 1, Example 1
Example: Christine has breast tumor with high probability
The individual _:Diagnosis_Relation_1here represents a single object encapsulating
both the diagnosis (Breast_Tumor_Christine) and the probability of the diagnosis
(HIGH)
- It contains all the information held in the original 3 arguments: who is being
diagnosed, what the diagnosis is, and what the probability is
- Blank nodes (rdf:Description element that does not have an rdf:about
attribute assigned to it) in RDF are used to represent instances of a relation.
Class definitions:
Pattern 1 case 2
Different aspects of the same relation:
• In this case we need to represent the relation between an
individual, and an object that represents different aspects
of a property (relation) about the individual
– Ex: Steve has temperature which is high but falling
• This instance of a relation cannot be viewed as an instance
of a binary relation with additional attributes attached to it.
• It is a relation instance relating the individual and the
complex object representing different facts about the
specific relation between the individual and the object.
Pattern 1, Example 2
Example: Steve has temperature, which is high, but falling
•This cannot be viewed as an instance of a binary relation with additional
attributes attached to it, but rather it is a relation instance relating the individual
Steve and the complex object representing different facts about his temp
Such cases often come about in the course of evolution of an ontology when it is
realized that two relations need to be collapsed.
•For example, initially, one might have had two properties (e.g.
has_temperature_level and has_temperature_trend) both relating to people,
and then it is realized that these properties really are inextricably intertwined
because one needs to talk about "temperatures that are elevated but falling"
Pattern 1 case 3
N-ary relation with no distinguished participant:
• In some cases the n-ary relationship links individuals
that play different roles in a structure without any
single individual standing out as the “owner” or the
relation
– Ex: John buys a "Lenny the Lion" book from
books.example.com for $15 as a birthday gift
• The solution is to create an individual that represents
the relation instance with links to all participants
Pattern 1, Example 3
Example: John buys a "Lenny the Lion" book from books.example.com for $15 as a
birthday gift
•The relation explicitly has more than one participant, and, in many contexts,
none of them can be considered a primary one, thus an individual is created to
represent the relation instance with links to all participants:
Considerations in introducing a new
class
• We did not give meaningful names to instances of
properties or to the classes used to represent instances
of n-ary relations, but merely label them.
• In most cases, these individuals do not stand on their
own but merely function as auxiliaries to group together
other objects. Hence a distinguishing name serves no
purpose. Note that a similar approach is taken when
reifying statements in RDF.
• Creating a class to represent an n-ary relation limits the
use of many OWL constructs and creates a maintenance
problem, especially when dealing with inverse relations.
Pattern 2
Using lists for arguments in a relation
• Some n-ary relations do not naturally fall into either of the
use cases above, but are more similar to a list or sequence of
arguments.
• Example: United Airlines flight 3177 visits the following
airports: LAX, DFW, and JFK
• The relation holds between the flight and the airports it
visits, in the order of the arrival of the aircraft at each airport
in turn.
• This relation might hold between many different numbers of
arguments, and there is no natural way to break it up into a
set of distinct properties relating the flight to each airport.
The order of the arguments is highly meaningful.
Pattern 2, N-ary relations
Example: United Airlines flight 3177 visits the following airports: LAX, DFW, and JFK
•Basic idea: when all but one participant in a relation do not have a specific role
and essentially form an ordered list, it is natural to connect these arguments into a
sequence according to some relation, and to relate the one participant to this
sequence (or the first element of the sequence)
nextSegment is an ordering relation between
instances of the FlightSegment class; each flight
segment has a property for the destination of
that segment
•A special subclass of flight segment,
FinalFlightSegment is added with a maximum
cardinality of 0 on the nextSegment property, to
indicate the end of the sequence.
Additional resources
•
•
•
•
•
•
W3C Working Group Note -Defining N-ary Relations on the Semantic
Web
http://www.w3.org/TR/swbp-n-aryRelations
W3C Semantic Web Best Practices and Deployment Working Group
http://www.w3.org/2001/sw/BestPractices/
General references on Semantic Web
http://www.w3.org/2001/sw/
+ many other resources/tutorials on the Web
More Patterns:
Part-whole relations
113
Part-whole relations
One method: NOT a SWBP draft
• How to represent part-whole relations in OWL
is a commonly asked question
• SWBP has published a draft
– http://www.w3.org/2001/sw/BestPrac
tices/OEP/SimplePartWhole
• This is one approach that will be proposed
– It has been used in teaching
– It has no official standing
114
Part Whole relations
• OWL has no special constructs
– But provides the building blocks
• Transitive relations
– Finger is_part_of Hand
Hand is_part_of Arm
Arm is_part_of Body
•
–
Finger is_part_of Body
115
Implementation Pattern
Transitive properties with non-transitive “direct”
subproperties
• Transitive properties should have non-transitive children
– isPartOf : transitive
isPartOfDirectly : non-transitive
• Split which is used in partial descriptions and complete definitions
– Necessary conditions use non-transitive version
– Definitions use transitive version
• Benefits
– Allows more restrictions in domain/range constraints and cardinality
• Allows the hierarchy along that axis to be traced one step at a time
• Allow a good approximation of pure trees
– Make the nontransitive subproperty functional
» Transitive properties can (almost) never be functional
(by definition, a transitive property has more than one value in any nontrivial system)
• Constraints on transitive properties easily lead to unsatisfiability
116
Many kinds of part-whole relations
• Physical parts
– hand-arm
• Geographic regions
– Hiroshima - Japan
• Functional parts
– cpu – computer
• See Winston & Odell
Artale
Rosse
117
Simple version
• One property is_part_of
– transitive
• Finger is_part_of some Hand
Hand is_part_of some Arm
Arm is_part_of some Body
118
Get a simple list
• Probe_part_of_body =
Domain_category
is_part_of some Body
• Logically correct
– But may not be what we want
to see
119
Injuries, Faults, Diseases, Etc.
• A hand is not a kind of a body
– … but an injury to a hand is a kind of injury to
a body
• A motor is not a kind of automobile
– … but a fault in the motor is a kind of fault in
the automobile
• And people often expect to see partonomy hierarchies
120
Using part-whole relations: Defining
injuries or faults
•
•
•
Injury_to_Hand =
Injury has_locus some Hand_or_part_of_hand
Injury_to_Arm =
Injury has_locus some Arm_or_part_of_Arm
Injury_to_Body =
Injury has_locus some Body_or_part_of_Body
• The expected
hierarchy from
point of view of
anatomy
121
Parts & wholes:
Some examples
•
•
•
•
•
•
•
The leg is part of the chair
The left side of the body is part of the body
The liver cells are part of the liver
The ignition of part of the electrical system of the car
The goose is part of the flock
Liverpool r is part of England
Computer science is part of the University
122
Five families of relations
• Partonomic
– Parts and wholes
• The lid is part of the box
– Constitution
• The box is made of cardboard
– Membership?
• The box is part of the shipment
• Nonpartonomic
– Containment
• The gift is contained in the box
– Connection/branching/Adjacency
• The box is connected to the container by a strap
123
Some tests
• True kinds of part-of are transitive
– A fault to the part is a fault in the whole
– The finger nail is part of the finger is part of the hand is
part of the upper extremity is part of the body
• Injury to the fingernail is injury to the body
– The tail-light is part of the electrical system is part of
the car
• A fault in the tail light is a fault in the car
• Membership is not transitive
– The foot of the bird is part of the bird but not part of the
flock of birds
• Damage to the foot of the bird is not damage to the
flock of birds
124
Some tests
• Containment is transitive but things contained are not
necessarily parts
– A fault (e.g. souring) to the milk contained in the bottle
is not damage to the bottle
• Some kinds of part-whole relation are questionably
transitive
– Is the cell that is part of the finger a part of the body?
• Is damage to the cell that is part of the finger
damage to the body?
– Not necessarily, since the cells in my body die
and re-grow constantly
125
Structural parts
• The leg is a component of of the table
• Discrete
• connected,
• clear boundary,
• specifically named
• may be differently constituted
• Can have metal legs on a wooden table or vice versa
• The left side is a subdivision of the table
– ‘Side’, ‘Lobe’, ‘segment’, ‘region’,…
• Arbitrary, similarly constituted,
• components typically fall into one or another subdivision;
• defined in relation to something else;
• sensible to talk about what fraction it is: half the table, a
third of the table, etc.
126
Propagates_via / transitive_across
• Components of subdivisions are components of the
whole, but
subdivisions of components are not subdivisions of the
whole
– A the left side of the steering wheel of the car is not a subdivision
of the left side of the car (at least not in the UK)
• No consistent name for this relation between properties
– We shall call it propagates_via or transitive_across
• Also known as “right identities”
– Not supported in most DLs or OWL directly
• Although an extension to FaCT to support it exists
• Heavily used in medical ontologies (GRAIL and SNOMED-CT)
127
No simple solution:
Here’s one of several nasty kluges
• Component_of_table is defined as a component of table or any
subdivision of table
– Must do it for each concept
• A Schema rather than an axiom
– No way to say “same as”
– No variables in OWL
» or most DLs
• SCHEMA:
Components_of_X ≡
isComponentOf someValuesFrom
(X or (someValuesfrom isSubDivisionOf X))
– Tedious to do
• Schemas to be built into new tools
128
Functional parts
• Structural parts form a contiguous whole
– May or may not contribute to function
e.g. decorative parts, accidental lumps and bumps
• The remote control is part of the projection system
– May or may not be physically connected to it
• Part of a common function
• Biology examples:
– The endocrine system
• The glands are not connected, but form part of a
functioning system communicating via hormones and
transmitters
• The blood-forming system
– Bone marrow in various places, the spleen, etc. 129
If something is both a structural and
functional part…
• Must put in both restrictions explicitly
– Can create a common child property but this gets
complicated with the different kinds of structural
parts
130