1. Evolution of OWL 2 QL and EL Ontologies Bernardo Cuenca Grau, Ernesto Jiménez-Ruiz Computer Science Department, University of Oxford, UK Evgeny Kharlamov, Dmitriy Zheleznyakov KRDB research centre, Free University of Bozen-Bolzano, Italy

2. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 2

3. Ontologies: schema + data o Schema provide o standard vocabularies for data o a way to structure data o means for machines to be able to understand data o Schemas are in terms of o classes: Person, Country,... o (binary) properties: State-of-Origin, Subclass-of,... o Data is a collections of facts o Instantiations of classes o Instantiations of properties 3

4. Domain ontologies o Goal: to provide standard vocabularies to communities o Clinical sciences ontologies: o SNOMED CT : Systematized Nomenclature of Medicine - Clinical Terms o > 311k concepts o NCIt : National Cancer Institute thesaurus o ~ 89k concepts, 200m cross links between them [NCI] o FMA : Foundational Model of Anatomy o 75k classes, 168 relations, 120k terms, 3.1m relat. inst. 4

5. Languages for domain ontologies o Domain ontologies are o complex and large o manually created o should be error free o Languages that are natural for domain ontologies o flexible to capture complex interaction o logic-based (e.g., based on Description Logics) o Ontology Web Language: OWL 2 o OWL DL o OWL 2 QL o OWL 2 EL o e.g. SMOMED 5 forall x: instance-of (x, Common cold)  exists y: instance-of (y, Virus) and causative-agent (y, x)

6. Evolution in SNOMED 6 o Development teams o 1 main team and o 4 geographically distributed teams o each team makes modifications o Every 2 weeks the main team o integrates changes, resolve conflicts o From 2002 to 08 SNOMED went from 278k to 311k concepts [SM-1] o Example of modifications: o In Jan. 2006 a number of concepts from the “Clinical finding” hierarchy were moved to the “Event hierarchy” [SM-2]

7. Evolution in NCI and FMA o Developers of NCI do over 900 monthly changes [HKR’08] o 20 full time editors for NCI o they work o independently o on a separate copy of the ontology o There is one curator for NCI o every 2 weeks curator o reviews changes using a workflow management tool o approves the changes o they merge results once a month o there is one curator who curates once a month o FMA “is an evolving computer-based knowledge source...” [FMA] 7

8. Evolution of domain ontologies o Evolution of domain ontologies is common o Ontologies are changed by o insertion of axioms o deletion of axioms o Evolution affects both o schema level o data level 8 Evolution of domain ontologies should be error free

9. Design errors: incoherency o incoherency is a schema level design error: o incoherent concept = empty concepts o can be caused by disjointness and cardinality restrictions o incoherent role = empty role o can be caused by disjointness and cardinality restrictions 9 EquivalentClasses( :Nothing ObjectIntersectionOf( :Airplane :Boat)) SubClassOf( :Amphibian :Airplane) SubClassOf( :Amphibian :Boat )

10. Design errors: inconsistency o Inconsistency is an error that involves both o data level and o schema level o Inconsistency: o disjoint concepts are Instantiated o functionality is violated o number restrictions are not respected 10 EquivalentClasses( :Nothing ObjectIntersectionOf( :Airplane :Boat )) ClassAssertion(:Airplane :BerievA-40 ) ClassAssertion(:Boat :BerievA-40 )

11. Insertions bring errors o Insertions introduce errors which should be repaired o Incoherency o Inconsistency o Challenge : how to repair the ontology after “bad” insertions? 11 EquivalentClasses( :Nothing ObjectIntersectionOf( :Airplane :Boat )) ClassAssertion(:Airplane :BerievA-40 ) EquivalentClasses( :Nothing ObjectIntersectionOf( :Airplane :Boat )) SubClassOf( :Amphibian :Airplane) SubClassOf( :Amphibian :Boat ) ClassAssertion(:Boat :BerievA-40 )

12. Deletions bring headache o Deletions do not introduce (design) errors o no inconsistency o no incoherency o Contraction can provoke o restoring of implicit data o deletion of implicitly related data 12 SubClassOf( :Airplane :Transport ) ClassAssertion( :Transport :BerievA-40 ) SubClassOf( :Airplane :Transport ) ClassAssertion( :Airplane :BerievA-40)

