survey of ontology engineering methodologies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Survey of Ontology Engineering Methodologies PowerPoint Presentation
Download Presentation
Survey of Ontology Engineering Methodologies

Survey of Ontology Engineering Methodologies

143 Vues Download Presentation
Télécharger la présentation

Survey of Ontology Engineering Methodologies

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Survey of OntologyEngineering Methodologies 22071062 AettieJi

  2. OUTLINE • Part 1 – Review of Chap. 9 in “Semantic Web Technologies”, Davies, J., R. Studer and P. Warren, WILEY • Introduction • The Methodology Focus • Past and Current Research • DILIGENT Methodology • Discussion and Next Step • Part 2 - Brief Introduction of NeOn Methodology, NeON Project,

  3. Part1 - Ontology Engineering Methodologies Sure, Y., C. Tempich and D. Vrandecic

  4. Introduction • Methodologies of traditional knowledge management systems(KMS)  Centralized Approach • Domain experts who provide the model for the knowledge • Ontology engineers who structure and formalize it • Decentralized knowledge management systems  Methodologies based on traditional, centralized KMS are no longer feasible.

  5. Methodology Focus • Ontology Engineering Methodology • Ontology management activities • Scheduling of the ontology engineering task • Control mechanism and quality assurance steps. • Ontology development activities • Procedures to specify, conceptualize, formalize, and implement ontology (which is defined for environment and feasibility study) • Guidance for the maintenance, population, use, and evolution of the ontology. • Ontology support activities • Knowledge acquisition, evaluation, integration, merging and alignment, and configuration management.

  6. Methodology Focus • Documentation • Results of each activities • Sometime the decision making process itself • Evaluation • Means to measure the quality of the created ontology • Difficult!!  in most cases, modeling decisions are subjective. • Measures derived from statistical data or philosophical principles. • OntoClean (Guarino and Welty, 2002)

  7. Past and Current Research • Methodologies • UPON, (Nicole et al., 2005) • HCONE (Kotis et al., 2004) • OTK Methodology (Sure, 2003) • OntoWeb project, (Leger et al., 2002) • CommonKADS, (Schreiber et al., 1999) • DOGMA, (Jarrar and Meersman , 2002) • The Enterprise Ontology, (Uschod and King, 1995) • The KACTUS, (Bernaras et al., 1996) • METHODOLOGY, (Fernandez-Lopez et al., 1999) • Etc.

  8. Past and Current Research • Discussion and Open Issues • Ontology maintenance support. • Distributed ontology engineering. • Fine-grained guidelines for all phases. • Representation of multiple views. • Agreement support under conflicting interests. • Best practices. • Ontology engineering with the help of automated methods. • Process definition by single process step combination. • Integration into business process model. • Cost estimation and pricing.

  9. Past and Current Research • OntologyEngineering Tools • KAONOImodeller (Bozsak et al., 2002; Motika et al., 2002) • Protégé (Noy et al., 2000) • WebODE (Arptrez et al., 2001) • OntoEdit(=OntoStudio) (Sure et al., 2002, 2003) • OpenIssues • Support for an arbitrary process • Inter-operability • Technical solution to support versioning, ontology learning or distributed engineering of ontologies

  10. DILIGENT Methodology • Assumptions • The users: • Several experts involved in collaboratively building the same ontology who are also users. • Much larger community of users than the community of experts. • Birds-eye view: • Users are free to use and modify an initial ontology locally. • A central board maintains and assures the quality of the core ontology. • The board is responsible for updating the core ontology. • The board only loosely controls the process.

  11. DILIGENT Methodology • Main Steps • Build • An initial ontology doesn’t have to be complete, • It should be relatively small for easy access. • Local adaptation • Users work with the core ontology and adopt it locally to their own needs. • They are not allowed to directly change the shared ontology. • The control board collects changes requests to it and logs local adaptation.

  12. DILIGENT Methodology • Main Steps • Analysis • The board analyses the local ontologies and the requests for changes and tries to identify similarities in users’ ontologies. • Deciding which changes are going to be introduced in the next version of the shared ontology is crucial activity of the board. • Revision • The board should regularly revise the shared ontology realigning users needs and gaining higher acceptance, ‘sharedness’ and less local differences.

  13. DILIGENT Methodology • Main Steps • Revision • Users can be involved in ontology development and evaluate the ontology from an usability point of view. • Domain experts evaluates it from a domain point of view. • Knowledge engineers evaluates it from a domain and technical point of view. • Ontology engineers are responsible for technical evaluation, including analyzing and balancing arguments, and updating the ontology. • Local Update • User can update their own local ontologies to better use the knowledge represented in the new version.

  14. DILIGENT Methodology

  15. DILIGENT Methodology • Argumentation Support • The exchange of arguments should be embedded into a general argumentation framework. • Facilitating the ontology engineering and evaluation process. • Offering more fine-grained guidance to achieve agreement. • The creation of a shared conceptualization without any guidance is almost impossible, or time consuming. • Argumentation model of DILIGENT • Two virtual chat room, one for providing topics for discussion, hand raising and voting and the other one for exchanging arguments. • Due to the stricter procedural rule agreement is reached more quickly and a much wider consensus is reached.

  16. Conclusion and Next Steps • With DILIGENT methodology, some of open issues are tackled and proposed a methodology which allows continuous improvement of the underlying ontology in distributed setting. • The methodology is still under development to cover • The improved quality of the results of current ontology learning methods. • A more fine-grained process model. • Criteria to identify proper ontology evaluation scheme. • Tools for a more automatic appliance of such evaluation technique. • Integration the process model into a knowledge management business model. • The estimation of costs incurred by the building process. • Capturing experiences and describing best practices from application.

  17. Part 2 – BriefIntroduction of NeOn Methodology NeOn Project

  18. Comparison of Presented Methodologies

  19. Comparison of Presented Methodologies • Regarding NeOn dimensions, • In the collaboration dimension, none of the methodologies consider distributed ontology engineering. (DILIGENT does it, but it only provides a rich argumentation framework.) • In context dimension, none of them treat with it. • None of them provide guidelines for treating the dynamic and evolution of the ontology. • None of them provide detailed guidelines for the process or activities. • None of them are described targeted to software developers and ontology practitioners.

  20. Aim within the NeOn Project • Creation of the NeOn methodology for building ontology networks covering the drawbacks of the three methodologies and benefiting from the advantages included in such methodologies. • NeOn methodology will include the benefits provided by DILGENT about collaboration. • Furthermore, it will take into account the proposal of METHONTOLOGY and On-To-Knowledge about the use of competency questions for the ontology specification activity.

  21. When do Ontologies become Ontology Network? • If there is a requirement or it is advisable to express meta relationship, for example • priorVersionOf • useImports • extendingBy • composedByModules • haveMapping • Ontology permits a fluent knowledge sharing and an easy enrichment of the network.

  22. NeOn Ontology Development Process • Consensus reaching process • For the identification and definition of the activities involved in the ontology network development process. • NeOn glossary of activities • Definitions of the activities involved in ontology network construction, which have been collaboratively built and consensuated by all NeOn partners, by means of the consensus reaching process. • NeOn Table of “Recommended and If-Applicable” • A classification of the activities required for the development of ontology networks and those that are applicable, but not required, and, therefore, they are non-essential or dispensable.

  23. NeOn Ontology Development Process Maintenance Activities O. Enrichment Knowledge Acquisition O. Elicitation O. Learning O. Extension O. Specialization Development Activities O. Evolution O. Update O. Upgrade O. Evaluation O. Validation O. Verification O. Summarization Environment Study Feasibility Study O. Transforming O. Versioning O. Specification O. Conceptualization O. Formalization O. Implementation O. Pruning O. Reuse O. Documentation O. Modularization O. Module Extraction O. Partitioning O. Diagnosis O. Repair O. Searching O. Selection O. Alignment O. Integration O. Mapping O. Merging O. Configuration Management O. Translating O. Population O. Assessment O. Combining Use Activities

  24. Scenarios for Building Ontology Networks • 9 identified NeOn scenarios for building ontology network. • Scenario 1: Building ontology networks from scratch without reusing existing knowledge resources. • Scenario 2: Building ontology networks by reusing and reengineering non ontological resources. • Scenario 3: Building ontology networks by reusing ontological resources. • Scenario 4: Building ontology networks by reusing and reengineering ontological resources. • Scenario 5: Building ontology networks by reusing and merging ontological resources.

  25. Scenarios for Building Ontology Networks • 9 identified NeOn scenarios for building ontology network. • Scenario 6: Building ontology networks by reusing, merging and reengineering ontological resources. • Scenario 7: Building ontology networks by reusing ontology design patterns. • Scenario 8: Building ontology networks by restructuring ontological resources. • Scenario 9: Building ontology networks by localizing ontological resources.

  26. Scenarios in the Ontology Life Cycle

  27. Life Cycle of Ontology Networks • NeOn Life Cycle Models • Waterfall Ontology Network Life Cycle Model • Incremental Ontology Network Life Cycle Model • Iterative Ontology Network Life Cycle Model • Evolving Prototyping Ontology Network Life Cycle Model • Spiral Ontology Network Life Cycle Model

  28. Conclusions and References • Which one are the activities involved in the ontology development process? • Which one is the goal of each activity? • NeOn Glossary of Activities • NeOnTable of “Recommended and If-Applicable” • NeOn Development Process • When should I carry out each activity? • Where is the relationship of one activity with the others? • Ontology Network Life Cycle models

  29. Conclusions and References • Where can I find ontologies with the goal of reusing them? • Ontology Metadata Vocabulary • Ontology Registries • How can I build the ontology for my application? • Do I need a single ontology or an ontology network? • Several examples from NeOn deliverables 5.3.1 and 5.4.1.