| Line 63 was replaced by line 63 |
| - <individual type="ont:C" foreach="R.x"> |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| Lines 66-78 were replaced by lines 66-75 |
| - <p> This pattern can be read as "For each unique x value of R create |
| - an instance of C." In this example, the term "R.x" is a <em><a |
| - href="#variable">resource variable</a></em>. Executing this pattern |
| - results in the following document, assuming there are <em>n</em> |
| - unique values of <code>x</code> in <code>R</code> <a |
| - href="#3">[4]</a>. As above, identifiers are generated as a result of |
| - executing the pattern over <code>R</code>. |
| - |
| - <pre> |
| - <rdf:RDF xmlns="local-ns" ...> |
| - <owl:Ontology rdf:about=""> |
| - <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| - </owl:Ontology> |
| + This pattern can be read as "For each unique x value of R create |
| + an instance of C." In this example, the term "R.x" is a __resource variable__. Executing this pattern results in the following document, assuming there are __n__ |
| + unique values of {{x}} in {{R}}[4]. As above, identifiers are generated as a result of |
| + executing the pattern over {{R}}. |
| + |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about=""> |
| + <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| + </owl:Ontology> |
| Lines 80-81 were replaced by lines 77-78 |
| - <ont:C rdf:ID="id-val1"/> |
| - <ont:C rdf:ID="id-val2"/> |
| + <ont:C rdf:ID="id-val1"/> |
| + <ont:C rdf:ID="id-val2"/> |
| Line 83 was replaced by line 80 |
| - <ont:C rdf:ID="id-valn"/> |
| + <ont:C rdf:ID="id-valn"/> |
| Lines 85-86 were replaced by lines 82-83 |
| - </rdf:RDF> |
| - </pre> |
| + </rdf:RDF> |
| + }}} |
| Line 88 was replaced by line 85 |
| - <p> Note that this document has a different namespace than the |
| + Note that this document has a different namespace than the |
| Lines 96-97 were replaced by lines 93-94 |
| - <p> We use rules expressed in first-order logic to formalize how |
| - instantiation patterns should be interpreted <a href="#5">[5]</a>. For |
| + We use rules expressed in first-order logic to formalize how |
| + instantiation patterns should be interpreted[5]. For |
| Line 100 was replaced by line 97 |
| - <pre> |
| + {{{ |
| Line 102 was replaced by line 99 |
| - </pre> |
| + }}} |
| Lines 104-105 were replaced by lines 101-102 |
| - <p> Here, the predicate <code>triple</code> asserts an RDF triple |
| - (with subject, property, value), and <code>id_p1</code> is a (Skolem) |
| + Here, the predicate {{triple}} asserts an RDF triple |
| + (with subject, property, value), and {{id_p1}} is a (Skolem) |
| Lines 107-109 were replaced by lines 104-106 |
| - <code>id_p1</code> is meant to apply only within this rule, where p1 |
| - stands for "pattern 1." We say in this case that each <code>x</code> |
| - value of <code>R</code> constitues a particular <code>C</code>. |
| + {{id_p1}} is meant to apply only within this rule, where p1 |
| + stands for "pattern 1." We say in this case that each {{x}} |
| + value of {{R}} constitues a particular {{C}}. |
| Line 111 was replaced by line 108 |
| - <p> There are a number of additional features of instantiation |
| + There are a number of additional features of instantiation |
| Line 119 was replaced by line 116 |
| - <h3>3.1 Individuals</h3> |
| + !!3.1 Individuals |
| Lines 121-129 were replaced by lines 118-126 |
| - <p> <b>Iteration.</b> More than one variable can be given in a |
| - <code>foreach</code> expression. For example, the following pattern |
| - creates an instance of <code>C</code> for every unique pair of |
| - <code>x</code> and <code>y</code> values occurring together in tuples |
| - of <code>R</code>. |
| - |
| - <pre> |
| - <individual type="ont:C" foreach="R.x, R.y"/> |
| - </pre> |
| + __Iteration.__ More than one variable can be given in a |
| + {{foreach}} expression. For example, the following pattern |
| + creates an instance of {{C}} for every unique pair of |
| + {{x}} and {{y}} values occurring together in tuples |
| + of {{R}}. |
| + |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x, R.y"/> |
| + }}} |
| Line 131 was replaced by line 128 |
| - <p> This pattern can be read as "For each unique x, y (tuple) value |
| + This pattern can be read as "For each unique x, y (tuple) value |
| Line 135 was replaced by line 132 |
| - <pre> |
| + {{{ |
| Line 137 was replaced by line 134 |
| - </pre> |
| + }}} |
| Lines 139-140 were replaced by lines 136-137 |
| - <p> In this example, we say that each <code>x,y</code> value |
| - constitutes a particular <code>C</code>. |
| + In this example, we say that each {{x,y}} value |
| + constitutes a particular {{C}}. |
| Line 142 was replaced by line 139 |
| - <p> Resource labels (such as <code>R</code>) in annotations are used |
| + Resource labels (such as {{R}}) in annotations are used |
| Lines 145-147 were replaced by lines 142-144 |
| - resource in an annotation header. For example, if <code>R1</code> and |
| - <code>R2</code> are both labels for the <code>Employee</code> |
| - relation, the iteration expression "<code>R1.x, R2.x</code>" is |
| + resource in an annotation header. For example, if {{R1}} and |
| + {{R2}} are both labels for the {{Employee}} |
| + relation, the iteration expression "{{R1.x, R2.x}}" is |
| Lines 150-151 were replaced by lines 147-148 |
| - <pre> |
| - SELECT R1.x, R2.x |
| + {{{ |
| + SELECT DISTINCT R1.x, R2.x |
| Line 153 was replaced by line 150 |
| - </pre> |
| + }}} |
| Lines 155-156 were replaced by lines 152-153 |
| - <p> In a similar way, one can view <code>foreach</code> expressions as |
| - group constructors, similar to the <code>GROUP BY</code> clause in |
| + In a similar way, one can view {{foreach}} expressions as |
| + group constructors, similar to the {{GROUP BY}} clause in |
| Line 159 was replaced by line 156 |
| - <p> <b>Conditions.</b> Conditions can be added to restrict the |
| + __Conditions.__ Conditions can be added to restrict the |
| Lines 161-162 were replaced by lines 158-159 |
| - the creation of <code>C</code> instances based on positive values of |
| - <code>x</code>. |
| + the creation of {{C}} instances based on positive values of |
| + {{x}}. |
| Lines 164-166 were replaced by lines 161-163 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x, R.y" if="R.x>0"/> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x, R.y" if="R.x>0"/> |
| + }}} |
| Line 168 was replaced by line 165 |
| - <p> This pattern can be read as "For each unique x, y (tuple) value |
| + This pattern can be read as "For each unique x, y (tuple) value |
| Line 172 was replaced by line 169 |
| - <pre> |
| + {{{ |
| Line 174 was replaced by line 171 |
| - </pre> |
| + }}} |
| Lines 176-181 were replaced by lines 173-178 |
| - <p> In general, conditions are Boolean expressions of the form |
| - <code>term op term</code>, where a <code>term</code> is a constant or |
| - variable (such as <code>R.x</code> or the value <code>5</code>), and |
| - <code>op</code> is a Boolean operator such as <code><</code>, |
| - <code>></code>, <code><=</code>, <code>>=</code>, or |
| - <code>=</code>. |
| + In general, conditions are Boolean expressions of the form |
| + {{term op term}}, where a {{term}} is a constant or |
| + variable (such as {{R.x}} or the value {{5}}), and |
| + {{op}} is a Boolean operator such as {{<}}, |
| + {{>}}, {{<=}}, {{>=}}, or |
| + {{=}}. |
| Line 183 was replaced by line 180 |
| - <p> As with <code>foreach</code> expressions, <code>if</code> |
| + As with {{foreach}} expressions, {{if}} |
| Lines 186-187 were replaced by lines 183-184 |
| - variables that are outside the condition's <em><a |
| - href="#context">iteration context</a></em>, i.e., the set of variables |
| + variables that are outside the condition's __<a |
| + href="#context">iteration context</a>__, i.e., the set of variables |
| Lines 189-190 were replaced by lines 186-187 |
| - corresponding <code>foreach</code> expression. Note that any given |
| - binding of <code>foreach</code> variables may have many associated |
| + corresponding {{foreach}} expression. Note that any given |
| + binding of {{foreach}} variables may have many associated |
| Lines 192-193 were replaced by lines 189-190 |
| - <code>if</code> expression is satisfied whenever the condition is true |
| - for any one of these values (i.e., similar to the <code>ANY</code> |
| + {{if}} expression is satisfied whenever the condition is true |
| + for any one of these values (i.e., similar to the {{ANY}} |
| Lines 197-198 were replaced by line 194 |
| - |
| - <h3>3.2 Object Properties</h3> |
| + !!3.2 Object Properties |
| Line 200 was replaced by line 196 |
| - <p> A <code>property</code> expression assigns OWL properties to |
| + A {{property}} expression assigns OWL properties to |
| Lines 202-203 were replaced by lines 198-199 |
| - example, the following pattern creates instances of <code>C</code> |
| - containing properties <code>P</code>: |
| + example, the following pattern creates instances of {{C}} |
| + containing properties {{P}}: |
| Lines 205-209 were replaced by lines 201-205 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" valuetype="ont:D"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" valuetype="ont:D"/> |
| + </individual> |
| + }}} |
| Line 211 was replaced by line 207 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Lines 214-215 were replaced by lines 210-216 |
| - <em>n</em> unique values of <code>x</code> in <code>R</code> <a |
| - href="#6">[6]</a>. |
| + __n__ unique values of {{x}} in {{R}}[6]. |
| + |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about=""> |
| + <owl:imports rdf:resource="htt://ontologies.org/ont"/> |
| + </owl:Ontology> |
| Lines 217-227 were replaced by lines 218-222 |
| - <pre> |
| - <rdf:RDF xmlns="local-ns" ...> |
| - <owl:Ontology rdf:about=""> |
| - <owl:imports rdf:resource="htt://ontologies.org/ont"/> |
| - </owl:Ontology> |
| - |
| - <ont:C rdf:ID="id-val1"> |
| - <ont:P> |
| - <ont:D/> |
| - </ont:P> |
| - </ont:C> |
| + <ont:C rdf:ID="id-val1"> |
| + <ont:P> |
| + <ont:D/> |
| + </ont:P> |
| + </ont:C> |
| Lines 229-233 were replaced by lines 224-228 |
| - <ont:C rdf:ID="id-valn"> |
| - <ont:P> |
| - <ont:D/> |
| - </ont:P> |
| - </ont:C> |
| + <ont:C rdf:ID="id-valn"> |
| + <ont:P> |
| + <ont:D/> |
| + </ont:P> |
| + </ont:C> |
| Lines 235-236 were replaced by lines 230-231 |
| - </rdf:RDF> |
| - </pre> |
| + </rdf:RDF> |
| + }}} |
| Line 238 was replaced by line 233 |
| - <p> The first-order rule for this pattern is: |
| + The first-order rule for this pattern is: |
| Line 240 was replaced by line 235 |
| - <pre> |
| + {{{ |
| Line 244 was replaced by line 239 |
| - </pre> |
| + }}} |
| Line 246 was replaced by line 241 |
| - <p> Note that in this rule, <code>v</code> is existentially |
| + Note that in this rule, {{v}} is existentially |
| Lines 249-250 were replaced by lines 244-245 |
| - function over <code>x</code> values (similar to <code>id_p4</code>) |
| - for generating the appropriate <code>D</code> identifiers. |
| + function over {{x}} values (similar to {{id_p4}}) |
| + for generating the appropriate {{D}} identifiers. |
| Line 252 was replaced by line 247 |
| - <p> <b>Nested Properties.</b> Property expressions corresponding to |
| + __Nested Properties.__ Property expressions corresponding to |
| Line 255 was replaced by line 250 |
| - <code>D</code> instances above with <code>Q</code> properties: |
| + {{D}} instances above with {{Q}} properties: |
| Lines 257-263 were replaced by lines 252-258 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" valuetype="ont:D"> |
| - <property type="ont:Q" valuetype="ont:E"/> |
| - </property> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" valuetype="ont:D"> |
| + <property type="ont:Q" valuetype="ont:E"/> |
| + </property> |
| + </individual> |
| + }}} |
| Line 265 was replaced by line 260 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Line 270 was replaced by line 265 |
| - <pre> |
| + {{{ |
| Line 276 was replaced by line 271 |
| - </pre> |
| + }}} |
| Line 278 was replaced by line 273 |
| - <p> <b>Multiple Properties.</b> Individuals can be assigned more than |
| + __Multiple Properties.__ Individuals can be assigned more than |
| Line 280 was replaced by line 275 |
| - <code>P1</code> and <code>P2</code>. |
| + {{P1}} and {{P2}}. |
| Lines 282-287 were replaced by lines 277-282 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P1" valuetype="ont:D1"/> |
| - <property type="ont:P2" valuetype="ont:D2"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P1" valuetype="ont:D1"/> |
| + <property type="ont:P2" valuetype="ont:D2"/> |
| + </individual> |
| + }}} |
| Line 290 was replaced by line 285 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Line 293 was replaced by line 288 |
| - <pre> |
| + {{{ |
| Line 299 was replaced by line 294 |
| - </pre> |
| + }}} |
| Lines 302-304 were replaced by lines 297-299 |
| - <p> The general form of a pattern consists of an |
| - <code>individual</code> expression, followed by any number of |
| - (possibly nested) <code>property</code> expressions: |
| + The general form of a pattern consists of an |
| + {{individual}} expression, followed by any number of |
| + (possibly nested) {{property}} expressions: |
| Lines 306-308 were replaced by lines 301-303 |
| - <pre> |
| - <individual type="..." foreach="..." if="..." ...> |
| - <property type="..." ...> |
| + {{{ |
| + <individual type="..." foreach="..." if="..." ...> |
| + <property type="..." ...> |
| Line 310 was replaced by line 305 |
| - </property> |
| + </property> |
| Lines 312-313 were replaced by lines 307-308 |
| - </individual> |
| - </pre> |
| + </individual> |
| + }}} |
| Lines 315-316 were replaced by lines 310-311 |
| - <p> The additional attributes of <code>individual</code> and |
| - <code>property</code> statements are described further below (as well |
| + The additional attributes of {{individual}} and |
| + {{property}} statements are described further below (as well |
| Line 319 was replaced by line 314 |
| - <h3>3.3 Datatype Properties</h3> |
| + !!3.3 Datatype Properties |
| Line 321 was replaced by line 316 |
| - <p> The examples so far assume the use of OWL object properties, whose |
| + The examples so far assume the use of OWL object properties, whose |
| Lines 327-329 were replaced by lines 322-324 |
| - <p> Datatype <code>property</code> statements use the attribute |
| - <code>value</code> instead of <code>valuetype</code>. In general, a |
| - <code>value</code> attribute is used to assign a specific data value |
| + Datatype {{property}} statements use the attribute |
| + {{value}} instead of {{valuetype}}. In general, a |
| + {{value}} attribute is used to assign a specific data value |
| Lines 331-332 were replaced by lines 326-327 |
| - <code>valuetype</code> attribute is used to give the type of the |
| - individual linked to the property. Thus, <code>valuetype</code> |
| + {{valuetype}} attribute is used to give the type of the |
| + individual linked to the property. Thus, {{valuetype}} |
| Lines 334-336 were replaced by lines 329-331 |
| - <code>value</code> attributes can be used for assigning both object |
| - and datatype properties. <code>Property</code> statements that use a |
| - <code>value</code> attribute (for either an object or datatype |
| + {{value}} attributes can be used for assigning both object |
| + and datatype properties. {{Property}} statements that use a |
| + {{value}} attribute (for either an object or datatype |
| Line 339 was replaced by line 334 |
| - <p> <b>Constants.</b> One use of a datatype property annotation is for |
| + __Constants.__ One use of a datatype property annotation is for |
| Lines 342-343 were replaced by lines 337-338 |
| - property <code>P</code> with the value <code>5</code> to each |
| - generated <code>C</code> instance. |
| + property {{P}} with the value {{5}} to each |
| + generated {{C}} instance. |
| Lines 345-349 were replaced by lines 340-344 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" value="5"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="5"/> |
| + </individual> |
| + }}} |
| Line 351 was replaced by line 346 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Line 355 was replaced by line 350 |
| - <pre> |
| + {{{ |
| Line 358 was replaced by line 353 |
| - </pre> |
| + }}} |
| Line 360 was replaced by line 355 |
| - <p> <b>Resource Values.</b> Another common use of datatype property |
| + __Resource Values.__ Another common use of datatype property |
| Lines 362-363 were replaced by lines 357-358 |
| - the following pattern assigns each instance a property <code>P</code> |
| - whose value is taken from the resource variable <code>x</code>. |
| + the following pattern assigns each instance a property {{P}} |
| + whose value is taken from the resource variable {{x}}. |
| Lines 365-369 were replaced by lines 360-364 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" value="$R.x"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="$R.x"/> |
| + </individual> |
| + }}} |
| Line 371 was replaced by line 366 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Line 377 was replaced by line 372 |
| - <pre> |
| + {{{ |
| Line 380 was replaced by line 375 |
| - </pre> |
| + }}} |
| Lines 382-383 were replaced by lines 377-378 |
| - <p> Resource variables can be used outside of the current iteration |
| - context (i.e., the enclosing <code>foreach</code> expression). In this |
| + Resource variables can be used outside of the current iteration |
| + context (i.e., the enclosing {{foreach}} expression). In this |
| Lines 388-396 were replaced by lines 383-391 |
| - assigns to each instance associated with <code>x</code>, a property |
| - <code>P</code> for each of <code>x</code>'s corresponding |
| - <code>y</code> values. |
| - |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" value="$R.y"/> |
| - </individual> |
| - </pre> |
| + assigns to each instance associated with {{x}}, a property |
| + {{P}} for each of {{x}}'s corresponding |
| + {{y}} values. |
| + |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="$R.y"/> |
| + </individual> |
| + }}} |
| Line 398 was replaced by line 393 |
| - <p> This pattern can be read as "For each unique x value of R, create |
| + This pattern can be read as "For each unique x value of R, create |
| Line 400 was replaced by line 395 |
| - value of x" <a href="#7">[7]</a>. The corresponding first-order rule for this pattern is: |
| + value of x"[7]. The corresponding first-order rule for this pattern is: |
| Line 402 was replaced by line 397 |
| - <pre> |
| + {{{ |
| Line 405 was replaced by line 400 |
| - </pre> |
| + }}} |
| Lines 407-413 were replaced by lines 402-408 |
| - <p> In this case, if a particular <code>x</code> value has multiple |
| - <code>y</code> values, each such <code>y</code> value will result in a |
| - <code>P</code> property. Note that if <code>x</code> and |
| - <code>y</code> were not related, (e.g., if the expressions were |
| - <code>R1.x</code> and <code>R2.y</code>, respectively), the result |
| - would be a cross-product in which every <code>x</code> value would be |
| - <code>P</code>-related to every <code>y</code> value. For example, the |
| + In this case, if a particular {{x}} value has multiple |
| + {{y}} values, each such {{y}} value will result in a |
| + {{P}} property. Note that if {{x}} and |
| + {{y}} were not related, (e.g., if the expressions were |
| + {{R1.x}} and {{R2.y}}, respectively), the result |
| + would be a cross-product in which every {{x}} value would be |
| + {{P}}-related to every {{y}} value. For example, the |
| Lines 416-424 were replaced by lines 411-419 |
| - <pre> |
| - <individual type="ont:C" foreach="R1.x"> |
| - <property type="ont:P" value="$R2.y"/> |
| - </individual> |
| - </pre> |
| - |
| - <p> corresponds to the following first-order rule, assuming |
| - <code>R1</code> and <code>R2</code> both represent relation |
| - <code>R</code>: |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R1.x"> |
| + <property type="ont:P" value="$R2.y"/> |
| + </individual> |
| + }}} |
| + |
| + corresponds to the following first-order rule, assuming |
| + {{R1}} and {{R2}} both represent relation |
| + {{R}}: |
| Line 426 was replaced by line 421 |
| - <pre> |
| + {{{ |
| Lines 429-430 were replaced by line 424 |
| - </pre> |
| - |
| + }}} |
| Line 432 was replaced by line 426 |
| - <p> In an instantiation pattern, <code>value</code> expressions must |
| + In an instantiation pattern, {{value}} expressions must |
| Line 434 was replaced by line 428 |
| - useful to define functions for use in <code>value</code> expressions, |
| + useful to define functions for use in {{value}} expressions, |
| Lines 437-440 were replaced by lines 431-434 |
| - <p> <b>Conditional Properties.</b> A <code>property</code> statement |
| - can be conditionally applied using an <code>if</code> expression. In |
| - particular, the conditions of the <code>if</code> expression must hold |
| - for the <code>property</code> to be added to the corresponding |
| + __Conditional Properties.__ A {{property}} statement |
| + can be conditionally applied using an {{if}} expression. In |
| + particular, the conditions of the {{if}} expression must hold |
| + for the {{property}} to be added to the corresponding |
| Line 442 was replaced by line 436 |
| - <code>P</code> to the individual if <code>x</code> is a positive |
| + {{P}} to the individual if {{x}} is a positive |
| Lines 445-449 were replaced by lines 439-443 |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" value="$R.x" if="R.x>0"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="$R.x" if="R.x>0"/> |
| + </individual> |
| + }}} |
| Line 451 was replaced by line 445 |
| - <p> This patterns must be represented using two first-order rules: |
| + This patterns must be represented using two first-order rules: |
| Line 453 was replaced by line 447 |
| - <pre> |
| + {{{ |
| Line 457 was replaced by line 451 |
| - </pre> |
| + }}} |
| Line 459 was replaced by line 453 |
| - <p> Thus, the condition on the property does not affect whether the |
| + Thus, the condition on the property does not affect whether the |
| Line 461 was replaced by line 455 |
| - <code>P</code> property. Using property conditions, it is possible to |
| + {{P}} property. Using property conditions, it is possible to |
| Line 466 was replaced by line 460 |
| - <p> Like with conditions on <code>individual</code> statements, no |
| + Like with conditions on {{individual}} statements, no |
| Line 468 was replaced by line 462 |
| - <code>property</code> statement conditions. Variables used in |
| + {{property}} statement conditions. Variables used in |
| Lines 470-471 were replaced by lines 464-465 |
| - property, with the exception of variables within <code>value</code> |
| - expressions <a href="#8">[8]</a>, require only one associated value to |
| + property, with the exception of variables within {{value}} |
| + expressions[8], require only one associated value to |
| Line 473 was replaced by line 467 |
| - to the <code>ANY</code> keyword in SQL). |
| + to the {{ANY}} keyword in SQL). |
| Line 476 was replaced by line 470 |
| - <h3>3.3 Complex Instantiation Patterns</h3> |
| + !!3.3 Complex Instantiation Patterns |
| Lines 478-480 were replaced by lines 472-474 |
| - <p> We have described two mechanisms to link individuals to object |
| - properties: through <code>valuetype</code> expressions that generate |
| - new, anonymous individuals "in place"; and through <code>value</code> |
| + We have described two mechanisms to link individuals to object |
| + properties: through {{valuetype}} expressions that generate |
| + new, anonymous individuals "in place"; and through {{value}} |
| Lines 482-483 were replaced by lines 476-477 |
| - introduce the use of <em><a href="#label">pattern labels</a></em> and |
| - <em><a href="#reference">pattern references</a></em> to additionally |
| + introduce the use of __pattern labels__ and |
| + __pattern references__ to additionally |
| Line 487 was replaced by line 481 |
| - <p> <b>Pattern Labels.</b> Each individual instantiation pattern can |
| + __Pattern Labels.__ Each individual instantiation pattern can |
| Lines 491-493 were replaced by lines 485-487 |
| - <pre> |
| - <individual label="o1" type="ont:C" foreach="R.x"/> |
| - </pre> |
| + {{{ |
| + <individual label="o1" type="ont:C" foreach="DISTINCT R.x"/> |
| + }}} |
| Line 495 was replaced by line 489 |
| - <p> The first-order rule for this pattern is: |
| + The first-order rule for this pattern is: |
| Line 497 was replaced by line 491 |
| - <pre> |
| + {{{ |
| Line 499 was replaced by line 493 |
| - </pre> |
| + }}} |
| Line 501 was replaced by line 495 |
| - <p> The use of labels in this way does not change the interpretation |
| + The use of labels in this way does not change the interpretation |
| Lines 506-508 were replaced by lines 500-501 |
| - <p> <b>Referencing Patterns.</b> Properties can reference patterns |
| - using pattern labels in <code>value</code> expressions <a |
| - href="#9">[9]</a>. To distinguish pattern references from constants |
| + __Referencing Patterns.__ Properties can reference patterns |
| + using pattern labels in {{value}} expressions[9]. To distinguish pattern references from constants |
| Lines 513-517 were replaced by lines 506-510 |
| - <pre> |
| - <individual label="o2" type="ont:D" foreach="R.x, R.y"> |
| - <property type="ont:P" value="@o1"/> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual label="o2" type="ont:D" foreach="DISTINCT R.x, R.y"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| + }}} |
| Line 519 was replaced by line 512 |
| - <p> This pattern can be read as "For each unique x, y (tuple) value |
| + This pattern can be read as "For each unique x, y (tuple) value |
| Line 524 was replaced by line 517 |
| - <pre> |
| + {{{ |
| Line 527 was replaced by line 520 |
| - </pre> |
| + }}} |
| Line 529 was replaced by line 522 |
| - <p> As with resource variables, pattern references are interpreted |
| + As with resource variables, pattern references are interpreted |
| Lines 531-534 were replaced by lines 524-527 |
| - because <code>P</code>'s iteration context is "R.x, R.y" and |
| - <code>o1</code>'s iteration context is "R.x" (i.e., <code>o1</code>'s |
| - <code>foreach</code> expression is contained in <code>P</code>'s |
| - enclosing <code>foreach</code> expression), the added <code>P</code> |
| + because {{P}}'s iteration context is "R.x, R.y" and |
| + {{o1}}'s iteration context is "R.x" (i.e., {{o1}}'s |
| + {{foreach}} expression is contained in {{P}}'s |
| + enclosing {{foreach}} expression), the added {{P}} |
| Line 536 was replaced by line 529 |
| - <code>x</code> value of the iteration context. |
| + {{x}} value of the iteration context. |
| Line 538 was replaced by line 531 |
| - <p> The iteration context of a property is not required to be a |
| + The iteration context of a property is not required to be a |
| Lines 542-552 were replaced by lines 535-545 |
| - <pre> |
| - <individual label="o3" type="ont:D" foreach="R.y, R.z"> |
| - <property type="ont:P" value="@o1"/> |
| - </individual> |
| - </pre> |
| - |
| - <p> each unique <code>y</code>, <code>z</code> pair for <code>R</code> |
| - will be assigned a property <code>P</code> for every corresponding |
| - <code>x</code> value of the pair. Note that in this example, any given |
| - <code>y</code>, <code>z</code> pair may have multiple associated |
| - <code>x</code> values. |
| + {{{ |
| + <individual label="o3" type="ont:D" foreach="DISTINCT R.y, R.z"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| + }}} |
| + |
| + each unique {{y}}, {{z}} pair for {{R}} |
| + will be assigned a property {{P}} for every corresponding |
| + {{x}} value of the pair. Note that in this example, any given |
| + {{y}}, {{z}} pair may have multiple associated |
| + {{x}} values. |
| Lines 554-555 were replaced by lines 547-548 |
| - <p> Also, the iteration context of a property only applies to the |
| - referenced pattern, and does <em>not</em> apply to additionally nested |
| + Also, the iteration context of a property only applies to the |
| + referenced pattern, and does __not__ apply to additionally nested |
| Lines 558-561 were replaced by lines 551-554 |
| - <pre> |
| - <individual label="o5" type="ont:E" foreach="R.x, R.z"> |
| - <property type="ont:Q" value="@o4"/> |
| - </individual> |
| + {{{ |
| + <individual label="o5" type="ont:E" foreach="DISTINCT R.x, R.z"> |
| + <property type="ont:Q" value="@o4"/> |
| + </individual> |
| Lines 563-565 were replaced by lines 556-558 |
| - <individual label="o4" type="ont:D" foreach="R.y"> |
| - <property type="ont:P" value="@o1"/> |
| - </individual> |
| + <individual label="o4" type="ont:D" foreach="DISTINCT R.y"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| Line 567 was replaced by line 560 |
| - </pre> |
| + }}} |
| Line 569 was replaced by line 562 |
| - <p> The corresponding first-order rules for these patterns are: |
| + The corresponding first-order rules for these patterns are: |
| Line 571 was replaced by line 564 |
| - <pre> |
| + {{{ |
| Line 577 was replaced by line 570 |
| - </pre> |
| + }}} |
| Line 579 was replaced by line 572 |
| - <p> Thus, although property values containing pattern references are |
| + Thus, although property values containing pattern references are |
| Lines 581-582 were replaced by lines 574-575 |
| - <code>foreach</code> expression, each distinct pattern is still |
| - executed within its own context. To illustrate, let <code>R</code> be |
| + {{foreach}} expression, each distinct pattern is still |
| + executed within its own context. To illustrate, let {{R}} be |
| Line 585 was replaced by line 578 |
| - <pre> |
| + {{{ |
| Line 590 was replaced by line 583 |
| - </pre> |
| + }}} |
| Line 592 was replaced by line 585 |
| - <p> The triples created from pattern <code>o1</code> are: |
| + The triples created from pattern {{o1}} are: |
| Line 594 was replaced by line 587 |
| - <pre> |
| + {{{ |
| Line 597 was replaced by line 590 |
| - </pre> |
| + }}} |
| Line 599 was replaced by line 592 |
| - <p> The triples created from pattern <code>o4</code> are: |
| + The triples created from pattern {{o4}} are: |
| Line 601 was replaced by line 594 |
| - <pre> |
| + {{{ |
| Line 605 was replaced by line 598 |
| - </pre> |
| + }}} |
| Line 607 was replaced by line 600 |
| - <p> And the triples created from pattern <code>o5</code> are: |
| + And the triples created from pattern {{o5}} are: |
| Line 609 was replaced by line 602 |
| - <pre> |
| + {{{ |
| Line 614 was replaced by line 607 |
| - </pre> |
| + }}} |
| Lines 616-635 were replaced by lines 609-620 |
| - <p> Notice that both individuals of pattern <code>o5</code> are |
| - <code>Q</code>-related to the same <code>o4</code> |
| - individual. Similarly, this <code>o4</code> individual is |
| - <code>P</code>-related to both individuals of <code>o1</code>, |
| - corresponding to <em>both</em> <code>x</code> values of |
| - <code>R</code>, and thus going "out of context" for pattern |
| - <code>o5</code>. |
| - |
| - <p> To use the iteration context of <code>o5</code> for |
| - <code>o1</code> while still generating intermediate instances of |
| - <code>D</code>, we can use the following pattern, combining |
| - <code>o5</code> and <code>o4</code>: |
| - |
| - <pre> |
| - <individual label="o6" type="ont:E" foreach="R.x, R.z"> |
| - <property type="ont:Q" valuetype="ont:D"> |
| - <property type="ont:P" value="@o1"/> |
| - </property> |
| - </individual> |
| - </pre> |
| + Notice that both individuals of pattern {{o5}} are |
| + {{Q}}-related to the same {{o4}} |
| + individual. Similarly, this {{o4}} individual is |
| + {{P}}-related to both individuals of {{o1}}, |
| + corresponding to __both__ {{x}} values of |
| + {{R}}, and thus going "out of context" for pattern |
| + {{o5}}. |
| + |
| + To use the iteration context of {{o5}} for |
| + {{o1}} while still generating intermediate instances of |
| + {{D}}, we can use the following pattern, combining |
| + {{o5}} and {{o4}}: |
| Line 637 was replaced by lines 622-630 |
| - <p> The corresponding first-order rule for this pattern is: |
| + {{{ |
| + <individual label="o6" type="ont:E" foreach="DISTINCT R.x, R.z"> |
| + <property type="ont:Q" valuetype="ont:D"> |
| + <property type="ont:P" value="@o1"/> |
| + </property> |
| + </individual> |
| + }}} |
| + |
| + The corresponding first-order rule for this pattern is: |
| Line 639 was replaced by line 632 |
| - <pre> |
| + {{{ |
| Line 644 was replaced by line 637 |
| - </pre> |
| + }}} |
| Lines 646-649 were replaced by lines 639-642 |
| - <p> Note that in this case, however, we generate only one |
| - <code>D</code> instance per <code>x</code>, <code>z</code> |
| - pair,(instead of one for every value of <code>y</code>. Also, with |
| - pattern <code>o6</code>, we can no longer reference the <code>D</code> |
| + Note that in this case, however, we generate only one |
| + {{D}} instance per {{x}}, {{z}} |
| + pair,(instead of one for every value of {{y}}. Also, with |
| + pattern {{o6}}, we can no longer reference the {{D}} |
| Lines 652-653 were replaced by lines 645-646 |
| - <p> <b>Property Iteration and Labels</b>. It is also possible to apply |
| - <code>foreach</code> expressions to <code>property</code> statements, |
| + __Property Iteration and Labels__. It is also possible to apply |
| + {{foreach}} expressions to {{property}} statements, |
| Line 655 was replaced by line 648 |
| - individuals, for cases like <code>o6</code> above, should be |
| + individuals, for cases like {{o6}} above, should be |
| Lines 658-664 were replaced by lines 651-657 |
| - <pre> |
| - <individual label="o7" type="ont:E" foreach="R.x, R.z"> |
| - <property type="ont:Q" valuetype="ont:D" foreach="R.y" label="o8"> |
| - <property type="ont:P" value="@o1"/> |
| - </property> |
| - </individual> |
| - </pre> |
| + {{{ |
| + <individual label="o7" type="ont:E" foreach="DISTINCT R.x, R.z"> |
| + <property type="ont:Q" valuetype="ont:D" foreach="DISTINCT R.y" label="o8"> |
| + <property type="ont:P" value="@o1"/> |
| + </property> |
| + </individual> |
| + }}} |
| Line 666 was replaced by line 659 |
| - <p> results in the first-order rule: |
| + results in the first-order rule: |
| Line 668 was replaced by line 661 |
| - <pre> |
| + {{{ |
| Line 674 was replaced by line 667 |
| - </pre> |
| + }}} |
| Lines 676-677 were replaced by lines 669-670 |
| - <p> As shown, labels may also be applied to intermediate individuals |
| - (via their corresponding <code>property</code> statements), allowing |
| + As shown, labels may also be applied to intermediate individuals |
| + (via their corresponding {{property}} statements), allowing |
| Lines 680-681 were replaced by lines 673-674 |
| - <code>foreach</code> expression with each of its ancestor's |
| - <code>foreach</code> expressions. |
| + {{foreach}} expression with each of its ancestor's |
| + {{foreach}} expressions. |
| At line 683 added 1 line. |
| + !!!Glossary |
| Line 685 was replaced by line 679 |
| - <a name="glossary"></a> <h2>Glossary</h2> |
| + ;Semantic Annotation: A mapping from a resource to an instance(s) of an ontology(ies). Semantic annotations in our framework have identifiers as well as associated metadata (who created the annotation, and so on). |
| Lines 687-690 were replaced by line 681 |
| - <p> <b><a name="annotation">Semantic Annotation<a/>:</b> A mapping |
| - from a resource to an instance(s) of an ontology(ies). Semantic |
| - annotations in our framework have identifiers as well as associated |
| - metadata (who created the annotation, and so on). |
| + ;Resource: A structured information source with a defined schema. Can be a dataset or a service, such as a workflow, actor, or web-service. |
| Lines 692-694 were replaced by line 683 |
| - <p> <b><a name="resource">Resource</a>:</b> A structured information |
| - source with a defined schema. Can be a dataset or a service, such as |
| - a workflow, actor, or web-service. |
| + ;Ontology: Here, by ontology we mean an OWL-based representation of a set of concepts, properties, and constraints (axioms). |
| Lines 696-698 were replaced by line 685 |
| - <p> <b><a name="ontology">Ontology</a>:</b> Here, by ontology we mean |
| - an OWL-based representation of a set of concepts, properties, and |
| - constraints (axioms). |
| + ;Semantic Annotation Template: A set of instantiation patterns within a particular semantic annotation. |
| Lines 700-726 were replaced by lines 687-695 |
| - <p> <b><a name="template">Semantic Annotation Template</a>:</b> A set |
| - of instantiation patterns within a particular semantic annotation. |
| - |
| - <p> <b><a name="pattern">Instantiation Pattern</a>:</b> An XML-based |
| - specification of a mapping from portions of a resource to instances |
| - of an ontology. |
| - |
| - <p> <b><a name="prefix">Prefix Label</a>:</b> A label used to |
| - represent an ontology location. |
| - |
| - <p> <b><a name="variable">Resource Variable</a>:</b> An attribute of a |
| - resource, which in an annotation template takes the form 'R.x' (or |
| - more generally a path expression 'R.x1.x2...xn' for nested |
| - relations). |
| - |
| - <p> <b><a name="context">Iteration Context</a>:</b> The set of |
| - resource variables, or current variable bindings (as the pattern is |
| - being executed), for a property or condition in an instantiation |
| - pattern. The iteration context is determined by the enclosing |
| - <code>foreach</code> expression of the item in question. |
| - |
| - <p> <b><a name="label">Pattern Label</a>:</b> A label assigned to a |
| - template instantiation pattern. |
| - |
| - <p> <b><a name="reference">Pattern Reference</a>:</b> A reference to a |
| - template instantiation pattern (using a pattern label) from within |
| - an object property in another (or possibly the same) pattern. |
| + ;Instantiation Pattern: An XML-based specification of a mapping from portions of a resource to instances of an ontology. |
| + |
| + ;Prefix Label: A label used to represent an ontology location. |
| + |
| + ;Resource Variable: An attribute of a resource, which in an annotation template takes the form 'R.x' (or more generally a path expression 'R.x1.x2...xn' for nested relations). |
| + |
| + ;Iteration Context: The set of resource variables, or current variable bindings (as the pattern is being executed), for a property or condition in an instantiation pattern. The iteration context is determined by the enclosing {{foreach}} expression of the item in question. |
| + |
| + ;Pattern Label: A label assigned to a template instantiation pattern. |
| At line 727 added 1 line. |
| + ;Pattern Reference: A reference to a template instantiation pattern (using a pattern label) from within an object property in another (or possibly the same) pattern. |
| Lines 730-764 were replaced by line 700 |
| - <a name="footnotes"></a> <h2>Footnotes</h2> |
| - |
| - <p> <a name="1">[1]</a> In OWL, instances of classes are called |
| - 'individuals.' |
| - |
| - <p> <a name="2">[2]</a> Alternatively, we could use anonymous |
| - identifiers for generated OWL individuals. However, using explicit |
| - as opposed to anonymous identifiers has a number of advantages, |
| - e.g., identifiers can be used for "provenance" (that is, using |
| - conventions for identifier names one could go from the created OWL |
| - individuals back to the resource item used to generte the resource), |
| - and also make it easier to formalize the interpretation of patterns |
| - in first-order logic. |
| - |
| - <p> <a name="2">[3]</a> The examples of resources in this document are |
| - assumed to be relational data sets. However, the approach described |
| - here can be used with a variety of resource structures, including |
| - nested relational data (e.g., like in XML). |
| - |
| - <p> <a name="3">[4]</a> By default, variables in <code>foreach</code> |
| - expressions that are null in the resource do not generate |
| - corresponding ontology class instances. |
| - |
| - <p> <a name="5">[5]</a> We use the notation <code>(Axy)</code> for |
| - universal quantification over variables <code>x</code> and |
| - <code>y</code>; <code>(Exy)</code> for existential quantification |
| - over variables <code>x</code> and <code>y</code>; and |
| - <code>-></code> for implication. |
| - |
| - <p> <a name="6">[6]</a> Note that the use of <code>property</code> |
| - expressions in this way is useful for cases in which the property is |
| - either (i) not defined (or optional) in the ontology for the |
| - associated class, or (ii) is a required property, but the |
| - <code>valuetype</code> expression gives a subclass of the property's |
| - defined range. |
| + !!!Footnotes |
| At line 765 added 12 lines. |
| + [#1] In OWL, instances of classes are called 'individuals.' |
| + |
| + [#2] Alternatively, we could use anonymous identifiers for generated OWL individuals. However, using explicit as opposed to anonymous identifiers has a number of advantages, e.g., identifiers can be used for "provenance" (that is, using conventions for identifier names one could go from the created OWL individuals back to the resource item used to generte the resource), and also make it easier to formalize the interpretation of patterns in first-order logic. |
| + |
| + [#3] The examples of resources in this document are assumed to be relational data sets. However, the approach described here can be used with a variety of resource structures, including nested relational data (e.g., like in XML). |
| + |
| + [#4] By default, variables in {{foreach}} expressions that are null in the resource do not generate corresponding ontology class instances. |
| + |
| + [#5] We use the notation {{(Axy)}} for universal quantification over variables {{x}} and {{y}}; {{(Exy)}} for existential quantification over variables {{x}} and {{y}}; and {{->}} for implication. |
| + |
| + [#6] Note that the use of {{property}} expressions in this way is useful for cases in which the property is either (i) not defined (or optional) in the ontology for the associated class, or (ii) is a required property, but the {{valuetype}} expression gives a subclass of the property's defined range. |
| + |
| Lines 772-773 were replaced by line 720 |
| - </pre> |
| - }}} |
| + }}} |
| Line 775 was replaced by line 722 |
| - That is, for each unique <code>x</code>, <code>y</code> pair, assign a <code>P</code> property with value <code>y</code> to the corresponding <code>C</code> instance. Additional uses of <code>foreach</code> attributes on properties are discussed later. |
| + That is, for each unique {{x}}, {{y}} pair, assign a {{P}} property with value {{y}} to the corresponding {{C}} instance. Additional uses of {{foreach}} attributes on properties are discussed later. |
