Science Environment for Ecological Knowledge
Ecoinformatics site parent site of Partnership for Biodiversity Informatics site parent site of SEEK - Home
Science Environment for Ecological Knowledge








 

 

 

KRSMS Semantic Annotation Language
Your trail: EcoGridIdentifiers | EcoGridWebDesignNotes | CertificateAuthorityDesign | EcoGridConferenceCallNotes7Sep2004 | EcoGridConferenceCallNotes17Sep2004 | KRSMSMeasurement | SparrowLanguage | SemanticsInKepler | KRSMSOntoCreationGuide | SMSServiceInterfaces

Difference between version 172 and version 81:

At line 1 added 1 line.
+
Lines 4-5 were replaced by lines 5-6
- It is a __DRAFT DESIGN DOCUMENT__ and does not reflect functionality as it
- currently exists in Kepler or SEEK. Comments and feedback are appreciated.
+ It is a __DRAFT DESIGN DOCUMENT__ and does not reflect functionality as it currently exists in Kepler or SEEK. Comments and feedback are appreciated (see [Comments Page|KRSMSSemanticAnnotationComments]).
+
Line 9 was replaced by lines 10-27
- This page describes an interchange syntax that can be used to express semantics 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.
+
+ 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"/>
+ ...
+ <!-- annotation assertions -->
+ ontology instantiation templates
+ ...
+ </annotation>
+ }}}
At line 10 added 2 lines.
+ 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.
Line 12 was replaced by lines 32-33
- !!! KR/SMS Semantic Types
+ 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 14 was replaced by line 35
- A __semantic type__ classifies and constrains the semantic, as opposed to structural interpretation of a __resource__. Datasets, actors (also known as __services__), and actor input and output ports are examples of resources that may have semantic types within SEEK.
+ !!! 2 Overview of Annotation Templates
Line 16 was replaced by line 37
- A semantic type is expressed as a set of __semantic annotations__. A semantic annotation assigns objects of a resource a "meaning" via ontology expressions (that is, using ontology terms), thus serving to "link" or "glue" a portion of a resource to a portion of an ontology. In this way, the semantic interpretation of a resource (its semantic type) is built from the annotations of its parts.
+ 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 18 was replaced by line 39
- Semantic types can be expressed using the following XML representation:
+ The simplest form of an instantiation pattern is:
Lines 21-23 were replaced by lines 42-400
- <sms:SemanticType id="..." xmlns:sms="http://seek.ecoinformatics.org/sms">
-
- <sms:Label name="..." resource="..."/>
+ <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}}.
+
+ {{{
+ <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"/>
+
+ </rdf:RDF>
+ }}}
+
+ 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.
+
+ 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:
+
+ {{{
+ (Axyz) R(x, y, z), u=id_p1(x) -> triple(u, rdfs:type, ont:C).
+ }}}
+
+ 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}}.
+
+ 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.
+
+
+ <a name="section3"></a>
+ <h2>3. Template Instantiation Patterns</h2>
+
+ !!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"/>
+ }}}
+
+ 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:
+
+ {{{
+ (Axyz) R(x, y, z), u=id_p2(x, y) -> triple(u, rdfs:type, ont:C).
+ }}}
+
+ In this example, we say that each {{x,y}} value
+ constitutes a particular {{C}}.
+
+ 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:
+
+ {{{
+ SELECT DISTINCT R1.x, R2.x
+ FROM Employee R1, Employee R2
+ }}}
+
+ In a similar way, one can view {{foreach}} expressions as
+ group constructors, similar to the {{GROUP BY}} clause in
+ SQL.
+
+ __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}}.
+
+ {{{
+ <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:
+
+ {{{
+ (Axyz) R(x, y, z), x>0, u=id_p3(x, y) -> triple(u, rdfs:type, ont:C).
+ }}}
+
+ 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).
+
+
+ !!3.2 Object Properties
+
+ 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>
+ }}}
+
+ 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].
+
+ {{{
+ <rdf:RDF xmlns="local-ns" ...>
+ <owl:Ontology rdf:about="">
+ <owl:imports rdf:resource="htt://ontologies.org/ont"/>
+ </owl:Ontology>
+
+ <ont:C rdf:ID="id-val1">
+ <ont:P>
+ <ont:D/>
+ </ont:P>
+ </ont:C>
+ ...
+ <ont:C rdf:ID="id-valn">
+ <ont:P>
+ <ont:D/>
+ </ont:P>
+ </ont:C>
+
+ </rdf:RDF>
+ }}}
+
+ The first-order rule for this pattern is:
+
+ {{{
+ (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.
+
+ __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:
+
+ {{{
+ <individual type="ont:C" foreach="DISTINCT R.x">
+ <property type="ont:P" valuetype="ont:D">
+ <property type="ont:Q" valuetype="ont:E"/>
+ </property>
+ </individual>
+ }}}
+
+ 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:
+
+ {{{
+ (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).
+ }}}
+
+ __Multiple Properties.__ Individuals can be assigned more than
+ one property. The following pattern assigns two properties
+ {{P1}} and {{P2}}.
+
+ {{{
+ <individual type="ont:C" foreach="DISTINCT R.x">
+ <property type="ont:P1" valuetype="ont:D1"/>
+ <property type="ont:P2" valuetype="ont:D2"/>
+ </individual>
+ }}}
+
+
+ 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:
+ {{{
+ (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).
+ }}}
+
+
+ The general form of a pattern consists of an
+ {{individual}} expression, followed by any number of
+ (possibly nested) {{property}} expressions:
+
+ {{{
+ <individual type="..." foreach="..." if="..." ...>
+ <property type="..." ...>
+ ... nested property expressions ...
+ </property>
+ ... additional property expressions ...
+ </individual>
+ }}}
+
+ The additional attributes of {{individual}} and
+ {{property}} statements are described further below (as well
+ as in the footnotes).
+
+ !!3.3 Datatype Properties
+
+ 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).
+
+ 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.
+
+ __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.
+
+ {{{
+ <individual type="ont:C" foreach="DISTINCT R.x">
+ <property type="ont:P" value="5"/>
+ </individual>
+ }}}
+
+ 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:
+
+ {{{
+ (Axyz) R(x, y, z), u=id_p7(x) -> triple(u, rdf:type, ont:C),
+ triple(u, ont:P, 5).
+ }}}
+
+ __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}}.
+
+ {{{
+ <individual type="ont:C" foreach="DISTINCT R.x">
+ <property type="ont:P" value="$R.x"/>
+ </individual>
+ }}}
+
+ 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:
+
+ {{{
+ (Axyz) R(x, y, z), u=id_p8(x) -> triple(u, rdf:type, ont:C),
+ triple(u, ont:P, x).
+ }}}
+
+ 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>
+ }}}
+
+ 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:
+
+ {{{
+ (Axyz) R(x, y, z), u=id_p9(x) -> triple(u, rdf:type, ont:C),
+ triple(u, ont:P, y).
+ }}}
Line 25 was replaced by lines 402-409
- ...
+ 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 27 was replaced by lines 411-424
- <sms:Annotation object="..." meaning="..."/>
+ {{{
+ <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}}:
+
+ {{{
+ (Axvzwyt) R(x, v, z), R(w, y, t), u=id_p10(x) -> triple(u, rdf:type, ont:C),
+ triple(u, ont:P, y).
+ }}}
Line 29 was replaced by lines 426-437
- ...
+ 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.
+
+ __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 31 was replaced by lines 439-442
- </sms:SemanticType>
+ {{{
+ <individual type="ont:C" foreach="DISTINCT R.x">
+ <property type="ont:P" value="$R.x" if="R.x>0"/>
+ </individual>
Line 34 was replaced by line 445
- A semantic type is required to have a unique identifier, which is given by the {{id}} attribute. The identifier should (preferably) be represented as an LSID, where the semantic type is managed as an LSID data object.
+ This patterns must be represented using two first-order rules:
Line 36 was replaced by lines 447-448
- !! Labels
+ {{{
+ (Axyz) R(x, y, z), u=id_p11(x) -> triple(u, rdf:type, ont:C).
Line 38 was replaced by lines 450-451
- Labels within a semantic-type description provide a mechanism to identify and name the resources and ontology terms used in the corresponding annotations. A {{Label}} element assigns the value of the {{name}} attribute to the associated resource identified by the {{resource}} attribute value. 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 an actor or dataset and the other identifying an ontology term. Further, no two {{Label}} elements within a semantic type may have the same {{name}} attribute value.
+ (Axyz) R(x, y, z), x>0, u=id_p11(x) -> triple(u, ont:P, x).
+ }}}
Line 40 was replaced by lines 453-483
- The first label shown below associates a dataset to the name {{crops}} and the second label associates an ontology concept to the name {{Biodiversity}}.
+ 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.
+
+ 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).
+
+
+ !!3.3 Complex Instantiation Patterns
+
+ 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.
+
+ __Pattern Labels.__ Each individual instantiation pattern can
+ be assigned a unique label. For example, the following pattern is
+ assigned the label 'o1'.
Line 43 was replaced by lines 486-487
- <sms:Label name="crops" resource="KBS019-003"/>
+ <individual label="o1" type="ont:C" foreach="DISTINCT R.x"/>
+ }}}
Line 45 was replaced by lines 489-492
- <sms:Label name="Biomass" resource="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#Biomass"/>
+ The first-order rule for this pattern is:
+
+ {{{
+ (Axyz) R(x, y, z) u=o1(x) -> triple(u, rdf:type, ont:C).
At line 47 added 10 lines.
+ 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.
+
+ __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 49 was replaced by lines 506-510
- !! Annotations
+ {{{
+ <individual label="o2" type="ont:D" foreach="DISTINCT R.x, R.y">
+ <property type="ont:P" value="@o1"/>
+ </individual>
+ }}}
Line 51 was replaced by lines 512-515
- An annotation asserts that an object of a resource has a particular meaning according to definitions within an ontology. The {{object}} and {{meaning}} attributes of an {{Annotation}} element relate the associated object and ontology expressions, respectively. We provide a uniform __annotation language__ for identifying resource objects and specifying ontology expressions.
+ 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 53 was replaced by lines 517-520
- Some resources (in particular, 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. 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.
+ {{{
+ (Axyz) R(x, y, z) u=o1(x), v=o2(x, y) -> triple(v, rdf:type, ont:D),
+ triple(v, ont:P, u).
+ }}}
Line 55 was replaced by lines 522-533
- The annotation language has two forms: a simple "shorthand" syntax, and a more complex, full syntax. For resources and their objects, the simple syntax permits the following expressions given a resource label {{T}} and attributes {{A1}} to {{An}:
+ 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.
+
+ The iteration context of a property is not required to be a
+ superset of its referenced pattern. For example, in the following
+ pattern:
Line 58 was replaced by lines 536-549
- T
+ <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.
+
+ 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.
Line 60 was replaced by lines 551-558
- T.A1
+ {{{
+ <individual label="o5" type="ont:E" foreach="DISTINCT R.x, R.z">
+ <property type="ont:Q" value="@o4"/>
+ </individual>
+
+ <individual label="o4" type="ont:D" foreach="DISTINCT R.y">
+ <property type="ont:P" value="@o1"/>
+ </individual>
Removed line 62
- T.A1.A2. ... .An
Line 65 was replaced by lines 562-566
- The expression {{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. Similarly, the expression {{T.A1}} selects the nested {{A1}} objects of {{T}}. For {{T}} representing a data set, this expression would select the values of attribute {{A1}}. The last expression selects nested attributes for complex structures that can occur in actor input/output ports. For example, if {{T}} represented an input port to some actor, the expression {{T.A1.A2}} selects the {{A2}} objects nested within {{A1}} objects of {{T}} instances.
+ 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).
Line 67 was replaced by lines 568-570
- In the simple-version of the annotation syntax ontology expressions consist of single concept labels {{C}} defined as resources.
+ (Axyz) R(x, y, z) v=o4(y), w=o5(x, z) -> triple(w, rdf:type, ont:E),
+ triple(w, ont:Q, v).
+ }}}
Line 69 was replaced by lines 572-576
- To illustrate, consider the following semantic-type definition expressed using the simple annotation syntax for a data set resource:
+ 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 72 was replaced by lines 579-585
- <sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#>
+ x y z
+ --- --- ---
+ 1 4 8
+ 2 4 9
+ }}}
+
+ The triples created from pattern {{o1}} are:
Line 74 was replaced by lines 587-590
- <sms:Label name="Crops" resource="KBS019-003"/>
+ {{{
+ triple(o1(1), rdf:type, ont:C)
+ triple(o1(2), rdf:type, ont:C)
+ }}}
Line 76 was replaced by line 592
- <sms:Label name="Measurement" resource="ont:Measurement"/>
+ The triples created from pattern {{o4}} are:
Line 78 was replaced by lines 594-598
- <sms:Label name="Biomass" resource="ont:Biomass"/>
+ {{{
+ triple(o4(4), rdf:type, ont:D)
+ triple(o4(4), ont:P, o1(1))
+ triple(o4(4), ont:P, o1(2))
+ }}}
Line 80 was replaced by line 600
- <sms:Label name="Species" resource="ont:Species"/>
+ And the triples created from pattern {{o5}} are:
Line 82 was replaced by lines 602-607
- <sms:Label name="Year" resource="ont:Year"/>
+ {{{
+ 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 84 was replaced by lines 609-620
- <sms:Label name="NamedLocation" resource="ont:NamedLocation"/>
+ Notice that both individuals of pattern {{o5}} are
+ {{Q}}-related to the same {{o4}}
+ individual. Similarly, this {{o4}} individual is
+ {{P}}-related to both individuals of {{o1}},
+ corresponding to __both__ {{x}} values of
+ {{R}}, and thus going "out of context" for pattern
+ {{o5}}.
+
+ To use the iteration context of {{o5}} for
+ {{o1}} while still generating intermediate instances of
+ {{D}}, we can use the following pattern, combining
+ {{o5}} and {{o4}}:
Line 86 was replaced by lines 622-628
- <sms:Annotation object="Crops" meaning="Measurement"/>
+ {{{
+ <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 88 was replaced by line 630
- <sms:Annotation object="Crops.bm" meaning="Biomass"/>
+ The corresponding first-order rule for this pattern is:
Line 90 was replaced by lines 632-637
- <sms:Annotation ojbect="Crops.spp" meaning="Species"/>
+ {{{
+ (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 92 was replaced by lines 639-649
- <sms:Annotation ojbect="Crops.yr" meaning="Year"/>
+ 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.
+
+ __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 94 was replaced by lines 651-657
- <sms:Annotation ojbect="Crops.station" meaning="NamedLocation"/>
+ {{{
+ <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 96 was replaced by line 659
- </sms:SemanticType>
+ results in the first-order rule:
At line 97 added 6 lines.
+ {{{
+ (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 99 added 23 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.
+
+
+ !!!Glossary
+
+ ;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).
+
+ ;Resource: 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).
+
+ ;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 100 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 101 added 1 line.
+ ;Pattern Label: A label assigned to a template instantiation pattern.
Line 103 was replaced by line 697
- In addition, the label also represents the collection of
+ ;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.
Line 105 was replaced by lines 699-720
- denotes the set of corresponding objects satisfying the structural constraints of the resource. For example, if {{T}} is a label for a dataset, the expression {{T}} implicitly denotes the set of tuple objects in the corresponding dataset. Similarly, if {{T}} is a label for an actor, the expression{{T}} implicitly denotes an instance of that actor.
+
+ !!!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:
+
+ {{{
+ <individual type="ont:C" foreach="R.x">
+ <property type="ont:P" value="$R.y" foreach="R.y">
+ </individual>
+ }}}
At line 106 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.
At line 107 added 1 line.
+ [#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.
Lines 109-112 were replaced by line 726
- * How to give the annotation of a resource as a dl-style expression, preferably in the same language
- * Discuss/explain what a resource dentoes, e.g., is it a name that denotes a set of instances (e.g., a dataset/table name denotes a set of instances, where an instance is a row in the table). What about for actors?
- * Discuss/explain that the "structure" language is generic and can represent many data models (ptolemy types, relational, even xml).
- * Describe the language step-by step, without a grammar :)
+ [#9] Pattern references can be cyclic, i.e., a property within a pattern p can contain a property that refers to p.
Removed line 114
- !!! Examples
Line 117 was replaced by line 730
- !!! Comments
+ [Comments|KRSMSSemanticAnnotationComments]

Back to KRSMS Semantic Annotation Language, or to the Page History.


This material is based upon work supported by the National Science Foundation under award 0225676. Any opinions, findings and conclusions or recomendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).

LTER Logo
Long Term Ecological Research Network, UNM National Center for Ecological Analysis and Synthesis, UCSB Biodiversity Research Center, KU San Diego Supercomputer Center, UCSD
 
Arizona State University Napier University University of North Carolina University of Vermont
 
UC Davis Genome Center

Copyright 2004 Partnership for Biodiversity Informatics, University of New Mexico, The Regents of the University of California, and University of Kansas