General Actions:
This document space describes the tools and processes for the quality verification of the design patterns.
These are: ontology editors, code validators and inference engines.
The ones that are used for CB-NL are described here.
The meaning of CB-NL concepts are coded with a design pattern that says:
a. subclasses obtain properties from all of their superclasses
b. because of a) sets of instances that are described by the subclass have properties from the superclasses above
c. subclasses have properties that discriminate them from their superclass
The design pattern that describes the above is (bold type):
X a owl:Class ;
rdfs:subClassOf Y ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty A ;
owl:someValuesFrom B
] ;
You can verify the correct behaviour of this design pattern with appropriate tools, such as Topbraid Composer.
The following procedure shows how subclasses obtain properties from all of their superclasses.
Write the following query:
CONSTRUCT { ?subject rdfs:subClassOf ?object }
WHERE {
?subject rdfs:subClassOf+ ?object .
}
You will see that the result shows a list of all the superclasses that exist above every subclass, even if they are not asserted. The “+” after rdfs:subClassOf tells the query engine to take one or more steps along the rdfs:subClassOf property. Since the properties are defined into the class via rdfs:subClassOf they are also listed.
Step 1: enable custom inferencing in Topbraid Composer via the menu Inference..Configure Inferencing.
NOTICE THE COMPLETE MODE CHECKMARK!
Step 2: Run the inference process by executing via the menu option Inference..Run Inferences.
The result shows inferred statements in blue next to the asserted statements in white.
The subClassOf section shows that the subclass “VasteBrug” of superclass “Brug” has received the subClassOf statements that are defined for “Brug” and its superclasses.
This section describes what is to be done to show that sets of instances that are described by the subclass have also properties from the superclasses above.
To be proven: the instances of VasteBrug receive the rdf:type definition of the superclass Brug and above. The rdfs:type definition means that the instance belongs to the class that is mentioned as the object of rdfs:type. When an instance belongs to a class, it satisfies the class definition, hence it receives the discriminating restrictions.
Step 1:
Before inferencing an example instance of VasteBrug looks like this:
After inferencing:
In the section where the RDF for the design pattern is listed the Turtle format is shown. The picture below shows how this code appears in the ontology editor Topbraid Composer. The class is “Brug”, the owl:ObjectProperty is hasFunction, and the filler Class is “Overbruggen”.
The editor has a feature that shows in natural language the meaning of this construction.
The owl:Restriction owl:someValuesFrom assigns to the class Brug the meaning that any instance that has at least one property value for hasFunction assigned to it that is of type “Overbruggen” is of type Brug.
So if we create an instance of Brug and do NOT assign any Overbruggen to hasFunction then it cannot be an instance of type Brug.
To verify this kind of constraint Topbraid Composer has some mechanism that you enable as follows:
Enable the library that controls this in the ontology profile:
Turn on the constraint violation warning icon in the menu:
Create an instance for Brug and do not fill anything in for hasFunction
A violation marker displayed, and with a mouse over some explanation is displayed: