WP4: Ontology Engineering

1. WP4: Ontology Engineering Heiner Stuckenschmidt, Michel Klein Vrije Universiteit Amsterdam WonderWeb Review Meeting Brussels, March 11th 2004

2. Overview of Work • Versioning • Detect, track and represent changes in semantic web ontologies • Deliverable 4.1 • Presented at first review • Modularization • Represent, use and manage modular ontology descriptions • Deliverable 4.2 • Focus of this presentation • Refinement • Enrich, extend and partition existing ontologies • Deliverable 4.3 • Due end of june   

3. Role in WonderWeb • Ontology Management • Wonderweb scenario includes the creation of different representations. • Different ontologies • HR, DOLCE • Different versions of HR • These representations have to be managed to support and document the engineering process

4. Motivation for Modularization • Maintenance • Distributed Teams of Domain Experts • Update and Integrity Problems • Validation • Manual Inspection of definitions difficult • Local errors are hard to spot • Publication • Stable Subsets canot be published independently • Fine-grained Access Control not possible • Processing • A single inconsistency disables reasoning for the whole model • Ontology Management Tools do not scale

5. Outline and Contributions • Modular Architecture • We proposed an architecture for modular ontologies an analyze the role of mappings in logical reasoning across modules. • Compilation of Implied Knowledge • We described a knowledge compilation approach that makes local reasoning within modules possible and define the notion of integrity. • Change Detection and Automatic Update • We developed an update strategy that preserves integrity by identifying changes in ontology modules and deciding whether the compiled knowledge has to be updated or not.

6. Concrete Case: The WonderWeb Case Study

7. Definition of Mappings Employee DOLCE+HR ontology HR:Employee(x) Fulltime Employee HR:y(Department(y)  hasMember(y,x)  Employee(x) HR:y(manages(y,x)) DepartmentMember HeadOfDepartment

8. Added subsumption relations: DepartmentMember  Employee (redundant) HeadOfDepartment  Employee (redundant) HeadOfDepartment  DepartmentMember Reasoning and Compilation Employee DOLCE+HR ontology HR:Employee(x) Fulltime Employee HR:y(Department(y)  hasMember(y,x)  Employee(x) HR:y(manages(y,x)) DepartmentMember HeadOfDepartment

9. Integrity and Change • Integrity of two ontologies: M,M' |= Mc, where Mc is the result of adding subsumption axioms implied by M' to M • Integrity cannot always be guaranteed if M' changes ! • Characterize Changes: • harmless changes  integrity is preserved • harmful changes  integrity is destroyed

10. Update Management Process • Detecting Changes • find differences between ontologies • Determining the Effect of Changes • add “generalized”, “specialized” or “unknown” to all concepts and relations • Testing mappings against Effects • conjuncts of the more general queries are not allowed to become more specific • conjuncts of the more specific queries are not allowed to become more general

11. Example from the Case Study • Example relation: • HeadOfDepartment  DepartmentMember Employee DOLCE+HR ontology HR:Employee(x) Fulltime Employee HR:y(Department(y)  hasMember(y,x)  Employee(x) HR:y(manages(y,x)) DepartmentMember HeadOfDepartment

12. Detecting changes (D4.1) • Changes are detected by comparison tool • Syntax independent comparison: • analysis of RDF triples • language specific rules determine type of change IF exist:new <$X, rdfs:subClassOf, $_1> <$_1, rdf:type, &daml;#Restriction> <$_1, daml:onProperty, $Y> <$_1, daml:hasClass, $Z>not-exist:old <$X, rdfs:subClassOf, $_1> <$_1, daml:onProperty, $Y>THEN "HasClass restriction added on $Y to $Z"

13. Changes that (could) make definitions more specific attach a slot to a class change the superclass of a class to a class lower in the hierarchy add a class to the range of a slot add a cardinality constraint to a slot-restriction Changes that (could) make definitions more general remove a superclass relation change the superclass of a class to a class higher in the hierarchy remove a class from the range of a slot change a class definition from primitive to defined Specify the Effect of Changes Examples of changes and their effect:

14. Changes and Effects • Detected Changes • The Property ‚employee-email‘ was removed from the concept ‘Employee‘ • The domain of the ‚manages‘ relation was refined from ‚employee‘ to ‚manager‘ • Impact • ‚Employee‘ becomes more general • ‚manages‘ becomes more specific • Changes are harmless wrt to the implied subsumption between Department-Member and Head-of-Department • No Update required !

15. Summary and Conclusions • Practical Approach to Modularization • Limited Expressiveness (still far beyond OWL imports!) • Supports Update Management • Update Management: • Advantages • Can be done automatically • Can avoid expensive subsumption reasoning • Disadvantage • Used heuristics are not complete

16. Key Publications • M. Klein: Change Management for Distributed Ontologies. PhD Thesis, submitted to the Faculty of Sciences, Vrije Universiteit Amsterdam 2004. • H. Stuckenschmidt, M. Klein: Integrity and Change in Modular Ontologies. Proceedings of IJCAI'03, Acapulco, Mexico, 2003. • H. Stuckenschmidt, F. van Harmelen: Information Sharing on the Semantic Web, (Part IV: Distributed Ontologies) Springer Verlag, to appear 2004. • Deliverables D41 and D42