|
|||
|
This is version 36.
It is not the current version, and thus it cannot be edited. Coming soon!
KR/SMS Semantic TypesA semantic type is meant to classify and constrain 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 can have semantic types. We define semantic types as sets containing one or more semantic annotations. A semantic annotation assigns one or more objects of a resource (possibly including the resource itself) a "meaning" specified via an ontology expressions (using ontology terms). A semantic annotation serves to "link" or "glue" a portion of a resource to a portion of an ontology. Thus, the semantic interpretation of a resource (its semantic type) is built of the annotations of its parts.
Semantic types can be expressed using the following XML representation:
<sms:SemanticType ID="..."> <sms:Label name="..." resource="..."/> ... <sms:Annotation object="..." meaning="..."/> ... </sms:SemanticType> A semantic type is required to have a unique identifier, given using the ID attribute. The identifier should (preferably) be represented as an LSID, and the semantic type managed as an LSID data object.
LabelsLabels within semantic-type descriptions provide a mechanism to name the resources and ontology terms used in the annotations. The Label element assigns the name attribute value as the name, or "tag," for the associated resource given by the resource attribute value (this attribute value is the associated identifier for a resource). Each Label tag is required to have exactly one name and resource attribute. A SemanticType element must have at least one Label sub-element identifying a resource and one Label element identifying an ontology term. Further, no two Label elements within a semantic type may have the same value for the name attribute.
AnnotationsAn annotation asserts that a resource object has a particular semantic meaning.
Examples
|
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). Copyright 2004 Partnership for Biodiversity Informatics, University of New Mexico, The Regents of the University of California, and University of Kansas |