General Actions:
Log-in
Register
Home
▼
:
Wiki Index
Document Index
User Index
»
Space:
3. Modeling Guide
▼
:
Document Index
»
Page:
Ontology Quality Assurance Tools
Search
Page Actions:
Export
▼
:
Export as PDF
Export as RTF
Export as HTML
More actions
▼
:
Print preview
View Source
Welcome to the CB-NL Wiki
»
Modeling Guide
»
Ontology Quality Assurance
Wiki source code of
Ontology Quality Assurance
Last modified by
Linda van den Brink
on 2014/10/02 11:16
Content
·
Comments
(1)
·
Attachments
(3)
·
History
·
Information
Hide line numbers
1: **====THIS DOCUMENT IS UNDER CONSTRUCTION** 2: 3: {{toc start="1" depth="3" numbered="false" scope="page"/}} 4: 5: = Introduction = 6: 7: The development process of the CB-NL ontology is guided by //requirements//, //modeling principles and rules//, //design patterns//, //software tooling// and //human interaction//. 8: 9: CB-NL requirements come first. They determine the CB-NL capabilities: for what automated task can you use CB-NL? The requirements are documented on [[this page>>doc:Requirements]]. Modeling Principles are next. They describe how CB-NL is developed. The modeling principles are described [[here>>doc:Modeling Approach]]. [[Design patterns>>doc:Design Patterns]] help modelers to decide which OWL code represents which natural language statement. Software tools support the ontology development and QA process. And in the end a human always needs to test and verify if this all leads to the required endproduct. In this sense the development of CB-NL can be compared to any [[software development life cycle>>url:http://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Process/Life_Cycle||rel="__blank"]]. There are however particular differences between developing an ontology such as CB-NL and developing any other kind of software. This page describes just that difference. It describes the way CB-NL has implemented the QA process. 10: 11: = The CB-NL ontology QA Process = 12: 13: The CB-NL is a software representation (in the form of a file) of statements and axioms that record the meaning of concepts used in the construction sector. For QA, both the //representation //and the //meaning //of the concepts need to be correct. The representation of the concepts is checked via a syntax check. Correct syntax refers to proper use of the W3C [[RDF>>url:http://www.w3.org/TR/rdf11-primer/||rel="__blank"]], [[SKOS >>url:http://www.w3.org/TR/skos-primer/||rel="__blank"]]and [[OWL2 >>url:http://www.w3.org/TR/owl2-primer/||rel="__blank"]]standards.This is an automated task. The meaning of the concepts is verified via a semantic check. This can be done automatically. Correct semantics means that the ontology is consistent (the ontology axioms do not contain contradictions). Correct semantics also means that concepts are coded as intended. This can be checked automatically when certain rules are implemented (such as design patterns) but they must always be verified via human intervention. 14: 15: 16: The quality of the CB-NL content is guaranteed by following these processes and principles: 17: 18: 1. The concepts are modelled according to the [[Modeling guide>>doc:WebHome]] 19: 1. For the coding of the concepts ontology editors are used to ensure use of proper syntax. When issues arise online RDF and OWL validators are used. 20: 1. Only modeling constructions that are described in [[Design Patterns>>doc:3\. Modeling Guide.Design Patterns||rel="__blank"]] are used 21: 1. Every ontology release is checked for consistent semantics in an automated process 22: 11. the ontology is verified with a reasoner 23: 11. reverse engineering of design patterns 24: 1. Human eyes have checked the correct meaning of every concept 25: 26: Every release of CB-NL is accompanied by a report with the outcome of the QA test that were executed. An example of such a report can be found [[here>>attach:CBNL QA report example.docx]]. 27: 28: = Tools used in the CB-NL QA process = 29: 30: The QA process is supported by a number of free tools that are available for download on the web. 31: 32: 33: == Tools for syntax validation == 34: 35: The tools that the CB-NL project uses to verify the correct use of syntax are: 36: 37: === Ontology editor === 38: 39: Ontology editors display and log syntax errors via the user interface. CB-NL is validated with [[Topbraid Composer>>url:http://www.topquadrant.com/tools/IDE-topbraid-composer-maestro-edition/||rel="__blank"]] (use [[this link>>url:http://www.topquadrant.com/downloads/topbraid-composer-install/||rel="__blank"]] to free version) and [[Protege (version 4)>>url:http://protegewiki.stanford.edu/wiki/Protege_Desktop_Old_Versions||rel="__blank"]] . 40: 41: Topbraid composer displays a syntax error like this: 42: 43: [[image:TBCsyntaxerror.png]] 44: 45: And Protege like this: 46: 47: [[image:ProtegeSyntaxerror.png]] 48: 49: 50: 51: === RDF validator === 52: 53: //purpose//: check if code is valid RDF 54: 55: //source~://[[http:~~/~~/www.w3.org/RDF/Validator/>>url:http://www.w3.org/RDF/Validator/||rel="__blank" title="RDF validator"]] (works only for RDF/XML) 56: 57: === OWL validator === 58: 59: //purpose//: check if code is valid OWL and determine which OWL dialect is used 60: 61: //source~://[[http:~~/~~/mowl-power.cs.man.ac.uk:8080/validator/>>url:http://mowl-power.cs.man.ac.uk:8080/validator/||rel="__blank" title="OWL validator"]] 62: 63: == Tools for validation of semantics == 64: 65: === Reasoner === 66: 67: A reasoner or inference engine can check whether an ontology is logically consistent. It can also infer logical entailments. 68: 69: The command line reasoner [[Pellet>>url:http://clarkparsia.com/pellet/||rel="__blank"]] is used to verify the semantic quality of CB-NL. Pellet supports multiple reasoning tasks. For optimal semantic quality checking they must be executed in a particular order: 70: 71: * pellet consistency (if not consistent - use pellet explain and fix issues first), 72: * pellet classify, 73: * pellet unsat.