• Save
Rapid Ontology Development
Upcoming SlideShare
Loading in...5

Like this? Share it with your network

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 18

http://www.slideshare.net 17
http://www.slideee.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • 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).


  • 1. Dejan Lavbič [email_address] University of Ljubljana, Faculty of Computer and Information Systems , SLOVENIA
  • 2. Agenda
    • Motivation
    • Related work
    • Rapid Ontology Development (ROD) model
      • Process
      • Ontology completeness (OC) indicator
      • Financial Instruments and Trading Strategies (FITS) ontology
    • Conclusions
  • 3. Motivation
    • The employment of Semantic Web technologies is less than expected
    • Existing approaches are too complex
    • Intersection between ontologies and business rules
    • Continuous evaluation of ontologies used in development process might be useful
  • 4. Related work ( 1 )
    • Methodologies for ontology development :
      • CommonKADS ,
      • Enterprise Ontology,
      • TOVE,
      • HCONE,
      • OTK Methodology,
      • UPON,
      • DILIGENT etc.
  • 5. Related work ( 2 )
    • Criticism of current methodologies
      • lack of support for maintenance of ontology,
      • domain expert’s dependence on knowledge engineer due to lack of technical knowledge etc.
    • Evaluation of ontologies:
      • compare ontology to “golden standard” ,
      • using ontology in an application and evaluating results,
      • compare with source of data about the domain to be covered by ontology and
      • evaluation done by humans .
  • 6. Rapid Ontology Development (ROD) Overview
  • 7. Rapid Ontology Development (ROD) Process
  • 8. Rapid Ontology Development (ROD) Functional components
    • Developed ontology can be used in various scenarios :
      • BPEL element as a decision node,
      • intelligent agent’s (IA) behaviour (JADE),
      • standalone application (J2SE, J2EE, WS),
      • standalone ontology ,
      • database schema,
      • semantics verification etc.
  • 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
  • 10. Rapid Ontology Development (ROD) Ontology completeness (OC) indicator (2)
    • Impact of weights on OC sub-levels in ROD process
  • 11. Rapid Ontology Development (ROD) Ontology completeness (OC) indicator (3)
  • 12. FITS Overview
    • Evaluation of approach on Financial Instruments and Trading Strategies (FITS) ontology
  • 13. FITS Excerpt from Japanese Trading Strategy
  • 14. FITS Progressing through steps of ROD process
    • Guide user through construction process
    • Improve ontology’s quality
  • 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)
  • 19. Rapid Ontology Development (ROD) Execution platform
    • Used technologies
      • OWL + SWRL
      • KAON2 inference engine and API
      • Java
    • Automation
      • individuals are automatically imported in runtime from described resources (files, DBs, Web etc.)
      • only neighbouring entities, rules and instances stored in memory, while the rest is persistent in DB
  • 20. Conclusion
    • The presented ROD approach defines steps in rapid ontology development
      • from mind maps to SWRL rules
      • includes deployment of functional components
    • The process is supported with constant evaluation – OC indicator
      • aid users (lower level of required technical knowledge)
      • improve quality of developed ontology
  • 21. Questions
    • Thank you for your attention!
      • Questions, comments and critiques are more than welcome !