KRSMS Semantic Annotation Language

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

KR/SMS Semantic Types

Datasets, actors (also known as services), and actor input and output ports are examples of resources that can have semantic types, that is, types that classify and constraint the semantic, as opposed to structural interpretation resources. A semantic type may also describe how the semantic interpretation is "encoded" within a resource. For example, given a dataset that contains measurements of biomass at a particular location, the "encoding" may state that a particular column denotes biomass values and that another column denotes location values.

We define a semantic type as a set of one or more semantic annotations. Generally speaking, a semantic annotation assigns some object (or set of objects) within a resource a meaning, where the "meaning" is specified via ontology expressions (that use terms from ontologies). A semantic annotation serves to "link" or "glue" a portion of a resource to a portion of an ontology.

A semantic type expressed in XML takes the following form:

<sms:SemanticType ID="...">

   <sms:Resources>

      ...

   </sms:Resources>

   <sms:SemanticTypes>

      ...

   </sms:SemanticTypes>

   <sms:Encodings>

      ...

   </sms:Encodings>

</sms:Annotation>

Note that every annotation should have a unique identifier, preferably an LSID. We describe each of the annotation subelements in turn below.

Resources

A resource can take one of the following three forms, depending its resource type (i.e., dataset, actor, or actor input/output port):

<sms:Dataset resource="..."/>

<sms:Actor resource="..."/>

<sms:ActorPort portName="..." resource="..."/>

The Dataset tag designates a dataset resource, whose resource identifier is given via the resource attribute. A dataset identifier is a unique identifier (e.g., an LSID) for the dataset, and we assume that the dataset identifier can be used (via additional tools) to retrieve the actual dataset. The Actor tag designates an actor resource and the resource attribute the unique identifier for the actor being reference. The ActorPort tag denotes a port of an actor. The portName attribute specifies the port for an actor identified via the resource attribute. A Resources element in an annotation must specify at least one resource subelement (either Dataset, Actor, or ActorPort). More than one resource subelement is permitted. For each subelement, the resource is attribute is required. In addition, for ActorPort elements, the portName attribute is required.

Semantic Types

The SemanticTypes element contains one or more class references or new class definitions:

<owl:Class rdf:about="..."/>

<owl:Class rdf:ID="...">

   ...

</owl:Class>

Every class definition defines a semantic type for the associated annotation resource(s). That is, the resources are said to "contribute" the semantic types. We impose the following constraints on semantic types. First, a referenced class (as in the first expression above) must come from an existing (and accessible) ontology. Second, every new class must have a class definition (i.e., be defined in terms of other roles and classes). And third, all classes and properties referenced in a new class definition must either come from an existing (and accessible) ontology or must be defined as a semantic type in the current annotation. Each annotation is required to contain a SemanticTypes tag that contains at least one semantic type.

Encodings

Encodings define the "glue" or "links" between the resource(s) and the semantic type(s) and are optional. An encoding takes the form:

<sms:Link> ... </sms:Link>

The content of the Link element uses a specific textual language that we define briefly here.

Examples