| | 33 | |
| | 34 | = Validation of PIMO Models - !PimoChecker = |
| | 35 | The semantics of the PIMO language allow us to verify the integrity of the data. In normal RDF/S semantics, verification is not possible. For example, setting the domain of the property knows to the class Person, and then using this property on an instance Rome Business Plan of class Document creates, using RDF/S, the new information that the Document is also a Person. In the PIMO language, domain and range restrictions are used to validate the data. |
| | 36 | The PIMO is checked using a Java Object called PimoChecker, that encapsulates a Jena reasonser to do the checking and also does more tricks: |
| | 37 | * source:branches/gnowsis0.9/gnowsis-server/src/java/org/gnowsis/pimo/impl/PimoChecker.java |
| | 38 | |
| | 39 | The following rules describe what is validated in the PIMO, a formal description is given in the gnowsis implementation's PIMO rule file. |
| | 40 | * All relating properties need inverse properties. |
| | 41 | * Check domain and range of relating and describing properties. |
| | 42 | * Check domain and range for rdf:type statements |
| | 43 | * Cardinality restrictions using the protege statements |
| | 44 | * Rdfs:label is mandatory for instances of ”Thing” and classes |
| | 45 | * Every resource that is used as object of a triple has to have a rdf:type set. This is a prerequisite for checking domains and ranges. |
| | 46 | |
| | 47 | Above rules are checking semantic modeling errors, that are based on errors made by programmers or human users. |
| | 48 | Following are rules that check if the inference engine correctly created the closure of the model: – |
| | 49 | |
| | 50 | * All statements that have a predicate that has an inverse defined require another triple in the model representing the inverse statement. |
| | 51 | |
| | 52 | The rules work only, when the language constructs and upper ontology are part of the model that is validated. For example, validating Paul’s PIMO is only possible when the PIMO-Basic and PIMO-Upper is available to the inference engine, otherwise the definition of the basic classes and properties are missing. The validation can be used to restrict updates to the data model in a way that only valid data can be stored into the database. Or, the model can be validated on a regular basis after the changes were made. In the gnowsis prototype, validation was activated during automatic tests of the system, to verify that the software generates valid data in different situations. Ontologies are also validated during import to the ontology store. Before validating a new ontology, it’s import declarations have to be satisfied. The test begins by building a temporal ontology model, where first the ontology under test and then all imported ontologies are added. If an import cannot be satisfied, because the required ontology is not already part of the system, either the missing part could be fetched from the internet using the ontology identifier as URL, or the user can be prompted to import the missing part first. When all imports are satisfied, the new ontology under test is validated and added to the system. A common mistake at this point is to omit the PIMO-Basic and PIMO-Upper import declarations. By using this strict testing of ontologies, conceptual errors show at an early stage. Strict usage of import-declarations makes dependencies between ontologies explicit, whereas current best practice in the RDF/S based semantic web community has many implicit imports that are often not leveraged. |
| | 53 | |
