SlideShare a Scribd company logo

Ontology Evaluation: a pitfall-based approach to ontology diagnosis

•
•
María Poveda Villalón
María Poveda Villalón

Ontology evaluation, which includes ontology diagnosis and repair, is a complex activity that should be carried out in every ontology development project, because it checks for the technical quality of the ontology. However, there is an important gap between the methodological work about ontology evaluation and the tools that support such an activity. More precisely, not many approaches provide clear guidance about how to diagnose ontologies and how to repair them accordingly. This thesis aims to advance the current state of the art of ontology evaluation, specifically in the ontology diagnosis activity. The main goals of this thesis are (a) to help ontology engineers to diagnose their ontologies in order to find common pitfalls and (b) to lessen the effort required from them by providing the suitable technological support. This thesis presents the following main contributions: • A catalogue that describes 41 pitfalls that ontology developers might include in their ontologies. • A quality model for ontology diagnose that aligns the pitfall catalogue to existing quality models for semantic technologies. • The design and implementation of 48 methods for detecting 33 out of the 41 pitfalls defined in the catalogue. • A system called OOPS! (OntOlogy Pitfall Scanner!) that allows ontology engineers to (semi)automatically diagnose their ontologies. According to the feedback gathered and satisfaction tests carried out, the approach developed and presented in this thesis effectively helps users to increase the quality of their ontologies. At the time of writing this thesis, OOPS! has been broadly accepted by a high number of users worldwide and has been used around 3000 times from 60 different countries. OOPS! is integrated with third-party software and is locally installed in private enterprises being used both for ontology development activities and training courses.

