Rapid Ontology Development
•
5 j'aime•837 vues
The document proposes a Rapid Ontology Development (ROD) model and process to develop ontologies more quickly and with less technical expertise required. It evaluates ontologies using an Ontology Completeness (OC) indicator to identify areas for improvement. The approach was applied to develop the Financial Instruments and Trading Strategies (FITS) ontology and helped guide users through the construction process and improve the ontology's quality.
![Dejan Lavbič [email_address] University of Ljubljana, Faculty of Computer and Information Systems , SLOVENIA](https://image.slidesharecdn.com/ejc2009dejanlavbi-v0-3-091116060603-phpapp01/85/rapid-ontology-development-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Similaire à Rapid Ontology Development
Similaire à Rapid Ontology Development (20)
Dernier
Dernier (20)
Rapid Ontology Development
- 1. Dejan Lavbič [email_address] University of Ljubljana, Faculty of Computer and Information Systems , SLOVENIA
- 6. Rapid Ontology Development (ROD) Overview
- 7. Rapid Ontology Development (ROD) Process
- 9. Rapid Ontology Development (ROD) Ontology completeness (OC) indicator (1) ' Evaluation is executed on top condition “OC components” with weight 1 Evaluate (X, w) price OC = 0 mark condition X as visited if not exists sub-condition of X ' Execute semantic check on leaf element return w exec (X) else for all conditions Y that are sub-conditions of X such that Y is not visited ' Aggregate ontology evaluation prices if w(X,Y) 0 price OC += Evaluate (Y, w(X,Y)) return w price OC End
- 11. Rapid Ontology Development (ROD) Ontology completeness (OC) indicator (3)
- 13. FITS Excerpt from Japanese Trading Strategy
- 15. FITS OC and detection of anomalies (property clumps) while exist complete bipartite sub-graph K’ m,n of graph G(V, E) select K’’ m,n from K’ m,n , where max (m’’ n’’/(m’’ + n’’)) propertyClumps = propertyClumps K’’ m,n remove all edges from G(V, E) that appear in K’’ m,n price = price – (m’’ n’’ – (m’’ + n’’))/n R end while “ Group properties streetName , streetNumber , postName and ZIPcode into abstract class that is related to classes Subject and Office . Group properties value and currency into abstract class that is related to classes Debt , Bill and BillItem .” Algorithm Recommendations
- 16. FITS OC and detection of partition errors (hierarhy)
- 17. FITS OC and detection of anomalies ( c hain of inheritance)
- 18. FITS OC and detection of partition errors (commons classes)
Notes de l'éditeur
- The employment of Semantic Web technologies is less than expected Successful applications are mainly Internet use cases and less from business oriented environments Existing approaches are too complex not suitable for business users not enough emphasis on reuse Intersection between ontologies and business rules
- CommonKADS (Schreiber et al., 1999) – not a methodology for ontology development, but is focused towards KM in IS with analysis, design and implementation of knowledge (early stages of software development for KM) Enterprise Ontology (Uschold & King, 1995) – recommends 3 simple steps: definition of intention, capturing concepts, mutual relation and expressions based on concepts and relations (groundwork for many other approaches). METHONTOLOGY (Fernandez-Lopez et al., 1999) – creating ontology from scratch by reusing existing ontologies (very close to prototyping) TOVE (Uschold & Grueninger, 1996) – using questionnaires that describe questions to which ontology should give answers (useful where domain experts have little technical knowledge) HCONE (Kotis & Vouros, 2003) – decentralized approach by introducing regions where ontology is saved during its lifecycle OTK Methodology (Sure, 2003) – introduce two processes; Knowledge Meta Process and Knowledge Process UPON (Nicola et al., 2005) – based on Unified Software Development Process and supported by UML language DILIGENT (Davies et al., 2006) – different approaches to distributed ontology development
- Critisim Lack of Rapid Application Development (RAD) approaches in ontology development, the use of ontologies in business applications and approaches analogous agile methodologies in software engineering. Not supporting the maintenance of developed ontology. Focus is mainly on development for specific application and the devlopment cycle usually ends with the last successful iteration. Lack of approaches that do not require extensive technical knowledge of formal languages and techniques for capturing knowledge from domain experts. The majority of approaches require and additional role of knowledge engineer that transfers the knowledge into formal syntax within KB. The domain expert is dependent on knowledge engineer in case of any modifications, due to experts’ lack of knowledge of languages for formal representation. Various approaches to evaluation of ontologies are considered in the literature. Based on existing reviews in [20, 16, 7, 17] we classify evaluation approaches into following categories: compare ontology to “golden standard” [27], using ontology in an application and evaluating results [33], compare with source of data about the domain to be covered by ontology [8] and evaluation done by humans [26, 31]. Usually evaluation of different levels of ontology separately is more practical than trying to directly evaluate the ontology as whole. Therefore, classification of evaluation approaches based on the level of evaluation is also feasible and is as follows: lexical, vocabulary or data layer, hierarchy or taxonomy, other semantic relations, context or application level, syntactic level, structure, architecture and design. Prior the application of ontologies we have to assure that they are free of errors. The research performed by [14] resulted in classification and consequences of ontology errors. These errors can be divided into inconsistency errors, incompleteness errors, redundancy errors and design anomalies. In the rest of this section some methods and tools from aforementioned categorizations will be presented. There are several tools available for ontology evaluation: ConsVISor (verifying axioms in UML class diagrams, RDFS, DAML+OIL ontologies), evOWLution (consistency checking of OWL ontologies), ONTOMETRIC (suitability of existing ontology, regarding the requirements), Protege (web based approach of annotation of ontologies), OntoClean (based on notions: rigidity, unity, identity and dependence).
- In general it defines 3 simple steps: capturing concepts, mutual relations and expressions based on concepts and relations (can include reusing elements from various resource or defining them from scratch), schematic part is binded to existing instances of that vocabulary (relational databases, text files, other ontologies etc.), bringing ontology into use by creating functional component for te employment in other systems.
- Every stage delivers a specific output with the common goal of creating functional component based on ontology that can be used in several systems and scenarios. Pre-development feasibility study Development essential model definition (schema of problem domain) Post-development implementation model definition (functional component) At the begining of the development process the emphasis is on simple capture of knowledge in semi-structured way (annotated mind maps). By forcing users to provide natural language descriptions of schematic part of ontology (TBox, Rbox and rules) this allows simplified entering more complex restrictions and rules. At the end of the ontology development process we have a functional component that is executable in runtime.
- After completing the terminological and assertion aspect of building ontology our vocabulary consists of enough information that can be efficiently used as a functional component in other systems.
- We don’t evaluate ontology as whole but rather it’s components. This architecture allows us to be very versatile in a sense of adding extra semantic checks and altering the importance of individual semantic check in certain step of ontology development process.
- Description of ontology’s components is very important aspect mainly in early stages of ontology development. As OC calculation is concerned there are several components considered: Existence of entities (classes and properties) and instances , (multiple) natural language descriptions of TBox and RBox components and formal description of concepts and instances. Partition errors deal with omitting important axioms or information about the classification of concept and therefore reducing reasoning power and inferring mechanisms. In OC calculation several components are considered: Common classes and instances , external instances of ABox component, connectivity of concepts of RBox component and hierarchy of entities . Redundancy occurs when particular information is inferred more than once from the entities and instances. When calculating OC we take into consideration following components: Identical formal definition and redundancy in hierarchy of entities. Consistency – circulatory errors . Design anomalies prohibit simplicity and maintainability of taxonomic structures within ontology. They don’t cause inaccurate reasoning about concepts, but point to problematic and badly designed areas in ontology. Identification and removal of these anomalies should be necessary for improving the usability and providing better maintainability of ontology. As OC calculation is concerned there are several components considered: Chain of inheritance in TBox component, property clumps and lazy entities (classes and properties).