Ontologyengineering (( - University of Liverpool...

Ontology engineering

Valen.na 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 representa.on;

•  Ontology development phases;

•  Modelling problems and paKerns – N-‐ary rela.onships – Part whole rela.onships

What Is “Ontology Engineering”?

Ontology Engineering: Defining terms in the domain and rela.ons among them

–  Defining concepts in the domain (classes)

–  Arranging the concepts in a hierarchy (subclass-‐superclass hierarchy)

–  Defining which aKributes and proper.es (slots) classes can have and constraints on their values

–  Defining individuals and filling in slot values

Methodological Ques.ons

–  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 ques.ons for ontology engineering have been

studied in other contexts –  E.g. so[ware engineering, object-‐oriented design, and

knowledge engineering

Historical context

Ontology

Philosophy

Knowledge Representa.on and logic

Ar.ficial Intelligence

Philosophical roots

•  Socrates ques.ons of being, Plato’s studies of epistemology: – the nature of knowledge

•  Aristotle’s classifica.ons of things in the world and contribu.on to syllogism and induc.ve 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, linguis.cs, computer science, and cogni.ve science

•  The goal is to provide an unambiguous descrip.on of the concepts and rela.onships that can exist for an agent or a community of agent, so they can understand, share, and use this descrip.on to accomplish some task on behalf of users

T. Gruber, 1993; R. Studer, V. R. Benjamins, and D. Fensel, 1998

So what is an ontology then? An ontology is a (formal), explicit specifica.on of a shared conceptualisa.on

explicit: the types of concepts used, and the constraints on their use are explicitly defined

shared: an ontology captures consensual knowledge, that is not private to some individual, but accepted by a group

conceptualisa.on: an abstract model of some phenomenon in the world which iden.fies the relevant concepts of that phenomenon

formal: an ontology should be machine-‐readable

What is a conceptualisa.on •  Conceptualisa.on: 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 situa*on

•  Different situa.ons involving the same objects, described by different vocabularies, may share the same conceptualisa.on.

apple

mela

Logic as a representa.on 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 Representa7on: Logical, Philosophical, and Computa7onal Founda7ons, Brooks/Cole, 2000.

•  Logic is a simple language with few basic symbols.

•  The granularity of representa.on depends on the choice of predicates – i.e. an ontology of the relevant concepts in the domain.

•  Different choices of predicates (with different interpreta.ons) represent different ontological commitments.

Logic as a representa.on formalism

From John F. Sowa: Knowledge Representa7on: Logical, Philosophical, and Computa7onal Founda7ons, 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 applica.on 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 descrip.on of the: •  Terminology, concepts, vocabulary

•  Proper.es explicitly describing concepts •  Rela.ons among concepts

•  Rules dis.nguishing concepts, refining defini.ons and rela.ons (constraints, restric.ons, regular expressions) relevant to a par.cular domain or area of interest.

Based on the AAAI’99 Ontology Panel – McGuinness, Welty, Uschold, Gruninger, Lehman

Ontology based informa.on systems

•  Ontologies provide a common vocabulary and defini.on of rules defining the use of the ontologies by independently developed resources, processes, services

•  Agreements among companies, organiza.ons sharing common services can be achieved with regard to their usage and the meaning of relevant concepts can be expressed unambiguously


•  By composing component ontologies, mapping ontologies to one another and media.ng terminology among par.cipa.ng resources and services, independently developed systems, agents and services can work together to share informa.on and processes consistently, accurately, and completely.


•  Ontologies also facilitate conversa.ons among agents to collect, process, merge, and exchange informa.on.

•  Improve search accuracy by enabling contextual search through the use of concept defini.ons and rela.ons among them.

•  Used instead of/in addi.on to sta.s.cal relevance of keywords.

Ontology design process

Requirement

and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Really more like…

Ontology design process Requirement

and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Requirement analysis Performing Requirements, Domain & Use Case Analysis is a cri.cal stage as in any so[ware engineering design. It allows ontology engineers to ground the work and priori.se.

The analysis has to elicit and make explicit: •  The nature of the knowledge and the ques.ons (competency ques7ons) 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 effec.veness of using tradi.onal approaches with knowledge intensive approaches;

Aim: The main goal of this phase is to support the applica.on in dealing with: – Changing assump.ons – Hypothesis genera.on (analogy) – System evolu.on, or dynamic knowledge evolu.on -‐ where .me

and situa.ons change necessita.ng re-‐evalua.on of assump.ons – Support for interopera.on with other (poten.ally legacy) systems − Genera.on of explana.on for dialogue genera.on – facilitate interface with users − Standardiza7on of terminology: to reflect the engineers different backgrounds

Separa.on of concerns is crucial when dealing with knowledge •  Declara.ve domain knowledge (what?) needs to be treated differently

from procedural knowledge (how?) –  Ontologies vs Problem solving methods

•  Background (unchanging) knowledge from changing informa.on •  Provenance and level of trust of knowledge

Applica.on requirements Applica.on requirements can be acquired by: •  Iden.fying any controlled vocabulary used in the applica.on;

•  Iden.fying 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 computa.on)

•  Ad-‐hoc reasoning to deal with par.cular domain requirements:

–  temporal rela.ons, geospa.al, process-‐specific, condi.onal opera.ons

•  Computa.onal tractability

•  Need for Explana.ons, Traces, Provenance

Domain requirements •  Take into account heterogeneity, distribu.on, and autonomy needs

–  so[ware agents based applica.ons; •  Open vs. Closed World (does lack of informa.on imply nega.ve

informa.on?) •  Sta.c vs dynamic ontology processes:

–  Evolu.on, alignment

•  Limited or incomplete knowledge •  Knowledge evolu.on over .me

•  Analysis and consistency checking of instance data •  Use Case analysis should facilitate the understanding of: – The informa.on that is likely to be available – The ques.ons 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 rela.onships are described from an objec.ve standpoint, and they do not reflect the defini.ons in databases, or the views of programmers. –  Experts from different backgrounds with significant domain knowledge –

will classify knowledge differently from someone interested in op.miza.on of algorithms, or forcing informa.on into an exis.ng framework, or legacy applica.ons

•  Shortcuts at the top levels do not help; automa.on and mapping among ontologies and terminology at lower levels provides significant benefit


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Determine ontology scope

Addresses straight forward ques.ons such as: •  What is the ontology going to be used for

•  How is the ontology ul.mately going to be used by the so[ware implementa.on?

•  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 Ques.ons

•  Which inves.ga.ons were done with a high-‐fat-‐diet study?

•  Which study employs microarray in combina.on with metabolomics technologies?

•  List those studies in which the fas.ng phase had as dura.on one day.

•  What is a vegetarian pizza? •  What type of wine can accompany seafood?


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

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 star.ng 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 applica.ons

Consider Reuse

•  Standard vocabularies are available for most domains, many of which are overlapping

•  Iden.fy the set that is most relevant to the problem and applica.on issue

•  A component-‐based approach based on modules facilitates dealing with overlapping domains: –  Reuse an ontology module as one would reuse a so[ware

module –  Standards; complex rela.onships are defined such that term

usage and overlap is unambiguous and machine interpretable •  Ini.al brainstorming with domain experts can be highly

produc.ve; then subsequent refinement and itera.on lead to the level required by the applica.on

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 Seman.c Net – GO (Gene Ontology) (www.geneontology.org)


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

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 sor.ng is o[en 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

•  Dangerous •  Pet •  Domes.c Animal

•  Farm animal

•  Dra[ animal •  Food animal

•  Fish •  Carp •  Goldfish

•  Carnivore •  Plant •  Animal

•  Fur •  Child •  Parent •  Mother •  Father


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Define classes and their taxonomy

•  A class is a concept in the domain: – Animal (cow, cat, fish) – A class of proper.es (father, mother)

•  A class is a collec.on of elements with similar proper.es

•  A class contains necessary condi.ons for membership (type of food, dwelling)

•  Instances of classes – A par.cular farm animal, a par.cular person – Tweety the penguin

38

Organise the concepts Example: Animals & Plants

•  Dog •  Cat

•  Cow

•  Person •  Tree

•  Grass

•  Herbivore •  Male

•  Female

•  Healthy •  Pet

•  Domes.c Animal

•  Farm animal •  Dra[ animal

•  Food animal

•  Fish •  Carp

•  Goldfish

•  Carnivore •  Plant •  Animal

•  Fur •  Child •  Parent •  Mother •  Father

39

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, Domes.c Domes.ca.on •  What other states – “Feral” (domes.c returned to wild)

40

Choose some main axes

•  Add abstrac.ons where needed – e.g. “Living thing”

•  iden.fy rela.ons (this feeds into the next step) – e.g. “eats”, “owns”, “parent of”

•  Iden.fy 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

41

Example

•  Living Thing –  Animal

•  Mammal –  Cat –  Dog –  Cow –  Person

•  Fish –  Carp –  Goldfish

–  Plant •  Tree •  Grass •  Fruit

•  Modifiers –  domes.c

•  pet •  Farmed

–  Dra[ –  Food

–  Wild –  Health

•  healthy •  sick

–  Sex •  Male •  Female

–  Age •  Adult •  Child

  Definable   Carinvore   Herbivore   Child   Parent   Mother   Father   Food Animal   Draft Animal

  Relations   eats   owns   parent-of   …

42

Iden.fy self-‐standing en..es

•  Things that can exist on there own – People, animals, houses, ac.ons, processes, …

•  Roughly nouns

•  Modifiers – Things that modify (“inhere”) in other things

•  Roughly adjec.ves and adverbs

43

Reorganise everything but “definable” things into pure trees – these will be the “primi.ves”

•  Self_standing –  Living Thing

•  Animal

–  Mammal »  Cat »  Dog »  Cow »  Person »  Pig

–  Fish »  Carp

Goldfish

•  Plant –  Tree –  Grass –  Fruit

•  Modifiers –  Domes.ca.on

•  Domes.c •  Wild

–  Use •  Dra[ •  Food •  pet

–  Risk •  Dangerous •  Safe



  Definables   Carnivore   Herbivore   Child   Parent   Mother   Father   Food Animal   Draft Animal


44

Comments can help to clarify

•  Self_standing –  Living Thing

•  Animal

–  Mammal »  Cat »  Dog »  Cow »  Person »  Pig

–  Fish »  Carp

Goldfish

•  Plant –  Tree –  Grass –  Fruit

–  Abstract ancestor concept including all living things – restrict to plants and animals for now

Class inheritance •  Classes are organized into subclass-‐superclass (or generaliza.on-‐

specializa.on)

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

–  Dra[ 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 –  BoKom-‐up -‐ define the most specific concepts and then organize them in more general classes

–  Combina.on (typical – breadth at the top level and depth along a few branches to test design)

•  Class inheritance is Transi.ve – A is a subclass of B – B is a subclass of C – therefore A is a subclass of C

Levels in the class hierarchy

Middle level

Top level

Bo:om level


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Define proper.es

•  O[en interleaved with the previous step •  Proper.es (or roles in DL) describe the aKributes of the members of a class

•  The seman.cs 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 aKach proper.es to the highest class in the hierarchy to which they apply

Define proper.es

•  Types of proper.es – “intrinsic” proper.es: flavor and color of wine – “extrinsic” proper.es: name and price of wine – parts: ingredients in a dish – rela.ons to other objects: producer of wine (winery)

•  They are represented by data and object proper.es – simple (datatype) contain primi.ve values (strings, numbers) – complex proper.es contain other objects (e.g., a winery instance)

51

Modifiers and rela.ons

•  Modifiers –  Domes.ca.on

•  Domes.c •  Wild

–  Use •  Dra[ •  Food •  pet

–  Risk •  Dangerous •  Safe





and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

53

Iden.fy the domain and range constraints for proper.es

•  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

54

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

55

For definable things •  Paraphrase and formalise the defini.ons in terms of the

primi.ves, rela.ons and other definables.

•  Note any assump.ons to be represented elsewhere.

– Add as comments when implemen.ng

•  “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

56

Which proper.es 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

57

Fill in the details (can use property matrix wizard)

58

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

59

Closure Axiom

Cows are animals and, amongst other things, eat some plants and eat only plants

Closure Axiom

60

In the tool

•  Right mouse buKon short cut for closure axioms

–  for any existen.al restric.on

adds closure axiom

61

Open vs Closed World reasoning

•  Open world reasoning –  Nega.on as contradic.on

•  Anything might be true unless it can be proven false –  Reasoning about any world consistent with this one

•  Closed world reasoning –  Nega.on as failure

•  Anything that cannot be found is false –  Reasoning about this world

•  Ontologies are not databases


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Crea.ng 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-‐acquisi.on tools o[en check that constraints are sa.sfied

Crea.ng instances

•  Filling the ontologies with such instances is a separate step

•  Number of instances >> number of classes

•  Thus popula.ng an ontology with instances is not done manually – Retrieved from legacy data sources (DBs)

– Extracted automa.cally from a text corpus


and domain analysis

Determine scope

Consider reuse

Enumerate terms

Define classes

Define proper.es

Define constraints

Add Instances

Ontology editors

Help with: •  Ini.al conceptual modelling

•  Use of Descrip.on Logic to represent classes, proper.es, and restric.ons. – Error detec.on and consistency checking while wri.ng 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 considera.on

•  Common problems have been addressed by W3C SWBP cookbook style documents and the defini.on of ontology paKerns

•  Some useful hints follow

70

Normalisa.on and Untangling Let the reasoner do mul.ple classifica.on

•  Tree – Everything has just one parent

•  A ‘strict hierarchy’ •  Directed Acyclic Graph (DAG)

– Things can have mul.ple parents •  A ‘Polyhierarchy’

•  NormalisaGon – Separate primi7ves into disjoint trees – Link the trees with defini.ons & restric.ons

•  Fill in the values – Let the classifier produce the DAG

71

Tables are easier to manage than DAGs / Polyhierarchies

…and get the benefit of inference: Grass and Leafy_plants are both kinds of Plant

72

Remember to add any closure axioms

Closure Axiom

Then let the reasoner do the work

73

Normalisa.on: From Trees to DAGs

  Before classification   A tree

  After classification   A DAG

  Directed Acyclic Graph

74

Common traps of restric.ons

•  ‘Some’ does not imply only ‘Only’ does not imply some’

•  Trivial sa.sfac.on of universal restric.ons •  Domain and Range Constraints

•  What to do when it all turns red – Don’t panic!

75

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.

76

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”

77

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”

78

“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 hasPet allValuesFrom (Dog or Cat)

79

“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…

80

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

81

Trivial Sa.sfiability

•  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

82

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)

83

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”?

84

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

85

Example of Coercion by Domain viola.on •  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

» Only domain constraints can cause

86

Reminder Subsump.on means necessary implica.on

•  “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 liKle of interest in DL terms

» “some ice_creams are pizza_toppings” says nothing about “all ice creams”

87

Summary:Domain & Range Constraints Non-‐Obvious Consequences

•  Range constraint viola.ons – unsa7sfiable or ignored –  If filler and RangeClass are disjoint: unsa7sfiable –  Otherwise nothing happens!

•  Domain constraint viola.ons – unsa7sfiable or coerced –  If subject and DomainClass are disjoint: unsa7sfiable

–  Otherwise, subject reclassified (coerced) to kind of DomainClass!

•  Furthermore cannot be fully checked before classifica7on –  although tools can issue warnings.

88

What to do when “Its all turned red”

•  Unsa.sfiability propagates – so trace it to its source –  Any class with an unsa.sfiable filler in a someValuesFor (existen.al) restric.on is unsa.sfiable

–  Any subclass of an unsa.sfiable class is unsa.sfiable –  Therefore errors propagate, trace them back to their source

•  Only a few possible sources –  Viola.on of disjoint axioms –  Unsa.sfiable expressions in some restric.ons

•  Confusion of “and” and “or” –  Viola.on of a universal (allValuesFrom) constraint (including range and domain constraints) •  Unsa.sfiable domain or range constraints

89

Saying something about a restric.on

•  Not just –  that an animal is dangerous, –  but why –  And how dangerous –  And how to avoid

•  But can say nothing about proper.es –  except special thing

•  Super and subproper.es •  Func.onal, transi.ve, symmetric

90

Re-‐represen.ng proper.es as classes •  To say something about a property it must be re-

represented 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

91

Re-representing the property has_danger as the class Risk

Animal Dangerous has_danger

Animal Risk has_Quality

Seriousness

Avoidance

has_seriousness

92

Lions are dangerous •  All lions pose a deadly risk of physical aKack that can be avoided by physical separa.on

•  All lions have the quality risk that is –  of type some physical aKack

–  of seriousness some deadly

–  has avoidance means some physical separa.on

93

Can add a second defini.on 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”]

94

In the tool •  Dangerous_animal =

–  Animal has_quality some (Risk AND has_seriousness some Deadly )

95

This says that

•  Any animal that is Dangerous

is also

An animal that has the quality Risk with the seriousness Deadly

96

Anopheles Mosquitos now count as dangerous

– Because they have a deadly risk of carrying disease

97

Mul.ple defini.ons are dangerous

•  BeKer to use one way or the other – Otherwise keeping the two ways consistent is difficult

– … but ontologies o[en evolve so that simple Proper.es are re-‐represented as Quali.es •  Then throw away the simple property

98

O[en 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 ques.ons of “ontology” –  The informa.on we really want to convey

•  O[en a sign that we have gone to far –  So we will stop

99

More PaKerns: N-‐ary rela.ons

•  In OWL a property is a binary rela.on: instances of proper.es link two individuals (or an individual and a value)

•  However, some.mes the most intui.ve way to represent certain concepts is to use rela.ons to link an individual to more than just one individual or value. Such rela.ons are called n-‐ary rela*ons.

•  Some issues: –  If property instances can link only two individuals, how do we deal with

cases where we need to describe the instances of rela.ons ? –  If instances of proper.es can link only two individuals, how do we

represent rela.ons among more than two individuals? ("n-‐ary rela*ons")

Pa:ern 1 –  If instances of proper.es can link only two individuals, how do we represent rela.ons in which one of the par.cipants is an ordered list of

individuals rather than a single individual? Pa:ern 2

N-‐ary rela.ons from http://www.w3.org/TR/swbp-n-aryRelations/

•  Chris.ne has breast tumor with high probability –  A rela7on ini7ally thought to be binary, needs a further argument

•  Steve has temperature, which is high, but falling –  Two binary proper7es turn out to always go together and should be

represented as one n-‐ary rela7on •  John buys a "Lenny the Lion" book from books.example.com for $15 as a

birthday gi[ –  From the beginning the rela7on 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

Examples

Can you think of some more examples?

•  Represent the rela.on as a class rather than a property

–  Individual instances of such classes correspond to instances of the rela.on

–  Addi.onal proper.es provide binary links to each argument of the rela.on

•  Basic idea: create a new class and new proper.es to represent an n-‐ary rela.on; then an instance of the rela.on linking the n individuals is then an instance of this class.

•  The classes created in this way are o[en called "reified rela*ons"

PaKern 1, N-‐ary rela.ons

PaKern 1 case 1 Addi.onal aKributes describing a rela.on: •  In this case we need to represent an addi.onal aKribute that represents a rela.on instance –  Ex: Chris7ne has breast tumor with high probability

•  The solu.on is to create an individual that represents the rela.on instance itself, with links from the subject of the rela.on to this instance, and with links from this instance to all par.cipants that represent addi.onal informa.on about this instance

PaKern 1, Example 1 Example: Christine has breast tumor with high probability "

The individual _:Diagnosis_Rela.on_1here represents a single object encapsula.ng both the diagnosis (Breast_Tumor_Chris.ne) and the probability of the diagnosis (HIGH)

-‐ It contains all the informa.on held in the original 3 arguments: who is being diagnosed, what the diagnosis is, and what the probability is

-‐ Blank nodes (rdf:Descrip.on element that does not have an rdf:about aKribute assigned to it) in RDF are used to represent instances of a rela.on.

Class defini.ons:

PaKern 1 case 2 Different aspects of the same rela.on: •  In this case we need to represent the rela.on between an

individual, and an object that represents different aspects of a property (rela.on) about the individual –  Ex: Steve has temperature which is high but falling

•  This instance of a rela.on cannot be viewed as an instance of a binary rela.on with addi.onal aKributes aKached to it.

•  It is a rela.on instance rela.ng the individual and the complex object represen.ng different facts about the specific rela.on between the individual and the object.

PaKern 1, Example 2 Example: Steve has temperature, which is high, but falling

• This cannot be viewed as an instance of a binary rela.on with addi.onal aKributes aKached to it, but rather it is a rela.on instance rela.ng the individual Steve and the complex object represen.ng different facts about his temp

Such cases o[en come about in the course of evolu.on of an ontology when it is realized that two rela.ons need to be collapsed.

• For example, ini.ally, one might have had two proper.es (e.g. has_temperature_level and has_temperature_trend) both rela.ng to people, and then it is realized that these proper.es really are inextricably intertwined because one needs to talk about "temperatures that are elevated but falling"

PaKern 1 case 3 N-‐ary rela.on with no dis.nguished par.cipant: •  In some cases the n-‐ary rela.onship links individuals that play different roles in a structure without any single individual standing out as the “owner” or the rela.on –  Ex: John buys a "Lenny the Lion" book from books.example.com for $15 as a birthday gia

•  The solu.on is to create an individual that represents the rela.on instance with links to all par.cipants

PaKern 1, Example 3 Example: John buys a "Lenny the Lion" book from books.example.com for $15 as a birthday gia

• The rela.on explicitly has more than one par.cipant, and, in many contexts, none of them can be considered a primary one, thus an individual is created to represent the rela.on instance with links to all par.cipants:

Considera.ons in introducing a new class

•  We did not give meaningful names to instances of proper.es or to the classes used to represent instances of n-‐ary rela.ons, but merely label them.

•  In most cases, these individuals do not stand on their own but merely func.on as auxiliaries to group together other objects. Hence a dis.nguishing name serves no purpose. Note that a similar approach is taken when reifying statements in RDF.

•  Crea.ng a class to represent an n-‐ary rela.on limits the use of many OWL constructs and creates a maintenance problem, especially when dealing with inverse rela.ons.

PaKern 2 Using lists for arguments in a rela.on •  Some n-‐ary rela.ons 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 rela.on holds between the flight and the airports it visits, in the order of the arrival of the aircra[ at each airport in turn.

•  This rela.on might hold between many different numbers of arguments, and there is no natural way to break it up into a set of dis.nct proper.es rela.ng the flight to each airport. The order of the arguments is highly meaningful.

PaKern 2, N-‐ary rela.ons Example: United Airlines flight 3177 visits the following airports: LAX, DFW, and JFK

• Basic idea: when all but one par.cipant in a rela.on do not have a specific role and essen.ally form an ordered list, it is natural to connect these arguments into a sequence according to some rela.on, and to relate the one par.cipant to this sequence (or the first element of the sequence)

nextSegment is an ordering rela.on between instances of the FlightSegment class; each flight segment has a property for the des.na.on 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.

•  W3C Working Group Note -‐Defining N-‐ary Rela.ons on the Seman.c Web

•  http://www.w3.org/TR/swbp-n-aryRelations

•  W3C Seman.c Web Best Prac.ces and Deployment Working Group

•  http://www.w3.org/2001/sw/BestPractices/ •  General references on Seman.c Web

•  http://www.w3.org/2001/sw/

+ many other resources/tutorials on the Web

Addi.onal resources

113

More PaKerns: Part-‐whole rela.ons

114

Part-‐whole rela.ons One method: NOT a SWBP draa

•  How to represent part-‐whole rela.ons in OWL is a commonly asked ques.on

•  SWBP has published a dra[ –  http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole!

•  This is one approach that will be proposed –  It has been used in teaching –  It has no official standing

115

Part Whole rela.ons

•  OWL has no special constructs – But provides the building blocks

•  Transi.ve rela.ons – Finger is_part_of Hand Hand is_part_of Arm Arm is_part_of Body • 

–  Finger is_part_of Body

116

Implementa.on PaKern Transi.ve proper.es with non-‐transi.ve “direct”

subproper.es

•  Transi.ve proper.es should have non-‐transi.ve children –  isPartOf : transi.ve

isPartOfDirectly : non-‐transi.ve •  Split which is used in par.al descrip.ons and complete defini.ons

–  Necessary condi.ons use non-‐transi.ve version –  Defini.ons use transi.ve version

•  Benefits –  Allows more restric.ons in domain/range constraints and cardinality

•  Allows the hierarchy along that axis to be traced one step at a .me •  Allow a good approxima.on of pure trees

–  Make the nontransi.ve subproperty func.onal »  Transi.ve proper.es can (almost) never be func.onal

(by defini.on, a transi.ve property has more than one value in any non-‐trivial system)

•  Constraints on transi.ve proper.es easily lead to unsa.sfiability

117

Many kinds of part-‐whole rela.ons

•  Physical parts –  hand-‐arm

•  Geographic regions –  Hiroshima -‐ Japan

•  Func.onal parts –  cpu – computer

•  See Winston & Odell Artale Rosse

118

Simple version •  One property is_part_of

–  transi.ve

•  Finger is_part_of some Hand Hand is_part_of some Arm Arm is_part_of some Body

119

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

120

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 o[en expect to see partonomy hierarchies

121

Using part-‐whole rela.ons: 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

122

Parts & wholes: Some examples

•  The leg is part of the chair •  The le[ side of the body is part of the body •  The liver cells are part of the liver •  The igni.on 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

123

Five families of rela.ons

•  Partonomic –  Parts and wholes

•  The lid is part of the box –  Cons.tu.on

•  The box is made of cardboard

–  Membership? •  The box is part of the shipment

•  Nonpartonomic –  Containment

•  The gi[ is contained in the box –  Connec.on/branching/Adjacency

•  The box is connected to the container by a strap

124

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

125

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

126

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.

127

Propagates_via / transi.ve_across

•  Components of subdivisions are components of the whole, but subdivisions of components are not subdivisions of the whole –  A the le[ side of the steering wheel of the car is not a subdivision

of the le[ side of the car (at least not in the UK)

•  No consistent name for this rela.on between proper.es –  We shall call it propagates_via or transi7ve_across

•  Also known as “right iden77es” –  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)

128

No simple solu.on: 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

129

Func.onal parts

•  Structural parts form a con.guous whole – May or may not contribute to func.on

e.g. decora.ve parts, accidental lumps and bumps •  The remote control is part of the projec.on system

– May or may not be physically connected to it •  Part of a common func.on

•  Biology examples: –  The endocrine system

•  The glands are not connected, but form part of a func.oning system communica.ng via hormones and transmiKers

•  The blood-‐forming system – Bone marrow in various places, the spleen, etc.

130

If something is both a structural and func.onal part…

•  Must put in both restric.ons explicitly – Can create a common child property but this gets complicated with the different kinds of structural parts

Date post:	17-Dec-2018
Category:	Documents
Upload:	lenhu
View:	220 times
Download:	0 times

Ontologyengineering (( - University of Liverpool...

Documents