Education
1 of 120
Ontology Evaluation: a pitfall-based approach to ontology diagnosis María Poveda Villalón Supervisors: Prof. Dr. Asunción Gómez Pérez Dr. María del Carmen Suárez de Figueroa Baonza ETSI Informaticos Universidad Politécnica de Madrid Campus de Montegancedo s/n 28660 Boadilla del Monte, Madrid, Spain 8th of February, 2016 ®
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 2
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation 3 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation •  The correct application of methodologies benefits the ontology quality •  No complete guaranty 4 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation •  The correct application of methodologies benefits the ontology quality •  No complete guaranty 5 Ontology evaluation (checking the technical quality of an ontology against a frame of reference) is a crucial activity in ontology engineering projects Ontology diagnosis: identifying parts of the ontology directly responsible for incorrectness and incompleteness 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 6 Ontology Evaluation Conceptual Practical Top level frameworks and definitions Guidelines and methods Tools
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Top level frameworks and definitions Guidelines and methods Tools Introduction 7 Ontology Evaluation Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 8 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical Top level frameworks and definitions Guidelines and methods Tools •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 9 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy Top level frameworks and definitions Guidelines and methods Tools •  Ontology developers •  Domain experts
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 10 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy Top level frameworks and definitions Guidelines and methods Tools •  Ontology developers •  Domain experts Target audience
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 11
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 12 ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 13 Frameworks and models ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 14 Frameworks and models Only taxonomies ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 15 Frameworks and models Only metrics Only taxonomies ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 16 Frameworks and models Only metrics ✗ ✗ ✗ ? ? ✗ Only taxonomies ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 17 Frameworks and models Only metrics ✗ ✗ ✗ ? q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered ? ✗ Only taxonomies ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 18 Frameworks and models Only metrics ✗ ✗ ✗ ? q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems ? ✗ Only taxonomies ToolsApproaches
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 19
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 20 q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 21 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 22 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 23 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 24 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 25 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies C1. Pitfall catalogue C2. Quality model Contributions:
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 26 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies Assumptions: A1: The catalogue of pitfalls proposed in this thesis is not exhaustive A2: New pitfalls could appear and could be added to the catalogue in the future C1. Pitfall catalogue C2. Quality model Contributions:
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 27 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 28 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity Contributions: C3. Detection methods C4. OOPS!
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 29 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity Assumptions: A3: An ontology network or an ontology that reuses parts from other ontologies, is considered as a unique ontology A4: Two or more anonymous ontologies executed with OOPS! are considered the same ontology if their evaluation results are equal Contributions: C3. Detection methods C4. OOPS!
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Restrictions 30 The pitfall catalogue addresses the diagnose of the T-box of OWL DL ontologies. The technological support: §  does not take as input data or information associated to the ontology §  does not address ontology repair §  takes as input OWL syntactically correct ontologies in RDF/XML or turtle §  addresses only English language §  does not perform inference §  relies on third-party software (Wordnet, TripleChecker and Licensius) R8 R7 R5 R4 R6R3 R2R1 R9 R10 R11
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 31
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 32 Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 33 SotA ontology evaluation Methodological inputs SotA methodologies for ontology engineering Empirical inputs Linked Data development experience Ontology development experience Technological inputs ToolsAPIs Linked Data guidelines Frameworks Methods Metadata recommendations Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 34 SotA ontology evaluation Methodological inputs SotA methodologies for ontology engineering Empirical inputs Linked Data development experience Ontology development experience Technological inputs ToolsAPIs Linked Data guidelines Frameworks Methods Metadata recommendations Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions Researchers Ontology experts Users Community feedback and validation
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Iterative process 35 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Compilation Phase
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st ExtensionCompilation Phase Iterative process 36
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd ExtensionCompilation Implementation Phase Iterative process 37
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd Manual inspection Literature review Collaborations Web User Interface Web Service 40 piftalls Classification: aspects and importance levels 2014 32 pitfalls detected ExtensionCompilation Implementation Linked Data ext. 4th Phase Iterative process 38
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review Collaborations Web User Interface Web Service 41 piftalls Classification: aspects and importance levels 2015 33 pitfalls detected Quality model Repair suggestions 5th Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd Manual inspection Literature review Collaborations Web User Interface Web Service 40 piftalls Classification: aspects and importance levels 2014 32 pitfalls detected RefinementExtensionCompilation Implementation Linked Data ext. 4th Phase Iterative process 39
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 40
Ontology Evaluation: a pitfall-based approach to ontology diagnosis What is a pitfall •  Pitfalls could represent errors •  Pitfalls could lead to errors •  Pitfalls are not always errors depending on: o  modelling decisions taken by the team of developers o  ontology requirements previously set o  application context of the ontology o  the domain of the ontology 41
Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 42
Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 43
Ontology Evaluation: a pitfall-based approach to ontology diagnosis List of 41 pitfalls 44 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P01. Creating polysemous elements P02. Creating synonyms as classes P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” P04. Creating unconnected ontology elements P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P13. Inverse relationships not explicitly declared P14. Misusing “owl:allValuesFrom” P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P19. Defining multiple domains or ranges in properties P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P30. Equivalent classes not explicitly declared P31. Defining wrong equivalent classes P32. Several classes with the same label P33. Creating a property chain with just one property P34. Untyped class P35. Untyped property P36. URI contains file extension P37. Ontology not available on the Web P38. No OWL ontology declaration P39. Ambiguous namespace P40. Namespace hijacking P41. No license declared
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 45 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 46 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 47 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional Process details Process details C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 48 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 1 • Survey Phase 2 • New pitfalls • Assign during description
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 49 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Input • 35 pitfall out of 41 • Semantic Web community Process • Survey • Statistical techniques •  Weighted sum •  Lexicographic order •  Centroid function Output •  Classification by importance levels Phase 1 • Survey Phase 2 • New pitfalls • Assign during description
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level §  Survey to the Semantic Web community §  For 35 pitfalls §  Participants were asked to mark each pitfall as: o  Critical o  Important o  Minor o  Not a problem (additional) §  54 answers: o  28 experts o  22 medium confidence o  4 low confidence 50 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model According to the negative consequences of each pitfall in the ontology
Ontology Evaluation: a pitfall-based approach to ontology diagnosis q  Weighted sum Assigning importance level 51 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis q  Weighted sum q  Lexicographic order Assigning importance level 52 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Critical (1) Important (2) Minor (3) Not im- portant P06. Including cycles in a class hierarchy 47 4 3 0 P19. Defining multiple domains or ranges in properties 42 9 2 0 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 41 7 6 0 P01. Creating polysemous elements 38 13 3 0 P29. Defining wrong transitive relationships 37 12 2 1 P14. Misusing ‘owl:allValuesFrom” 37 9 6 1 P31. Defining wrong equivalent classes 36 13 3 0 P16. Using a primitive class in place of a defined one 35 11 6 1 P15. Using “some not” in place of “not some” 34 13 3 1 P27. Defining wrong equivalent properties 33 14 5 0 P28. Defining wrong symmetric relationships 32 18 2 0 P05. Defining wrong inverse relationships 29 20 5 0 P24. Using recursive definitions 24 23 3 1 P12. Equivalent properties not explicitly declared 23 24 6 0 P10. Missing disjointness 23 18 11 2 P23. Duplicating a datatype already provided by the implementation language 22 25 5 0 P34. Untyped class 21 21 9 2 P35. Untyped property 19 24 8 2 P11. Missing domain or range in properties 19 17 12 4 P25. Defining a relationship as inverse to itself 17 24 12 0 P26. Defining inverse relationships for a symmetric one 15 26 11 0 P18. Overspecializing the domain or range 15 26 9 3 P17. Overspecializing a hierarchy 15 23 13 2 P30. Equivalent classes not explicitly declared 14 33 5 0 P04. Creating unconnected ontology elements 14 22 13 5 P07. Merging different concepts in the same class 13 21 14 5 P02. Creating synonyms as classes 10 24 17 3 P09. Missing domain information 7 33 11 3 P33. Creating a property chain with just one property 7 29 16 0 P21. Using a miscellaneous class 7 24 20 2 P13. Inverse relationships not explicitly declared 7 20 22 4 P32. Several classes with the same label 6 26 18 2 P20. Misusing ontology annotations 4 21 20 8 P08. Missing annotations 2 24 19 9 P22. Using different naming conventions in the ontology 2 22 26 1 Table 2: Pitfalls from P01 to P35 ranked according to the lexicographic order
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 53 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Critical (1) Important (2) Minor (3) Not im- portant P06. Including cycles in a class hierarchy 47 4 3 0 P19. Defining multiple domains or ranges in properties 42 9 2 0 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 41 7 6 0 P01. Creating polysemous elements 38 13 3 0 P29. Defining wrong transitive relationships 37 12 2 1 P14. Misusing ‘owl:allValuesFrom” 37 9 6 1 P31. Defining wrong equivalent classes 36 13 3 0 P16. Using a primitive class in place of a defined one 35 11 6 1 P15. Using “some not” in place of “not some” 34 13 3 1 P27. Defining wrong equivalent properties 33 14 5 0 P28. Defining wrong symmetric relationships 32 18 2 0 P05. Defining wrong inverse relationships 29 20 5 0 P24. Using recursive definitions 24 23 3 1 P12. Equivalent properties not explicitly declared 23 24 6 0 P10. Missing disjointness 23 18 11 2 P23. Duplicating a datatype already provided by the implementation language 22 25 5 0 P34. Untyped class 21 21 9 2 P35. Untyped property 19 24 8 2 P11. Missing domain or range in properties 19 17 12 4 P25. Defining a relationship as inverse to itself 17 24 12 0 P26. Defining inverse relationships for a symmetric one 15 26 11 0 P18. Overspecializing the domain or range 15 26 9 3 P17. Overspecializing a hierarchy 15 23 13 2 P30. Equivalent classes not explicitly declared 14 33 5 0 P04. Creating unconnected ontology elements 14 22 13 5 P07. Merging different concepts in the same class 13 21 14 5 P02. Creating synonyms as classes 10 24 17 3 P09. Missing domain information 7 33 11 3 P33. Creating a property chain with just one property 7 29 16 0 P21. Using a miscellaneous class 7 24 20 2 P13. Inverse relationships not explicitly declared 7 20 22 4 P32. Several classes with the same label 6 26 18 2 P20. Misusing ontology annotations 4 21 20 8 P08. Missing annotations 2 24 19 9 P22. Using different naming conventions in the ontology 2 22 26 1 Table 2: Pitfalls from P01 to P35 ranked according to the lexicographic order q  Weighted sum q  Lexicographic order q  Centroid function Centroid function Order Normalized Score P19. Defining multiple domains or ranges in properties 0.0379 P06. Including cycles in a class hierarchy 0.0375 P01. Creating polysemous elements 0.0369 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0365 P28. Defining wrong symmetric relationships 0.035 P29. Defining wrong transitive relationships 0.035 P05. Defining wrong inverse relationships 0.0348 P27. Defining wrong equivalent properties 0.0344 P31. Defining wrong equivalent classes 0.0341 P14. Misusing “owl:allValuesFrom” 0.034 P15. Using “some not” in place of “not some” 0.0339 Critical(1) P16. Using a primitive class in place of a defined one 0.0334 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0297 P34. Untyped class 0.0282 P35. Untyped property 0.0278 P25. Defining a relationship as inverse to itself 0.0278 P18. Overspecializing the domain or range 0.0277 P10. Missing disjointness 0.0277 P30. Equivalent classes not explicitly declared 0.0274 P17. Overspecializing a hierarchy 0.0271 P26. Defining inverse relationships for a symmetric one 0.0277 Important(2) P04. Creating unconnected ontology elements 0.0251 P11. Missing domain or range in properties 0.0247 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0241 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0233 P21. Using a miscellaneous class 0.0225 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0197 P22. Using different naming conventions in the ontology 0.0188 P08. Missing annotations 0.0187 Minor(3) P20. Misusing ontology annotations 0.0186 Table 3: Pitfalls from P01 to P35 ranked according to the centroid function
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 54 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 55 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 1 survey Phase 1 survey Phase 1 survey
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 56 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 2 Phase 1 survey Phase 1 survey Phase 2 Phase 1 survey Phase 2
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 57 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Input • Ontology evaluation dimensions (Gangemi et al., 2006) • Ontology evaluation aspects Process • Manual analysis • Assign one or more aspects to each pitfall • If it does not fit à add new aspect(s) Output •  Classification according to dimensions •  Fine grained division according to aspects Classifying by ontology evaluation aspects
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 58 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 59 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 60 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 61 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice P05. Defining wrong inverse relationships P19. Defining multiple domains or ranges in properties P06. Including cycles in a class hierarchy P15. Using “some not” in place of “not some” P18. Overspecializing the domain or range P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P01. Creating polysemous elements *
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 62 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice P05. Defining wrong inverse relationships P19. Defining multiple domains or ranges in properties P06. Including cycles in a class hierarchy P15. Using “some not” in place of “not some” P18. Overspecializing the domain or range P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P01. Creating polysemous elements * P13. Inverse relationships not explicitly declared P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared
Ontology Evaluation: a pitfall-based approach to ontology diagnosis 63 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects P05. Defining wrong inverse relationships P13. Inverse relationships not explicitly declared P19. Defining multiple domains or ranges in properties P24. Using recursive definitions P09. Missing domain information * P07. Merging different concepts in the same class P02. Creating synonyms as classes P20. Misusing ontology annotations P01. Creating polysemous elements * P17. Overspecializing a hierarchy P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” P11. Missing domain or range in properties P21. Using a miscellaneous class P12. Equivalent properties not explicitly declared P23. Duplicating a datatype already provided by the implementation language P04. Creating unconnected ontology elements P06. Including cycles in a class hierarchy P08. Missing annotations P10. Missing disjointness (2) P14. Misusing “allValuesFrom” P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P18. Overspecializing the domain or range Ontology Understanding Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Ontology Clarity P22. Using different naming conventions in the ontology Structural Dimension Usability-profiling Dimension Functional Dimension P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P30. Equivalent classes not explicitly declared P31. Defining wrong equivalent classes P32. Several classes with the same label P33. Creating a property chain with just one property Ontology Language P34. Untyped class P35. Untyped property P36. URI contains file extension Application Context P37. Ontology not available on the Web * P38. No OWL ontology declaration * P39. Ambiguous namespace P40. Namespace hijacking P41. No license declared Ontology Metadata P01. Creating polysemous elements * P38. No OWL ontology declaration * P37. Ontology not available on the Web * Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 64
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 65 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 66 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional From pitfall template C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 67 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional From pitfall template C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template 68 §  48 methods for detecting 33 pitfalls §  For each pitfall 0..N methods o  No method: •  Human or background knowledge •  Requirements 2 methods: P12. Equivalent properties not explicitly declared C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Pitfall description Method description P01. Creating polysemous elements Table 4.1 Needs background knowledge. P02. Creating synonyms as classes Table 4.2 Table 5.2 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” Table 4.3 Table 5.3 P04. Creating unconnected ontology elements Table 4.4 Table 5.4 P05. Defining wrong inverse relationships Table 4.5 Table 5.5 P06. Including cycles in a class hierarchy Table 4.6 Table 5.6 P07. Merging different concepts in the same class Table 4.7 Table 5.7 P08. Missing annotations Table 4.8 Table 5.8, Table 5.9 and Table 5.10 P09. Missing domain information Table 4.9 Needs ontology requirements docu- ment. P10. Missing disjointness Table 4.10 Table 5.11 P11. Missing domain or range in properties Table 4.11 Table 5.12 and Table 5.13 P12. Equivalent properties not explicitly declared Table 4.12 Table 5.14 and Table 5.15 P13. Inverse relationships not explicitly declared Table 4.13 Table 5.16 P14. Misusing “owl:allValuesFrom” Table 4.14 Needs background knowledge and hu- man intervention. P15. Using “some not” in place of “not some” Table 4.15 Needs background knowledge and hu- man intervention. P16. Using a primitive class in place of a defined one Table 4.16 Needs background knowledge. P17. Overspecializing a hierarchy Table 4.17 Needs background knowledge and/or ontology requirements document. P18. Overspecializing the domain or range Table 4.18 Needs background knowledge and/or ontology requirements document. P.19 Definining multiple domains or ranges in properties Table 4.19 Table 5.17 and Table 5.18 P20. Misusing ontology annotations Table 4.20 Table 5.19, Table 5.20 and Table 5.21 … 1 method: P07. Merging different concepts in the same class No method: P15. Using “some not” in place of “not some”
Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 69
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P25 70 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itself Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged.
Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 71 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged.
Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 72 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Title P25. Defining a relationship as inverse to itself Importanc level Aspects Modelling decisions Affects to Description A relationship is defined as inverse of itself. In this case, this relationship c owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural langu <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example “hasBorderWith”, which of itself by means of the How to solve it One should check whether the object property defined as inverse of itself sa tion: every time the object property holds between the individuals “a” and “b” and “a”. If the object property does fulfil the condition, it should be de owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning considered a workaround to avoid increasing the ontology expressivity, it is m object property as symmetric (using owl:SymmetricProperty) instead of as inver Table 6: P25. Defining a relationship as inverse to
Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 73 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Title P25. Defining a relationship as inverse to itself Importanc level Aspects Modelling decisions Affects to Description A relationship is defined as inverse of itself. In this case, this relationship c owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural langu <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example “hasBorderWith”, which of itself by means of the How to solve it One should check whether the object property defined as inverse of itself sa tion: every time the object property holds between the individuals “a” and “b” and “a”. If the object property does fulfil the condition, it should be de owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning considered a workaround to avoid increasing the ontology expressivity, it is m object property as symmetric (using owl:SymmetricProperty) instead of as inver Table 6: P25. Defining a relationship as inverse to Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P25 74 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model M1-P25. Detecting relationships inverse to themselvesP25 description While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8
Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P19 75 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer.
Ontology Evaluation: a pitfall-based approach to ontology diagnosis P19 description Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer. Table 3: P19. Defining multiple domains or ranges in properties 5 Pitfalls and methods: example P19 76 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong
Ontology Evaluation: a pitfall-based approach to ontology diagnosis P19 description Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer. Table 3: P19. Defining multiple domains or ranges in properties 5 Pitfalls and methods: example P19 77 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis
Ontology Evaluation: a pitfall-based approach to ontology diagnosis