13. Deletions bring headache o Deletions do not introduce (design) errors o no inconsistency o no incoherency o Contraction can provoke o restoring of implicit data o deletion of implicitly related data 13 SubClassOf( :Airplane :Transport ) ClassAssertion( :Airplane :BerievA-40 ) ClassAssertion( :Transport :BerievA-40 ) o Challenge : how to respect implicit relations while deleting knowledge?

14. SPARQL 1.1 Update o Proposed by HP and based on SPARUL extension of SPARQL for o adding o deleting o updating RDF triples o Deletion without deletion effect o only explicit occurrences of triples are deleted o there is no validation whether the tuple is still there implicitly 14 SubClassOf( :Airplane :Transport ) ClassAssertion( :Airplane :BerievA-40 ) SubClassOf( :Airplane :Transport ) ClassAssertion( :Airplane :BerievA-40 ) ClassAssertion( :Transport :BerievA-40 )

15. Syntactic approaches to evolution 15 o In the ontology: o “Children are baklava fans” o “Children are not cats” o To delete: “Children are baklava fans” o To this end it is enough to delete [HS’05] [JRCGHB’11] [KPSCG’06] and o In the resulted ontology: o “Children are not baklava fans” o “Children are not cats” is lost OK Not desirable

16. Semantic approaches to evolution o How to restore knowledge which o was semantically deleted and o is desirable o One has to find semantic difference between o the original and o the obtained ontology o There is a number of approaches and tools to find semantic difference o Collaborative Protege o DOGMA-MESS o Content CVS approach o.... 16 [FDCM’08] [MDM’06] [JRCGHB’11]

17. Limitations of current sem. approaches o Quite application and language oriented o Heuristic based o What is missing: the big picture o a general understanding of evolution of logic based ontologies o proper theory that explains relationships among o different types of ontology modifications o different ontology languages o feasibility and complexity of evolution computation o There are several attempts to understand logic based evolution o We are working on that too 17 2 nd part of this tutorial is about current achievements in this direction!

18. Summary on domain ontologies o Domain ontologies are o large o logic based o Changes in domain ontologies o are frequent o are about insertion and deletions o Insertions easily introduce errors o incoherency o inconsistency o Deletions o do not introduce (logical) errors o not trivial: implicit knowledge relationships should be traced 18

19. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 19

20. Web knowledge bases (ontologies) o Goal: gathering general purpose knowledge from the Web o DBpedia : o structural counterpart of Wikipedia o 320 classes, 1.650 different properties, 19m facts o Yago : o combines Wikipedia and WordNet, GeoNames, o 10m entities, 120m facts about them o (Open)Cyc: o started in 1984, formalizing knowledge manually o logic based KB with reasoing o 47.000 concepts, 306.000 facts o These ontologies are not static o they constantly change, since Wiki does so o Yago crawls Wikipedia every couple of weeks 20...

21. Languages for Web KBs o Web KBs o have rather simple and small schemas o should be error free o errors are rare o Languages that are natural for domain ontologies o able to describe basic things o SubClassOf, Domain, Range, etc. o These languages are: o Resource Description Framework with Schema: RDF and RDFS o a bit of OWL 2: owl:equivalentClass o Some rule languages: OWL 2 RL o Evolution is performed ad hoc o Each KB has its approach 21

22. Evolution in DBpedia o DBpedia o 18 functional properties o new information is obtained from Wikipedia o new data can violate functional properties o Inconsistency is possible 22 FunctionalObjectProperty( :netIncome) FunctionalObjectProperty( :co2Emission) FunctionalObjectProperty( :height)...

23. Evolution in Yago o Yago is a clean (inconsistency fee) ontology o 95% of accuracy - manually validated on 6k facts o New knowledge should not cause contradictions 23

24. Yago consistency check [Yago-1] o Yago has rules to check consistency o check uniqueness of entities and functional arguments o domains and rages of relations o type checking 24 Rock Singer type 1935 born Singer subclassOf Physics born GuitaristGuitar

25. Summary on Web KBs o Web KBs aim at consistency o Schemas of Web KBs are rather simple and small o it is hard to make errors o Evolution is performed ad hoc 25

26. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 26

27. Ontologies for semantic markup o Goal: o to nest semantics within existing content on web pages o to help search engines, crawlers and browsers find the right data 27 Person: name photo URL... text embedding semantic annotations

