Semantic Recognition of Ontology Refactoring

856 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
856
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Semantic Recognition of Ontology Refactoring

  1. 1. Web Science & Technologies University of Koblenz ▪ Landau, GermanySemantic Recognition of Ontology Refactoring Gerd Gröner Fernando Silva Parreiras Steffen Staab ISWC2010, Shanghai
  2. 2. Distributed Development of Ontologies Ontology Ontology Ontology Version V1 Change Version V2 Change Version V3 Change ... Ontology Change Version V4 Change ...No change logs!WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 2
  3. 3. What has changed? ontology version V ontology version V Compare ∆? Recognize, analyze and explain!WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 3
  4. 4. Agenda Problem Description and Ontology Refactoring Analyze and describe Changes Recognize Changes Reasoning for Comparison of Ontology Versions Refactoring Recognition Discussion and ConclusionWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 4
  5. 5. Refactoring Scenario ontology version V ontology version V ChangeWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 5
  6. 6. Comparison: What has changed? ontology version V ontology version V Employee ⊑ PersonEmployee ⊑ Person Employee ⊑ ∃ department.DepartmentEmployee ⊑ ∃ project.Project (d) Employee ⊑ ∃≥1 SSN.string (a)Employee ⊑ ∃ department.Department Person ⊑ ∃ name.stringEmployee ⊑ ∃=1 SSN.string (d) Person ⊑ ∃≤1 SSN.string (a)Person ⊑ ∃ name.string Person ⊑ ∃ contact.ContactData (a)Person ⊑ ∃ address.string (d) ContactData ⊑ ∃ telephone.string (a)Person ⊑ ∃ telephone.string (d) ContactData ⊑ ∃ address.string (a) Department ⊑ ∃ project.Project (a) WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 6
  7. 7. Analyze and Describe ChangesObservation: Is the set of axioms (V and V) helpful to recognize changes? How can we communicate about changes? (domain knowledge, modeling details)Idea:➔ Categorize Changes by RefactoringsWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 7
  8. 8. Refactoring Pattern 13 refactoring pattern Example: Extract ClassRefactoring PatternSome properties p1, …, pn of class C should be extracted to a new class DRefactoringE.g., extract properties address and telephoneWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 8
  9. 9. Refactoring: Extract Class V V Employee ⊑ Person Employee ⊑ ∃ department.DepartmentEmployee ⊑ Person Employee ⊑ ∃≥1 SSN.string (a)Employee ⊑ ∃ project.Project (d)Employee ⊑ ∃ department.Department Person ⊑ ∃ name.stringEmployee ⊑ ∃=1 SSN.string (d) Person ⊑ ∃≤1 SSN.string (a)Person ⊑ ∃ name.string Person ⊑ ∃ contact.ContactData (a)Person ⊑ ∃ address.string (d) ContactData ⊑ ∃ telephone.string (a)Person ⊑ ∃ telephone.string (d) ContactData ⊑ ∃ address.string (a) Department ⊑ ∃ project.Project (a) WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 9
  10. 10. Refactoring: Pull-Up Property V V Employee ⊑ PersonEmployee ⊑ Person Employee ⊑ ∃ department.DepartmentEmployee ⊑ ∃ project.Project (d) Employee ⊑ ∃≥1 SSN.string (a)Employee ⊑ ∃ department.Department Person ⊑ ∃ name.stringEmployee ⊑ ∃=1 SSN.string (d) Person ⊑ ∃≤1 SSN.string (a)Person ⊑ ∃ name.string Person ⊑ ∃ contact.ContactData (a)Person ⊑ ∃ address.string (d) ContactData ⊑ ∃ telephone.string (a)Person ⊑ ∃ telephone.string (d) ContactData ⊑ ∃ address.string (a) Department ⊑ ∃ project.Project (a) WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 10
  11. 11. Refactoring: Move Of Property V V Employee ⊑ PersonEmployee ⊑ Person Employee ⊑ ∃ department.DepartmentEmployee ⊑ ∃ project.Project (d) Employee ⊑ ∃≥1 SSN.string (a)Employee ⊑ ∃ department.Department Person ⊑ ∃ name.stringEmployee ⊑ ∃=1 SSN.string (d) Person ⊑ ∃≤1 SSN.string (a)Person ⊑ ∃ name.string Person ⊑ ∃ contact.ContactData (a)Person ⊑ ∃ address.string (d) ContactData ⊑ ∃ telephone.string (a)Person ⊑ ∃ telephone.string (d) ContactData ⊑ ∃ address.string (a) Department ⊑ ∃ project.Project (a) WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 11
  12. 12. Recognition: Difficulties1. (syntactical) comparisonof axioms or triples in Vand V2. purely structuralcomparison➔ Semantic comparisonWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 12
  13. 13. Agenda Problem Motivation and Ontology Refactoring Reasoning for Comparison of Ontology Versions Comparison Problem Solution ➔ Combining Knowledge Bases ➔ Version Comparison Refactoring Recognition Discussion and ConclusionWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 13
  14. 14. The Comparison Problem V V Situation: Conceptual relations in each ontology (version) Same classes, e.g., PersonPerson ⊑ ∃ address.string Person ⊑ ∃ address.string ? Goal: ➔ Conceptual relation across versionsWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 14
  15. 15. Comparison MethodsMatching: compare class and property names and typesStructural and semantic comparison: class subsumptionchecking to compare their extensions➔ Joint reasoning on two ontology versions to identify conceptual relationsProblems: How to connect them? How to compare them? WeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 15
  16. 16. Connecting two Versions1. Matching between classes2. Renaming of classes that appear in both versions Person1 ⊑ ⊤ Person2 ⊑ ⊤3. Introduce a common superclass Person1 ⊑ Person Person2 ⊑ Person4. Relax range ContactData ⊑ ∃ person . Person1 ⇒ ContactData ⊑ ∃ person . PersonWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 16
  17. 17. Comparison – affected axiomsVariety of modeling principles in OWL➔ Only some need to be considered:Property restrictions:Corresponding axioms: Person ⊑ ∃ contact.ContactDataPerson ⊑ ∃ address.string ContactData ⊑ ∃ address.string → Analyzes: Class expressions of property restrictionsWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 17
  18. 18. Comparison – affected axioms (2)Sub- and superclasses:Corresponding axioms: Employee ⊑ Person Employee ⊑ Person Employee ⊑ ∃≥1 SSN.string Employee ⊑ ∃=1 SSN.string Person ⊑ ∃≤1 SSN.string→ Analyzes: Subclass axioms and property restrictions➔ Only certain kinds of axioms are relevant!➔ Next Step: Normalization to ease version comparisonWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 18
  19. 19. NormalizationAnalyze axioms of class definitions of class C: Conjunctive normal form of C: Ĉ ≡ C1 ⊓ … ⊓ Cn ∀ i = 1 … n: C ⊑ Ci Reduced conjunctive normal form: Ċ • Flattened nested conjunctions: A ⊓ (B ⊓ C) → A ⊓ B ⊓ C • Normalized negation: ¬D → D is a named class • B ⊑ A and A ⊔ B : A ⊔ B → AWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 19
  20. 20. Reduced Conjunctive Normal Form Uniqueness of the normal form Ċ Ċ is reduced conjunctive normal form of Ĉ ≡ C1 ⊓ … ⊓ Cn for each Ci one of the following condition holds:  Ci is a named class  Ci is a data type or object property restriction  Ci is a complex class definition that is neither a named superclass of C nor a property restrictionWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 20
  21. 21. Using the NormalizationExploit two results1. Only certain types of axioms are affected by the refactoring ➔ Other axioms can be neglected2. Representation in the normal form ● Axioms are covered by the normal form representation ● Uniqueness: class expressions C of C can be extracted i ● Each Ci of C subsumes C➔ Analyze changes by comparing class expressions Ci of C and C using subsumption checkingWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 21
  22. 22. Diff and Common AlgorithmDiff: Compute class expressions (superclasses) from C and C1. Class expressions of C in version V but not in VE.g.,For each class expression A of Ċ If the subsumption ( A ⊑ C ) does not hold then Class expression A belongs to the difference2. Likewise the expressions of C in version V but not in V➔ Difference is computed in two steps (invert V and V):Reduced conjunctive normal form applies to the class expressions of the resultWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 22
  23. 23. Agenda Problem Motivation and Ontology Refactoring Reasoning for Comparison of Ontology Versions Refactoring Recognition Discussion and ConclusionWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 23
  24. 24. Refactoring Recognition Each pattern:  specification of differences for comparing two versions  description of conditions on these differences Comparison algorithms: determining the different and common parts of a class in two versions  Comparing class expressions of Ċ  Using subsumption checking to test the conditions on the differencesWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 24
  25. 25. Extract ClassV VDifference (C = Person):D2 = { ∃ address.string, D1 = { ∃ contact.ContactData } ∃ telephone.string }Extracted Class: RC = ContactData (range of ∃ contact.ContactData)Condition: ContactData ⊑ ∃ address.string ContactData ⊑ ∃ telephone.string are inferred in VWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 25
  26. 26. ConclusionDescribed Solution:Adopted 13 refactoring patterns and described the recognitionRealization:Class comparison using subsumption checking Connect versions (V and V are unaffected) Compare classes and class expressions of Ċ Only certain class expressions are relevant in the refactoringFuture Work:Consider further refactoring patternsWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 26
  27. 27. Thank You! Supported by: MOST-ProjectWeST Gerd Gröner ISWC 2010 groener@uni-koblenz.de 27

×