KRSMS Semantic Annotation Language

This is version 124. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Intended audience

Introduction

This page describes an interchange syntax that can be used to express semantics types.

KR/SMS Semantic Types

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.

A semantic type is expressed as a set of semantic annotations. The purpose of a semantic annotation is to assign objects of a resource a "meaning" using ontology terms. A semantic annotation serves to "link" 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 annotation of its parts.

Semantic types can be expressed using the following XML representation.

<sms:SemanticType id="..." xmlns:sms="http://seek.ecoinformatics.org/sms">
 
   <sms:Label name="..." resource="..."/>

   ...

   <sms:Annotation object="..." meaning="..."/>

   ...

</sms:SemanticType>

Semantic types should be uniquely identified. The unique identifier of a semantic type can be stated using the id attribute of the SemanticType element. An identifier is (preferably) expressed as a Life-Science Identifer (LSID) in which the semantic type is managed as an LSID data object. Alternatively, if a semantic type is embedded within a document, the semantic-type id can be expressed as a fragment identifier (for example, when used within EML). As shown above, a semantic type consists of a set of labels and annotations. The rest of this page describes these two components, starting with labels and then describing annotations.

Semantic-Type Labels

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.

The first label shown below associates a dataset to the name crops and the second label associates an ontology concept to the name Biomass.

<sms:Label name="crops" resource="KBS019-003"/>

<sms:Label name="Biomass" resource="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#Biomass"/>

Semantic Annotations

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 object and ontology expressions, respectively. We provide a uniform annotation language for identifying resource objects and specifying ontology expressions.

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.

The annotation language has two forms: an abbreviated syntax, and a more complex, full syntax.

Abbreviated Annotation-Language Syntax

For resources and their objects, the abbreviated syntax permits the following expressions given a resource label T and attributes A1 to An.

T

T.A1

T.A1.A2. ... .An

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. The expression T.A1 selects the nested A1 objects for objects of T. For T representing a data set, this expression would select the values of attribute A1 for tuples of T. The last expression selects nested attributes for complex structures occuring, for example, in actor input/output ports. For instance, if T represents an input port to some actor, the expression T.A1.A2 selects the A2 objects nested within A1 objects for T objects.

In the abbreviated syntax, ontology expressions consist of single concept labels C.

To illustrate, consider the following semantic-type definition for a data-set resource.

<sms:SemanticType id="mySemType" xmlns:sms="http://seek.ecoinformatics.org/sms" xmlns:ont="http://seek.ecoinformatics.org/seek/ontos/DefaultOnto#">

  <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: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"/>

</sms:SemanticType>

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 thrid annotation that each spp attribute value is a Species instance, and so on.

For convenience, we also permit ontology concept expressions to be "embedded" within labels. The purpose of this features is to allow one to specialize certain concepts 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[1].

To illustrate, 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.

<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#">

   <sms:Label name="Crops" resource="KBS019-003"/>

   <sms:Label name="MyMeasurement">
      <sms:Resource sms:resourceType="OWL">
         <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>
   </sms:Label>

   ...

   <sms:Annotation object="Crops" meaning="MyMeasurement"/>

   ...

</sms:SemanticType>

Full Annotation-Language Syntax

The full annotation-language syntax provides access to various parts of a complex structure and the ability to assign those parts to ontology expressions. To support a wide variety of complex structures -- the primary ones including relational, XML, and Ptolemy types -- we consider a generic data model consisting of nested-relational-style constructs. In addition, we permit multi-valued attributes (that is, an attribute can have an associated, possibly ordered, collection of values).

The abbreviated annotation-language syntax is shorthand for a subset of the full syntax. In the full syntax, resource expressions consist of lists of atoms (separated by commas) taking one of the following forms.

x:T

x[A1=y]

Here, symbols x and y denote either constants or variables. Variables are prefixed with a $ sign. Constants that contain spaces must be delimited using single quotes.

Atoms can be composed to form more complex expressions as follows. Atoms x:T and x[A1=y] can be composed to form the expression x:T[A1=y]. Atoms x[A1=y] and x[A2=z can be composed to form the expression x[A1=y, A2=z]. In a similar way, atoms and expressions can be composed to form additional expressions.

The same syntax is used to describe the meaning of an annotation. In paricular, T must be a concept label, and A1 a property label.

The meaning of a full annotation can be interpreted as follows. Define var function. Then we have forall var(...) ... -> exists var(...) ...

For instance, ...

If x is a variable, the first expression above is identical to the abbreviated expression T except that each selected object of T is assigned to the variable. Similarly, if x and y are both variables, the second atom is identical to the abbreviated expression T.A1 except that x and y are assigned to the T and A1 objects, respectively. If x is a constant, the atom x:T is true if x is an object of T. If x and y are constants, the atom x[A=y] is true if x is an object having y as one of its A attribute values. If x is a constant and y is a variable, the second atom assigns y to each of the A1 attributes of x. And if x is a variable and y is a constant, the atom x[A1=y] is true if x has already been assigned an object and it has y as one of its A1 values.

Examples

[#1] Perhaps originally converted from a Sparrow expression.

Comments