1. 1 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 1 Advanced databases – Defining and combining heterogeneous databases: Ontology evolution Bettina Berendt Katholieke Universiteit Leuven, Department of Computer Science http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ Last update: 8 November 2007

2. 2 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 2 Agenda Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies

3. 3 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 3 Changes (1) n Recall: Lessons learned in EDI: Semantics are dynamic (new EDIFACT versions, often > once a year!) n What can change? l „An ontology is an explicit specification of a conceptualization of a domain.“ (Gruber, 1993)  l Changes in the domain –e.g., fusion of two companies l Changes in conceptualization –e.g., transport connections: bicycle perspective – ship perspective  implications on bridges l Changes in the explicit specification –e.g., change of ontology language

4. 4 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 4 Changes (2) How can the need to change be discovered? n Structure-driven l based on the knowledge of ontology engineers that they use in the decision making during the ontology evolution. l exploits a set of heuristics to improve an ontology based on the analysis of its structure. l e.g., „A concept with a single subconcept should be merged with its subconcept.“ n Data-driven l Reflecting changes in the data that are modelled by the ontology l e.g. „If no instance of a concept C uses any of the properties defined for C, but only properties inerited from the parent concept, C is not necessary.“ n Usage-driven l Usage patterns show more or less often used parts  user interest l E,g., „If a concept has not been queried for 6 months, it is probably out of date and not needed any more.“

5. 5 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 5 2 Examples of manual ontology evolution

6. 6 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 6 Example 1: The Gene Ontology – basic evolution procedure n www.geneontology.org www.geneontology.org n Developed since 2000 (Ashburner et al., 2000) n Goal: provide a controlled vocabulary that can be applied to all organisms, even as knowledge of gene and protein roles in cells is accumulating and changing n A few full time „curators“ that work on the vocabulary and relations n GO users can make change requests and track progress n Procedures to check for local conflicts n Daily changes, monthly new versions

7. 7 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 7 Example 1: The Gene Ontology – reasons, problems, policies n Reasons for changes: l search for completeness  mostly additions l Repairing errors n Problems and fixes: l It was not possible to track a term that disappeared  Obsoleting instead of deleting terms l Mis-annotation (e.g., because of ambiguous definitions, no triggers when def. Changed)  Policy: definitions may not be changed; if there is a different meaning, a new term has to be introduced with a different ID

8. 8 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 8 Example 2: Category schema top level

9. 9 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 9 Example 2: Category schema lower level

10. 10 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 10 Example 2: revision history

11. 11 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 11 Example 2: discussion of revision history

12. 12 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 12 Types of changes (How can the ontology change?) n Extensions (see last session) n Ontology merging (based on identified matching elements) n Any other types of changes (such as the examples given above)

13. 13 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 13 Agenda Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies

14. 14 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 14 The ontology merging task n Given two source ontologies O1 and O2, create a new ontology Om (merged ontology) n Decisions are necessarily subjective, e.g. l Some parts of the source ontologies will not be included (even if they match) because unimportant for task at hand l Subjectivity as to whether parts of the source ontologies represent similar concepts or not

15. 15 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 15 Ontology merging: needs analysis n Name searching support (across multiple ontologies) n Support for changing names in a systematic manner n Support for merging multiple terms into a single term n Focus of attention support for term merging based on term names n Focus of attention support for term merging based on the semantics of term descriptions n Browsing support for class and property taxonomies n Support for modifying subclass/subsumption relationships n Support for recognizing logical inconsistencies introduced by merges and edits n Diagnostic support for verifying, validating, and critiquing ontologies n... consistency matching usability

16. 16 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 16 iPROMPT: overview n a part of the PROMPT suite, an extension to Protégé n Leads users through the ontology merging process n suggests what should be merged, identifying inconsistencies + potential problems n Suggests strategies to resolve them n Uses only local context in decision making: n Class to be inspected  properties  classes referenced through range restrictions

17. 17 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 17 iPROMPT: example

18. 18 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 18 1. Create an initial list of matches based on lexical similarity of class names