Recommended

Validating ontologies with OOPS! - EKAW2012
Validating ontologies with OOPS! - EKAW2012Validating ontologies with OOPS! - EKAW2012
Validating ontologies with OOPS! - EKAW2012María Poveda Villalón
 
Survey Research in Software Engineering
Survey Research in Software EngineeringSurvey Research in Software Engineering
Survey Research in Software EngineeringDaniel Mendez
 
Research in EFL: Current needs and trends
Research in EFL: Current needs and trendsResearch in EFL: Current needs and trends
Research in EFL: Current needs and trendsEvelyn Izquierdo
 
Creation of collaborative study community in engineering studies
Creation of collaborative study community in engineering studiesCreation of collaborative study community in engineering studies
Creation of collaborative study community in engineering studiesHelsinki Metropolia University of Applied Sciencies
 
OEG-Tools for supporting Ontology Engineering
OEG-Tools for supporting Ontology EngineeringOEG-Tools for supporting Ontology Engineering
OEG-Tools for supporting Ontology EngineeringMaría Poveda Villalón
 
Ontology and Ontology Libraries: a Critical Study
Ontology and Ontology Libraries: a Critical StudyOntology and Ontology Libraries: a Critical Study
Ontology and Ontology Libraries: a Critical StudyDebashisnaskar
 
Ontology engineering
Ontology engineering Ontology engineering
Ontology engineering Aliabbas Petiwala
 
Ontology and its various aspects
Ontology and its various aspectsOntology and its various aspects
Ontology and its various aspectssamhati27
 

Recommended

Validating ontologies with OOPS! - EKAW2012
Validating ontologies with OOPS! - EKAW2012Validating ontologies with OOPS! - EKAW2012
Validating ontologies with OOPS! - EKAW2012María Poveda Villalón
 
Survey Research in Software Engineering
Survey Research in Software EngineeringSurvey Research in Software Engineering
Survey Research in Software EngineeringDaniel Mendez
 
Research in EFL: Current needs and trends
Research in EFL: Current needs and trendsResearch in EFL: Current needs and trends
Research in EFL: Current needs and trendsEvelyn Izquierdo
 
Creation of collaborative study community in engineering studies
Creation of collaborative study community in engineering studiesCreation of collaborative study community in engineering studies
Creation of collaborative study community in engineering studiesHelsinki Metropolia University of Applied Sciencies
 
OEG-Tools for supporting Ontology Engineering
OEG-Tools for supporting Ontology EngineeringOEG-Tools for supporting Ontology Engineering
OEG-Tools for supporting Ontology EngineeringMaría Poveda Villalón
 
Ontology and Ontology Libraries: a Critical Study
Ontology and Ontology Libraries: a Critical StudyOntology and Ontology Libraries: a Critical Study
Ontology and Ontology Libraries: a Critical StudyDebashisnaskar
 
Ontology engineering
Ontology engineering Ontology engineering
Ontology engineering Aliabbas Petiwala
 
Ontology and its various aspects
Ontology and its various aspectsOntology and its various aspects
Ontology and its various aspectssamhati27
 
Food Informatics-Sharing Food
Food Informatics-Sharing FoodFood Informatics-Sharing Food
Food Informatics-Sharing FoodAIMS (Agricultural Information Management Standards)
 
ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...ORPHEUS
 
OOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria PovedaOOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria Povedasemanticsconference
 
Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...Daniel Mendez
 
FOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principlesFOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principlesdgarijo
 
2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopment2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopmentPieter Pauwels
 
Master project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells DetectionMaster project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells DetectionMohamed BOUSSAA
 
A Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology DevelopmentA Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology DevelopmentUniversity of Bologna
 
Linked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms DiscoveryLinked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms DiscoveryIoannis Stavrakantonakis
 
RESEARCH in software engineering
RESEARCH in software engineeringRESEARCH in software engineering
RESEARCH in software engineeringIvano Malavolta
 
Experiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology DesignExperiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology Designevabl444
 
Ontologies for Smart Cities
Ontologies for Smart CitiesOntologies for Smart Cities
Ontologies for Smart CitiesLD4SC
 
OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...EduSkills OECD
 
Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)evabl444
 
Caenti Huelva2007 Wp6 Catalyse Content
Caenti Huelva2007 Wp6 Catalyse ContentCaenti Huelva2007 Wp6 Catalyse Content
Caenti Huelva2007 Wp6 Catalyse ContentTerritorial Intelligence
 
Presentation on Software process improvement in GSD
Presentation on Software process improvement in GSDPresentation on Software process improvement in GSD
Presentation on Software process improvement in GSDRafi Ullah
 
[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineering[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineeringIvano Malavolta
 
Requirement engineering evaluation
Requirement engineering evaluationRequirement engineering evaluation
Requirement engineering evaluationIshraq Al Fataftah
 
How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)OARSI
 
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...Daniel Mendez
 
Ontology development basic tools
Ontology development basic toolsOntology development basic tools
Ontology development basic toolsMaría Poveda Villalón
 
Chowlk notation
Chowlk notation Chowlk notation
Chowlk notation María Poveda Villalón
 

More Related Content

Similar to Ontology Evaluation: a pitfall-based approach to ontology diagnosis

ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...ORPHEUS
 
OOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria PovedaOOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria Povedasemanticsconference
 
Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...Daniel Mendez
 
FOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principlesFOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principlesdgarijo
 
2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopment2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopmentPieter Pauwels
 
Master project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells DetectionMaster project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells DetectionMohamed BOUSSAA
 
A Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology DevelopmentA Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology DevelopmentUniversity of Bologna
 
Linked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms DiscoveryLinked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms DiscoveryIoannis Stavrakantonakis
 
RESEARCH in software engineering
RESEARCH in software engineeringRESEARCH in software engineering
RESEARCH in software engineeringIvano Malavolta
 
Experiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology DesignExperiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology Designevabl444
 
Ontologies for Smart Cities
Ontologies for Smart CitiesOntologies for Smart Cities
Ontologies for Smart CitiesLD4SC
 
OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...EduSkills OECD
 
Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)evabl444
 
Presentation on Software process improvement in GSD
Presentation on Software process improvement in GSDPresentation on Software process improvement in GSD
Presentation on Software process improvement in GSDRafi Ullah
 