28. Standards for semantic markup o Microformats, since 2003 o Small set of fixed formats. E.g.: o hcard : people, companies, organizations, and places o XFN : relationships between people o hCalendar : calendaring and events o RDFa : Resource Description Framework – in – attributes o since in 2004, W3C recommendation o serialization format for embedding RDF data into HTML pages o can be used together with any vocabulary, e.g. FOAF o Microdata o alternative techniques for embedding strucuted data o proposed in 2009, comes with HTML 5 28

29. Is semantic markup popular? [CB’12] o Yahoo Crawl of 2011 o 12 billion pages were crawled o 431 million of then contain RDFa 29 in 2011 - 3.5% of the HTML pages had structured (meta) data VocabularyNumber of web sites Dublin Core344.545 Open Graph Protocol177.761 Creative Commons37.890 Google’s Rich Snippets Vocab.6.083 Friend-of-a-Friend2.545...

30. Big step in promoting ontologies o Schema.org initiative : o started on June 2011 o initiated by Bing, Google, Yahoo!, Yandex o they propose: to mark up / annotate websites with metadata o they support: Microdata 30

31. Schema.org ontologies o Metadata by Schema.org: o Person o Organization o Event o Place o Product o... o 200+ types 31

32. Where can you see Scmeha.org impact? 32

33. Semantic markup today o Common Crawl foundation o goal: building and maintaining an open crawl of the Web o current data is about 5 billion web pages o WebDataCommons.org project o goal: extracting Microformats, Microdata, RDFa from Common Crawl corpus o Feb 2012: o processed 1.4 billion HTML pages of CC corpus o 20.9 Terabyte of compressed data o this is a big fraction of the Web 33

34. Structured Web data is fast growing o 1.4 billion HTML pages processes o 188 millions of them contain structural data in Microformat, Microdata, RDFa [CB’12] o This data is 3.2 billions RDF triples 34 13% of the HTML pages contain structured (meta) data from 2011 to 2012 the fraction of structured data went from 3.5% to 13%

35. Evolution at schema level: Schema.org o It is a very simple and coherent schema o Coherency o basic Schema.org vocabulary can be mapped to RDFS o RDFS schemas are always coherent so does Schema.org o What is used from RDFS: [SO-2] o subclass o domain, range restriction of properties o literal, o... o Schema can be extended o mechanism: specialization o of classes, properties, enums o Person/Engineer [SO-3] 35 PloiceStation A police station. Subclass of: CivicStructure Subclass of: EmergencyService creator The creator/author of this Creative Work Domain: CreativeWork Domain: UserComments Range: Person Range: Organization

36. Evolution at data level: Schema.org o It is RDFS embeddable  no inconsistency is possible o Schema.org convention: on range restriction [SO-1] o each property may have 1 or more types at its range o the value(s) of the property should be instances of at least one of these types o Thus, they accept that data can be inconsistent 36

37. Evolution at data level: Schema.org o Is data inconsistency important? o Data gathered by crawling the Web is inconsistent by nature o data consistency is not important o data consistency is unrealistic o Data maintained locally can be consistent o consistency of data can be important 37 In the spirit of "some data is better than none", we will accept this [inconsistent] markup and do the best we can. [SO-1]

38. Summary on semantic markup o Semantic mark up schemas are o small o very simple o In many cases logical errors with semantic markup are simply impossible o Consistency and coherency is in general not important 38

39. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 39

40. Summary: ontologies and evolution o Three major groups of ontologies o unification of terminology by specific communities o domain ontologies o storing general purpose web content in o Web knowledge bases o enriching Web content with information understandable by agents, e.g. crawlers – 13% of Web data is enriched! o ontologies for semantic markup o In all these cases ontologies are dynamic o insertions and o deletions happen at the level of o schema and o data 40

41. Summary: attitude to evolution 41 ontologies for semantic markup domain ontologies Web knowledge bases o schema is simple (RDFS): errors are (almost) impossible o data may disrespect the schema o “some data is better than none” o “do the best we can” o schema is more involved but still no incoherency (RDFS + some OWL e.g., functionality) o data may be inconsistent o conflicts can be detected by simple reasoning o many problems are solved by type checking o schema is complex (OWL 2) – incoherency o data can easily be inconsistent o coherency + consistency are vital o logical reasoning can guarantee it don’t care logic based

42. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 42