19. 19 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 19 2. Merging Cycle 1. User triggers an operation (select or specify) 2. system performs the operation 3. system automatically executes additional changes based on the type of the operation 4. System generates a list of suggestions for the user 5. System determines inconsistencies and potential problems 6. Tries to find possible solutions

20. 20 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 20 Operations n Operations performed during traditional ontology editing of a single ontology n Operations specific to merging and alignment: l Merge classes l Merge properties l Merge instances l Perform a deep or shallow copy of a class from one ontology to another

21. 21 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 21 Operation „merge classes“ n To merge two classes A and B, create a new class M in Om n For each class C that is a subclass or a superclass of A or B: l If there is an image Ci of C in Om: –Ci becomes a subclass or superclass of M, resp. n For each property P attached to A or B, l if there is no image of P in Om, –copy P to Om n For each image Pi of P, l attach Pi to M n If A or B was already in Om prior to the operation l All references to it in Om become references to M, l original class is deleted

22. 22 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 22 Operation „merge properties“ n To merge two properties P1 and P2, create a new property Pm n For each class C in the domain and range of P1 or P2 l If there is an image Ci of C in Om, –add Ci to the domain or range of Pm, resp. n If either P1 or P2 was in Om prior to the operation l All references to it become references to Pm, l original property deleted

23. 23 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 23 Operation „merge instances“ n To merge two properties I1 and I2, create a new instance Im n If classes C1 and C2 (types of I1, I2) have no images in Om l Shallow-Copy them to Om n If they already have images l Merge the images (user must confirm!) n For each value V for each property P attached to I1 or I2 l If V is a primitive value // P is a datatype property –Add V to the value of the image of P for Im l If V is an object and there is an image of V, Vi, in Om // P is an object property –Add Vi to the value of the image of P for Im

24. 24 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 24 Operation „perform a shallow copy of a class“ n When copying a class C, create a new class Ci in Om n For each property P directly attached to C l If there is no image of P in Om –Copy P to Om –Attach images of all the properties of C to Ci

25. 25 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 25 Operation „perform a deep copy of a class“ n Copy all the parents of a class up to the root of the hierarchy n = perform the shallow copy of this class & a deep copy of its superclass (where deep copy of root = do nothing)

26. 26 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 26 Inconsistencies and potential problems n Name conflicts l Ontologies have unique names assumption! l Suggestion: rename one of the offenders n Dangling references l Range type of a property may not exist yet l Suggestion: copy the dangling element to Om (see also: merge classes) n Redundancy in the class hierarchy l > 1 path from a class to its superclass l Suggestion: remove one of the offending parents (but not necessary) n Property values violate property-value restrictions l Especially when merging instances l Suggestion: ?

27. 27 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 27 Suggestions n Class merge: l Merge sub-/superclasses with linguistically similar names l Merge properties with linguistically similar names n Property merge, instance merge: l merge classes in the domain and range of Pm that came from different source ontologies

28. 28 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 28 Example: state after merging Person classes and sex/gender properties

29. 29 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 29 Agenda Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies

30. 30 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 30 Roots: Schema evolution (et al.) in databases n Schema modification: l A DB allows changes to the schema definition of a populated DB n Schema evolution: l A DB system facilitates the modification of the DB schema without loss of existing data n Schema versioning: l A DB system allows the accessing of all data, both retrospectively and prospectively, through user-definable version interfaces n Note: changes have a transaction time!

31. 31 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 31 Example: domain/type evolution n Want to replace position code by a four-digit integer code n Issues include: l Is the position code attribute to be defined as (the hybrid) alphanumeric despite the new position codes being purely numeric? l Is another attribute required to store the old codes, if so, for how long is this attribute retained? How is this old field related to the new one by the applications? l What about position histories and retired employees for whom no new format position code may be allocated?

32. 32 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 32 Further issues n Architectural l Data conversion mechanisms l Access right considerations l Concurrency considerations n Query-language support l Which schema should a query refer to? What is the effective schema definition that should be used (data valid time – data transaction time – schema time)? –Ex. Query: „Find all employees who earned more than $40,000 in 1992, as recorded on January 1, 1993, and report the details using the format in use in March 1993.“  should this be supported? l Periodic updating of old data by providing selection predicates indicating schema format time

