본문으로 건너뛰기

3.2. Semantic Validator

This document describes the method and setting information for deploying Semantic Validator.

NOTE: It is not a standalone application, rather it is a project which can be used in the processes like Semantic Annotation.

3.2.1. Overview

The document provides the system design aspects of the Semantic Validator module, covering system architecture, methodology and utilization. In general, validation covers broader scope and can vary based on different use cases. For city-hub data, the scope of validation is limited to considered city-hub use cases and ontologies, which are related to Smart Parking, Air-Quality and Weather. Semantic Validator is used to validate the semantic assertions in an instance, generated by the Annotator, based on the existing ontologies in the triple database (TDB). After generating the instance, the Annotator passes them to the Validator for crosschecking the assertions based on the ontologies (vocabularies) already stored in the TDB. Upon successful validation, the annotations are stored in the TDB, and rejected otherwise. The semantic validator particularly focuses on validation of syntax of the assertions, as well as the logical reasoning, which make sure that these assertions don’t contradict with the underlying axioms in the ontology.

3.2.2. Semantic Validator Methodology

As mentioned earlier, validation can cover vast scope and it can vary based on different application environment and use cases. Since an ontology definition follows an open world assumption, which means that the system can interpret only the declared axioms and cannot interpret or validate others because there is no information available. This leads to the first assumption of semantic validator that the ontologies are correctly defined and must have enough information so the assertions considered for validation can be reasoned with at least one axiom in the ontology. Secondly, semantic validation does not take into account, other aspects, which are not defined as axioms in the ontologies and rather considered as an implicit criteria by other systems. As an example, consider figure 1, which shows the two different assertions based on parking ontology. In figure 1(a), the assertion cannot be stated as incorrect, because semantic ontologies does not state any limitations on URI structure and terminology. Which means, that this assertion will be successfully validated because it does not include any other assertion that contradicts the ontology. Whereas the Object property assertion in figure 1(b) will be invalidated because in the parking ontology, the range defined for object property: “common:hasParkingLotProfile” is the class “common:ParkingLotProfile” and not “common:ParkingSpot”. Applications can have different URI structure and use different terminologies, so it is not feasible to fixate on validating syntax regarding URI format and the involved terminologies.

Semantic Validator uses reasoning techniques to validate the assertions based on the ontologies. Based on current implementation of semantic annotator and mashup, semantic validator analyzes following assertions as shown in table 1. The other assertions, such as union, intersaction, Disjointness, reflexive and irreflexive properties, asymmetric properties, cardinality restrictions etc. have not been added to the validation process, and are considered for future enhancements.

Table 1. Assertions for validations

No.Assertion typeDescription
1Class AssertionThe validator checks the class assertion, which is the declaration of owl:NamedIndividual. This assertion must include class representation, which should be available in one of the ontologies in the TDB.
2Object Property AssertionThe validator checks that whether the object property used in the assertion, is declared in one of the ontologies available in the TDB. In addition, it checks for the domain and ranges involved in the assertions, to validate that the domains and ranges should include valid named individuals.
3Data Property AssertionThe validator checks that whether the data property used in the assertion, is declared in one of the ontologies available in TDB. In addition, it checks for the domain and ranges involved in the assertions, to validate that the domains refer to a valid named individuals and the ranges include data values of valid XSD datatype, as specified in the respective data property domain and range assertions in the ontology.

The validation of these above mentioned assertions, is performed using standard description logic reasoning tasks , which are described as follows:

3.2.2.1. Satisfiability Validation

This checks “satisfiability” condition for a class in the ontology. A class is test as “unsatisfiable” if there is a contradiction in the ontology that implies that the class cannot have any instances (OWL individuals). An example of this case can be an intersection of two classes where the resultant class is a null set. In current implementation, the ontology models do not contain intersection based classes. In addition, this validation focuses primarily on class axioms which resides in ontologies, hence is a part of ontology validation. So, based on the first assumption, this validation is currently not involved ontology validation because ontology validation is considered for future extension of validation. However, it is involved as a sub-process in the consistency and entailment validation process.

3.2.2.2. Consistency Validation

Checks for “consistency” condition: the ontology is “inconsistent” it is impossible to interpret the axioms in the ontology such that there is at least one class which can have an instance. This can be viewed as validation process at higher level, where complete ontology is taken into account (having many classes). If the ontology is tested as inconsistent, then it means that no single instance can be asserted and the validation process will not proceed further. This validation process involves satisfiability checking for each class defined in the ontology. Note that ontology can be considered consistent, if it as at least one class validated as satisfiable.

3.2.2.3. Entailment Validation

This validation specifically checks “entailment” condition for each assertion against given ontologies. An assertion or the set of assertions n is said to entail O (where O is a set of ontology models), if all models of O also satisfy n. In this case “O entails n”. This is the core step of ontology validation, where all the instance assertions are analyzed. In case satisfiability and consistency validation serve as a preliminary step. For the entailment validation to be executed, the considered ontologies must be successfully evaluated as consistent and for the entailment validation to be successful, the respective satisfiability validation should be successfully executed.