43. Logic-Based Evolution o The main principle of logic-based evolution is the principal of minimal change o Ontologies should change as little as possible o There are two main classes of logic-based approaches: o Model-based approach (MBA) o Formula-based approach (FBA) o There are two main types of evolution: o Update (or revision), when new information is added o Contraction (or erasure), when some old information is retracted o We illustrate o update with MBA o contraction with FBA 43 [KM’91] [EG’92] [LLMW’06] [QD’09] [WWT’10] [Wins’90] [CKNZ’10] [KZ’11] [Wins’90] [DGLPR’09]

44. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 44

45. MBA: Evolution Process 45 Ontology Models Model Transformer Evolved models Evolved ontology New data

46. MBA: Ontology to Models 46 Priest Bob WifeHusband MaryJohn Model 1: Model 2: Priest Bob Adam WifeHusband MaryPeter …

47. MBA: Evolution Process 47 Ontology Models Model Transformer Evolved models Evolved ontology New data

48. MBA: Data Evolution 48 Priest Bob WifeHusband MaryJohn Model 1: Model 2: Priest Bob Adam WifeHusband MaryPeter … Dalal’s operator Satoh’s operator … Winslett’s operator

49. WifeHusband MaryJohn Priest Bob Model 1: Priest Bob Adam 49 ✔ Model 2.1: WifeHusband MaryJohn ✔ Priest Bob Adam WifeHusband MaryPeter AnnaJohn Model 2.2: ✔ WifeHusband MaryPeter ✘ Model 2: MBA: Data Evolution

50. MBA: Evolution Process 50 Ontology Models Model Transformer Evolved models Evolved ontology New data

51. WifeHusband MaryJohn Priest Bob Model 1: Priest Bob Adam Model 2.1: WifeHusband MaryJohn Priest Bob Adam WifeHusband MaryPeter AnnaJohn Model 2.2: 51 MBA: Models to Ontology

52. Models Model Transformer New data Winslett’s operator Evolved models MBA: Issues 52 Ontology Evolved ontology Can be computationally hard Can be inexpressible

53. MBA: Example of Issues 53 MaryJohn Models: Priest Bob 1. WifeHusband MaryPeter Priest Bob John 2. WifeHusband MaryBob Priest John 3. WifeHusband John

54. MBA: Example of Issues o The case analysis of the situation with Mary gives that: o Bob is not a priest iff Bob is Mary’s husband o Mary can have as many husbands as she wants, but if Bob is her husband, she cannot be married to anyone else o … o These properties cannot be expressed o in OWL 2 QL nor o in OWL 2 EL 54 [KZ’11]

55. MBA: Issues with Data Evolution [KZ’11] o Both OWL 2 QL and OWL 2 EL are not closed under data evolution o The source of the problem: DisjointClasses o With some restriction on DisjointClasses: o can be computed in polynomial time o Without restrictions on DisjointClasses: o can be computed only in OWL DL in exponential time o can be approximated in polynomial time (with significant loss of information) o Conclusion: MBS are not very suitable for ontology evolution 55

56. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 56

57. FBA: Evolution Process 57 Ontology Filter Evolved ontology New data Closure Evolved closure

58. FBA: Ontology to Closure 58

59. FBA: Ontology to Closure 59

60. FBA: Ontology to Closure 60

61. FBA: Ontology to Closure 61

62. FBA: Ontology to Closure 62 …

63. FBA: Evolution Process 63 Ontology Filter Evolved ontology New data Closure Evolved closure

64. FBA: Schema Evolution 64 … WIDTIO semantics Cross-product semantics … Bold semantics

65. FBA: Schema Evolution 65 Bold semantics … ✘ or ✔ ? ✔ ✔ ✔ ✘ ?

66. Bold semantics … ✔ ✔ ✔ ✔ ✔ FBA: Schema Evolution 66 ✔ ✘ ?

67. FBA: Evolution Process 67 Ontology Filter Evolved ontology New data Closure Evolved closure

68. 68 FBA: Closure to Ontology … ✔ ✔ ✔ ✔ ✔✔ ✘

69. FBA: Evolution Process 69 Ontology Filter Evolved ontology New data Closure Evolved closure Bold semantics Can be computationally hard Can be inexpressible

70. FBA: Example of Issues 70 ✘ or ✔ ? ✔ ? ✘