33. 33 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 33 Agenda Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies

34. 34 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 34 Differences between ontologies and database schemas n Ontologies are data too n Ontologies themselves incorporate semantics n Ontologies are more often re-used n Ontologies are de-centralized by nature n Ontology data models are richer n Classes and instances can be the same

35. 35 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 35 Implications for evolution and versioning of ontologies n Ontology versioning and evolution is change management l The traditional distinction between versioning and evolution is not applicable n Compatibility of ontologies has several dimensions l Instance-data preservation l Ontology preservation l Consequence preservation l Consistency preservation n Ontology-change operations and effects l See table on the next slides n Two modes of evolution l Traced and untraced l Untraced: find the mapping (~ „the opposite of ontology merging“)

36. 36 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 36 Effects of operations + : information-preserving changes – no instance data is lost ~ : translatable changes – no instance data is lost if a part of the data is translated into a new form – : information-loss changes – it cannot be guaranteed that no instance data is lost

37. 37 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 37 Operations (1) Delete property P Create property P Delete class C Create class C Operation Remove a property P from class C Attach a property P to class C – + – + Effect – + Values of P for all instances are lost If instance move to superclass: Instances of C become less specific No data lost Comment Values of P for instances of C are lost

38. 38 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 38 Operations (2) Re-classify a class C as an instance Re-classify an instance I as a class Remove a subclass- superclass link between SubC & SuperC Add a subclass-superclass link between SubC & SuperC Operation Define a property P as transitive or symmetric Declare classes C1 and C2 as disjoint – + – + Effect – – Instances of C are less specifically typed SubC lost the properties inherited from SuperC (values lost) SubC has new properties inherited from SuperC (cf. adding new p.s) Comment Property values for P that violated the t./s. restriction are invalid Instances that belonged to both C1 and C2 are invalid

39. 39 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 39 Operations (3) Encapsulate a set of properties into a new class Move a property P from a class C1 to a referenced class C2 Move a property P from SuperC to SubC („move P down“) Move a property P from SubC to SuperC („move P up“) Operation Change a superclass of C to a class lower in the hierarchy („move class down“) Change a superclass of C to a class higher in the hierarchy („move class up“) ~ ~ – + Effect + – No data lost if values of the property are moved SuperC no longer has P. Values for P for instances of SuperC are lost SubC still inherits P; instances preserve all the values Comment C has possibly inherited additional properties; no data lost C loses its properties inherited from the direct superclass; values lost

40. 40 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 40 Operations (4) OperationEffectComment „Widen“ a restriction for a property P (e.g., increase no. Of allowed values, replace a class in the range with its superclass) +All the existing property values are still valid. „Narrow“ a restriction for a property P (e.g., increase no. Of allowed values, replace a class in the range with one of its subclasses) –Slot values that violated the narrower restriction are invalid Merge classes: the superclasses, subclasses, and properties of the merged class are the union of the superclasses, subclasses, and properties of the original ~No data lost if values of p.s are moved. However, cf. „adding subclass link“ Split a class; operation can specify which of the new classes the instances of the old class belong to based on a p. value ~No data lost if values of p.s are moved.

41. 41 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 41 Agenda Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies

42. 42 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 42 So what to do in those unclear cases? n Identify pre- and postconditions for each change n Both are parts of a consistent state of the ontology n Execute a change only if the preconditions are satisfied n Commit a change only if the posconditions are accomplished

43. 43 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 43 Examples

44. 44 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 44 The „semantics of change“ phase in ontology evolution n Task: enable the resolution of changes in a systematic manner by ensuring the consistency of the whole ontology n Method: identify and perform requested and derived changes n (cf. Ontology merging!)

45. 45 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 45 Problem example: deleting a class

46. 46 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 46 Solution

47. 47 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 47 Two methods for (semi-)automating the semantics of change n Procedural approach l Based on constraints that define the consistency of a schema and on definite rules l User-driven ontology evolution: the ontology engineer specifies an evolution strategy to tailor ontology evolution to suit her needs [and the system executes those changes] n Declarative approach l Based on the sound and complete set of axioms (provided with the inference mechanism) that formalises the dynamics of evolution l Removes control flow and sequencing from the solution l User specifies only the conditions that should hold before + after n In the following, I will show only the procedural approach

