Wiki source code of Design Pattern Verification

Last modified by Lieke Verhelst on 2014/09/18 15:45
Content · Comments (2) · Attachments (12) · History · Information
Hide line numbers
  1: This document space describes the tools and processes for the quality verification of the [[design patterns>>doc:Design Patterns]].
  2: 
  3: 
  4: = Quality verification tools =
  5: 
  6: These are: ontology editors, code validators and inference engines.
  7: 
  8: The ones that are used for CB-NL are described [[here>>doc:Ontology Quality Assurance Tools]].
  9: 
 10: 
 11: = **Steps to verify the design pattern for Concepts** =
 12: 
 13:  
 14: 
 15: The meaning of CB-NL concepts are coded with a design pattern that says:
 16: 
 17: a.       subclasses obtain properties from all of their superclasses
 18: 
 19: b.      because of a) sets of instances that are described by the subclass have properties from the superclasses above
 20: 
 21: c.       subclasses have properties that discriminate them from their superclass
 22: 
 23:  
 24: 
 25: == The design pattern for Concepts ==
 26: 
 27:  
 28: 
 29: The design pattern that describes the above is (bold type):
 30: 
 31: X      a       owl:Class ;
 32: 
 33:       rdfs:subClassOf Y ;
 34: 
 35:  **rdfs:subClassOf**
 36: 
 37: **~              [ a       owl:Restriction ;**
 38: 
 39: **~                owl:onProperty A ;**
 40: 
 41: **~                owl:someValuesFrom B**
 42: 
 43: **~              ] ;**
 44: 
 45:  
 46: 
 47: You can verify the correct behaviour of this design pattern with appropriate tools, such as Topbraid Composer.
 48: 
 49:  
 50: 
 51: **~ **
 52: 
 53: == Proof of the propagation of the property to the subclasses ==
 54: 
 55: **~ **
 56: 
 57: The following procedure shows how subclasses obtain properties from all of their superclasses.
 58: 
 59:  
 60: 
 61:  
 62: 
 63: === With SPARQL ===
 64: 
 65: Write the following query:
 66: 
 67: **CONSTRUCT** {  ?subject rdfs:subClassOf ?object }
 68: 
 69: **WHERE** {
 70: 
 71:     ?subject rdfs:subClassOf+ ?object .
 72: 
 73: }
 74: 
 75:  
 76: 
 77: 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.
 78: 
 79: 
 80: **[[image:1.png]]**
 81: 
 82:  
 83: 
 84: === With inferencing ===
 85: 
 86: Step 1: enable custom inferencing in Topbraid Composer via the menu Inference..Configure Inferencing.
 87: 
 88: [[image:2.png]]
 89: 
 90: [[image:3.png]]
 91: 
 92: **NOTICE THE COMPLETE MODE CHECKMARK!**
 93: 
 94: 
 95: Step 2: Run the inference process by executing via the menu option Inference..Run Inferences.
 96: 
 97: The result shows inferred statements in blue next to the asserted statements in white.
 98: 
 99: [[image:5.png]]
100: 
101:  
102: 
103: The subClassOf section shows that the subclass “VasteBrug” of superclass “Brug” has received the subClassOf statements that are defined for “Brug” and its superclasses.
104: 
105:  
106: 
107: == Proof of the fact that sets of instances that are described by the subclass have properties from the superclasses above ==
108: 
109: 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.
110: 
111: 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.\\
112: 
113: Step 1: 
114: Before inferencing an example instance of VasteBrug looks like this:
115: 
116: [[image:6.png]]
117: 
118:  
119: 
120: After inferencing:
121: 
122:  
123: 
124: [[image:7.png]]
125: 
126: 
127:  
128: 
129: == How properties  are assigned to subclasses to discriminate them from their superclass ==
130: 
131:  
132: 
133: 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”.
134: 
135: 
136: [[image:8.png]]
137: 
138:  
139: 
140: The editor has a feature that shows in natural language the meaning of this construction.
141: 
142: [[image:9.png]]
143: 
144:  
145: 
146: 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.
147: 
148: 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.
149: 
150: To verify this kind of constraint Topbraid Composer has some mechanism that you enable as follows:
151: 
152: Enable the library that controls this in the ontology profile:
153: 
154: [[image:10.png]]
155: 
156: Turn on the constraint violation warning icon in the menu:
157: 
158: [[image:11.png]]
159: 
160:  
161: 
162: Create an instance for Brug and do not fill anything in for hasFunction
163: 
164:  
165: 
166: [[image:12.png]]
167: 
168: 
169: A violation marker displayed, and with a mouse over some explanation is displayed:
170: 
171: [[image:13.png]]
172: 
173: