-
Notifications
You must be signed in to change notification settings - Fork 9
/
annotation.tex
28 lines (20 loc) · 3.63 KB
/
annotation.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
\subsection{Annotation and Extension of SBOL}
\label{sec:Annotations}
SBOL intentionally does not attempt to describe how all types of biological design data should be captured, since many of these data types (e.g., biological context and design performance metrics) are already covered by other standards, or lack a clear consensus on their proper representation, or are outside of the scope of SBOL.
SBOL is built upon the Resource Description Framework (RDF), and therefore can be used in conjunction with complementary standards as described in \ref{sec:complementaryStandards}. For example, use of the PROV-O ontology is recommended to capture provenance (see \ref{sec:provenance}).
Additionally, user-defined RDF can be used in conjunction with SBOL objects to capture custom application-specific information that does not yet have a standardized representation.
This annotation and extension mechanism is designed to enable new types of data to be easily incorporated into the SBOL standard once there is community consensus on their proper representation.
Several methods are supported for connecting the SBOL data model with other types of application-specific data:
\begin{itemize}
\item Custom data can be added to an SBOL object by annotating that object with non-conflicting properties. These properties could contain \sbol{literal} data types such as \sbol{String}s or \sbol{IRI}s that require a resolution mechanism to obtain external data. An example is annotating a \sbol{Component} with a property that contains a \sbol{String} description and \sbol{IRI} for the parts registry from which its source data was originally imported.
\item SBOL object classes can be extended to custom classes that add additional information. This works just like adding custom data via non-conflicting properties, except that the object receives both an \external{rdf:type} for the SBOL class that has been extended and also an \external{rdf:type} specifying the extension class.
\item Custom data in the form of independent objects can participate in the SBOL data model if they are assigned one of the SBOL types \sbol{Identified} or \sbol{TopLevel}. An example is an RDF object that is annotated such that it represents a data sheet that describes the performance of a \sbol{Component} in a particular context.
\item Finally, just as custom objects can be embedded in an SBOL document, external documents can embed or refer to SBOL objects. Support for this last case is not explicitly provided in this specification. Rather, this case depends on the external non-SBOL system managing its relationship to SBOL and data serialized in RDF, and is included here for completeness.
\end{itemize}
Each \sbol{Identified} object MAY be annotated with application-specific properties, which MUST be labelled using RDF predicates outside of the SBOL namespace. Additionally, application-specific types may be used in conjunction with the SBOL data model. These application-specific types MUST have at least two \external{rdf:type} properties: one type outside of the SBOL namespace AND an additional SBOL type of either:
\begin{itemize}
\item \sbol{TopLevel}, if the object is to be considered an SBOL top level (i.e., not owned by another object)
\item \sbol{Identified}, if the object is not to be considered an SBOL top level (i.e., is owned by another object)
\item The most specific applicable SBOL type, if the object is an instance of a custom class extending an SBOL class.
\end{itemize}
As with SBOL \sbol{Identified} objects, custom \sbol{Identified} objects (and thus also all other custom objects) MAY also include the properties \sbol{displayId}, \sbol{name}, \sbol{description}, etc.