[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineering[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineeringIvano Malavolta
 
Requirement engineering evaluation
Requirement engineering evaluationRequirement engineering evaluation
Requirement engineering evaluationIshraq Al Fataftah
 
How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)OARSI
 
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...Daniel Mendez
 

Similar to Ontology Evaluation: a pitfall-based approach to ontology diagnosis (20)

Food Informatics-Sharing Food
Food Informatics-Sharing FoodFood Informatics-Sharing Food
Food Informatics-Sharing Food
 
ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...ORPHEUS tools for assisting Institutions in implementing best practices for r...
ORPHEUS tools for assisting Institutions in implementing best practices for r...
 
OOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria PovedaOOPS!: on-line ontology diagnosis by Maria Poveda
OOPS!: on-line ontology diagnosis by Maria Poveda
 
Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...Where do we stand in Requirements Engineering Improvement Today? First Result...
Where do we stand in Requirements Engineering Improvement Today? First Result...
 
FOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principlesFOOPS!: An Ontology Pitfall Scanner for the FAIR principles
FOOPS!: An Ontology Pitfall Scanner for the FAIR principles
 
2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopment2_presFriday_ontologydevelopment
2_presFriday_ontologydevelopment
 
Master project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells DetectionMaster project - Competitive Co-evolutionary Code-Smells Detection
Master project - Competitive Co-evolutionary Code-Smells Detection
 
A Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology DevelopmentA Simplified Agile Methodology for Ontology Development
A Simplified Agile Methodology for Ontology Development
 
Linked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms DiscoveryLinked Open Vocabulary Ranking and Terms Discovery
Linked Open Vocabulary Ranking and Terms Discovery
 
RESEARCH in software engineering
RESEARCH in software engineeringRESEARCH in software engineering
RESEARCH in software engineering
 
Experiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology DesignExperiments on Pattern-based Ontology Design
Experiments on Pattern-based Ontology Design
 
Ontologies for Smart Cities
Ontologies for Smart CitiesOntologies for Smart Cities
Ontologies for Smart Cities
 
OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...OECD Feasibility Study for an international Assessment of Higher Education Le...
OECD Feasibility Study for an international Assessment of Higher Education Le...
 
Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)Experimenting with eXtreme Design (EKAW2010)
Experimenting with eXtreme Design (EKAW2010)
 
Caenti Huelva2007 Wp6 Catalyse Content
Caenti Huelva2007 Wp6 Catalyse ContentCaenti Huelva2007 Wp6 Catalyse Content
Caenti Huelva2007 Wp6 Catalyse Content
 
Presentation on Software process improvement in GSD
Presentation on Software process improvement in GSDPresentation on Software process improvement in GSD
Presentation on Software process improvement in GSD
 
[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineering[2017/2018] RESEARCH in software engineering
[2017/2018] RESEARCH in software engineering
 
Requirement engineering evaluation
Requirement engineering evaluationRequirement engineering evaluation
Requirement engineering evaluation
 
How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)How to write an effective review (and help editors and authors)
How to write an effective review (and help editors and authors)
 
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
Naming the Pain in Requirements Engineering - Design of a Global Family of Su...
 

More from María Poveda Villalón

New trends in ontological engineering, practices and tools
New trends in ontological engineering, practices and toolsNew trends in ontological engineering, practices and tools
New trends in ontological engineering, practices and toolsMaría Poveda Villalón
 
Publishing Linked Open Data on the Web & the Role of Ontologies
Publishing Linked Open Data on the Web & the Role of OntologiesPublishing Linked Open Data on the Web & the Role of Ontologies
Publishing Linked Open Data on the Web & the Role of OntologiesMaría Poveda Villalón
 
Detrás de un gran dataset siempre hay un gran vocabulario
Detrás de un gran dataset siempre hay un gran vocabularioDetrás de un gran dataset siempre hay un gran vocabulario
Detrás de un gran dataset siempre hay un gran vocabularioMaría Poveda Villalón
 
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...María Poveda Villalón
 
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web María Poveda Villalón
 
The Landscape of Ontology Reuse in Linked Data - OEDW2012
The Landscape of Ontology Reuse in Linked Data - OEDW2012The Landscape of Ontology Reuse in Linked Data - OEDW2012
The Landscape of Ontology Reuse in Linked Data - OEDW2012María Poveda Villalón
 

More from María Poveda Villalón (13)

Ontology development basic tools
Ontology development basic toolsOntology development basic tools
Ontology development basic tools
 
Chowlk notation
Chowlk notation Chowlk notation
Chowlk notation
 
Coming to terms to FAIR semantics
Coming to terms to FAIR semanticsComing to terms to FAIR semantics
Coming to terms to FAIR semantics
 
New trends in ontological engineering, practices and tools
New trends in ontological engineering, practices and toolsNew trends in ontological engineering, practices and tools
New trends in ontological engineering, practices and tools
 
Publishing Linked Open Data on the Web & the Role of Ontologies
Publishing Linked Open Data on the Web & the Role of OntologiesPublishing Linked Open Data on the Web & the Role of Ontologies
Publishing Linked Open Data on the Web & the Role of Ontologies
 
Introducción a la web semántica
Introducción a la web semánticaIntroducción a la web semántica
Introducción a la web semántica
 
Semantic Discovery in the Web of Things
Semantic Discovery in the Web of ThingsSemantic Discovery in the Web of Things
Semantic Discovery in the Web of Things
 
Linked Open Vocabularies
Linked Open VocabulariesLinked Open Vocabularies
Linked Open Vocabularies
 
Detrás de un gran dataset siempre hay un gran vocabulario
Detrás de un gran dataset siempre hay un gran vocabularioDetrás de un gran dataset siempre hay un gran vocabulario
Detrás de un gran dataset siempre hay un gran vocabulario
 
Ee bdm ws-v1
Ee bdm ws-v1Ee bdm ws-v1
Ee bdm ws-v1
 
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...
A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vo...
 
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web
Detecting Good Practices and Pitfalls when Publishing Vocabularies on the Web
 
The Landscape of Ontology Reuse in Linked Data - OEDW2012
The Landscape of Ontology Reuse in Linked Data - OEDW2012The Landscape of Ontology Reuse in Linked Data - OEDW2012
The Landscape of Ontology Reuse in Linked Data - OEDW2012
 

Recently uploaded

CARE OF CHILD IN INCUBATOR..........pptx
CARE OF CHILD IN INCUBATOR..........pptxCARE OF CHILD IN INCUBATOR..........pptx
CARE OF CHILD IN INCUBATOR..........pptxGaneshChakor2
 
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...Marc Dusseiller Dusjagr
 
Software Engineering Methodologies (overview)
Software Engineering Methodologies (overview)Software Engineering Methodologies (overview)
Software Engineering Methodologies (overview)eniolaolutunde
 
The Most Excellent Way | 1 Corinthians 13
The Most Excellent Way | 1 Corinthians 13The Most Excellent Way | 1 Corinthians 13
The Most Excellent Way | 1 Corinthians 13Steve Thomason
 
Organic Name Reactions for the students and aspirants of Chemistry12th.pptx
Organic Name Reactions for the students and aspirants of Chemistry12th.pptxOrganic Name Reactions for the students and aspirants of Chemistry12th.pptx
Organic Name Reactions for the students and aspirants of Chemistry12th.pptxVS Mahajan Coaching Centre
 
microwave assisted reaction. General introduction
microwave assisted reaction. General introductionmicrowave assisted reaction. General introduction
microwave assisted reaction. General introductionMaksud Ahmed
 
Presiding Officer Training module 2024 lok sabha elections
Presiding Officer Training module 2024 lok sabha electionsPresiding Officer Training module 2024 lok sabha elections
Presiding Officer Training module 2024 lok sabha electionsanshu789521
 
Solving Puzzles Benefits Everyone (English).pptx
Solving Puzzles Benefits Everyone (English).pptxSolving Puzzles Benefits Everyone (English).pptx
Solving Puzzles Benefits Everyone (English).pptxOH TEIK BIN
 
Employee wellbeing at the workplace.pptx
Employee wellbeing at the workplace.pptxEmployee wellbeing at the workplace.pptx
Employee wellbeing at the workplace.pptxNirmalaLoungPoorunde1
 
Concept of Vouching. B.Com(Hons) /B.Compdf
Concept of Vouching. B.Com(Hons) /B.CompdfConcept of Vouching. B.Com(Hons) /B.Compdf
Concept of Vouching. B.Com(Hons) /B.CompdfUmakantAnnand
 
Alper Gobel In Media Res Media Component
Alper Gobel In Media Res Media ComponentAlper Gobel In Media Res Media Component
Alper Gobel In Media Res Media ComponentInMediaRes1
 
Hybridoma Technology ( Production , Purification , and Application )
Hybridoma Technology ( Production , Purification , and Application ) Hybridoma Technology ( Production , Purification , and Application )
Hybridoma Technology ( Production , Purification , and Application ) Sakshi Ghasle
 
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPT
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPTECONOMIC CONTEXT - LONG FORM TV DRAMA - PPT
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPTiammrhaywood
 
Class 11 Legal Studies Ch-1 Concept of State .pdf
Class 11 Legal Studies Ch-1 Concept of State .pdfClass 11 Legal Studies Ch-1 Concept of State .pdf
Class 11 Legal Studies Ch-1 Concept of State .pdfakmcokerachita
 
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdf
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdfEnzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdf
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdfSumit Tiwari
 
