1 / 20

Ontology Evolution within Ontology Editors Presentation at EKAW, Sigüenza, October 2002

Ontology Evolution within Ontology Editors Presentation at EKAW, Sigüenza, October 2002. L. Stojanovic, B. Motik FZI Research Center for Information Technologies at the University of Karlsruhe, Germany. Agenda. Introduction Requirements Evaluation Conclusion. Introduction.

vragland
Download Presentation

Ontology Evolution within Ontology Editors Presentation at EKAW, Sigüenza, October 2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ontology Evolution within Ontology Editors Presentation at EKAW, Sigüenza, October 2002 L. Stojanovic, B. Motik FZI Research Center for Information Technologies at the University of Karlsruhe, Germany

  2. Agenda • Introduction • Requirements • Evaluation • Conclusion

  3. Introduction • Ontology editors are main tools for ontology development • Ontologies must be able to evolve for a number of reasons, including the following: • Application domains and user‘s needs are changing • System can be improved • An ontology editor has to support ontology evolution

  4. Agenda • Introduction • Requirements • Evaluation • Conclusion

  5. Requirements for Ontology Evolution • Functional requirement • User’s supervision requirement • Transparency requirement • Reversibility requirement • Auditing requirement • Ontology refinement requirement • Usability requirement

  6. Functional requirement • specifies which functionality must be provided for the ontology development and evolution • depends on the underlying ontology model

  7. Functional requirement • Composite changes • They are more powerful • They have coarser granularity • They have often more meaningful semantics • e.g. Move_Concept  (RemoveSubConcept + AddSubConcept)

  8. Functional requirement

  9. - delete • reconnect to the root • reconnect to the superconcepts Person Project Student X Hiwi PhDStudent User‘s supervision requirement - enables the user-driven process of change resolving Critical situations: • how to handle orphaned concepts; • how to handle orphaned properties; • how to propagate properties to the concept whose parent changes; • what constitutes a valid domain of a property; • what constitutes a valid range of a property; • whether a domain (range) of a property can contain a concept that is at the same; time a subconcept of some other domain (range) concept; • the allowed shape of the concept hierarchy; • the allowed shape of the property hierarchy; • must instances be consistent with the ontology.

  10. Transparency requirement • - provides a human-computer interaction for evolution by: • presenting change information in an orderly way • allowing easy spotting of potential problems • alleviating the understanding of the scope of the change

  11. X Reversibility requirement - states that an ontology editor has to allow undoing changes at the user’s request Remove Concept Add Concept

  12. Auditing requirement • - allows inspecting the performed changes by: • keeping a detailed log of all performed changes • associating meta information with each log change • tracking the identity of the change author

  13. If all subconcepts have the same property, the property may be moved to the parent concept • A concept with a single subconcept should be merged with its subconcept. • If a direct parent of a concept can be achieved though a non-direct path, then the direct link should be deleted. Ontology refinement requirement Structure-driven –exploits a set of heuristics to improve an ontology based on the analysis of the ontology structure Data-driven - detects the changes based on the analysis of the ontology instances If no instance of a concept C use any of the properties defined for C, but only properties inherited from the parent concept, we can make an assumption that C is not necessary. Usage-driven – takes into account the usage of the ontology By tracking when entity has last been retrieved by a query, it may be possible to discover that some entities are out of date

  14. Usability requirement • - states that an ontology editor should: • be ergonomically correct to minimise human errors • detect logical conflicts (verification) • provide the means for validation

  15. Agenda • Introduction • Requirements • Evaluation • Conclusion

  16. Evaluation “-“ - no support “<>” – partial support “+” - full support

  17. Agenda • Introduction • Requirements • Evaluation • Conclusion

  18. Conclusion • Ontology editors should: • enrich the list of possible changes • enable the customisation of the change resolving • inform the user about all effects of a change • allow undoing changes • allow inspecting the performed changes • suggest the user to generate a change • identify inconsistency and provide answers to the questions such as how, why, what if, etc.

  19. http://kaon.semanticweb.org Elementary evolution strategies Resolution points

  20. Thanks! Any questions? L. Stojanovic, B. Motik FZI Research Center for Information Technologies at the University of Karlsruhe, Germany http://wim.fzi.de/wim

More Related