| Removed line 8 |
| - |
| Lines 11-82 were replaced by lines 10-21 |
| - <html> |
| - <head> |
| - <title>Introduction to Semantic Annotation Templates</title> |
| - <!-- Oldstyle, Modernist, Midnight, Ultramarine, Swiss, Chocolate, |
| - Traditional, Steely --> |
| - <link rel="stylesheet" href="http://www.w3.org/StyleSheets/Core/Swiss" |
| - type="text/css"> |
| - |
| - <STYLE TYPE="text/css"> |
| - <!-- |
| - p { |
| - font-family:Arial; |
| - font-size:12pt; |
| - } |
| - pre { |
| - color:darkblue; |
| - font-size:11pt; |
| - } |
| - code { |
| - color:darkblue; |
| - font-size:12pt; |
| - } |
| - em { |
| - font-style:italic; |
| - } |
| - --> |
| - </STYLE> |
| - |
| - </head> |
| - |
| - <body> |
| - |
| - <h2><em>Technical Note:</em> Introduction to Semantic Annotation |
| - Templates</h2> |
| - |
| - <i> Shawn Bowers, UC Davis </i> <br> |
| - <i> sbowers@ucdavis.edu</i> <br> |
| - <i> August, 2006 </i> <br> |
| - <i> Version 0.0.1 </i> |
| - |
| - <br><p> |
| - |
| - <h2>1. Introduction</h2> |
| - |
| - <p> <em><a href="#annotation">Semantic annotations</a></em> leverage |
| - <em><a href="#ontology">ontologies<a/></em> to describe the conceptual |
| - aspects of structured <em><a href="#resource">resources</a></em>, |
| - e.g., information sources such as data sets and services (workflows, |
| - actors, and web-services). Each resource is assumed to have a well |
| - defined schema that describes the structure of associated data (in the |
| - case of services, e.g., inputs and outputs). In addition to providing |
| - metadata for resources, ontology-based semantic annotations can enable |
| - improved discovery and integration of data. |
| - |
| - <p> Properly describing the semantics of a resource often requires |
| - "fine-grain" annotation, in which different parts of the resource are |
| - annotated with distinct semantic information, possibly including the |
| - assertion of semantic relations among the parts. The challenge is to |
| - provide an appropriate language for accessing, annotating, and |
| - relating portions of resources. This technical note describes basic |
| - aspects of <em><a href="#template">semantic annotation |
| - templates</a></em>, which are designed to support these fine-grain |
| - resource annotations. |
| - |
| - <p> We use an XML-based language for representing semantic |
| - annotations, in which annotations take the form: |
| - |
| - <pre> |
| - <annotation id="..."> |
| - <!-- header --> |
| - <resource label="R" uri="http://resources.org/resource"/> |
| - <ontology label="ont" uri="http://ontologies.org/ont"/> |
| + __Semantic annotations__ leverage __ontologies__ to describe the conceptual aspects of structured __resources__, e.g., information sources such as data sets and services (workflows, actors, and web-services). Each resource is assumed to have a well defined schema that describes the structure of associated data (in the case of services, e.g., inputs and outputs). In addition to providing metadata for resources, ontology-based semantic annotations can enable improved discovery and integration of data. |
| + |
| + Properly describing the semantics of a resource often requires "fine-grain" annotation, in which different parts of the resource are |
| + annotated with distinct semantic information, possibly including the assertion of semantic relations among the parts. The challenge is to provide an appropriate language for accessing, annotating, and relating portions of resources. This technical note describes basic aspects of __semantic annotation templates__, which are designed to support these fine-grain resource annotations. |
| + |
| + We use an XML-based language for representing semantic annotations, in which annotations take the form: |
| + |
| + {{{ |
| + <annotation id="..."> |
| + <!-- header --> |
| + <resource label="R" uri="http://resources.org/resource" type="..."/> |
| + <ontology label="ont" uri="http://ontologies.org/ont"/> |
| Line 84 was replaced by line 23 |
| - <!-- annotation assertions --> |
| + <!-- annotation assertions --> |
| Lines 87-88 were replaced by lines 26-69 |
| - </annotation> |
| - </pre> |
| + </annotation> |
| + }}} |
| + |
| + The resources being annotated and the ontologies used for annotation are assigned labels in the annotation header. For the case |
| + of ontologies, we typically refer to these labels as __prefixes__. Ontologies are assumed to be expressed using the Web Ontology Language (OWL). Annotation headers may also include information concerning who the author of the annotation is, when the annotation was created, who manages the annotation, and so on. The template information, which is the focus of this technical note, specifes fine-grain semantic annotations as mappings from resources to instances of the ontologies listed in the header. |
| + |
| + This technical note gives an introduction to semantic annotation templates. Section 2 provides a short overview of annotation templates, and Section 3 gives a more detailed explanation. A number of the terms introduced in this technical note are defined in the Glossary at the end of the document. Following the Glossary is a list of footnotes. Some |
| + familiarity with [RDF|http://www.w3.org/TR/REC-rdf-syntax], [OWL|http://www.w3.org/TR/owl-guide/], and basic [First-Order Logic|http://en.wikipedia.org/wiki/First-order_logic] is assumed. |
| + |
| + !!! 2 Overview of Annotation Templates |
| + |
| + An annotation template consists of one or more __instantiation patterns__ for constructing OWL individuals from resources. Instantiation patterns are typically based on (or driven by) resource structure and content. |
| + |
| + The simplest form of an instantiation pattern is: |
| + |
| + {{{ |
| + <individual type="ont:C"/> |
| + }}} |
| + |
| + This expression creates a single, unique instance of the {{C}} class in the ontology refered to by {{ont}} (assumed to be an ontology prefix defined in the annotation header). The OWL document that results from running (executing) the pattern is: |
| + |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about="">; |
| + <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| + </owl:Ontology> |
| + |
| + <ont:C rdf:ID="id1"/> |
| + |
| + </rdf:RDF> |
| + }}} |
| + |
| + In this example, the pattern maps the resources given in the annotation to a single OWL individual[1]. Note that the identifier for the instance above is generated automatically as a result of executing the pattern[2]. |
| + |
| + A more common use of templates is to relate data values in a resource to class instances in the ontology. Assume we are annotating a relational table labeled {{R}} with attributes {{x}}, {{y}}, and {{z}}[3]. The following pattern, which uses a {{foreach}} attribute, creates an instance of class {{C}} for every unique value of {{x}} in the dataset. |
| + |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + }}} |
| + |
| + 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}}. |
| Lines 90-179 were replaced by lines 71-75 |
| - <p> The resources being annotated and the ontologies used for |
| - annotation are assigned labels in the annotation header. For the case |
| - of ontologies, we typically refer to these labels as <em><a |
| - href="#prefix">prefixes</a></em>. Ontologies are assumed to be |
| - expressed using the Web Ontology Language (OWL). Annotation headers |
| - may also include information concerning who the author of the |
| - annotation is, when the annotation was created, who manages the |
| - annotation, and so on. The template information, which is the focus of |
| - this technical note, specifes fine-grain semantic annotations as |
| - mappings from resources to instances of the ontologies listed in the |
| - header. |
| - |
| - <p> This technical note gives an introduction to semantic annotation |
| - templates. <a href="#section2">Section 2</a> provides a short |
| - overview of annotation templates, and <a href="#section3">Section |
| - 3</a> gives a more detailed explanation. A number of the terms |
| - introduced in this technical note are defined in the <a |
| - href="#glossary">glossary</a> at the end of the document. Following |
| - the glossary is a list of <a href="#footnotes">footnotes</a>. Some |
| - familiarity with <a |
| - href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>, <a |
| - href="http://www.w3.org/TR/owl-guide/">OWL</a>, and basic <a |
| - href="http://en.wikipedia.org/wiki/First-order_logic">first-order |
| - logic</a> is assumed. |
| - |
| - |
| - <a name="section2"></a> |
| - <h2>2. Overview of Annotation Templates</h2> |
| - |
| - |
| - <p> An annotation template consists of one or more <em><a |
| - href="#pattern">instantiation patterns</a></em> for constructing OWL |
| - individuals from resources. Instantiation patterns are typically based |
| - on (or driven by) resource structure and content. |
| - |
| - <p> The simplest form of an instantiation pattern is: |
| - |
| - <pre> |
| - <individual type="ont:C"/> |
| - </pre> |
| - |
| - <p> This expression creates a single, unique instance of the |
| - <code>C</code> class in the ontology refered to by <code>ont</code> |
| - (assumed to be an ontology prefix defined in the annotation |
| - header). The OWL document that results from running (executing) the |
| - pattern is: |
| - |
| - <pre> |
| - <rdf:RDF xmlns="local-ns" ...> |
| - <owl:Ontology rdf:about=""> |
| - <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| - </owl:Ontology> |
| - |
| - <ont:C rdf:ID="id1"/> |
| - |
| - </rdf:RDF> |
| - </pre> |
| - |
| - <p> In this example, the pattern maps the resources given in the |
| - annotation to a single OWL individual <a href="#1"/>[1]</a>. Note that |
| - the identifier for the instance above is generated automatically as a |
| - result of executing the pattern <a href="#2"/>[2]</a>. |
| - |
| - |
| - <p> A more common use of templates is to relate data values in a |
| - resource to class instances in the ontology. Assume we are annotating |
| - a relational table labeled <code>R</code> with attributes |
| - <code>x</code>, <code>y</code>, and <code>z</code> <a |
| - href="#3"/>[3]</a>. The following pattern, which uses a |
| - <code>foreach</code> attribute, creates an instance of class |
| - <code>C</code> for every unique value of <code>x</code> in the |
| - dataset. |
| - |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"/> |
| - </pre> |
| - |
| - <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> |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about=""> |
| + <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| + </owl:Ontology> |
| Lines 181-182 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 184 was replaced by line 80 |
| - <ont:C rdf:ID="id-valn"/> |
| + <ont:C rdf:ID="id-valn"/> |
| Lines 186-187 were replaced by lines 82-83 |
| - </rdf:RDF> |
| - </pre> |
| + </rdf:RDF> |
| + }}} |
| Line 189 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 197-198 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 201 was replaced by line 97 |
| - <pre> |
| + {{{ |
| Line 203 was replaced by line 99 |
| - </pre> |
| + }}} |
| Lines 205-206 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 208-210 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 212 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 220 was replaced by line 116 |
| - <h3>3.1 Individuals</h3> |
| + !!3.1 Individuals |
| Lines 222-230 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 232 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 236 was replaced by line 132 |
| - <pre> |
| + {{{ |
| Line 238 was replaced by line 134 |
| - </pre> |
| + }}} |
| Lines 240-241 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 243 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 246-248 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 251-252 were replaced by lines 147-148 |
| - <pre> |
| - SELECT R1.x, R2.x |
| + {{{ |
| + SELECT DISTINCT R1.x, R2.x |
| Line 254 was replaced by line 150 |
| - </pre> |
| + }}} |
| Lines 256-257 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 260 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 262-263 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 265-267 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 269 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 273 was replaced by line 169 |
| - <pre> |
| + {{{ |
| Line 275 was replaced by line 171 |
| - </pre> |
| + }}} |
| Lines 277-282 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 284 was replaced by line 180 |
| - <p> As with <code>foreach</code> expressions, <code>if</code> |
| + As with {{foreach}} expressions, {{if}} |
| Lines 287-288 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 290-291 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 293-294 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}} |
| At line 297 added 1 line. |
| + !!3.2 Object Properties |
| Lines 299-301 were replaced by line 196 |
| - <h3>3.2 Object Properties</h3> |
| - |
| - <p> A <code>property</code> expression assigns OWL properties to |
| + A {{property}} expression assigns OWL properties to |
| Lines 303-304 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 306-310 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 312 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 315-316 were replaced by line 210 |
| - <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]. |
| Lines 318-328 were replaced by lines 212-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> |
| + {{{ |
| + <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> |
| Lines 330-334 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 336-337 were replaced by lines 230-231 |
| - </rdf:RDF> |
| - </pre> |
| + </rdf:RDF> |
| + }}} |
| Line 339 was replaced by line 233 |
| - <p> The first-order rule for this pattern is: |
| + The first-order rule for this pattern is: |
| Line 341 was replaced by line 235 |
| - <pre> |
| + {{{ |
| Line 345 was replaced by line 239 |
| - </pre> |
| + }}} |
| Line 347 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 350-351 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 353 was replaced by line 247 |
| - <p> <b>Nested Properties.</b> Property expressions corresponding to |
| + __Nested Properties.__ Property expressions corresponding to |
| Line 356 was replaced by line 250 |
| - <code>D</code> instances above with <code>Q</code> properties: |
| + {{D}} instances above with {{Q}} properties: |
| Lines 358-364 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 366 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 371 was replaced by line 265 |
| - <pre> |
| + {{{ |
| Line 377 was replaced by line 271 |
| - </pre> |
| + }}} |
| Line 379 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 381 was replaced by line 275 |
| - <code>P1</code> and <code>P2</code>. |
| + {{P1}} and {{P2}}. |
| Lines 383-388 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 391 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 394 was replaced by line 288 |
| - <pre> |
| + {{{ |
| Line 400 was replaced by line 294 |
| - </pre> |
| + }}} |
| Lines 403-405 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 407-409 were replaced by lines 301-303 |
| - <pre> |
| - <individual type="..." foreach="..." if="..." ...> |
| - <property type="..." ...> |
| + {{{ |
| + <individual type="..." foreach="..." if="..." ...> |
| + <property type="..." ...> |
| Line 411 was replaced by line 305 |
| - </property> |
| + </property> |
| Lines 413-414 were replaced by lines 307-308 |
| - </individual> |
| - </pre> |
| + </individual> |
| + }}} |
| Lines 416-417 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 420 was replaced by line 314 |
| - <h3>3.3 Datatype Properties</h3> |
| + !!3.3 Datatype Properties |
| Line 422 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 428-430 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 432-433 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 435-437 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 440 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 443-444 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 446-450 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 452 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 456 was replaced by line 350 |
| - <pre> |
| + {{{ |
| Line 459 was replaced by line 353 |
| - </pre> |
| + }}} |
| Line 461 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 463-464 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 466-470 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 472 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 478 was replaced by line 372 |
| - <pre> |
| + {{{ |
| Line 481 was replaced by line 375 |
| - </pre> |
| + }}} |
| Lines 483-484 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 489-497 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 499 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 501 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 503 was replaced by line 397 |
| - <pre> |
| + {{{ |
| Line 506 was replaced by line 400 |
| - </pre> |
| + }}} |
| Lines 508-514 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 517-525 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 527 was replaced by line 421 |
| - <pre> |
| + {{{ |
| Lines 530-531 were replaced by line 424 |
| - </pre> |
| - |
| + }}} |
| Line 533 was replaced by line 426 |
| - <p> In an instantiation pattern, <code>value</code> expressions must |
| + In an instantiation pattern, {{value}} expressions must |
| Line 535 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 538-541 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 543 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 546-550 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 552 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 554 was replaced by line 447 |
| - <pre> |
| + {{{ |
| Line 558 was replaced by line 451 |
| - </pre> |
| + }}} |
| Line 560 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 562 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 567 was replaced by line 460 |
| - <p> Like with conditions on <code>individual</code> statements, no |
| + Like with conditions on {{individual}} statements, no |
| Line 569 was replaced by line 462 |
| - <code>property</code> statement conditions. Variables used in |
| + {{property}} statement conditions. Variables used in |
| Lines 571-572 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 574 was replaced by line 467 |
| - to the <code>ANY</code> keyword in SQL). |
| + to the {{ANY}} keyword in SQL). |
| Line 577 was replaced by line 470 |
| - <h3>3.3 Complex Instantiation Patterns</h3> |
| + !!3.3 Complex Instantiation Patterns |
| Lines 579-581 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 583-584 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 588 was replaced by line 481 |
| - <p> <b>Pattern Labels.</b> Each individual instantiation pattern can |
| + __Pattern Labels.__ Each individual instantiation pattern can |
| Lines 592-594 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 596 was replaced by line 489 |
| - <p> The first-order rule for this pattern is: |
| + The first-order rule for this pattern is: |
| Line 598 was replaced by line 491 |
| - <pre> |
| + {{{ |
| Line 600 was replaced by line 493 |
| - </pre> |
| + }}} |
| Line 602 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 607-609 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 614-618 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 620 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 625 was replaced by line 517 |
| - <pre> |
| + {{{ |
| Line 628 was replaced by line 520 |
| - </pre> |
| + }}} |
| Line 630 was replaced by line 522 |
| - <p> As with resource variables, pattern references are interpreted |
| + As with resource variables, pattern references are interpreted |
| Lines 632-635 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 637 was replaced by line 529 |
| - <code>x</code> value of the iteration context. |
| + {{x}} value of the iteration context. |
| Line 639 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 643-653 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 655-656 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 659-662 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 664-666 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 668 was replaced by line 560 |
| - </pre> |
| + }}} |
| Line 670 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 672 was replaced by line 564 |
| - <pre> |
| + {{{ |
| Line 678 was replaced by line 570 |
| - </pre> |
| + }}} |
| Line 680 was replaced by line 572 |
| - <p> Thus, although property values containing pattern references are |
| + Thus, although property values containing pattern references are |
| Lines 682-683 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 686 was replaced by line 578 |
| - <pre> |
| + {{{ |
| Line 691 was replaced by line 583 |
| - </pre> |
| + }}} |
| Line 693 was replaced by line 585 |
| - <p> The triples created from pattern <code>o1</code> are: |
| + The triples created from pattern {{o1}} are: |
| Line 695 was replaced by line 587 |
| - <pre> |
| + {{{ |
| Line 698 was replaced by line 590 |
| - </pre> |
| + }}} |
| Line 700 was replaced by line 592 |
| - <p> The triples created from pattern <code>o4</code> are: |
| + The triples created from pattern {{o4}} are: |
| Line 702 was replaced by line 594 |
| - <pre> |
| + {{{ |
| Line 706 was replaced by line 598 |
| - </pre> |
| + }}} |
| Line 708 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 710 was replaced by line 602 |
| - <pre> |
| + {{{ |
| Line 715 was replaced by line 607 |
| - </pre> |
| + }}} |
| Lines 717-736 were replaced by lines 609-628 |
| - <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}}: |
| + |
| + {{{ |
| + <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> |
| + }}} |
| Line 738 was replaced by line 630 |
| - <p> The corresponding first-order rule for this pattern is: |
| + The corresponding first-order rule for this pattern is: |
| Line 740 was replaced by line 632 |
| - <pre> |
| + {{{ |
| Line 745 was replaced by line 637 |
| - </pre> |
| + }}} |
| Lines 747-750 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 753-754 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 756 was replaced by line 648 |
| - individuals, for cases like <code>o6</code> above, should be |
| + individuals, for cases like {{o6}} above, should be |
| Lines 759-765 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 767 was replaced by line 659 |
| - <p> results in the first-order rule: |
| + results in the first-order rule: |
| Line 769 was replaced by line 661 |
| - <pre> |
| + {{{ |
| Line 775 was replaced by line 667 |
| - </pre> |
| + }}} |
| Lines 777-778 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 781-782 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 784 added 1 line. |
| + !!!Glossary |
| Line 786 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 788-791 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 793-795 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 797-799 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 801-885 were replaced by lines 687-714 |
| - <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. |
| - |
| - |
| - |
| - <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. |
| - |
| - <p> <a name="7">[7]</a> Implicitly, this pattern is equivalent to the pattern: |
| - |
| - <pre> |
| - <individual type="ont:C" foreach="R.x"> |
| - <property type="ont:P" value="$R.y" foreach="R.y"/> |
| - </individual> |
| - </pre> |
| - |
| - <p> 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. |
| - |
| - <p> <a name="8">[8]</a> Because the variable used within a |
| - <code>value</code> attribute is implicitly carried over to the |
| - <code>property</code> statement's <code>foreach</code> expression |
| - (see <a href="#7">[7]</a>), these resource variables are considered |
| - to be part of the <code>property</code> statement's iteration |
| - context. |
| + ;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. |
| + |
| + ;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. |
| + |
| + |
| + !!!Footnotes |
| + |
| + [#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. |
| + |
| + [#7] Implicitly, this pattern is equivalent to the pattern: |
| Lines 887-888 were replaced by lines 716-720 |
| - <p> <a name="9">[9]</a> Pattern references can be cyclic, i.e., a |
| - property within a pattern p can contain a property that refers to p. |
| + {{{ |
| + <individual type="ont:C" foreach="R.x"> |
| + <property type="ont:P" value="$R.y" foreach="R.y"> |
| + </individual> |
| + }}} |
| At line 889 added 1 line. |
| + 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. |
| Lines 891-892 were replaced by line 724 |
| - </body> |
| - </html> |
| + [#8] Because the variable used within a {{value}} attribute is implicitly carried over to the {{property}} statement's {{foreach}} expression (see [7]), these resource variables are considered to be part of the {{property}} statement's iteration context. |
| At line 893 added 1 line. |
| + [#9] Pattern references can be cyclic, i.e., a property within a pattern p can contain a property that refers to p. |