Crayon Activity Handout For the Crayon A
Crayon Activity Handout For the Crayon ACrayon Activity Handout For the Crayon A
Crayon Activity Handout For the Crayon AUnboundStockton
 
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptx
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptxPOINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptx
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptxSayali Powar
 
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...EduSkills OECD
 

Recently uploaded (20)

CARE OF CHILD IN INCUBATOR..........pptx
CARE OF CHILD IN INCUBATOR..........pptxCARE OF CHILD IN INCUBATOR..........pptx
CARE OF CHILD IN INCUBATOR..........pptx
 
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...
“Oh GOSH! Reflecting on Hackteria's Collaborative Practices in a Global Do-It...
 
Software Engineering Methodologies (overview)
Software Engineering Methodologies (overview)Software Engineering Methodologies (overview)
Software Engineering Methodologies (overview)
 
The Most Excellent Way | 1 Corinthians 13
The Most Excellent Way | 1 Corinthians 13The Most Excellent Way | 1 Corinthians 13
The Most Excellent Way | 1 Corinthians 13
 
Organic Name Reactions for the students and aspirants of Chemistry12th.pptx
Organic Name Reactions for the students and aspirants of Chemistry12th.pptxOrganic Name Reactions for the students and aspirants of Chemistry12th.pptx
Organic Name Reactions for the students and aspirants of Chemistry12th.pptx
 
Código Creativo y Arte de Software | Unidad 1
Código Creativo y Arte de Software | Unidad 1Código Creativo y Arte de Software | Unidad 1
Código Creativo y Arte de Software | Unidad 1
 
microwave assisted reaction. General introduction
microwave assisted reaction. General introductionmicrowave assisted reaction. General introduction
microwave assisted reaction. General introduction
 
Presiding Officer Training module 2024 lok sabha elections
Presiding Officer Training module 2024 lok sabha electionsPresiding Officer Training module 2024 lok sabha elections
Presiding Officer Training module 2024 lok sabha elections
 
Solving Puzzles Benefits Everyone (English).pptx
Solving Puzzles Benefits Everyone (English).pptxSolving Puzzles Benefits Everyone (English).pptx
Solving Puzzles Benefits Everyone (English).pptx
 
Employee wellbeing at the workplace.pptx
Employee wellbeing at the workplace.pptxEmployee wellbeing at the workplace.pptx
Employee wellbeing at the workplace.pptx
 
TataKelola dan KamSiber Kecerdasan Buatan v022.pdf
TataKelola dan KamSiber Kecerdasan Buatan v022.pdfTataKelola dan KamSiber Kecerdasan Buatan v022.pdf
TataKelola dan KamSiber Kecerdasan Buatan v022.pdf
 
Concept of Vouching. B.Com(Hons) /B.Compdf
Concept of Vouching. B.Com(Hons) /B.CompdfConcept of Vouching. B.Com(Hons) /B.Compdf
Concept of Vouching. B.Com(Hons) /B.Compdf
 
Alper Gobel In Media Res Media Component
Alper Gobel In Media Res Media ComponentAlper Gobel In Media Res Media Component
Alper Gobel In Media Res Media Component
 
Hybridoma Technology ( Production , Purification , and Application )
Hybridoma Technology ( Production , Purification , and Application ) Hybridoma Technology ( Production , Purification , and Application )
Hybridoma Technology ( Production , Purification , and Application )
 
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPT
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPTECONOMIC CONTEXT - LONG FORM TV DRAMA - PPT
ECONOMIC CONTEXT - LONG FORM TV DRAMA - PPT
 
Class 11 Legal Studies Ch-1 Concept of State .pdf
Class 11 Legal Studies Ch-1 Concept of State .pdfClass 11 Legal Studies Ch-1 Concept of State .pdf
Class 11 Legal Studies Ch-1 Concept of State .pdf
 
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdf
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdfEnzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdf
Enzyme, Pharmaceutical Aids, Miscellaneous Last Part of Chapter no 5th.pdf
 
Crayon Activity Handout For the Crayon A
Crayon Activity Handout For the Crayon ACrayon Activity Handout For the Crayon A
Crayon Activity Handout For the Crayon A
 
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptx
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptxPOINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptx
POINT- BIOCHEMISTRY SEM 2 ENZYMES UNIT 5.pptx
 
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
 

