1. Ontology engineering Valentina Tamma Based on slides by A. Gomez Perez, N. Noy, D. McGuinness, E. Kendal, A. Rector and O. Corcho

2. 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

3. 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

4. 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

5. Historical context Ontology Philosophy Knowledge Representation and logic Artificial Intelligence

6. 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, …

7. 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

8. T. Gruber, 1993; R. Studer, V. R. Benjamins, and D. Fensel, 1998 So what is an ontology then? An ontology is a (formal), explicit specification of a shared conceptualisation 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 conceptualisation: an abstract model of some phenomenon in the world which identifies the relevant concepts of that phenomenon formal: an ontology should be machine- readable

9. 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

10. 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” From John F. Sowa: Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks/Cole, 2000.

11. 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. Logic as a representation formalism From John F. Sowa: Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks/Cole, 2000.

12. Ontological commitment Agreement on the meaning of the vocabulary used to share knowledge. We need a pipe A pipe ?!?

13. 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

14. 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

15. 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

16. 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.

17. 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.

18. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances Really more like…

19. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

20. Ontology design process

21. 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;

22. 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

23. 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

24. 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

25. 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

26. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

27. 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?

28. Competency Questions Which investigations were done with a high-fat- diet 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?

29. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

30. 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

31. 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

32. What to Reuse? Ontology libraries – DAML ontology library (www.daml.org/ontologies)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)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)

33. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

34. 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

35. Example: animals & plants ontology Dog Cat Cow Person Tree Grass Herbivore Male Female Dangerous Pet Domestic Animal Farm animal Draft animal Food animal Fish Carp Goldfish Carnivore Plant Animal Fur Child Parent Mother Father

36. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

37. 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

38. 38 Organise the concepts Example: Animals & Plants Dog Cat Cow Person Tree Grass Herbivore Male Female Healthy Pet Domestic Animal Farm animal Draft animal Food animal Fish Carp Goldfish Carnivore Plant Animal Fur Child Parent Mother Father

39. 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, Domestic  Domestication What other states – “Feral” (domestic returned to wild)

40. 40 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

41. 41 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 Definable Carinvore Herbivore Child Parent Mother Father Food Animal Draft Animal Relations eats owns parent-of …

42. 42 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

43. 43 Reorganise everything but “definable” things into pure trees – these will be the “primitives” Self_standing – Living Thing Animal – Mammal » Cat » Dog » Cow » Person » Pig – Fish » Carp Goldfish Plant – Tree – Grass – Fruit Modifiers – Domestication Domestic Wild – Use Draft Food pet – Risk Dangerous Safe – Sex Male Female – Age Adult Child Definables Carnivore Herbivore Child Parent Mother Father Food Animal Draft Animal Relations eats owns parent-of …

44. 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

45. Class inheritance Classes are organized into subclass-superclass (or generalization- specialization) 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

46. 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

47. Levels in the class hierarchy Middle level Top level Bottom level

48. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

49. 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

50. 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)

51. 51 Modifiers and relations Modifiers – Domestication Domestic Wild – Use Draft Food pet – Risk Dangerous Safe – Sex Male Female – Age Adult Child Relations eats owns parent-of …

52. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

53. 53 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

54. 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. 55 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

56. 56 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

57. 57 Fill in the details (can use property matrix wizard)

58. 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. 59 Closure Axiom Cows are animals and, amongst other things, eat some plants and eat only plants Closure Axiom

60. 60 In the tool Right mouse button short cut for closure axioms – for any existential restriction adds closure axiom

61. 61 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

62. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

63. 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

64. 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

65. Ontology design process Requirement and domain analysis Determine scope Consider reuse Enumerate terms Define classes Define properties Define constraints Add Instances

66. 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

67. Remember DL?

68. Protégé 4

69. 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

70. 70 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

71. 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. 72 Remember to add any closure axioms Closure Axiom Then let the reasoner do the work

73. 73 Normalisation: From Trees to DAGs Before classification A tree After classification A DAG Directed Acyclic Graph

74. 74 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!

75. 75 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. 76 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. 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. 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. 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. 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. 81 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

82. 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. 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. 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. 85 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 »Only domain constraints can cause reclassification

86. 86 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”

87. 87 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.

88. 88 What to do when “Its all turned red” 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 Don’t Panic!

89. 89 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

90. 90 Re-representing properties 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. 91 Re-representing the property has_danger as the class Risk Animal Dangerous has_danger AnimalRisk has_Quality Seriousness Avoidance has_risk_type has_seriousness has_avoidance

92. 92 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

93. 93 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”]

94. 94 In the tool Dangerous_animal = – Animal has_quality some (Risk AND has_seriousness some Deadly )

95. 95 This says that Any animal that is Dangerous is also An animal that has the quality Risk with the seriousness Deadly

96. 96 Anopheles Mosquitos now count as dangerous – Because they have a deadly risk of carrying disease

97. 97 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

98. 98 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

99. 99 More Patterns: N-ary relations

100. 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 N-ary relations from http://www.w3.org/TR/swbp-n-aryRelations/

101. 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 Examples Can you think of some more examples?

102. 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 n- ary 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, N-ary relations

103. 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

104. 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:

105. 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.

106. 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"

107. 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

108. 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:

109. 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.

110. 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.

111. 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.

112. 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 Additional resources

113. 113 More Patterns: Part-whole relations

114. 114 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/BestPractices/OE P/SimplePartWholehttp://www.w3.org/2001/sw/BestPractices/OE P/SimplePartWhole This is one approach that will be proposed – It has been used in teaching – It has no official standing

115. 115 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

116. 116 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 non- trivial system) Constraints on transitive properties easily lead to unsatisfiability

117. 117 Many kinds of part-whole relations Physical parts – hand-arm Geographic regions – Hiroshima - Japan Functional parts – cpu – computer See Winston & Odell Artale Rosse

118. 118 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

119. 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. 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 often expect to see partonomy hierarchies

121. 121 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

122. 122 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

123. 123 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

124. 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. 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. 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. 127 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)

128. 128 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

129. 129 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.

130. 130 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