71. FBA: Example of Issues 71 ✔ … ✔ ✔ ✘ ?

72. FBA: Example of Issues 72 Ontology Filter Evolved ontology New data Closure Evolved closure

73. FBA: Example of Issues 73

74. FBA: Example of Issues o We cannot keep that gourmets are French, while we have to keep too much useless information: o Gourmets who like bikes are French o Gourmets who like those who like bikes are French o … o This cannot be expressed in OWL 2 EL 74 [CJKZ’12]

75. FBA: Issues of Evolution o OWL 2 EL is not closed under schema nor data evolution o The closure is infinite  Cannot be captured in general o OWL 2 QL is closed under both schema and data evolution o The closure is always infinite  The evolved ontology always exists o Can be computed in polynomial time 75 [CJKZ’12] [CKNZ’10]

76. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 76

77. Syntactic-Deductive Approach o There are two extreme cases o FBS — it preserves too much information o In the example, all that information about who likes bikes o SA — it preserves not enough information. o When it deletes something, does not restore meaningful entailments o Deletion without deletion (SPARQL 1.1) o Possible solution: o to be between these extreme cases, to preserve only some part of closure. o How big that part is — depends on an application o This approach is called Syntactic-Deductive (SDA) 77 [CJKZ’12]

78. Syntactic-Deductive Approach 78 SA FBS

79. SDA: Example of Issues 79 ✔ … ✔ Restriction: n ≤ 2 ? ✔ ✘

80. SDS: Example 80 Ontology Filter Evolved ontology New data Closure Evolved closure

81. SDS: Example 81

82. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 82

83. Experiments: Setting [CJKZ’12] o A contraction SDA algorithm was implemented o Experiments o Ontology — a fragment of SNOMED with 6802 classes o Reasoner — HermiT [MSH2009] o Facility for computing justification — OWL API [Kal2007] o Closure — only “active” classes, i.e., mentioned in the ontologylogy 83

84. Experiments: Setting [CJKZ’12] o A contraction SDA algorithm was implemented o Experiments o Ontology — a fragment of SNOMED with 6802 classes o Reasoner — HermiT [MSH2009] o Facility for computing justification — OWL API [Kal2007] o Closure — only “active” classes, i.e., mentioned in the ontology 84

85. Experiments: Results [CJKZ’12] 85 # of contracted axioms # of recovered axioms (max/avg/min) Time (s) (avg) # of tests 152/5/013552 296/24/021751 3195/70/017651 4257/138/2616939 5281/162/7516542 o 95% of recovered axioms are not redundant o Hence, SA leads to significant loss of information o Average time 2-4 minutes o Time does not depend on the amount of recovered axioms

86. Experiments: Summary o SDA contraction is feasible o Running time is practical o Approach is scalable o The most of recovered axioms are logically not redundant o Recovered axioms seem practically relevant o We are working on further implementations 86

87. Outline 1.Ontologies and evolution o Domain ontologies o Web knowledge bases o Semantic markup 2.Logic-based approaches o Model-Based approaches o Formula-Based approaches o Syntactic-deductive approach o Experiments 3.Conclusion and directions 87

88. Conclusion 88 ontologies for semantic markup domain ontologies Web knowledge bases don’t care logic based simple schema complex schema o There are three main classes of ontologies o Ontologies are naturally dynamic o Understanding how to do evolution is important o Keeping ontologies error free is important for some applications o The more schema involved  the more consistency is important

89. Conclusion 89 ontologies for semantic markup domain ontologies Web knowledge bases don’t care logic based simple schema complex schema o Logical based approaches help to prevent errors in ontologies o Model-based approaches o misbehave badly: inexpressibility is built-in o Formula-based approaches o better, but have issues: ignorant to original structure, can be impractical o Syntactic-Deductive Approaches: very promising

90. Directions o Proper ontology update language o SPARQL 1.1 Update does not do the right job for many applications o For domain ontologies o Can one find “the” logic approach? o SDA is one approach – are there better ones? o Good ontology CVS system o For web knowledge bases o Can one do more than just ignoring conflicting data? o Maybe some probabilistic techniques can be useful? o How can reliability of knowledge sources help in better “ignoring”? o For semantic markups o Consistency is impossible  o consistent query answering over inconsistent knowledge 90