48. 48 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 48 There are many ways to achieve consistency after a change request  Should be possible to specify an evolution strategy Existing system usually only realize one (the simplest) strategy

49. 49 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 49 Identify dependencies Table: The cause and effect relationship between ontology changes organised as the Dependency matrix. The value x of an element, i.e. Dependency[i][j]=x, indicates that the resolution of a change related to the row i might induce a change related to the column j. [partial view:]

50. 50 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 50 Determine evolution strategy = how to deal with resolution points See ex. 2 pp.s ago

51. 51 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 51 Resolution points and elementary evolution strategies (contd.)  Further resolution points: See Stojanovic (2004), pp. 97f.

52. 52 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 52 Propagating the changes according to the evolution strategy... (the other cases) [see Stojanovic (2004), pp. 103f.]

53. 53 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 53 Advanced evolution strategies n Automatically combine available elementary evolution strategies to satisfy the user‘s critiera: l Structure-driven –e.g., number of levels of ontology (  ex. MEDLINE) l Process-driven –e.g., optimize cost of process, minimize number of steps l Frequency-driven –Apply the most often used or most recently used strategy

54. 54 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 54 Next lecture Motivation: Why change an ontology? “Between matching and evolution”: Ontology merging “The roots”: (Database) Schema evolution Issues and operators in ontology evolution Consistency-maintaining changes & evolution strategies Web services

55. 55 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 55 Similarities between (database schemas and ontologies) or (databases and knowledge bases) n Same problems: Match conceptual schemata, map instances n Much overlap in expressivity, including l Objects, l properties, l aggregation, l generalization, l set-valued properties, l constraints n Structural similarities: l Matching structure of relational tables  matching class hierarchies  Can re-use schema matching methods from DB literature

56. 56 Berendt: Advanced databases, winter term 2007/08, http://www.cs.kuleuven.be/~berendt/teaching/2007w/adb/ 56 References / background reading; acknowledgements n Gene ontology evolution strategy reported in: l Michel Klein Change Management for Distributed. Ontologies. Disseration VU Amsterdam 2004. www.cs.vu.nl/res/theses/klein_thesis.pdfwww.cs.vu.nl/res/theses/klein_thesis.pdf n Ontology merging: l DL McGuinness, R Fikes, J Rice, S Wilder. An environment for merging and testing large ontologies. Proceedings of the Seventh International Conference on …, 2000 http://dit.unitn.it/~accord/RelatedWork/Matching/McGuinnessKR.pdfhttp://dit.unitn.it/~accord/RelatedWork/Matching/McGuinnessKR.pdf l NF Noy, MA Musen. The PROMPT suite: interactive tools for ontology merging and mapping. International Journal of Human-Computer Studies, 2003 http://smi.stanford.edu/people/noy/papers/InteractiveMergingTools.pdf http://smi.stanford.edu/people/noy/papers/InteractiveMergingTools.pdf n Schema versioning: l J.F. Roddick. A Survey of Schema Versioning Issues for Database Systems. Information and Software Technology, 37(7):383--393, 1995. http://citeseer.ist.psu.edu/roddick95survey.html http://citeseer.ist.psu.edu/roddick95survey.html n Ontology evolution and schema evolution: l N. F. Noy, M. Klein, Ontology evolution: not the same as schema evolution, Knowledge and Information Systems, Volume 6, Number 4, July 2004, available as SMI technical report SMI-2002-0926, http://smi- web.stanford.edu/pubs/SMI_Abstracts/SMI-2002-0926.html, 2002.http://smi- web.stanford.edu/pubs/SMI_Abstracts/SMI-2002-0926.html l Ljiljana Stojanovic. Methods and Tools for Ontology Evolution. Dissertation Univ. Karlsruhe, 2004. http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1241http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1241 n Picture on p. 12: http://www.w3c.de/PubPraes/PNGS/Merge.pnghttp://www.w3c.de/PubPraes/PNGS/Merge.png