| Line 8 was replaced by line 8 |
| - !!! ToDo |
| + !!! Introduction |
| Lines 10-13 were replaced by line 10 |
| - # allow an entire ontology to be "labeled" without having to name any of the items (where labels are local names) |
| - # describe a MoML embedded and EML embedded version (and mapping to the "canonical" version) |
| - # extend the description of types / move to more XML-style syntax |
| - # add "superimposed" data types |
| + __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. |
| At line 14 added 2 lines. |
| + 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. |
| At line 15 added 1 line. |
| + We use an XML-based language for representing semantic annotations, in which annotations take the form: |
| Line 17 was replaced by lines 17-27 |
| - !!! Introduction |
| + {{{ |
| + <annotation id="..."> |
| + <!-- header --> |
| + <resource label="R" uri="http://resources.org/resource" type="..."/> |
| + <ontology label="ont" uri="http://ontologies.org/ont"/> |
| + ... |
| + <!-- annotation assertions --> |
| + ontology instantiation templates |
| + ... |
| + </annotation> |
| + }}} |
| Line 19 was replaced by lines 29-30 |
| - This document describes an interchange syntax that can be used to express semantic types. We describe __three__ versions of the format: a canonical version, a version for embedding within MoML files, and a version for embedding within EML files. For the case of embeddings, we show how the embedding can be converted to the canonical version. |
| + 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. |
| At line 20 added 2 lines. |
| + 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. |
| Line 22 was replaced by line 35 |
| - !!! KR/SMS Semantic Types |
| + !!! 2 Overview of Annotation Templates |
| Line 24 was replaced by line 37 |
| - A __semantic type__ classifies and constrains the semantic, as opposed to structural interpretation of a __resource__. Datasets, workflows, actors (and other workflow components), and actor input and output ports are examples of resources that may have semantic types within SEEK. |
| + 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. |
| Line 26 was replaced by line 39 |
| - A semantic type is an ontology expression that is "linked" to a resource using a __semantic annotation__. Generally, a semantically typed resource will have an annotation to a single concept. Plus, additional resource "sub-structure" (e.g., particular attributes of a dataset) annotations may exist that further link portions of the resource to parts of the resource's more general concept (examples are given below). |
| + The simplest form of an instantiation pattern is: |
| Line 28 was replaced by lines 41-43 |
| - The following XML representation shows the general form of the canonical semantic-type interchange syntx (see below [3] for the XML Schema). |
| + {{{ |
| + <individual type="ont:C"/> |
| + }}} |
| At line 29 added 1 line. |
| + 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: |
| Line 32 was replaced by lines 48-51 |
| - <sms:semtype id="id3" xmlns:sms="http://seek.ecoinformatics.org/sms"> |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about="">; |
| + <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| + </owl:Ontology> |
| Lines 34-36 were replaced by lines 53-64 |
| - <sms:resource name="R" id="id1"/> |
| - |
| - ... |
| + <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"> |
| + }}} |
| Line 38 was replaced by lines 66-69 |
| - <sms:ontology name="C" id="id2"/> |
| + 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}}. |
| Line 40 was replaced by lines 71-80 |
| - ... |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about=""> |
| + <owl:imports rdf:resource="http://ontologies.org/ont"/> |
| + </owl:Ontology> |
| + |
| + <ont:C rdf:ID="id-val1"/> |
| + <ont:C rdf:ID="id-val2"/> |
| + ... |
| + <ont:C rdf:ID="id-valn"/> |
| Line 42 was replaced by lines 82-83 |
| - <sms:annotation object="R" meaning="C"/> |
| + </rdf:RDF> |
| + }}} |
| Line 44 was replaced by lines 85-91 |
| - ... |
| + Note that this document has a different namespace than the |
| + corresponding ontology(ies), but imports the ontologies referenced in |
| + the annotation header. Thus, the individuals listed in this document |
| + are treated as distinct from the ontology itself, but OWL-based tools |
| + (such as Protege or a description-logic reasoner) can display and |
| + reason over the individuals as though they were part of the original |
| + ontology. |
| At line 45 added 3 lines. |
| + We use rules expressed in first-order logic to formalize how |
| + instantiation patterns should be interpreted[5]. For |
| + example, the first-order logic rule for the above pattern is: |
| Line 47 was replaced by lines 97-98 |
| - </sms:semtype> |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p1(x) -> triple(u, rdfs:type, ont:C). |
| Line 50 was replaced by lines 101-106 |
| - The element {{semtype}} starts a semantic type definition. A semantic type can have an optional unique identifier, which is given in the {{id}} attribute. Unique identifiers are (preferably) expressed as an LSID, allowing the semantic type to be managed as an LSID data object. Alternatively, if a semantic type is embedded within a document, the semantic-type id can also be expressed as a fragment identifier (for example, when used within EML). |
| + Here, the predicate {{triple}} asserts an RDF triple |
| + (with subject, property, value), and {{id_p1}} is a (Skolem) |
| + function mapping values into identifiers. The function |
| + {{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 52 was replaced by lines 108-110 |
| - As shown above, a semantic type consists of a set of {{resource}} elements, {{ontology}} elements, and {{annotation}} elements. Every semantic type (expressed in the canonical form) is required to have at least one {{resource}}, one {{ontology}}, and one {{annotation}} element. We consider each of these elements, in turn, below. |
| + There are a number of additional features of instantiation |
| + patterns for describing fine-grain semantic annotations. These |
| + features are discussed in more detail in the next section. |
| At line 54 added 2 lines. |
| + <a name="section3"></a> |
| + <h2>3. Template Instantiation Patterns</h2> |
| Line 56 was replaced by lines 116-126 |
| - !!! Semantic-Type Resource References |
| + !!3.1 Individuals |
| + |
| + __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 58 was replaced by lines 128-130 |
| - Items that are semantically typed are called ''resources''. A {{resource}} element identifies a resource using the resource's unique identifier. A {{resource}} element also assigns a name to the resource, which is used as a surrogate for the referencing the resource in semantic annotations. |
| + This pattern can be read as "For each unique x, y (tuple) value |
| + pair of R, create an instance of C." The corresponding first-order |
| + rule for this pattern is: |
| At line 59 added 3 lines. |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p2(x, y) -> triple(u, rdfs:type, ont:C). |
| + }}} |
| At line 60 added 2 lines. |
| + In this example, we say that each {{x,y}} value |
| + constitutes a particular {{C}}. |
| At line 61 added 7 lines. |
| + Resource labels (such as {{R}}) in annotations are used |
| + in a similar way as tuple variables (i.e., "range variables") in |
| + SQL. In particular, a different label can be applied to the same |
| + 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 |
| + equivalent to the SQL cross-product projection: |
| Line 63 was replaced by lines 147-150 |
| - Resource tags within a semantic-type description provide a mechanism to identify and name those resources that are semantic |
| + {{{ |
| + SELECT DISTINCT R1.x, R2.x |
| + FROM Employee R1, Employee R2 |
| + }}} |
| Line 65 was replaced by lines 152-154 |
| - Labels within a semantic-type description provide a mechanism to identify and name resources and ontology terms. Label names are used within annotations to refer to resources and ontology terms. In a {{Label}} element, the {{name}} attribute is assigned to the resource identified by the {{resource}} attribute. Each {{Label}} element is required to have exactly one {{name}} and {{resource}} attribute. A {{SemanticType}} element must contain at least two {{Label}} elements: one identifying the resource to be annotated and the other identifying an ontology concept. Further, no two {{Label}} elements within a semantic type may have the same {{name}} attribute. |
| + In a similar way, one can view {{foreach}} expressions as |
| + group constructors, similar to the {{GROUP BY}} clause in |
| + SQL. |
| Line 67 was replaced by lines 156-159 |
| - Two label definitions are shown below. The first label associates a data set to the name {{crops}} and the second label associates an ontology concept to the name {{Biomass}}. |
| + __Conditions.__ Conditions can be added to restrict the |
| + application of a pattern. For example, the following pattern restricts |
| + the creation of {{C}} instances based on positive values of |
| + {{x}}. |
| Line 70 was replaced by lines 162-167 |
| - <sms:Label name="crops" resource="KBS019-003"/> |
| + <individual type="ont:C" foreach="DISTINCT R.x, R.y" if="R.x>0"/> |
| + }}} |
| + |
| + This pattern can be read as "For each unique x, y (tuple) value |
| + pair of R in which x is greater than 0, create an instance of C." The |
| + corresponding first-order rule for this pattern is: |
| Line 72 was replaced by lines 169-170 |
| - <sms:Label name="Biomass" resource="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#Biomass"/> |
| + {{{ |
| + (Axyz) R(x, y, z), x>0, u=id_p3(x, y) -> triple(u, rdfs:type, ont:C). |
| At line 74 added 19 lines. |
| + 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 |
| + {{=}}. |
| + |
| + As with {{foreach}} expressions, {{if}} |
| + expressions can be given as a conjunction of comma-separated |
| + conditions. Further, condition expressions may contain resource |
| + variables that are outside the condition's __<a |
| + href="#context">iteration context</a>__, i.e., the set of variables |
| + (or particular bindings of the variables) used in the condition's |
| + corresponding {{foreach}} expression. Note that any given |
| + binding of {{foreach}} variables may have many associated |
| + values for an "out-of-context" variable. For these cases, the |
| + {{if}} expression is satisfied whenever the condition is true |
| + for any one of these values (i.e., similar to the {{ANY}} |
| + keyword in SQL). |
| At line 76 added 1 line. |
| + !!3.2 Object Properties |
| Line 78 was replaced by lines 196-205 |
| - !!! Semantic Annotations |
| + A {{property}} expression assigns OWL properties to |
| + corresponding individuals within an instantiation pattern. For |
| + example, the following pattern creates instances of {{C}} |
| + containing properties {{P}}: |
| + |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" valuetype="ont:D"/> |
| + </individual> |
| + }}} |
| Line 80 was replaced by lines 207-210 |
| - An annotation asserts that an object of a resource has a particular meaning according to an ontology. The {{object}} and {{meaning}} attributes of an {{Annotation}} element relate the object and ontology expressions, respectively. We provide a uniform __annotation language__ for identifying resource objects and for creating corresponding ontology instances. |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has a property P to an instance of D." Executing |
| + this pattern results in the following document, assuming there are |
| + __n__ unique values of {{x}} in {{R}}[6]. |
| Line 82 was replaced by lines 212-216 |
| - Some resources, such as data sets and actors with input/output ports, can have complex data structures. For example, a data set typically is structured according to a schema, which specifies among other things a relation name (that is, the name of the table) and names for each attribute of the relation and their data types. Actor ports can also have complex structure, including arbitrarily nested relations. The annotation language facilitates the selection of the various (sub-) objects of structured resources. |
| + {{{ |
| + <rdf:RDF xmlns="local-ns" ...> |
| + <owl:Ontology rdf:about=""> |
| + <owl:imports rdf:resource="htt://ontologies.org/ont"/> |
| + </owl:Ontology> |
| Line 84 was replaced by lines 218-228 |
| - The annotation language has two forms: an abbreviated syntax, and a more complex, full syntax. |
| + <ont:C rdf:ID="id-val1"> |
| + <ont:P> |
| + <ont:D/> |
| + </ont:P> |
| + </ont:C> |
| + ... |
| + <ont:C rdf:ID="id-valn"> |
| + <ont:P> |
| + <ont:D/> |
| + </ont:P> |
| + </ont:C> |
| Line 86 was replaced by lines 230-231 |
| - !! The Abbreviated Annotation-Language Syntax |
| + </rdf:RDF> |
| + }}} |
| Line 88 was replaced by line 233 |
| - For expressing annotation objects, the abbreviated syntax permits the following atoms given a resource label {{T}} and attributes {{A1}} to {{An}}. |
| + The first-order rule for this pattern is: |
| Line 91 was replaced by lines 236-245 |
| - T |
| + (Axyz) R(x, y, z), u=id_p4(x) -> (Ev) triple(u, rdf:type, ont:C'), |
| + triple(u, ont:P, v), |
| + triple(v, rdf:type, ont:D'). |
| + }}} |
| + |
| + Note that in this rule, {{v}} is existentially |
| + quantified, which we assume is interpreted as an RDF anonymous |
| + identifier. Alternatively, we could have introduced a new Skolem |
| + function over {{x}} values (similar to {{id_p4}}) |
| + for generating the appropriate {{D}} identifiers. |
| Line 93 was replaced by lines 247-250 |
| - T.A1 |
| + __Nested Properties.__ Property expressions corresponding to |
| + OWL object properties can be arbitrarily nested within instantiation |
| + patterns. For example, the following pattern further elaborates the |
| + {{D}} instances above with {{Q}} properties: |
| Line 95 was replaced by lines 252-257 |
| - T.A1.A2. ... .An |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" valuetype="ont:D"> |
| + <property type="ont:Q" valuetype="ont:E"/> |
| + </property> |
| + </individual> |
| At line 97 added 4 lines. |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has a property P to an instance of D such that |
| + the D instance has a property Q to an instance of E." The first-order |
| + rule for this pattern is: |
| Line 99 was replaced by lines 265-271 |
| - The first atom {{T}} selects corresponding objects of the resource. For example, if the resource is a data set, {{T}} selects the tuple objects of the resource. If the resource is an actor, {{T}} selects instances of the actor. The second atom {{T.A1}} selects {{A1}} objects contained within {{T}} objects. For {{T}} representing a data set, {{T.A1}} selects the values of attribute {{A1}} for tuples of {{T}}. The last atom selects nested attributes for complex structures, for example, used by actor input/output ports. For instance, if {{T}} represents an input port to some actor[1], {{T.A1.A2}} selects the {{A2}} objects nested within {{A1}} objects contained in {{T}} objects. |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p5(x) -> (Evw) triple(u, rdf:type, ont:C), |
| + triple(u, ont:P, v), |
| + triple(v, rdf:type, ont:D) |
| + triple(v, ont:Q, w), |
| + triple(w, rdf:type, ont:E). |
| + }}} |
| Line 101 was replaced by lines 273-275 |
| - Atoms can be combined to form expressions. In particular, an expression is either: (1) a single atom or (2) a comma-separated list of atoms of the form {{T.A1}} or {{T.A1.A2. ... An}}. |
| + __Multiple Properties.__ Individuals can be assigned more than |
| + one property. The following pattern assigns two properties |
| + {{P1}} and {{P2}}. |
| Line 103 was replaced by lines 277-282 |
| - In the abbreviated syntax, ontology expressions only consist of a single concept label {{C}}. |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P1" valuetype="ont:D1"/> |
| + <property type="ont:P2" valuetype="ont:D2"/> |
| + </individual> |
| + }}} |
| Removed line 105 |
| - To illustrate, consider the following semantic-type description for the {{crops}} data set. |
| At line 106 added 3 lines. |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has two properties, P1 to an instance of D1, and |
| + P2 to an instance of D2." The first-order rule for this pattern is: |
| Lines 108-109 were replaced by lines 289-294 |
| - <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" |
| - xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#"> |
| + (Axyz) R(x, y, z), u=id_p6(x) -> (Evw) triple(u, rdf:type, ont:C), |
| + triple(u, ont:P1, v), |
| + triple(v, rdf:type, ont:D1) |
| + triple(u, ont:P2, w), |
| + triple(w, rdf:type, ont:D2). |
| + }}} |
| Removed lines 111-116 |
| - <sms:Label name="crops" resource="KBS019-003"/> |
| - <sms:Label name="Measurement" resource="ont:Measurement"/> |
| - <sms:Label name="Biomass" resource="ont:Biomass"/> |
| - <sms:Label name="Species" resource="ont:Species"/> |
| - <sms:Label name="Year" resource="ont:Year"/> |
| - <sms:Label name="Location" resource="ont:Location"/> |
| Lines 118-122 were replaced by lines 297-299 |
| - <sms:Annotation object="crops" meaning="Measurement"/> |
| - <sms:Annotation object="crops.bm" meaning="Biomass"/> |
| - <sms:Annotation object="crops.spp" meaning="Species"/> |
| - <sms:Annotation object="crops.yr" meaning="Year"/> |
| - <sms:Annotation object="crops.station" meaning="Location"/> |
| + The general form of a pattern consists of an |
| + {{individual}} expression, followed by any number of |
| + (possibly nested) {{property}} expressions: |
| Line 124 was replaced by lines 301-307 |
| - </sms:SemanticType> |
| + {{{ |
| + <individual type="..." foreach="..." if="..." ...> |
| + <property type="..." ...> |
| + ... nested property expressions ... |
| + </property> |
| + ... additional property expressions ... |
| + </individual> |
| At line 126 added 3 lines. |
| + The additional attributes of {{individual}} and |
| + {{property}} statements are described further below (as well |
| + as in the footnotes). |
| Lines 128-129 were replaced by line 314 |
| - In this simple example, we (1) associate the label {{crops}} to the data-set resource identifed as {{KBS019-003}}, (2) associate the |
| - remaining labels to corresponding ontology concepts (simplifying their identifiers using XML namespaces), (3) state with the first annotation that each {{crops}} tuple is a {{Measurement}} instance, (4) state with the second annotation that each {{bm}} attribute value is a {{Biomass}} instance, (5) state with the third annotation that each {{spp}} attribute value is a {{Species}} instance, and so on. |
| + !!3.3 Datatype Properties |
| At line 130 added 5 lines. |
| + The examples so far assume the use of OWL object properties, whose |
| + ranges (i.e., what the properties "point" to) are individuals. Here we |
| + describe support for annotating to datatype properties, in which |
| + ranges are assumed to be atomic data values (e.g., strings, integers, |
| + or doubles). |
| At line 131 added 11 lines. |
| + Datatype {{property}} statements use the attribute |
| + {{value}} instead of {{valuetype}}. In general, a |
| + {{value}} attribute is used to assign a specific data value |
| + or individual identifier to a property, whereas a |
| + {{valuetype}} attribute is used to give the type of the |
| + individual linked to the property. Thus, {{valuetype}} |
| + attributes are used exclusively for object properties, and |
| + {{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 |
| + property) cannot be further nested. |
| At line 132 added 5 lines. |
| + __Constants.__ One use of a datatype property annotation is for |
| + assigning constant values to each corresponding individual generated |
| + by a pattern. For example, the following pattern assigns a |
| + property {{P}} with the value {{5}} to each |
| + generated {{C}} instance. |
| Line 134 was replaced by lines 340-344 |
| - !! Semantic-Type Ontology Definitions |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="5"/> |
| + </individual> |
| + }}} |
| Line 136 was replaced by lines 346-348 |
| - For convenience, we permit ontology concept definitions to be directly included within a semantic type using the {{OntologyDefinitions}} element. The purpose of this features is to allow specialized concept definitions to more accurately annotate objects, without having to go through the process of creating a new ontology, or editing an existing one. These concept definitions are expressed using OWL[2]. |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has a property P with the value 5." The |
| + corresponding first-order rule for this pattern is: |
| Line 138 was replaced by lines 350-353 |
| - To illustrate, part of the previous semantic type is shown below with an embedded concept. (Note that to simplify the definition below we take liberty with the use of namespaces in OWL). This embedded concept definition states that {{MyMeasurement}} is both a {{Measurement}} and a {{SubjectiveObservation}}. |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p7(x) -> triple(u, rdf:type, ont:C), |
| + triple(u, ont:P, 5). |
| + }}} |
| At line 139 added 4 lines. |
| + __Resource Values.__ Another common use of datatype property |
| + annotations is for capturing associated resource values. For example, |
| + the following pattern assigns each instance a property {{P}} |
| + whose value is taken from the resource variable {{x}}. |
| Lines 142-146 were replaced by lines 361-364 |
| - <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" |
| - xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#" |
| - xmlns:owl="http://www.w3.org/2002/07/owl#" |
| - xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" |
| - xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="$R.x"/> |
| + </individual> |
| + }}} |
| Line 148 was replaced by lines 366-370 |
| - <sms:Label name="crops" resource="KBS019-003"/> |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has a property P with the value x." Note that |
| + the symbol '$' is used to distinguish references to resource values |
| + from constants. The corresponding first-order rule for this pattern |
| + is: |
| Line 150 was replaced by lines 372-375 |
| - <sms:Label name="Measurement" resource="MyMeasurement"/> |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p8(x) -> triple(u, rdf:type, ont:C), |
| + triple(u, ont:P, x). |
| + }}} |
| Line 152 was replaced by lines 377-391 |
| - <sms:Annotation object="crops" meaning="MyMeasurement"/> |
| + Resource variables can be used outside of the current iteration |
| + context (i.e., the enclosing {{foreach}} expression). In this |
| + case, the current iteration context is used to determine the |
| + particular resource values that are accessed. Note that it is possible |
| + for multiple properties to be created when the resource variables are |
| + outside of the iteration context. For example, the following pattern |
| + 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 154 was replaced by lines 393-395 |
| - <sms:OntologyDefinitions> |
| + This pattern can be read as "For each unique x value of R, create |
| + an instance of C that has a property P with value y, for each unique y |
| + value of x"[7]. The corresponding first-order rule for this pattern is: |
| Lines 156-163 were replaced by lines 397-400 |
| - <owl:Class rdf:ID="MyMeasurement"> |
| - <owl:equivalentClass> |
| - <owl:intersectionOf rdf:parseType="Collection"> |
| - <owl:Class rdf:resource="ont:Measurement"/> |
| - <owl:Class rdf:resource="ont:SubjectiveObservation"/> |
| - </owl:intersectionOf> |
| - </owl:equivalentClass> |
| - </sms:Resource> |
| + {{{ |
| + (Axyz) R(x, y, z), u=id_p9(x) -> triple(u, rdf:type, ont:C), |
| + triple(u, ont:P, y). |
| + }}} |
| Line 165 was replaced by lines 402-409 |
| - </sms:OntologyDefinitions> |
| + 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 |
| + following pattern: |
| Line 167 was replaced by lines 411-414 |
| - </sms:SemanticType> |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R1.x"> |
| + <property type="ont:P" value="$R2.y"/> |
| + </individual> |
| At line 169 added 8 lines. |
| + corresponds to the following first-order rule, assuming |
| + {{R1}} and {{R2}} both represent relation |
| + {{R}}: |
| + |
| + {{{ |
| + (Axvzwyt) R(x, v, z), R(w, y, t), u=id_p10(x) -> triple(u, rdf:type, ont:C), |
| + triple(u, ont:P, y). |
| + }}} |
| At line 170 added 4 lines. |
| + In an instantiation pattern, {{value}} expressions must |
| + evaluate to a single value. Although not considered here, it may be |
| + useful to define functions for use in {{value}} expressions, |
| + such as concatenation, addition, and so on. |
| Line 172 was replaced by lines 431-437 |
| - !! The Full Annotation-Language Syntax |
| + __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 |
| + individual. For example, the following pattern only adds |
| + {{P}} to the individual if {{x}} is a positive |
| + value. |
| Line 174 was replaced by lines 439-443 |
| - The full annotation-language syntax provides more access to various parts of a complex structure and the ability to assign those parts to more complex ontology instances. To support a wide variety of structural models -- the primary ones including relational, XML, and the Ptolemy type system -- we consider a generic model consisting of nested-relational-style constructs. In addition, we permit multi-valued attributes in which an attribute can have an associated collection of values. |
| + {{{ |
| + <individual type="ont:C" foreach="DISTINCT R.x"> |
| + <property type="ont:P" value="$R.x" if="R.x>0"/> |
| + </individual> |
| + }}} |
| Line 176 was replaced by line 445 |
| - The abbreviated annotation-language syntax is shorthand for a subset of the full syntax (we give more details of the relationship below). In the full syntax, resource expressions consist of lists of atoms (separated by commas) taking one of the following forms. |
| + This patterns must be represented using two first-order rules: |
| Line 179 was replaced by line 448 |
| - x:T |
| + (Axyz) R(x, y, z), u=id_p11(x) -> triple(u, rdf:type, ont:C). |
| Line 181 was replaced by line 450 |
| - x[A1=y] |
| + (Axyz) R(x, y, z), x>0, u=id_p11(x) -> triple(u, ont:P, x). |
| Line 184 was replaced by lines 453-458 |
| - Here, symbols {{x}} and {{y}} denote either constants, variables, or skolem terms. Variables are prefixed with a '$' sign. Constants that contain spaces must be delimited using single quotes. A skolem term takes the form {{f(z1, ..., zn)}} for constants and/or variables {{z1}} to {{zn}} and {{n > 0}}. |
| + Thus, the condition on the property does not affect whether the |
| + individual is created, only whether the individual has a |
| + {{P}} property. Using property conditions, it is possible to |
| + define simple mappings from resource values to standard property |
| + values, e.g., for converting coded values in a dataset to their |
| + corresponding "full" names. |
| Line 186 was replaced by lines 460-467 |
| - For {{x}} and {{y}} constants, the atom {{x:T}} is true if {{x}} is a {{T}} object, and the atom {{x[[A1=y]}} is true if {{x}} is an object that has {{y}} as one of its {{A1}} attribute values. |
| + Like with conditions on {{individual}} statements, no |
| + restrictions are placed on the variables that can be used in |
| + {{property}} statement conditions. Variables used in |
| + property conditions that are outside the iteration context of the |
| + property, with the exception of variables within {{value}} |
| + expressions[8], require only one associated value to |
| + satisfy the condition for the property to be applied (again, similar |
| + to the {{ANY}} keyword in SQL). |
| Removed lines 188-189 |
| - Complex expressions are constructed as follows: each atom is an expression; expressions {{x:T}} and {{x[[A1=y]}} can be composed to |
| - form the expression {{x:T[[A1=y]}}; expressions {{x[[A1=y]}} and {{x[[A2=z]}} can be composed to form the expression {{x[[A1=y, A2=z]}}; expressions {{y:T1[[A2=z]}} and {{x:T[[A1=y]}} can be composed to form the expression {{x:T[[A1=y:T1[[A2=z]]}}; and so on. |
| Line 191 was replaced by line 470 |
| - This same syntax is used to describe ontology expressions, where {{T}} can be replaced with a concept label {{C}} and {{A1}} represents a property label. For {{x}} and {{y}} constants, the atom {{x:C}} is true if {{x}} is an instance of concept {{C}}, and the atom {{x[[A1=y]}} is true if {{x}} has {{y}} as one of its {{A1}} property values. |
| + !!3.3 Complex Instantiation Patterns |
| Line 193 was replaced by lines 472-479 |
| - The meaning of an annotation can be interpreted as follows. Assume we have an annotation {{A}} such that {{R}} is the expression selecting resource objects (the expression in the {{object}} attribute) and {{O}} is the expression creating ontology instances (the expression in the {{meaning}} attribute). The annotation is a constraint that says whenever {{R}} is true, {{O}} is true. Let {{Rvar}} be the set of variables in {{R}} and {{Ovar}} be the set of variables in {{O}} that are not in {{R}}. The annotation {{A}} asserts {{(forall Rvar) R -> (exists Ovar) O}}. That is, for each variable assignment making {{R}} true there are variable assignments for {{Ovar}} that make {{O}} true. In this way, an annotation can also be viewed as a mapping from {{R}} to {{O}}. |
| + We have described two mechanisms to link individuals to object |
| + properties: through {{valuetype}} expressions that generate |
| + new, anonymous individuals "in place"; and through {{value}} |
| + expressions containing pre-defined individual identifiers. Here, we |
| + introduce the use of __pattern labels__ and |
| + __pattern references__ to additionally |
| + allow object properties to link to individuals created in other |
| + instantiation patterns. |
| Lines 195-196 were replaced by lines 481-490 |
| - Consider the {{crops}} data set again. The following semantic type provides a more detailed description of {{crops}} using the full annotation syntax. |
| - |
| + __Pattern Labels.__ Each individual instantiation pattern can |
| + be assigned a unique label. For example, the following pattern is |
| + assigned the label 'o1'. |
| + |
| + {{{ |
| + <individual label="o1" type="ont:C" foreach="DISTINCT R.x"/> |
| + }}} |
| + |
| + The first-order rule for this pattern is: |
| + |
| Lines 198-199 were replaced by lines 492-493 |
| - <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" |
| - xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#"> |
| + (Axyz) R(x, y, z) u=o1(x) -> triple(u, rdf:type, ont:C). |
| + }}} |
| Lines 201-209 were replaced by lines 495-498 |
| - <sms:Label name="crops" resource="KBS019-003"/> |
| - <sms:Label name="Measurement" resource="ont:Measurement"/> |
| - <sms:Label name="Biomass" resource="ont:Biomass"/> |
| - <sms:Label name="Species" resource="ont:Species"/> |
| - <sms:Label name="Year" resource="ont:Year"/> |
| - <sms:Label name="Location" resource="ont:Location"/> |
| - <sms:Label name="measProp" resource="ont:measurementProperty"/> |
| - <sms:Label name="measItem" resource="ont:measurementItem"/> |
| - <sms:Label name="measContext" resource="ont:measurementContext"/> |
| + The use of labels in this way does not change the interpretation |
| + of the pattern, thus, the first-order rule associated with this |
| + pattern is the same as above (p1). However, for convenience, we use |
| + the label name as the Skolem function here. |
| Lines 211-215 were replaced by lines 500-504 |
| - <sms:Annotation object="$x:crops" meaning="$x:Measurement"/> |
| - <sms:Annotation object="$x:crops[bm=$y]" meaning="$x[measProp=$y:Biomass]"/> |
| - <sms:Annotation object="$x:crops[spp=$y]" meaning="$x[measItem=$y:Species]"/> |
| - <sms:Annotation object="$x:crops[yr=$y]" meaning="$x[measContext=$y:Year]"/> |
| - <sms:Annotation object="$x:crops[station=$y]" meaning="$x[measContext=$y:Location]"/> |
| + __Referencing Patterns.__ Properties can reference patterns |
| + using pattern labels in {{value}} expressions[9]. To distinguish pattern references from constants |
| + and resource variables, pattern references are prefixed with an '@' |
| + sign. For example, the following pattern contains a reference to the |
| + pattern labeled 'o1' above. |
| Line 217 was replaced by lines 506-509 |
| - </sms:SemanticType> |
| + {{{ |
| + <individual label="o2" type="ont:D" foreach="DISTINCT R.x, R.y"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| Line 220 was replaced by lines 512-515 |
| - The advantage of using the full syntax here is that we can properly relate attributes of a given tuple according to the ontology. For example, we are able to say that for a given tuple, the {{bm}} value represents the biomass of the species represented by the corresponding {{spp}} value. |
| + This pattern can be read as "For each unique x, y (tuple) value |
| + pair in R, create an instance of D that has a property P to the |
| + corresponding instance of C." The first-order rule for this pattern |
| + is: |
| Line 222 was replaced by lines 517-520 |
| - Another advantage of using the full syntax is that it allows annotations of resources that mix schema and data. Consider the following semantic-type description for a data set with attributes {{station}}, {{MEDSA}}, and {{GLYMX}}, where {{MEDSA}} and {{GLYMX}} are species codes containing biomass values. |
| + {{{ |
| + (Axyz) R(x, y, z) u=o1(x), v=o2(x, y) -> triple(v, rdf:type, ont:D), |
| + triple(v, ont:P, u). |
| + }}} |
| At line 223 added 8 lines. |
| + As with resource variables, pattern references are interpreted |
| + with respect to the current iteration context. In this example, |
| + 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}} |
| + property is assigned the individual corresponding to the current |
| + {{x}} value of the iteration context. |
| At line 224 added 4 lines. |
| + The iteration context of a property is not required to be a |
| + superset of its referenced pattern. For example, in the following |
| + pattern: |
| + |
| Lines 226-227 were replaced by lines 536-539 |
| - <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" |
| - xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#"> |
| + <individual label="o3" type="ont:D" foreach="DISTINCT R.y, R.z"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| + }}} |
| Lines 229-236 were replaced by lines 541-545 |
| - <sms:Label name="ds" resource="..."/> |
| - <sms:Label name="Measurement" resource="ont:Measurement"/> |
| - <sms:Label name="Biomass" resource="ont:Biomass"/> |
| - <sms:Label name="Species" resource="ont:Species"/> |
| - <sms:Label name="Location" resource="ont:Location"/> |
| - <sms:Label name="measProp" resource="ont:measurementProperty"/> |
| - <sms:Label name="measItem" resource="ont:measurementItem"/> |
| - <sms:Label name="measContext" resource="ont:measurementContext"/> |
| + 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 238-239 were replaced by lines 547-549 |
| - <sms:Annotation object="$x:ds[site=$y, MEDSA=$z]" |
| - meaning="f1($x):Measurement[measContext=$y:Location, measProp=$z:Biomass, measItem=MEDSA:Species]"/> |
| + Also, the iteration context of a property only applies to the |
| + referenced pattern, and does __not__ apply to additionally nested |
| + pattern references. For example, consider the following two patterns. |
| Lines 241-242 were replaced by lines 551-554 |
| - <sms:Annotation object="$x:ds[site=$y, GLYMX=$z]" |
| - meaning="f2($x):Measurement[measContext=$y:Location, measProp=$z:Biomass, measItem=GLYMX:Species]"/> |
| + {{{ |
| + <individual label="o5" type="ont:E" foreach="DISTINCT R.x, R.z"> |
| + <property type="ont:Q" value="@o4"/> |
| + </individual> |
| At line 243 added 3 lines. |
| + <individual label="o4" type="ont:D" foreach="DISTINCT R.y"> |
| + <property type="ont:P" value="@o1"/> |
| + </individual> |
| Removed line 245 |
| - </sms:SemanticType> |
| Line 248 was replaced by lines 562-566 |
| - Here, each tuple of the dataset represents two distinct measurements of biomass: one for the MEDSA species and the other for the GLYMX species. The skolem terms {{f1($x)}} and {{f2($x)}} distinguish these two observations given a tuple {{$x}}, that is, the skolem terms can be seen as creating two objects from the original object {{$x}}. |
| + The corresponding first-order rules for these patterns are: |
| + |
| + {{{ |
| + (Axyz) R(x, y, z) u=o1(x), v=o4(y) -> triple(v, rdf:type, ont:D), |
| + triple(v, ont:P, u). |
| At line 249 added 3 lines. |
| + (Axyz) R(x, y, z) v=o4(y), w=o5(x, z) -> triple(w, rdf:type, ont:E), |
| + triple(w, ont:Q, v). |
| + }}} |
| Line 251 was replaced by lines 572-576 |
| - The abbreviated syntax has a natural translation to the full syntax. For expressions {{T}} in the abbreviated syntax, the following two annotations are equivalent. |
| + Thus, although property values containing pattern references are |
| + assigned values from within the context of the enclosing |
| + {{foreach}} expression, each distinct pattern is still |
| + executed within its own context. To illustrate, let {{R}} be |
| + defined as follows. |
| Line 254 was replaced by lines 579-583 |
| - <sms:Annotation object="T" meaning="C"/> |
| + x y z |
| + --- --- --- |
| + 1 4 8 |
| + 2 4 9 |
| + }}} |
| Line 256 was replaced by lines 585-589 |
| - <sms:Annotation object="$x:T" meaning="$x:C"/> |
| + The triples created from pattern {{o1}} are: |
| + |
| + {{{ |
| + triple(o1(1), rdf:type, ont:C) |
| + triple(o1(2), rdf:type, ont:C) |
| Line 259 was replaced by line 592 |
| - For expressions {{T.A1}} in the abbreviated syntax, the following two annotations are equivalent. |
| + The triples created from pattern {{o4}} are: |
| Line 262 was replaced by lines 595-600 |
| - <sms:Annotation object="T.A1" meaning="C"/> |
| + triple(o4(4), rdf:type, ont:D) |
| + triple(o4(4), ont:P, o1(1)) |
| + triple(o4(4), ont:P, o1(2)) |
| + }}} |
| + |
| + And the triples created from pattern {{o5}} are: |
| Line 264 was replaced by lines 602-606 |
| - <sms:Annotation object="$x:T[A1=$y]" meaning="$y:C"/> |
| + {{{ |
| + triple(o5(1, 8), rdf:type, ont:E) |
| + triple(o5(1, 8), ont:Q, o4(4)) |
| + triple(o5(2, 9), rdf:type, ont:E) |
| + triple(o5(2, 9), ont:Q, o4(4)) |
| Line 267 was replaced by lines 609-615 |
| - For expressions {{T.A1.A2. ... .An}} in the abbreviated syntax, the following two annotations are equivalent. |
| + 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}}. |
| At line 268 added 5 lines. |
| + 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 270 was replaced by lines 623-628 |
| - <sms:Annotation object="T.A1.A2. ... .An" meaning="C"/> |
| + <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 272 was replaced by lines 630-636 |
| - <sms:Annotation object="$x:T[A1=$y1], $y1[A2=$y2] ... $yn-1[An=$yn]" meaning="$yn:C"/> |
| + The corresponding first-order rule for this pattern is: |
| + |
| + {{{ |
| + (Axyz) R(x, y, z) u=o1(x), w=o6(x, z) -> (Ev) triple(w, rdf:type, ont:E), |
| + triple(w, ont:Q, v), |
| + triple(v, rdf:type, ont:D), |
| + triple(v, ont:P, u). |
| Line 275 was replaced by lines 639-643 |
| - And finally, for expressions {{T.A1, T.A2, ..., T.Am}} in the abbreviated syntax, the following two annotations are equivalent, where {{f}} is a unique skolem symbol. |
| + 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}} |
| + instances in other patterns. |
| At line 276 added 6 lines. |
| + __Property Iteration and Labels__. It is also possible to apply |
| + {{foreach}} expressions to {{property}} statements, |
| + e.g., allowing one to additionally specify how intermediate |
| + individuals, for cases like {{o6}} above, should be |
| + constructed. For example, the following pattern: |
| + |
| Line 278 was replaced by lines 652-659 |
| - <sms:Annotation object="T.A1, T.A2, ..., T.Am" meaning="C"/> |
| + <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> |
| + }}} |
| + |
| + results in the first-order rule: |
| Line 280 was replaced by lines 661-666 |
| - <sms:Annotation object="$x:T, $x[A1=$y1], $x[A2=$y2], ..., $x[Am=$ym]" meaning="f($x, $y1, $y2, ..., $ym):C"/> |
| + {{{ |
| + (Axyz) R(x, y, z) u=o1(x), w=o7(x, z), v=o8(x, y, z) -> |
| + triple(w, rdf:type, ont:E), |
| + triple(w, ont:Q, v), |
| + triple(v, rdf:type, ont:D), |
| + triple(v, ont:P, u). |
| At line 282 added 6 lines. |
| + As shown, labels may also be applied to intermediate individuals |
| + (via their corresponding {{property}} statements), allowing |
| + these individuals to be referenced from within other patterns. In this |
| + case, the iteration context of the nested pattern is the union of its |
| + {{foreach}} expression with each of its ancestor's |
| + {{foreach}} expressions. |
| Removed line 284 |
| - The original semantic type for the {{crops}} data set expressed in the abbreviated syntax is translated below into an equivalent semantic type in the full syntax. Compared with the {{crops}} semantic type given above in the full syntax (relating tuple values via the ontology), the semantic type below is "less precise." However, in many cases where the semantic type is fairly simple, the abbreviated annotation syntax will be sufficient to describe the desired semantics. |
| Lines 286-288 were replaced by line 677 |
| - {{{ |
| - <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" |
| - xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#"> |
| + !!!Glossary |
| Lines 290-295 were replaced by line 679 |
| - <sms:Label name="crops" resource="KBS019-003"/> |
| - <sms:Label name="Measurement" resource="ont:Measurement"/> |
| - <sms:Label name="Biomass" resource="ont:Biomass"/> |
| - <sms:Label name="Species" resource="ont:Species"/> |
| - <sms:Label name="Year" resource="ont:Year"/> |
| - <sms:Label name="Location" resource="ont:Location"/> |
| + ;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 297-301 were replaced by line 681 |
| - <sms:Annotation object="$x:crops" meaning="$x:Measurement"/> |
| - <sms:Annotation object="$x:crops[bm=$y]" meaning="$y:Biomass"/> |
| - <sms:Annotation object="$x:crops[spp=$y]" meaning="$y:Species"/> |
| - <sms:Annotation object="$x:crops[yr=$y]" meaning="$y:Year"/> |
| - <sms:Annotation object="$x:crops[station=$y]" meaning="$y:Location"/> |
| + ;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 303-304 were replaced by lines 683-691 |
| - </sms:SemanticType> |
| - }}} |
| + ;Ontology: 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. |
| + |
| + ;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). |
| At line 305 added 1 line. |
| + ;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. |
| At line 306 added 1 line. |
| + ;Pattern Label: A label assigned to a template instantiation pattern. |
| Line 308 was replaced by line 697 |
| - ---- |
| + ;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. |
| Removed lines 310-316 |
| - [#1] We note that actor ports may not always be represented as an |
| - identifiable resource, and instead may be modeled as components of an |
| - actor. For example, consider an actor ''A'' having two ports ''P1'' |
| - and ''P2''. For the case where ''P1'' and ''P2'' are not separate |
| - resources, we can define the structural type of ''A'' as having two |
| - attributes {{P1}} and {{P2}} where {{A.P1}} denotes port ''P1'' and |
| - {{A.P2}} denotes port ''P2''. |
| Line 318 was replaced by line 700 |
| - [#2] Perhaps originally converted from a Sparrow expression. |
| + !!!Footnotes |
| Line 320 was replaced by lines 702-715 |
| - [#3] The semantic-type interchange-syntax XML Schema is: |
| + [#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 322-323 were replaced by lines 717-728 |
| - ... |
| - }}} |
| + <individual type="ont:C" foreach="R.x"> |
| + <property type="ont:P" value="$R.y" foreach="R.y"> |
| + </individual> |
| + }}} |
| + |
| + 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. |
| + |
| + [#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. |
| + |
| + [#9] Pattern references can be cyclic, i.e., a property within a pattern p can contain a property that refers to p. |
| + |
| + |
