Download
1 / 16
160 likes | 273 Vues
WP4: Ontology Engineering. Heiner Stuckenschmidt, Michel Klein Vrije Universiteit Amsterdam WonderWeb Review Meeting Brussels, March 11 th 2004. Overview of Work. Versioning Detect, track and represent changes in semantic web ontologies Deliverable 4.1 Presented at first review
E N D
WP4: Ontology Engineering Heiner Stuckenschmidt, Michel Klein Vrije Universiteit Amsterdam WonderWeb Review Meeting Brussels, March 11th 2004
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
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
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
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.
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
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
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
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
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
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"
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:
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 !
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
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