3.2.3. Architecture

Follow figure shows the Architecture of semantic validator as well as shows its interaction with the Semantic Annotator. The instance generated by the Annotator is sent to the Validator where it is forwarded to the OWL Ontology Modeler. The OWL Ontology Modeler parses the instance to extract all the assertions and sends them to each validator component in the form of model object.

It also contains sub-component called XSD Type Data Handler, which parses data values based on their respective XSD type and add them to the model object as Data Property Assertions. In addition, OWL Ontology Modeler also translates the triples of the ontologies (which actually is the SPARQL response) retrieved from the TDB. The process of retrieving ontologies from the TDB, using SPARQL queries, is carried out by the TDB Handler, which then forwards the response to the OWL Ontology Modeler. Therefore, the OWL Ontology Modeler sends two model objects to each validator, one contains the instance assertions provided by the annotator, second contains the ontology axioms. Then each validator component analyzes the model objects according to standard description logic techniques as described in 2.1, 2.2 and 2.3, and if each component successfully validates the assertions, the validator returns the response to annotator, allowing it to proceed with populating the TDB.

3.2.4. System Utilization

This section describes the operations of the Semantic Validator in the environment, where the instance data to be validated and the ontologies in the TDB have different structure than the existing one, as well the components which need to adapt the change. In this case, Entailment, Consistency and Satisfiability validators don’t need to change as their input remains the same, which are model objects. However, in case of addition of the complex assertions, as described in Section 2, OWL Ontology Modeler and TDB Handler have to add the methods to extract those assertions and add to the model object. The OWL Ontology Modeler should include methods to extract the new complex assertions from the instance generated by Annotator. The TDB Handler includes SPARQL queries, which need to be updated in order to retrieve new complex axioms defined in the ontologies.

3.2.5. User Guide

Semantic Validator is a Java Maven project which can be imported and executed in compatible java IDE such as Eclipse and IntelliJ. Following are the dependencies required for deployment.

3.2.5.1. Dependencies

  • Minimum version of Java Required: 1.5.
  • Maven Dependencies: These are listed under <dependencies> tab in “pom.xml”, in main project directory.
    • apache-jena-libs (version: 3.9.0)
    • org.semanticweb.hermit (version: 1.3.8.4)
  • External Jar Files: These files are not available in maven repository and may need to add in the build path manually. These can be found in project/lib/
    • virt_jena3.jar
    • virtjdbc4.jar
  • Connection with Virtuoso Triple Store: Three parameters are required to connect to the virtuoso: host URL, user name and password. In addition, it is required that the triple store is already populated with ontologies (vocabularies), so that Semantic Validator can retrieve them for the validation.

3.2.5.2. Configuration

  • The file is located at project/src/java/com/semantics/InterfaceConfiguration.java, where virtuoso triple store parameters can be configured.
    • The parameters are described as follows:
PropertySampleDescription
base_tdb__urljdbc:virtuoso://localhost:1111Parameter to set host URL. This default value is set for localhost. However it can be changed to the specific ip address
user_iddbaDefault user name for virtuoso TDB. However, different user can be provided if created in virtuoso with appropriate permissions.
user_passdbaDefault user password for virtuoso TDB. However, different user information can be provided if created in virtuoso with appropriate permissions.

3.2.5.3. Important File Directories

  • Following are the important directories for Semantic Validator.
    • Project java code files : project/src/java/com/semantics/validation
    • External Jar files : project/lib
    • Maven Dependencies : project/pom.xml

3.2.6. Deployment Steps

NOTE: the installation instructions are based on eclipse IDE in windows, so it may vary for different IDEs and platforms.

3.2.6.1. Download Project

Download the project from github and choose "semantic validator"

3.2.6.2. Import Project in IDE

  • In Eclipse, Go to File>Import>Maven>Existing Maven Projects
  • Locate the downloaded project and import.

3.2.6.3. Add external Jar dependencies

  • The external jars to be added are located in the project at project/lib. If they are not already added, then must be added manually.
  • In Eclipse, right click on project folder, go to Build Path > Configure Build Path > Java Build Path. Then go under the Libraries tab, which shows the current jars added to the build path.
  • On the right side click “Add External Jars”.
  • Locate the lib directory and select the files inside.
  • Click “Apply and Close”

3.2.6.4. Application Deployment

The class Validator.java can be used for validation. Which has three main functions: createOWLOntologyFromInstance(), isEntailed(), isConsistent().

  • Constructor: Validator(): retrieves the ontologies from the TDB and generates OWLOntology object which is required for validation. Therefore it’s object should be created only when the ontology is changed or added.
  • createOWLOntologyFromInstance(): this converts the individual assertions in the Jena Model object to OWLOntology object, which is required to be validated. Therefore execute this function before validation, to populate the instance object, which contains the individual assertions.
  • isConsistent(): Use this function to check whether the individual assertions are consistent with the ontologies in the TDB.
  • isEntailed(): Similarly use this function to validate entailment.