complementary_standards.tex

% -----------------------------------------------------------------------------
\section{Complementary Standards}
\label{sec:complementaryStandards}

Here we discuss two complementary standards that have been adapted for use as part of SBOL representation, following the pattern for extension of SBOL described in Section~\ref{sec:Annotations}.
In both cases, the extension uses the pattern in which object from another ontology are also assigned to either the SBOL \sbol{Identified} or \sbol{TopLevel} types.
Note that this means that the object receives both an \external{rdf:type} for the SBOL class and also an \external{rdf:type} in their own namespace.

% -----------------------------------------------------------------------------
\subsection{Adding Provenance with PROV-O}
\label{sec:provenance}
\label{sec:prov:Entity}

The PROV-O ontology (\url{https://www.w3.org/ns/prov#}) defines a complementary data model that is leveraged by SBOL to describe provenance. Provenance is central to a range of workflow management, quality control, and attribution tasks within the Synthetic Biology design process. Tracking attribution and derivation of one resource from another is paramount for managing intellectual property purposes. Source designs are often modified in systematic ways to generate derived designs, for example, by applying codon optimization or systematically removing all of a class of restriction enzyme sites.  Documenting the transformation used, and any associated parameters, makes this explicit and potentially allows the process to be reproduced systematically. If a design has been used within other designs, and is later found to be defective, it is paramount that all uses of it, including uses of edited versions of the design, can be identified, and ideally replaced with a non-defective alternative. When importing data from external sources, it is important not only to attribute the original source (for example, GenBank), but also the tool used to perform the import, as this may have made arbitrary choices as to how to represent the source knowledge as SBOL. All these activities have in common that it is necessary to track what resource, and what transformation process was applied by whom to derive an SBOL design.

This section describes a minimal subset of PROV-O terms and classes that may be used by SBOL tools to support representation of provenance\footnote{We thank Dr Paolo Missier from the School of Computing Science, Newcastle University for discussions regarding the use of PROV-O.},
and how it has been adapted for use with SBOL by assigning PROV-O classes to SBOL \sbol{Identified} or \sbol{TopLevel} types per  Section~\ref{sec:Annotations}.
%
 Although the full-set of PROV-O terms can be used in SBOL documents, a subset of PROV-O is adopted as a best practice. It is advised that SBOL tools should at least understand this subset, defined in \ref{uml:provenance}. Providers of provenance information are free to make use of more of PROV-O than is described here. It is acceptable for tools that understand more than this subset to use as much as they are able. Tools that only understand this subset must treat any additional data as annotations. Tools that are not aware of SBOL provenance at all MUST maintain and provide access to this information as annotations. This specification does not state what the newly added properties must point to. As long as they are resources that are consistent with the PROV-O property domains, they are legal. For example, a \sbol{Component} may be derived from another \sbol{Component}, but it would probably not make sense for it to be derived from a \sbol{Collection}.

The most basic and general type of provenance relationship can be represented using the \prov{wasDerivedFrom} property. This relationship describes derivation of an SBOL entity from another.
Any \sbol{Identified} object may be annotated with this property. More specific provenance relationships can also be defined using PROV-O, such as \prov{wasGeneratedBy}. Generation of a new object is defined by the W3C PROV-O specification as follows:
\begin{quote}
	...the completion of production of a new entity by an activity. This entity did not exist before generation and becomes available for usage after this generation.
\end{quote}
These relationships are leveraged in SBOL tooling for describing multi-stage synthetic biology workflows.

Synthetic biology workflows may involve multiple stages, multiple users, multiple organizations, and interdisciplinary collaborations. These workflows can be described using four core PROV-O classes: \prov{Entity}, \\ \prov{Activity}, \prov{Agent}, and \prov{Plan}. Any SBOL \sbol{Identified} object can implicitly act as an instance of PROV-O's \prov{Entity} class. Workflow histories (retrospective provenance) and workflow specifications (prospective provenance) can be described in SBOL using \prov{Activity} objects to link \sbol{Identified} objects into workflows. An \prov{Agent} (for example a software or a person) runs an \prov{Activity} according to a \prov{Plan} to generate new entities. Resources representing \prov{Agent}, \prov{Activity} and \prov{Plan} classes should be handled as \sbol{TopLevel}, whilst \prov{Usage} and \prov{Association} resources should be treated as child \sbol{Identified} objects within their parent \prov{Activity} objects.

A design-build-test-learn SBOL ontology has been adopted for use with PROV-O classes (see \ref{tbl:activity_types}). The terms \textit{design}, \textit{build}, \textit{test}, and \textit{learn} provide a high level workflow abstraction that allows tool-builders to quickly search for and isolate provenance histories relevant to their domain, while keeping track of the flow of data between different users working in different domains of synthetic biology. These terms SHOULD BE used on the \sbolmult{type:Activity}{type} property of the \prov{Activity} class. (Note that this property is a special property added by the SBOL specification, and is not part of the original PROV-O specification.) Additionally, these terms SHOULD BE used in the \provmult{hadRole:U}{hadRole} properties on \prov{Usage} to qualify how the referenced \prov{entity} is used by the parent \prov{Activity}.

\begin{table}[ht]
	\begin{edtable}{tabular}{llp{3.5in}}
		\toprule
		\textbf{Activity Type} & \textbf{URL}  & \textbf{Description}\\
		\midrule
		Design  & \url{http://sbols.org/v3\#design}  & Design describes the process by which a conceptual representation of an engineer's imagined and intended design for a biological system is created or derived.\\
		Build  & \url{http://sbols.org/v3\#build}  & Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory.\\
		Test  & \url{http://sbols.org/v3\#test} & Test describes the process of performing experimental measurements to characterize a synthetic biological construct.\\
		Learn  & \url{http://sbols.org/v3\#learn} & Learn describes the process of analyzing experimental measurements to produce a new entity that represents biological knowledge.\\
		\bottomrule
	\end{edtable}
	\caption{Synthetic biology workflow ontology}
	\label{tbl:activity_types}
\end{table}

Logical constraints are placed on the order in which different types of \prov{Activity}s are chained into design-build-test-learn workflows. These rules additionally place constraints on the types of objects that may be used as inputs for a particular type of \prov{Activity}. For example, a \textit{design} \prov{Usage} may be used as an input for either a \textit{design} or \textit{build} \prov{Activity} but SHOULD NOT be used as an input for a \textit{test} \prov{Activity}. An example of how these terms are used is provided in \ref{images:design-build-test-learn}.
The ordering of stages and constraints on referred object type are given in \ref{tbl:dbtl_stages}.

\begin{table}[ht]
\begin{tabular}{lll}
\toprule
\textbf{Stage} & \textbf{Preceding Stage} & \textbf{Referred Object Type} \\
\midrule
\url{http://sbols.org/v3\#design}	& \url{http://sbols.org/v3\#learn}		& \sbol{TopLevel} other than \sbol{Implementation} \\
\url{http://sbols.org/v3\#build}	& \url{http://sbols.org/v3\#design}	& \sbol{Implementation} \\
\url{http://sbols.org/v3\#test}	& \url{http://sbols.org/v3\#build}		& \sbol{ExperimentalData} \\
\url{http://sbols.org/v3\#learn}	& \url{http://sbols.org/v3\#test}		& \sbol{Identified} other than \sbol{Implementation} \\
\bottomrule
\end{tabular}
\caption{Ordering of design-build-test-learn stages, and the types of objects RECOMMENDED to be associated with them.}
\label{tbl:dbtl_stages}
\end{table}


In addition to the design-build-test-learn terms, users may also wish to include more specific terms to specify how SBOL objects are used in-house in their own recipes, protocols, or computational analyses. In fact, it is expected that the SBOL workflow ontology will be expanded over time, as users experiment with and develop their own custom ontologies. For now, however, it is RECOMMENDED that SBOL tools also include the high-level terms in \ref{tbl:activity_types} to support data exchange across interdisciplinary boundaries.

\begin{figure}[ht]
\begin{center}
\includegraphics[scale=0.6]{uml/provenance}
\caption[]{Relationships between SBOL and PROV-O classes. The PROV-O classes \external{prov:Activity}, \external{prov:Plan}, and \external{prov:Agent} all derive from \sbol{TopLevel} in the context of the SBOL data model.
\label{uml:provenance}}
\end{center}
\end{figure}

\subsubsection{prov:Activity}
\label{sec:prov:Activity}

A generated \prov{Entity} is linked through a \prov{wasGeneratedBy} relationship to an \prov{Activity}, which is used to describe how different \prov{Agent}s and other entities were used. An \prov{Activity} is linked through a \prov{qualifiedAssociation} to \prov{Association}s, to describe the role of agents, and is linked through \\ \prov{qualifiedUsage} to \prov{Usage}s to describe the role of other entities used as part of the activity. Moreover, each \prov{Activity} includes optional \prov{startedAtTime} and \prov{endedAtTime} properties. When using \prov{Activity} to capture how an entity was derived, it is expected that any additional information needed will be attached as annotations. This may include software settings or textual notes. Activities can also be linked together using the \prov{wasInformedBy} relationship to provide dependency without explicitly specifying start and end times.

\subparagraph{The \sbolheading{type} property}\label{sec:type:Activity}

An \prov{Activity} MAY have one or more \sbolmult{type:Activity}{type} properties, each of type \sbol{IRI} that explicitly specifies the type of the provenance \prov{Activity} in more detail.  If specified, it is RECOMMENDED that at least one \sbolmult{type:Activity}{type} property refers to a \sbol{URL} from \ref{tbl:activity_types}.

\subparagraph{The \sbolheading{prov:startedAtTime} property}\label{sec:prov:startedAtTime}

The \prov{startedAtTime} property is OPTIONAL and contains a DateTime (see~\ref{sec:DateTime}) value, indicating when the activity started.  If this property is present, then the \prov{endedAtTime} property is REQUIRED.

\subparagraph{The \sbolheading{prov:endedAtTime} property}\label{sec:prov:endedAtTime}

The \prov{endedAtTime} property is OPTIONAL and contains a DateTime (see~\ref{sec:DateTime}) value, indicating when the activity ended.

\subparagraph{The \sbolheading{prov:qualifiedAssociation} property}\label{sec:prov:qualifiedAssociation}

An \prov{Activity} MAY have one or more \prov{qualifiedAssociation} properties, each of type \sbol{IRI} that refers to an \prov{Association} object.

\subparagraph{The \sbolheading{prov:qualifiedUsage} property}\label{sec:prov:qualifiedUsage}

An \prov{Activity} MAY have one or more \prov{qualifiedUsage} properties, each of type \sbol{IRI} that refers to an \prov{Usage} object.

\subparagraph{The \sbolheading{prov:wasInformedBy} property}\label{sec:prov:wasInformedBy}

An \prov{Activity} MAY have one or more \prov{wasInformedBy} properties, each of type \sbol{IRI} that refers to another \prov{Activity} object.

\subsubsection{prov:Usage}
\label{sec:prov:Usage}

How different entities are used in an \prov{Activity} is specified with the \prov{Usage} class, which is linked from an \prov{Activity} through the \prov{Usage} relationship. A \prov{Usage} is then linked to an \prov{Entity} through the \prov{entity} property \sbol{IRI} and the \provmult{hadRole:U}{hadRole} property species how the \prov{Entity} is used.  When the \prov{wasDerivedFrom} property is used together with the full provenance described here, the entity pointed at by the \prov{wasDerivedFrom} property MUST be included in a \prov{Usage}.

\subparagraph{The \sbolheading{prov:entity} property}\label{sec:prov:entity}

The \prov{entity} property is REQUIRED and MUST contain a \sbol{IRI} which MAY refer to an \sbol{Identified} object.

\subparagraph{The \sbolheading{prov:hadRole} property}\label{sec:prov:hadRole:U}

An \prov{Usage} MAY have one or more \provmult{hadRole:U}{hadRole} properties, each of type \sbol{IRI} that refers to particular term(s) describing the usage of an \prov{Entity} referenced by the \prov{entity} property. Recommended terms that are defined in \ref{tbl:activity_types} can be used to indicate how the referenced \prov{Entity} is being used in this \prov{Activity}.

\subsubsection{prov:Association}
\label{sec:prov:Association}

An \prov{Association} is linked to an \prov{Agent} through the \prov{agent} relationship. The \prov{Association} includes the \provmult{hadRole:A}{hadRole} property to qualify the role of the \prov{Agent} in the \prov{Activity}.

\subparagraph{The \sbolheading{prov:agent} property}\label{sec:prov:agent}

The \prov{agent} property is REQUIRED and MUST contain a \sbol{IRI} that refers to an \prov{Agent} object.

\subparagraph{The \sbolheading{prov:hadRole} property}\label{sec:prov:hadRole:A}

An \prov{Association} MAY have one or more \provmult{hadRole:A}{hadRole} properties, each of type \sbol{IRI} that refers to particular term(s) that describes the role of the \prov{Agent} in the parent \prov{Activity}. 

\subparagraph{The \sbolheading{prov:hadPlan} property}\label{sec:prov:hadPlan}

The \prov{hadPlan} property is OPTIONAL and contains a \sbol{IRI} that refers to a \prov{Plan}.

\subsubsection{prov:Plan}
\label{sec:prov:Plan}

 The \prov{Plan} entity can be used as a place holder to describe the steps (for example scripts or lab protocols) taken when an \prov{Agent} is used in a particular \prov{Activity}.

\subsubsection{prov:Agent}
\label{sec:prov:Agent}

Examples of agents are a person, organization, or software tool.
These agents should be annotated with additional information, such as software version, needed to be able to run the same \prov{Activity} again.

\subparagraph{Example - Codon optimization}

Codon optimization is an example of where provenance properties can be applied.
The relationship between an original CDS and the codon-optimized version could simply be represented using the \prov{wasDerivedFrom} predicate, in a light-weight form. With more comprehensive use of the PROV ontology, the codon optimization can be represented as an \prov{Activity}. This \prov{Activity} can then include additional information, such as the \prov{Agent} responsible (in this case, codon-optimizing software), and additional parameters.

\subparagraph{Example - Deriving strains}

Bacterial strains are often derived from other strains through modifications such as gene knockouts or mutations. For example, the \textit{Bacillus subtilis} 168 strain was derived from the NCIMB3610 strain in the 1940s through x-radiation. \textit{B. subtilis} 168 is a laboratory strain and has several advantages as a model organism in synthetic biology.
The relationship between the original strain and the 168 strain can be represented using the \prov{wasDerivedFrom} predicate or, more comprehensively, with an \prov{Activity} describing the protocols used.

\subparagraph{Example - Design-build-test-learn Workflow}

\ref{images:design-build-test-learn} illustrates one complete iteration through a design-build-test-learn cycle.
The workflow begins with a \sbol{Model} which describes the hypothesized behavior of a biological device.
Using a computational tool, a new Design (\sbol{Component}) is composed from biological parts, which links back to its \sbol{Model}. A genetic construct is then produced in the laboratory via an assembly protocol, and this biological sample is represented by a Build (\sbol{Implementation}). Once constructed, the Build is then characterized in the laboratory using an automated measurement protocol on a Tecan plate reader, thus generating Test data (represented by an \sbol{ExperimentalData}). Finally, a new \sbol{Model} is derived from these data using a fitting algorithm implemented in the Python programming language. The final \sbol{Model} may not match the beginning \sbol{Model}, as the observed behavior may not match the prediction.

\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.75\linewidth]{uml/design-build-test}
\caption[]{An example data structure representing an idealized workflow for model-based design.}
\label{images:design-build-test-learn}
\end{center}
\end{figure}

%% proposed by issue #137
\clearpage

\subparagraph{Example - Combinatorial Derivation}

As specified in the description of \sbol{CombinatorialDerivation}, provenance can be used to link each generated \sbol{Component} (or \sbol{Collection} thereof) back to the source form which it was derived.
In particular, each derived design links with \prov{wasDerivedFrom} to the \sbol{CombinatorialDerivation} that it was derived from.  Also, each \sbol{SubComponent} has a \prov{wasDerivedFrom} linking it to the \sbol{SubComponent} within the \sbol{template} that it is derived from.  The advantage of these provenance links is that they provide sufficient information to validate that this derived design has been properly derived from the specified \sbol{CombinatorialDerivation}s.

\subsection{Adding Measures/Parameters with OM}
\label{sec:parameters}

There are at least two well-established cases for including measures/parameters and their associated units in SBOL design specifications. These use cases are the specification of genetic circuit designs and their associated parameters (such as rates of transcription) and the specification of environmental conditions for biological system designs (such as growth media concentrations and temperatures). In the first use case, parameters are necessary to enable the generation of quantitative models of circuit behavior from circuit design specifications. In the second use case, measures are necessary to define experimental conditions and enable the analysis of system behavior or characterization with respect to environmental context.

The Ontology of Units of Measure (OM) (\url{http://www.ontology-of-units-of-measure.org/resource/om-2}) already defines a data model for representing measures and their associated units. Here, a subset of OM is adopted by SBOL to describe these concepts for biological design specifications,
by assigning PROV-O classes to SBOL \sbol{Identified} or \sbol{TopLevel} types per  Section~\ref{sec:Annotations}.
%
As shown in \ref{uml:om}, SBOL leverages three of the base classes defined by the OM: \om{Measure}, \om{Unit} and \om{Prefix}. A \om{Measure} links a numerical value to a \om{Unit}, which may or may not have a \om{Prefix} (e.g. centi, milli, micro, etc.). As these classes are adopted by SBOL, \om{Measure} is treated as a subclass of \sbol{Identified}, while \om{Unit} and \om{Prefix} are treated as subclasses of \sbol{TopLevel}. In addition, SBOL adopts the following OM \om{Unit} subclasses: \om{SingularUnit}, \om{CompoundUnit}, \om{UnitMultiplication}, \om{UnitDivision}, \om{UnitExponentiation}, and \om{PrefixedUnit}. Lastly, SBOL adopts the following \om{Prefix} subclasses from OM: \om{SIPrefix} and \om{BinaryPrefix}.

OM also provides a large number of predefined \om{Unit} instances, so in most cases there is no need to create anything other than \om{Measure} objects that refer to pre-existing instances.
This can simplify the comparison and interpretation of units, so for this reason, a pre-existing \om{Unit} instance SHOULD be used whenever one is applicable.
If a unit does not already exist in the ontology, however, then the \om{Unit} subclasses MAY be used to create new units.


\begin{figure}[ht]
\begin{center}
\includegraphics[width=\linewidth]{uml/om}
\caption[]{OM classes adopted by SBOL and their subclass relationships to \sbol{Identified} and \sbol{TopLevel}}
\label{uml:om}
\end{center}
\end{figure}

SBOL-compliant tools are allowed to read, write, and modify data belonging to OM classes other than those described here, but this specification does not provide any guidance for the interpretation or use of these data in the context of SBOL.

\subsubsection{om:Measure} \label{sec:om:Measure}

The purpose of the \om{Measure} class is to link a numerical value to a \om{Unit}.

\subparagraph{The \sbolheading{om:hasNumericalValue} property}\label{sec:om:hasNumericalValue}
The \om{hasNumericalValue} property is REQUIRED and MUST contain a single xsd:float.

\subparagraph{The \sbolheading{om:hasUnit} property}\label{sec:om:hasUnit:Measure}
The \ommult{hasUnit:Measure}{hasUnit} property is REQUIRED and MUST contain a \sbol{IRI} that refers to a \om{Unit}. The OM provides \sbol{IRI}s for many existing instances of the \om{Unit} class for reference (for example,\\ \url{http://www.ontology-of-units-of-measure.org/resource/om-2/gramPerLitre}).

\subparagraph{The \sbolheading{type} property}\label{sec:type:Measure}

A \om{Measure} MAY have one or more \sbolmult{type:Measure}{type} properties, each is of type \sbol{IRI}. It is RECOMMENDED that one of these \sbol{IRI}s identify a term from the Systems Description Parameter branch of the Systems Biology Ontology (SBO) (\url{http://www.ebi.ac.uk/sbo/main/}). This \sbolmult{type:Measure}{type} property of the \om{Measure} class is not specified in the OM and is added by SBOL to describe different types of parameters 
(for example, rate of reaction is identified by the SBO term \url{http://identifiers.org/SBO:0000612}).

\subsubsection{om:Unit}
\label{sec:om:Unit}

As adopted by SBOL, \om{Unit} is an abstract class that is extended by other classes to describe units of measure using a shared set of properties.

\subparagraph{The \sbolheading{om:symbol} property}\label{sec:om:symbol:Unit}
The \ommult{symbol:Unit}{symbol} property is REQUIRED and MUST contain a \sbol{String}. This \sbol{String} is commonly used to abbreviate the unit of measure's name. For example, the unit of measure named ``gram per liter'' is commonly abbreviated using the \sbol{String} ``g/l''.

\subparagraph{The \sbolheading{om:alternativeSymbols} property}\label{sec:om:alternativeSymbols:Unit}
The \ommult{alternativeSymbols:Unit}{alternativeSymbols} property is OPTIONAL and MAY contain a set of \sbol{String}s. This property can be used to specify alternative abbreviations other than that specified using the \ommult{symbol:Unit}{symbol} property.

\subparagraph{The \sbolheading{om:label} property}\label{sec:om:label:Unit}
The \ommult{label:Unit}{label} property is REQUIRED and MUST contain a \sbol{String}. This \sbol{String} is a common name for the unit of measure and SHOULD be identical to any \sbol{String} contained by the \sbol{name} property inherited from \sbol{Identified}.

\subparagraph{The \sbolheading{om:alternativeLabels} property}\label{sec:om:alternativeLabels:Unit}
The \ommult{alternativeLabels:Unit}{alternativeLabels} property is OPTIONAL and MAY contain a set of \sbol{String}s. This property can be used to specify alternative common names other than that specified using the \ommult{label:Unit}{label} property.

\subparagraph{The \sbolheading{om:comment} property}\label{sec:om:comment:Unit}
The \ommult{comment:Unit}{comment} property is OPTIONAL and MAY contain a \sbol{String}. This \sbol{String} is a description of the unit of measure and SHOULD be identical to any \sbol{String} contained by the \sbol{description} property inherited from \sbol{Identified}.

\subparagraph{The \sbolheading{om:longcomment} property}\label{sec:om:longcomment:Unit}
The \ommult{longcomment:Unit}{longcomment} property is OPTIONAL and MAY contain a \sbol{String}. This \sbol{String} is a long description of the unit of measure and SHOULD be longer than any \sbol{String} contained by the \ommult{comment:Unit}{comment} property.

\subsubsection{om:SingularUnit}
\label{sec:om:SingularUnit}

The purpose of the \om{SingularUnit} class is to describe a unit of measure that is not explicitly represented as a combination of multiple units, but could be equivalent to such a representation. For example, a joule is considered to be a \om{SingularUnit}, but it is equivalent to the multiplication of a newton and a meter.

\subparagraph{The \sbolheading{om:hasUnit} property}\label{sec:om:hasUnit:SingularUnit}
The \ommult{hasUnit:SingularUnit}{hasUnit} is OPTIONAL and MAY contain a \sbol{IRI}. This \sbol{IRI} MUST refer to another \om{Unit}. The \ommult{hasUnit:SingularUnit}{hasUnit} propery can be used in conjunction with the \ommult{hasFactor:SingularUnit}{hasFactor} property to specify whether a \om{SingularUnit} is equivalent to another \om{Unit} multiplied by a factor. For example, an angstrom is equivalent to $10^{-10}$ meters.

\subparagraph{The \sbolheading{om:hasFactor} property}\label{sec:om:hasFactor:SingularUnit}
The \ommult{hasFactor:SingularUnit}{hasFactor} property is OPTIONAL and MAY contain a xsd:float. If the \ommult{hasFactor:SingularUnit}{hasFactor} property of a \om{SingularUnit} is non-empty, then its \ommult{hasUnit:SingularUnit}{hasUnit} property SHOULD also be non-empty.

\subsubsection{om:CompoundUnit}
\label{sec:om:CompoundUnit}

As adopted by SBOL, \om{CompoundUnit} is an abstract class that is extended by other classes to describe units of measure that can be represented as combinations of multiple other units of measure.

\subsubsection{om:UnitMultiplication}
\label{sec:om:UnitMultiplication}

The purpose of the \om{UnitMultiplication} class is to describe a unit of measure that is the multiplication of two other units of measure.

\subparagraph{The \sbolheading{om:hasTerm1} property}\label{sec:om:hasTerm1}
The \om{hasTerm1} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}. This \om{Unit} is the first multiplication term.

\subparagraph{The \sbolheading{om:hasTerm2} property}\label{sec:om:hasTerm2}
The \om{hasTerm2} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}. This \om{Unit} is the second multiplication term. It is okay if the \om{Unit} referred to by \om{hasTerm1} is the same as that referred to by \om{hasTerm2}.

\subsubsection{om:UnitDivision}
\label{sec:om:UnitDivision}

The purpose of the \om{UnitDivision} class is to describe a unit of measure that is the division of one unit of measure by another.

\subparagraph{The \sbolheading{om:hasNumerator} property}\label{sec:om:hasNumerator}
The \om{hasNumerator} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}.

\subparagraph{The \sbolheading{om:hasDenominator} property}\label{sec:om:hasDenominator}
The \om{hasDenominator} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}.

\subsubsection{om:UnitExponentiation}
\label{sec:om:UnitExponentiation}

The purpose of the \om{UnitExponentiation} class is to describe a unit of measure that is raised to an integer power.

\subparagraph{The \sbolheading{om:hasBase} property}\label{sec:om:hasBase}
The \om{hasBase} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}.

\subparagraph{The \sbolheading{om:hasExponent} property}\label{sec:om:hasExponent}
The \om{hasExponent} property is REQUIRED and MUST contain an \texttt{xsd:integer}.

\subsubsection{om:PrefixedUnit}
\label{sec:om:PrefixedUnit}

The purpose of the \om{PrefixedUnit} class is to describe a unit of measure that is the multiplication of another unit of measure and a factor represented by a standard prefix such as ``milli,'' ``centi,'' ``kilo,'' etc.

\subparagraph{The \sbolheading{om:hasUnit} property}\label{sec:om:hasUnit:PrefixedUnit}
The \ommult{hasUnit:PrefixedUnit}{hasUnit} property is REQUIRED and MUST contain a \sbol{IRI} that refers to another \om{Unit}. 

\subparagraph{The \sbolheading{om:hasPrefix} property}\label{sec:om:hasPrefix}
The \om{hasPrefix} property is REQUIRED and MUST contain a \sbol{IRI} that refers to a \om{Prefix}.

\subsubsection{om:Prefix}
\label{sec:om:Prefix}

As adopted by SBOL, \om{Prefix} is an abstract class that is extended by other classes to describe factors that are commonly represented by standard unit prefixes. For example, the factor $10^{-3}$ is represented by the standard unit prefix ``milli.''

\subparagraph{The \sbolheading{om:symbol} property}\label{sec:om:symbol:Prefix}
The \ommult{symbol:Prefix}{symbol} property is REQUIRED and MUST contain a \sbol{String}. This \sbol{String} is commonly used to abbreviate the name of the unit prefix. For example, the \sbol{String} ``m'' is commonly used to abbreviate the name ``milli.''

\subparagraph{The \sbolheading{om:alternativeSymbols} property}\label{sec:om:alternativeSymbols:Prefix}
The \ommult{alternativeSymbols:Prefix}{alternativeSymbols} property is OPTIONAL and MAY contain a set of \sbol{String}s. This property can be used to specify alternative abbreviations other than that specified using the \ommult{symbol:Prefix}{symbol} property.

\subparagraph{The \sbolheading{om:label} property}\label{sec:om:label:Prefix}
The \ommult{label:Prefix}{label} property is REQUIRED and MUST contain a \sbol{String}. This \sbol{String} is a common name for the unit prefix and SHOULD be identical to any \sbol{String} contained by the \sbol{name} property inherited from \sbol{Identified}.

\subparagraph{The \sbolheading{om:alternativeLabels} property}\label{sec:om:alternativeLabels:Prefix}
The \ommult{alternativeLabels:Prefix}{alternativeLabels} property is OPTIONAL and MAY contain a set of \sbol{String}s. This property can be used to specify alternative common names other than that specified using the \ommult{label:Prefix}{label} property.

\subparagraph{The \sbolheading{om:comment} property}\label{sec:om:comment:Prefix}
The \ommult{comment:Prefix}{comment} property is OPTIONAL and MAY contain a \sbol{String}. This \sbol{String} is a description of the unit prefix and SHOULD be identical to any \sbol{String} contained by the \sbol{description} property inherited from \sbol{Identified}.

\subparagraph{The \sbolheading{om:longcomment} property}\label{sec:om:longcomment:Prefix}
The \ommult{longcomment:Prefix}{longcomment} property is OPTIONAL and MAY contain a \sbol{String}. This \sbol{String} is a long description of the unit of measure and SHOULD be longer than any \sbol{String} contained by the \ommult{comment:Prefix}{comment} property.

\subparagraph{The \sbolheading{om:hasFactor} property}\label{sec:om:hasFactor:Prefix}
The \ommult{hasFactor:Prefix}{hasFactor} property is REQUIRED and MUST contain an xsd:float.

\subsubsection{om:SIPrefix}
\label{sec:om:SIPrefix}

The purpose of the \om{SIPrefix} class is to describe standard SI prefixes such as ``milli,'' ``centi,'' ``kilo,'' etc.

\subsubsection{om:BinaryPrefix}
\label{sec:om:BinaryPrefix}

The purpose of the \om{BinaryPrefix} class is to describe standard binary prefixes such as ``kibi,'' ``mebi,'' ``gibi,'' etc. These prefixes commonly precede units of information such as ``bit'' and ``byte.''

\begin{figure}[ht]
\begin{center}
\includegraphics[width=\linewidth]{uml/media_example}
\caption[]{Growth media recipe represented using instances of the \om{Measure} and \om{Unit} classes from the OM.}
\label{uml:media_example}
\end{center}
\end{figure}