Ontology Evaluation: a pitfall-based approach to ontology diagnosis

  • 1. Ontology Evaluation: a pitfall-based approach to ontology diagnosis María Poveda Villalón Supervisors: Prof. Dr. Asunción Gómez Pérez Dr. María del Carmen Suárez de Figueroa Baonza ETSI Informaticos Universidad Politécnica de Madrid Campus de Montegancedo s/n 28660 Boadilla del Monte, Madrid, Spain 8th of February, 2016 ®
  • 2. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 2
  • 3. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation 3 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
  • 4. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation •  The correct application of methodologies benefits the ontology quality •  No complete guaranty 4 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
  • 5. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Ontology engineering and ontology evaluation •  The correct application of methodologies benefits the ontology quality •  No complete guaranty 5 Ontology evaluation (checking the technical quality of an ontology against a frame of reference) is a crucial activity in ontology engineering projects Ontology diagnosis: identifying parts of the ontology directly responsible for incorrectness and incompleteness 1996 1997 ... 2001 2002 2003 20041995 2005 2006 ... 2009 2010 Guide 101 XD EXtreme Ontology RapidOWL Grüninger & Fox On-To- Knowledge METHON TOLOGY DILIGENT NeOn O. Development Methodologies Ontology Development Lightweight Approaches
  • 6. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 6 Ontology Evaluation Conceptual Practical Top level frameworks and definitions Guidelines and methods Tools
  • 7. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Top level frameworks and definitions Guidelines and methods Tools Introduction 7 Ontology Evaluation Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy
  • 8. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 8 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical Top level frameworks and definitions Guidelines and methods Tools •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy
  • 9. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 9 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy Top level frameworks and definitions Guidelines and methods Tools •  Ontology developers •  Domain experts
  • 10. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Introduction 10 Ontology Evaluation •  Ontology engineers •  Knowledge in ontological engineering Conceptual Practical •  Upper-level ontology engineers •  Deep knowledge in formal logic and philosophy Top level frameworks and definitions Guidelines and methods Tools •  Ontology developers •  Domain experts Target audience
  • 11. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 11
  • 12. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 12 ToolsApproaches
  • 13. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 13 Frameworks and models ToolsApproaches
  • 14. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 14 Frameworks and models Only taxonomies ToolsApproaches
  • 15. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 15 Frameworks and models Only metrics Only taxonomies ToolsApproaches
  • 16. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 16 Frameworks and models Only metrics ✗ ✗ ✗ ? ? ✗ Only taxonomies ToolsApproaches
  • 17. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 17 Frameworks and models Only metrics ✗ ✗ ✗ ? q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered ? ✗ Only taxonomies ToolsApproaches
  • 18. Ontology Evaluation: a pitfall-based approach to ontology diagnosis CQs ... 2001 2002 ... 20041995 2005 2006 ... 2008 2009 2010 2011 2012 Gómez- Pérez O2 model NeOn guidelines Vrandečić Unit Tests Rector et al. OntoClean OQuaRE OntoQA Semiotic metrics OQuaRE Patterns debugging XD- Analyzer Moki Onto Check AEONODEClean ODEval Eyeballimplements implements implements implements 1997 ... Taxonomy errors State of the art 18 Frameworks and models Only metrics ✗ ✗ ✗ ? q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems ? ✗ Only taxonomies ToolsApproaches
  • 19. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 19
  • 20. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 20 q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered
  • 21. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 21 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered
  • 22. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 22 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems
  • 23. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Open research problems and PhD objectives 23 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls q  ORP1: Most of the methods for ontology evaluation: §  only deal with taxonomical knowledge §  address a narrow range of ontology evaluation aspects §  provide a set of measurements but no concrete ontology diagnosis output are offered O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers q  ORP2: Lack of systems that (semi)automatically diagnose ontologies by addressing several aspects and pointing to specific problems
  • 24. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 24 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies
  • 25. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 25 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies C1. Pitfall catalogue C2. Quality model Contributions:
  • 26. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 26 O1: To help ontology engineers to diagnose their ontologies in order to find common pitfalls Hypothesis: H1: Systematic approaches to evaluate ontologies based on a list of common pitfalls improve the quality of ontologies Assumptions: A1: The catalogue of pitfalls proposed in this thesis is not exhaustive A2: New pitfalls could appear and could be added to the catalogue in the future C1. Pitfall catalogue C2. Quality model Contributions:
  • 27. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 27 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity
  • 28. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 28 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity Contributions: C3. Detection methods C4. OOPS!
  • 29. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Objectives, hypothesis, contributions and assumptions 29 O2: To ease the ontology diagnosis activity by means of providing suitable technological support, lessening thus the effort required from ontology engineers Hypothesis: H2: A collection of methods for detecting pitfalls in a (semi)automatic way facilitates the ontology diagnosis activity Assumptions: A3: An ontology network or an ontology that reuses parts from other ontologies, is considered as a unique ontology A4: Two or more anonymous ontologies executed with OOPS! are considered the same ontology if their evaluation results are equal Contributions: C3. Detection methods C4. OOPS!
  • 30. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Restrictions 30 The pitfall catalogue addresses the diagnose of the T-box of OWL DL ontologies. The technological support: §  does not take as input data or information associated to the ontology §  does not address ontology repair §  takes as input OWL syntactically correct ontologies in RDF/XML or turtle §  addresses only English language §  does not perform inference §  relies on third-party software (Wordnet, TripleChecker and Licensius) R8 R7 R5 R4 R6R3 R2R1 R9 R10 R11
  • 31. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 31
  • 32. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 32 Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions
  • 33. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 33 SotA ontology evaluation Methodological inputs SotA methodologies for ontology engineering Empirical inputs Linked Data development experience Ontology development experience Technological inputs ToolsAPIs Linked Data guidelines Frameworks Methods Metadata recommendations Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions
  • 34. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Research methodology 34 SotA ontology evaluation Methodological inputs SotA methodologies for ontology engineering Empirical inputs Linked Data development experience Ontology development experience Technological inputs ToolsAPIs Linked Data guidelines Frameworks Methods Metadata recommendations Frame Objectives Assumptions Restrictions C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Contributions Researchers Ontology experts Users Community feedback and validation
  • 35. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Iterative process 35 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Compilation Phase
  • 36. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st ExtensionCompilation Phase Iterative process 36
  • 37. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd ExtensionCompilation Implementation Phase Iterative process 37
  • 38. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd Manual inspection Literature review Collaborations Web User Interface Web Service 40 piftalls Classification: aspects and importance levels 2014 32 pitfalls detected ExtensionCompilation Implementation Linked Data ext. 4th Phase Iterative process 38
  • 39. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Manual inspection Literature review Collaborations Web User Interface Web Service 41 piftalls Classification: aspects and importance levels 2015 33 pitfalls detected Quality model Repair suggestions 5th Manual inspection Literature review 24 piftalls Classification: aspects and errors in hierarchies 20102nd 14 piftalls Manual inspection Classification: Ontology Design Patterns 2009 OOPS!PitfalloriginCatalogue 1st Manual inspection Literature review Web User Interface 29 piftalls Classification: dimensions in tools 2012 21 pitfalls detected 3rd Manual inspection Literature review Collaborations Web User Interface Web Service 40 piftalls Classification: aspects and importance levels 2014 32 pitfalls detected RefinementExtensionCompilation Implementation Linked Data ext. 4th Phase Iterative process 39
  • 40. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Outline •  Introduction •  State of the art •  Work objectives •  Research methodology •  Contributions •  Evaluation •  Conclusions and future work 40
  • 41. Ontology Evaluation: a pitfall-based approach to ontology diagnosis What is a pitfall •  Pitfalls could represent errors •  Pitfalls could lead to errors •  Pitfalls are not always errors depending on: o  modelling decisions taken by the team of developers o  ontology requirements previously set o  application context of the ontology o  the domain of the ontology 41
  • 42. Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 42
  • 43. Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 43
  • 44. Ontology Evaluation: a pitfall-based approach to ontology diagnosis List of 41 pitfalls 44 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P01. Creating polysemous elements P02. Creating synonyms as classes P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” P04. Creating unconnected ontology elements P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P13. Inverse relationships not explicitly declared P14. Misusing “owl:allValuesFrom” P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P19. Defining multiple domains or ranges in properties P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P30. Equivalent classes not explicitly declared P31. Defining wrong equivalent classes P32. Several classes with the same label P33. Creating a property chain with just one property P34. Untyped class P35. Untyped property P36. URI contains file extension P37. Ontology not available on the Web P38. No OWL ontology declaration P39. Ambiguous namespace P40. Namespace hijacking P41. No license declared
  • 45. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 45 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 46. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 46 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 47. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfall template Pitfall template 47 Title Code and title of the pitfall Importance level {Critical | Important | Minor} Aspects Ontology evaluation aspects related to the pitfall Affects to {Ontology | [Classes, Object properties, Datatype properties]} Description Detailed explanation of what the pitfall consists in. This field might contain references to other approaches. Example Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the graphical example or OWL code. How to solve it Description of the actions to be taken by ontology engineers in order to solve the described pitfall. References* Pointers to related bibliographical references or links to URLs. * optional Process details Process details C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 48. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 48 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 1 • Survey Phase 2 • New pitfalls • Assign during description
  • 49. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 49 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Input • 35 pitfall out of 41 • Semantic Web community Process • Survey • Statistical techniques •  Weighted sum •  Lexicographic order •  Centroid function Output •  Classification by importance levels Phase 1 • Survey Phase 2 • New pitfalls • Assign during description
  • 50. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level §  Survey to the Semantic Web community §  For 35 pitfalls §  Participants were asked to mark each pitfall as: o  Critical o  Important o  Minor o  Not a problem (additional) §  54 answers: o  28 experts o  22 medium confidence o  4 low confidence 50 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model According to the negative consequences of each pitfall in the ontology
  • 51. Ontology Evaluation: a pitfall-based approach to ontology diagnosis q  Weighted sum Assigning importance level 51 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 52. Ontology Evaluation: a pitfall-based approach to ontology diagnosis q  Weighted sum q  Lexicographic order Assigning importance level 52 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Critical (1) Important (2) Minor (3) Not im- portant P06. Including cycles in a class hierarchy 47 4 3 0 P19. Defining multiple domains or ranges in properties 42 9 2 0 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 41 7 6 0 P01. Creating polysemous elements 38 13 3 0 P29. Defining wrong transitive relationships 37 12 2 1 P14. Misusing ‘owl:allValuesFrom” 37 9 6 1 P31. Defining wrong equivalent classes 36 13 3 0 P16. Using a primitive class in place of a defined one 35 11 6 1 P15. Using “some not” in place of “not some” 34 13 3 1 P27. Defining wrong equivalent properties 33 14 5 0 P28. Defining wrong symmetric relationships 32 18 2 0 P05. Defining wrong inverse relationships 29 20 5 0 P24. Using recursive definitions 24 23 3 1 P12. Equivalent properties not explicitly declared 23 24 6 0 P10. Missing disjointness 23 18 11 2 P23. Duplicating a datatype already provided by the implementation language 22 25 5 0 P34. Untyped class 21 21 9 2 P35. Untyped property 19 24 8 2 P11. Missing domain or range in properties 19 17 12 4 P25. Defining a relationship as inverse to itself 17 24 12 0 P26. Defining inverse relationships for a symmetric one 15 26 11 0 P18. Overspecializing the domain or range 15 26 9 3 P17. Overspecializing a hierarchy 15 23 13 2 P30. Equivalent classes not explicitly declared 14 33 5 0 P04. Creating unconnected ontology elements 14 22 13 5 P07. Merging different concepts in the same class 13 21 14 5 P02. Creating synonyms as classes 10 24 17 3 P09. Missing domain information 7 33 11 3 P33. Creating a property chain with just one property 7 29 16 0 P21. Using a miscellaneous class 7 24 20 2 P13. Inverse relationships not explicitly declared 7 20 22 4 P32. Several classes with the same label 6 26 18 2 P20. Misusing ontology annotations 4 21 20 8 P08. Missing annotations 2 24 19 9 P22. Using different naming conventions in the ontology 2 22 26 1 Table 2: Pitfalls from P01 to P35 ranked according to the lexicographic order
  • 53. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Assigning importance level 53 Weighted sum Order Normalized Score P06. Including cycles in a class hierarchy 0.0379 P19. Defining multiple domains or ranges in properties 0.0375 P01. Creating polysemous elements 0.0367 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0364 P29. Defining wrong transitive relationships 0.0348 P28. Defining wrong symmetric relationships 0.0344 P31. Defining wrong equivalent classes 0.0343 P05. Defining wrong inverse relationships 0.0342 P14. Misusing “owl:allValuesFrom” 0.0341 P27. Defining wrong equivalent properties 0.0340 P15. Using “some not” in place of “not some” 0.0335 Critical(1) P16. Using a primitive class in place of a defined one 0.0335 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0301 P34. Untyped class 0.0284 P10. Missing disjointness 0.0283 P35. Untyped property 0.0281 P25. Defining a relationship as inverse to itself 0.0279 P30. Equivalent classes not explicitly declared 0.0279 P18. Overspecializing the domain or range 0.0272 P26. Defining inverse relationships for a symmetric one 0.0272 P17. Overspecializing a hierarchy 0.0267 Important(2) P11. Missing domain or range in properties 0.0252 P04. Creating unconnected ontology elements 0.0248 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0240 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0234 P21. Using a miscellaneous class 0.0222 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0201 P22. Using different naming conventions in the ontology 0.0189 P20. Misusing ontology annotations 0.0187 Minor(3) P08. Missing annotations 0.0186 Table 1: Pitfalls from P01 to P35 ranked according to the weighted sum C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Critical (1) Important (2) Minor (3) Not im- portant P06. Including cycles in a class hierarchy 47 4 3 0 P19. Defining multiple domains or ranges in properties 42 9 2 0 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 41 7 6 0 P01. Creating polysemous elements 38 13 3 0 P29. Defining wrong transitive relationships 37 12 2 1 P14. Misusing ‘owl:allValuesFrom” 37 9 6 1 P31. Defining wrong equivalent classes 36 13 3 0 P16. Using a primitive class in place of a defined one 35 11 6 1 P15. Using “some not” in place of “not some” 34 13 3 1 P27. Defining wrong equivalent properties 33 14 5 0 P28. Defining wrong symmetric relationships 32 18 2 0 P05. Defining wrong inverse relationships 29 20 5 0 P24. Using recursive definitions 24 23 3 1 P12. Equivalent properties not explicitly declared 23 24 6 0 P10. Missing disjointness 23 18 11 2 P23. Duplicating a datatype already provided by the implementation language 22 25 5 0 P34. Untyped class 21 21 9 2 P35. Untyped property 19 24 8 2 P11. Missing domain or range in properties 19 17 12 4 P25. Defining a relationship as inverse to itself 17 24 12 0 P26. Defining inverse relationships for a symmetric one 15 26 11 0 P18. Overspecializing the domain or range 15 26 9 3 P17. Overspecializing a hierarchy 15 23 13 2 P30. Equivalent classes not explicitly declared 14 33 5 0 P04. Creating unconnected ontology elements 14 22 13 5 P07. Merging different concepts in the same class 13 21 14 5 P02. Creating synonyms as classes 10 24 17 3 P09. Missing domain information 7 33 11 3 P33. Creating a property chain with just one property 7 29 16 0 P21. Using a miscellaneous class 7 24 20 2 P13. Inverse relationships not explicitly declared 7 20 22 4 P32. Several classes with the same label 6 26 18 2 P20. Misusing ontology annotations 4 21 20 8 P08. Missing annotations 2 24 19 9 P22. Using different naming conventions in the ontology 2 22 26 1 Table 2: Pitfalls from P01 to P35 ranked according to the lexicographic order q  Weighted sum q  Lexicographic order q  Centroid function Centroid function Order Normalized Score P19. Defining multiple domains or ranges in properties 0.0379 P06. Including cycles in a class hierarchy 0.0375 P01. Creating polysemous elements 0.0369 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” 0.0365 P28. Defining wrong symmetric relationships 0.035 P29. Defining wrong transitive relationships 0.035 P05. Defining wrong inverse relationships 0.0348 P27. Defining wrong equivalent properties 0.0344 P31. Defining wrong equivalent classes 0.0341 P14. Misusing “owl:allValuesFrom” 0.034 P15. Using “some not” in place of “not some” 0.0339 Critical(1) P16. Using a primitive class in place of a defined one 0.0334 P23. Duplicating a datatype already provided by the im- plementation language 0.0303 P24. Using recursive definitions 0.0303 P12. Equivalent properties not explicitly declared 0.0297 P34. Untyped class 0.0282 P35. Untyped property 0.0278 P25. Defining a relationship as inverse to itself 0.0278 P18. Overspecializing the domain or range 0.0277 P10. Missing disjointness 0.0277 P30. Equivalent classes not explicitly declared 0.0274 P17. Overspecializing a hierarchy 0.0271 P26. Defining inverse relationships for a symmetric one 0.0277 Important(2) P04. Creating unconnected ontology elements 0.0251 P11. Missing domain or range in properties 0.0247 P09. Missing domain information 0.0245 P33. Creating a property chain with just one property 0.0241 P02. Creating synonyms as classes 0.0239 P07. Merging different concepts in the same class 0.0233 P21. Using a miscellaneous class 0.0225 P32. Several classes with the same label 0.0219 P13. Inverse relationships not explicitly declared 0.0197 P22. Using different naming conventions in the ontology 0.0188 P08. Missing annotations 0.0187 Minor(3) P20. Misusing ontology annotations 0.0186 Table 3: Pitfalls from P01 to P35 ranked according to the centroid function
  • 54. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 54 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 55. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 55 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 1 survey Phase 1 survey Phase 1 survey
  • 56. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Critical (1) P01. Creating polysemous elements P03. Creating the relationship “is” instead of using ''rdfs:subClassOf'', ''rdf:type'' or ''owl:sameAs'' P05. Defining wrong inverse relationships P06. Including cycles in a class hierarchy P14. Misusing ''owl:allValuesFrom'' P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P19. Defining multiple domains or ranges in properties P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P37. Ontology not available on the Web P39. Ambiguous namespace P40. Namespace hijacking Important (2) P10. Missing disjointness P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared P17. Overspecializing a hierarchy P18. Overspecializing the domain or range P23. Duplicating a datatype already provided by the implementation language P24. Using recursive definitions P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P30. Equivalent classes not explicitly declared P34. Untyped class P35. Untyped property P38. No OWL ontology declaration P41. No license declared Minor (3) P02. Creating synonyms as classes P04. Creating unconnected ontology elements P07. Merging different concepts in the same class P08. Missing annotations P09. Missing domain information P13. Inverse relationships not explicitly declared P20. Misusing ontology annotations P21. Using a miscellaneous class P22. Using different naming conventions in the ontology P32. Several classes with the same label P33. Creating a property chain with just one property P36. URI contains file extension Pitfall classification by importance level 56 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Phase 2 Phase 1 survey Phase 1 survey Phase 2 Phase 1 survey Phase 2
  • 57. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 57 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Input • Ontology evaluation dimensions (Gangemi et al., 2006) • Ontology evaluation aspects Process • Manual analysis • Assign one or more aspects to each pitfall • If it does not fit à add new aspect(s) Output •  Classification according to dimensions •  Fine grained division according to aspects Classifying by ontology evaluation aspects
  • 58. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 58 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
  • 59. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 59 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
  • 60. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 60 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
  • 61. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 61 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice P05. Defining wrong inverse relationships P19. Defining multiple domains or ranges in properties P06. Including cycles in a class hierarchy P15. Using “some not” in place of “not some” P18. Overspecializing the domain or range P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P01. Creating polysemous elements *
  • 62. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 62 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects Structural Dimension Usability-profiling Dimension Functional Dimension Ontology Understanding Ontology Clarity Ontology Metadata Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Structural Dimension Functional Dimension Ontology Language Application Context Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice P05. Defining wrong inverse relationships P19. Defining multiple domains or ranges in properties P06. Including cycles in a class hierarchy P15. Using “some not” in place of “not some” P18. Overspecializing the domain or range P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P31. Defining wrong equivalent classes P01. Creating polysemous elements * P13. Inverse relationships not explicitly declared P11. Missing domain or range in properties P12. Equivalent properties not explicitly declared
  • 63. Ontology Evaluation: a pitfall-based approach to ontology diagnosis 63 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Classifying by ontology evaluation aspects P05. Defining wrong inverse relationships P13. Inverse relationships not explicitly declared P19. Defining multiple domains or ranges in properties P24. Using recursive definitions P09. Missing domain information * P07. Merging different concepts in the same class P02. Creating synonyms as classes P20. Misusing ontology annotations P01. Creating polysemous elements * P17. Overspecializing a hierarchy P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” P11. Missing domain or range in properties P21. Using a miscellaneous class P12. Equivalent properties not explicitly declared P23. Duplicating a datatype already provided by the implementation language P04. Creating unconnected ontology elements P06. Including cycles in a class hierarchy P08. Missing annotations P10. Missing disjointness (2) P14. Misusing “allValuesFrom” P15. Using “some not” in place of “not some” P16. Using a primitive class in place of a defined one P18. Overspecializing the domain or range Ontology Understanding Modeling Decisions Requirement Completeness Wrong Inference No Inference Real World Modelling or Common Sense Ontology Clarity P22. Using different naming conventions in the ontology Structural Dimension Usability-profiling Dimension Functional Dimension P25. Defining a relationship as inverse to itself P26. Defining inverse relationships for a symmetric one P27. Defining wrong equivalent properties P28. Defining wrong symmetric relationships P29. Defining wrong transitive relationships P30. Equivalent classes not explicitly declared P31. Defining wrong equivalent classes P32. Several classes with the same label P33. Creating a property chain with just one property Ontology Language P34. Untyped class P35. Untyped property P36. URI contains file extension Application Context P37. Ontology not available on the Web * P38. No OWL ontology declaration * P39. Ambiguous namespace P40. Namespace hijacking P41. No license declared Ontology Metadata P01. Creating polysemous elements * P38. No OWL ontology declaration * P37. Ontology not available on the Web * Legend AspectDimension Critical pitfall Important pitfall Minor pitfall * Pitfall appears twice
  • 64. Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 64
  • 65. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 65 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 66. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 66 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional From pitfall template C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 67. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template Detection method template 67 Code Code of the method Pitfall cardinality {1 |N} Method addresses {Ontology | [Classes, Object properties, Datatype properties]} Technique {[Structural pattern matching, Linguistic analysis, Specific characteristic search]} Pitfall affects to {Ontology | [Classes, Object properties, Datatype properties]} Description General explanation of what the method consists in based on the pitfall to be detected. Limitations* Corner cases or well-known exceptions where the pitfalls are not currently detected. Patterns Graphical representation Natural language description UML_Ont profile OWL source Natural language explanation of the pattern. External resources used* Pointers to external libraries, systems or resources used within the method implementation. * optional From pitfall template C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model
  • 68. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Detection method template 68 §  48 methods for detecting 33 pitfalls §  For each pitfall 0..N methods o  No method: •  Human or background knowledge •  Requirements 2 methods: P12. Equivalent properties not explicitly declared C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model Pitfall Pitfall description Method description P01. Creating polysemous elements Table 4.1 Needs background knowledge. P02. Creating synonyms as classes Table 4.2 Table 5.2 P03. Creating the relationship “is” instead of using “rdfs:subClassOf”, “rdf:type” or “owl:sameAs” Table 4.3 Table 5.3 P04. Creating unconnected ontology elements Table 4.4 Table 5.4 P05. Defining wrong inverse relationships Table 4.5 Table 5.5 P06. Including cycles in a class hierarchy Table 4.6 Table 5.6 P07. Merging different concepts in the same class Table 4.7 Table 5.7 P08. Missing annotations Table 4.8 Table 5.8, Table 5.9 and Table 5.10 P09. Missing domain information Table 4.9 Needs ontology requirements docu- ment. P10. Missing disjointness Table 4.10 Table 5.11 P11. Missing domain or range in properties Table 4.11 Table 5.12 and Table 5.13 P12. Equivalent properties not explicitly declared Table 4.12 Table 5.14 and Table 5.15 P13. Inverse relationships not explicitly declared Table 4.13 Table 5.16 P14. Misusing “owl:allValuesFrom” Table 4.14 Needs background knowledge and hu- man intervention. P15. Using “some not” in place of “not some” Table 4.15 Needs background knowledge and hu- man intervention. P16. Using a primitive class in place of a defined one Table 4.16 Needs background knowledge. P17. Overspecializing a hierarchy Table 4.17 Needs background knowledge and/or ontology requirements document. P18. Overspecializing the domain or range Table 4.18 Needs background knowledge and/or ontology requirements document. P.19 Definining multiple domains or ranges in properties Table 4.19 Table 5.17 and Table 5.18 P20. Misusing ontology annotations Table 4.20 Table 5.19, Table 5.20 and Table 5.21 … 1 method: P07. Merging different concepts in the same class No method: P15. Using “some not” in place of “not some”
  • 69. Ontology Evaluation: a pitfall-based approach to ontology diagnosis C4. OOPS! C1. Pitfall catalogue C3. Detection methods C2. Quality model Contributions 69
  • 70. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P25 70 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itself Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged.
  • 71. Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 71 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged.
  • 72. Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 72 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Title P25. Defining a relationship as inverse to itself Importanc level Aspects Modelling decisions Affects to Description A relationship is defined as inverse of itself. In this case, this relationship c owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural langu <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example “hasBorderWith”, which of itself by means of the How to solve it One should check whether the object property defined as inverse of itself sa tion: every time the object property holds between the individuals “a” and “b” and “a”. If the object property does fulfil the condition, it should be de owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning considered a workaround to avoid increasing the ontology expressivity, it is m object property as symmetric (using owl:SymmetricProperty) instead of as inver Table 6: P25. Defining a relationship as inverse to
  • 73. Ontology Evaluation: a pitfall-based approach to ontology diagnosis P25 description Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8 Pitfalls and methods: example P25 73 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P25. Defining a relationship as inverse to itselfTitle P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Title P25. Defining a relationship as inverse to itself Importanc level Aspects Modelling decisions Affects to Description A relationship is defined as inverse of itself. In this case, this relationship c owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural langu <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example “hasBorderWith”, which of itself by means of the How to solve it One should check whether the object property defined as inverse of itself sa tion: every time the object property holds between the individuals “a” and “b” and “a”. If the object property does fulfil the condition, it should be de owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning considered a workaround to avoid increasing the ontology expressivity, it is m object property as symmetric (using owl:SymmetricProperty) instead of as inver Table 6: P25. Defining a relationship as inverse to Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves
  • 74. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P25 74 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model M1-P25. Detecting relationships inverse to themselvesP25 description While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 Title P25. Defining a relationship as inverse to itself Importance level Important Aspects Modelling decisions Affects to Object properties Description A relationship is defined as inverse of itself. In this case, this relationship could have been defined as owl:SymmetricProperty instead. Examples Graphical representation and/or OWL code Natural language description <<owl:inverseOf>> <<owl:ObjectProperty>> hasBorderWith The graphical example shows the object property “hasBorderWith”, which has been defined as inverse of itself by means of the primitive owl:inverseOf. How to solve it One should check whether the object property defined as inverse of itself satisfies the following condi- tion: every time the object property holds between the individuals “a” and “b” it also holds between “b” and “a”. If the object property does fulfil the condition, it should be defined as symmetric (using owl:SymmetricProperty) and the owl:inverseOf statement should be deleted. While the situation described in this pitfall will not lead to any reasoning problem and it could be considered a workaround to avoid increasing the ontology expressivity, it is more accurate to define the object property as symmetric (using owl:SymmetricProperty) instead of as inverse to itself. Table 6: P25. Defining a relationship as inverse to itself Code M1-P25. Detecting relationships inverse to themselves Pitfall cardinality N Method addresses Object properties Technique Structural pattern matching Pitfall affects to Object properties Description This method iterates over the list of object properties included in the ontology. If a given object property acts at the same time as subject and object in an owl:inverseOf statement (pattern A), then a pitfall is flagged. Patterns Graphical representation and/or OWL code Natural language description Pattern A: <<owl:inverseOf>> <<owl:ObjectProperty>> objectPropertyS The graphical pattern shows an object property that has an owl:inverseOf axiom whose target object property is the same object property. Table 7: Detection method proposed for P25 8
  • 75. Ontology Evaluation: a pitfall-based approach to ontology diagnosis Pitfalls and methods: example P19 75 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer.
  • 76. Ontology Evaluation: a pitfall-based approach to ontology diagnosis P19 description Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer. Table 3: P19. Defining multiple domains or ranges in properties 5 Pitfalls and methods: example P19 76 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong
  • 77. Ontology Evaluation: a pitfall-based approach to ontology diagnosis P19 description Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different domain declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the domain of the property and (b) remove the initial rdfs:domain declarations. For ranges: (a) For each object property with multiple ranges in the ontology, we recommend answering the following question “Does every individual in the range of the given object property necessarily belong to each and every one of the intersected classes?”. If the answer is “no”, developers should (a) join the classes that appear in the different range declarations by the “or” operator (i.e., owl:unionOf) and set this union of classes as the range of the property and (b) remove the initial rdfs:range declarations. (b) For each datatype property with multiple domains in the ontology, we recommend including at most one datatype as range. We recommend taking into account the built-in datatype hierarchy defined in [1] to select such datatype. If there is more than one plausible candidate, find their lowest common ancestor and set it as the range of the datatype property. References [1] Built-in datatype hierarchy http://www.w3.org/TR/xmlschema-2/built-in-datatypes [2] Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C. (2004). OWL pizzas: Practical experience of teaching OWL-DL: Common errors & common patterns. In Engineering Knowledge in the Age of the Semantic Web, pages 63-81. Springer. Table 3: P19. Defining multiple domains or ranges in properties 5 Pitfalls and methods: example P19 77 C1. Pitfall catalogue C4. OOPS! C3. Detection methods C2. Quality model P19. Defining multiple domains or ranges in properties Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering the following question “Does every individual in the domain of the given property necessarily belong Title P19. Defining multiple domains or ranges in proper- ties Importance level Critical Aspects Wrong inference Affects to Object properties Datatype properties Description The domain or range (or both) of a property (relationships and attributes) is defined by stating more than one rdfs:domain or rdfs:range statements. In OWL multiple rdfs:domain or rdfs:range axioms are allowed, but they are interpreted as conjunction, being, therefore, equivalent to the construct owl:intersectionOf. This pitfall is related to the common error that appears when defining domains and ranges described in [2]. Examples Graphical representation and/or OWL code Natural language description Event Nation <<owl:ObjectProperty>> takesPlaceIn <<rdfs:domain>> <<rdfs:range>> City <<rdfs:range>> The graphical example shows an object property, “takesPlacesIn”, whose domain is the class “Event” and whose range is defined as “City” and as “Na- tion”. As the range of the relationship is interpreted as an intersection, whenever an individual appears as object in such relationship, it will be classified both as instance of “City” and “Nation”. This situation is probably not intended by the developer, since the intersection of “City” and “Nation” is the empty set. How to solve it If there is more than one rdfs:domain or rdfs:range statements defined for a given object or datatype property, check: For domains: (a) For each object or datatype property with multiple domains in the ontology, we recommend answering