91. References o [HKR’08] Hartung, M.; Kirsten, T.; and Rahm, E. 2008. Analyzing the evolution of life science ontologies and mappings. In Proc. of DILS, 11–27. o [SM] Spackman K. SNOMED RT and SNOMEDCT. Promise of an international clinical terminology. MD Comput. 2000 Nov;17(6):29. o [SM-1] http://www.ihtsdo.org/snomed-ct/snomed-ct0/adoption-of-snomed-ct/ o [SM-2] http://www.ihtsdo.org/fileadmin/user_upload/doc/download/doc_UserGuide_Cur rent-en-US_INT_20120131.pdf o [FMA] http://sig.biostr.washington.edu/projects/fm/AboutFM.html o [CB’12] Christian Bizer: Topology of the Web of Data. Joined keynote talk at the 2nd Workshop on Linked Web Data Management (LWDM2012) and the 3rd Workshop on Business Intelligence and the Web (BEWEB2012), Berlin, Germany, March, 2012. o [SO-1] http://schema.org/docs/datamodel.html 91

92. References o [SO-2] http://schema.org/docs/schema_org_rdfa.html o [SO-2] http://www.schema.org/docs/extension.html o [SO-3] http://schema.rdfs.org/mappings.html o [SO-4] https://raw.github.com/dcmi/schema.org/master/mappings_schema.org.xml o [NCI] https://wiki.nci.nih.gov/display/EVS/NCI+Thesaurus+versus+NCI+Metathesaurus o [Yago-1] Hady W. Lauw, Ralf Schenkel, Fabian M. Suchanek, Martin Theobald, Gerhard Weikum, "Harvesting Knowledge from Web Data and Text” Tutorial at the 19th International Conference on Information Management (CIKM 2010), o [HS’05]Haase, P., Stojanovic, L.: Consistent evolution of OWL ontologies. In: ESWC. (2005) 92

93. References o [KPSCG’06] Kalyanpur, A., Parsia, B., Sirin, E., Grau, B.C.: Repairing unsatisfiable concepts in OWL ontologies. In: ESWC. (2006) 170–184 o [Wins’90] Updating Logical Databases. 1990. Cambridge University Press. o [KM’91] Katsuno H., Mendelzón A. 1991. On the difference between updating a knowledge base and revising it. In Proc. of KR, 387-394. o [EG’92] On the complexity of propositional knowledge base revision, updates and counterfactuals. In Proc. of AI 57, 227-270. o [LLMW’06] Liu H., Lutz C., Milicic M., Wolter F. 2006. Updating description logic ABoxes. In Proc. of KR, 46-56. o [DGLPR’09] De Giacomo G., Lenzerini M., Poggi A., Rosatti R. 2009. On instance- level update and erasure in description logic ontologies. JLC, 745-770. o [QD’09] Qi G., Du J. 2009. Model-based revision operators for terminologies in description logics. In Proc. of IJCAI, 356-365. 93

94. References o [CKNZ’10] Calvanese D., Kharlamov E., Nutt W., Zheleznyakov D. 2010. Evolution of DL-Lite Knowledge Bases. In Proc. of ISWC, 112-128. o [WWT’10] Wang Z., Wang K., Topor R.W. 2010. A new approach to knowledge base revision in DL-Lite. In Proc. of AAAI. o [KZ’11] Kharlamov E., Zheleznyakov D. 2011.Capturing Instance-level ontology evolution for DL-Lite. In Proc. of ISWC, 321-337. o [CJKZ’12] Cuenca Grau B., Jiménez-Ruiz E., Kharlamov E., Zheleznyakov D. 2012. Ontology evolution under semantic constraints. In Proc. of KR. o [JRCGHB’11] Jimenez-Ruiz, E., Cuenca Grau, B., Horrocks, I., Berlanga, R.: Supporting concurrent ontology development: Framework, algorithms and tool. DKE. 70:1 (2011) o [FDCM’08] N. Fridman Noy, T. Tudorache, S. de Coronado, M. A. Musen, Developing biomedical ontologies collaboratively, in: Proc. of AMIA, 2008. 94

95. References o [MDM’06] A.deMoor,P.DeLeenheer,R.Meersman,DOGMA- MESS:Ameaningevolutionsupport system for interorganizational ontology engineering, in: 14th International Conference on Conceptual Structures, ICCS, vol. 4068 of Lecture Notes in Computer Science, Springer, 2006, pp. 189–202. 95