diff --git a/apdx-validation.tex b/apdx-validation.tex index 1a9d1b06..2ccb2fee 100644 --- a/apdx-validation.tex +++ b/apdx-validation.tex @@ -376,6 +376,11 @@ \subsubsection*{Rules for the \class{ComponentInstance} class} \printValid{The \sbol{access} property of a \sbol{ComponentInstance} is REQUIRED and MUST contain a \sbol{URI} from \ref{tbl:componentInstance_access} \\ Reference: \sec{sec:ComponentInstance}} +\twothreezero{ +\printValid{The \sbolmult{measures:CI}{measures} property of a \sbol{ComponentInstance} is OPTIONAL and may contain a set of \sbol{Measure} objects. +\\ Reference: \sec{sec:ComponentInstance}} +} + \subsubsection*{Rules for the \class{Component} class} \setcounter{sbolCtr}{10701} @@ -707,6 +712,11 @@ \subsubsection*{Rules for the \class{Module} class} \printValid{The \sbolmult{mapsTos:M}{mapsTos} property is OPTIONAL and MAY contain a set of \sbol{MapsTo} objects.\\ Reference: \sec{sec:Module}} +\twothreezero{ +\printValid{The \sbolmult{measures:M}{measures} property of a \sbol{Module} is OPTIONAL and may contain a set of \sbol{Measure} objects. +\\ Reference: \sec{sec:Module}} +} + \subsubsection*{Rules for the \class{FunctionalComponent} class} \setcounter{sbolCtr}{11801} @@ -744,6 +754,11 @@ \subsubsection*{Rules for the \class{Interaction} class} Reference: \sec{sec:Participation}} } +\twothreezero{ +\printValid{The \sbolmult{measures:I}{measures} property of an \sbol{Interaction} is OPTIONAL and may contain a set of \sbol{Measure} objects. +\\ Reference: \sec{sec:Interaction}} +} + \subsubsection*{Rules for the \class{Participation} class} \setcounter{sbolCtr}{12001} @@ -768,6 +783,11 @@ \subsubsection*{Rules for the \class{Participation} class} \printModeling{Exactly one role in the set of \sbolmult{roles:P}{roles} SHOULD be a \sbol{URI} from the participant role branch of the SBO (see \ref{tbl:participant_roles}).\\ Reference: \sec{sec:Participation}} } +\twothreezero{ +\printValid{The \sbolmult{measures:P}{measures} property of a \sbol{Participation} is OPTIONAL and may contain a set of \sbol{Measure} objects. +\\ Reference: \sec{sec:Participation}} +} + \subsubsection*{Rules for the \class{Collection} class} \setcounter{sbolCtr}{12101} @@ -823,7 +843,7 @@ \subsubsection*{Rules for the \class{Activity} class} \setcounter{sbolCtr}{12401} \twothreezero{ -\printValid{An \sbol{Activity} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ \sbol{description}, \sbol{annotations}, \texttt{\hyperref[sec:activity_types]{types}}, \sbol{startedAtTime}, \sbol{endedAtTime}, \sbol{wasInformedBys},\\ \sbol{usages}, and \sbol{associations}.\\ Reference: \sec{sec:Activity}} +\printValid{An \sbol{Activity} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ \sbol{description}, \sbol{annotations}, \sbolmult{types:Activity}{types}, \sbol{startedAtTime}, \sbol{endedAtTime}, \sbol{wasInformedBys},\\ \sbol{usages}, and \sbol{associations}.\\ Reference: \sec{sec:Activity}} } \printValid{The \sbol{startedAtTime} property of an \sbol{Activity} object is OPTIONAL and MAY contain a\\ @@ -854,7 +874,7 @@ \subsubsection*{Rules for the \class{Activity} class} \twothreezero{ %% EO: using the \hyperref here due to the specification of the \sbol command and the "types" property that appears in ComponentDefinition and Activity. -\printValid{The \texttt{\hyperref[sec:activity_types]{types}} property of an \sbol{Activity} object is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:Activity}} +\printValid{The \sbolmult{types:Activity}{types} property of an \sbol{Activity} object is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:Activity}} \printModeling{If an \sbol{Activity} has a types value of ~\url{http://sbols.org/v2\#design} and also contains an \sbol{Association}, then that \sbol{Association} MUST have a roles value of ~\url{http://sbols.org/v2\#design}. \\ Reference: \sec{sec:Activity}} \printModeling{If an \sbol{Activity} has a types value of ~\url{http://sbols.org/v2\#build} and also contains an \sbol{Association}, then that \sbol{Association} MUST have a roles value of ~\url{http://sbols.org/v2\#build}. \\ Reference: \sec{sec:Activity}} \printModeling{If an \sbol{Activity} has a types value of ~\url{http://sbols.org/v2\#test} and also contains an \\ @@ -1126,3 +1146,201 @@ \subsubsection*{Rules for the \class{Experiment} class} \printComplete{The \sbol{URI}s contained by the \sbol{experimentalData} property of a \sbol{Experiment} MUST each refer to an \sbol{ExperimentalData}. \\ Reference: \sec{sec:Experiment}} } + +\twothreezero{ +\subsubsection*{Rules for the \class{Measure} class} +\setcounter{sbolCtr}{13501} + +\printValid{A \sbol{Measure} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{hasNumericalValue}, \sbolmult{hasUnit:Measure}{hasUnit}, and \sbolmult{types:Measure}{types}.\\ Reference: \sec{sec:Measure}} + +\printValid{The \sbol{hasNumericalValue} property of a \sbol{Measure} is REQUIRED and MUST contain an xsd:float.\\ Reference: \sec{sec:Measure}} + +\printValid{The \sbolmult{hasUnit:Measure}{hasUnit} property of a \sbol{Measure} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:Measure}} + +\printValid{The \sbolmult{types:Measure}{types} property of a \sbol{Measure} is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:Measure}} + +\printModeling{If the \sbolmult{types:Measure}{types} property of a \sbol{Measure} is non-empty, then exactly one of the \sbol{URI}s that this property contains SHOULD refer to a term from the systems description parameter branch of the SBO.\\ Reference: \sec{sec:Measure}} + +\printComplete{The \sbol{URI} contained by the \sbolmult{hasUnit:Measure}{hasUnit} property of a \sbol{Measure} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:Measure}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{Unit} class} +\setcounter{sbolCtr}{13601} + +\printValid{The \sbolmult{symbol:Unit}{symbol} property of a \sbol{Unit} is REQUIRED and MUST contain a \sbol{String}.\\ Reference: \sec{sec:Unit}} + +\printValid{The \sbolmult{alternativeSymbols:Unit}{alternativeSymbols} property of a \sbol{Unit} is OPTIONAL and MAY contain a set of \sbol{String}s.\\ Reference: \sec{sec:Unit}} + +\printValid{The \sbolmult{label:Unit}{label} property of a \sbol{Unit} is REQUIRED and MUST contain a \sbol{String}.\\ Reference: \sec{sec:Unit}} + +\printValid{The \sbolmult{alternativeLabels:Unit}{alternativeLabels} property of a \sbol{Unit} is OPTIONAL and MAY contain a set of \sbol{String}s.\\ Reference: \sec{sec:Unit}} + +\printValid{The \sbolmult{comment:Unit}{comment} property of a \sbol{Unit} is OPTIONAL and MAY contain a \sbol{String}.\\ Reference: \sec{sec:Unit}} + +\printValid{The \sbolmult{longcomment:Unit}{longcomment} property of a \sbol{Unit} is OPTIONAL and MAY contain a \sbol{String}.\\ Reference: \sec{sec:Unit}} + +\printModeling{If both of the \sbol{name} property and \sbolmult{label:Unit}{label} properties of a \sbol{Unit} are non-empty, then they SHOULD contain identical \sbol{String}s.\\ Reference: \sec{sec:Unit}} + +\printModeling{If both of the \sbol{description} property and \sbolmult{comment:Unit}{comment} properties of a \sbol{Unit} are non-empty, then they SHOULD contain identical \sbol{String}s.\\ Reference: \sec{sec:Unit}} + +\printModeling{If both of the \sbolmult{comment:Unit}{comment} property and \sbolmult{longcomment:Unit}{longcomment} properties of a \sbol{Unit} are non-empty, then the \sbol{String} contained by the \sbolmult{longcomment:Unit}{longcomment} property SHOULD be longer than the \sbol{String} contained by the \sbolmult{comment:Unit}{comment} property.\\ Reference: \sec{sec:Unit}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{SingularUnit} class} +\setcounter{sbolCtr}{13701} + +\printValid{A \sbol{SingularUnit} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Unit}{symbol}, \sbolmult{alternativeSymbols:Unit}{alternativeSymbols}, \sbolmult{label:Unit}{label},\\ +\sbolmult{alternativeLabels:Unit}{alternativeLabels}, \sbolmult{comment:Unit}{comment}, \sbolmult{longcomment:Unit}{longcomment}, \sbolmult{hasUnit:SingularUnit}{hasUnit}, and \sbolmult{hasFactor:SingularUnit}{hasFactor}.\\ Reference: \sec{sec:SingularUnit}} + +\printValid{The \sbolmult{hasUnit:SingularUnit}{hasUnit} property of a \sbol{SingularUnit} is OPTIONAL and MAY contain a \sbol{URI}.\\ Reference: \sec{sec:SingularUnit}} + +\printValid{The \sbolmult{hasFactor:SingularUnit}{hasFactor} property of a \sbol{SingularUnit} is OPTIONAL and MAY contain an xsd:float.\\ Reference: \sec{sec:SingularUnit}} + +\printValid{Any \sbol{URI} contained by the \sbolmult{hasUnit:SingularUnit}{hasUnit} property of a \sbol{SingularUnit} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:SingularUnit}} + +\printModeling{If the \sbolmult{hasFactor:SingularUnit}{hasFactor} property of a \sbol{SingularUnit} is non-empty, then its \sbolmult{hasUnit:SingularUnit}{hasUnit} property \\SHOULD also be non-empty.\\ Reference: \sec{sec:SingularUnit}} + +\printComplete{The \sbol{URI} contained by the \sbolmult{hasUnit:SingularUnit}{hasUnit} property of a \sbol{SingularUnit} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:SingularUnit}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{UnitMultiplication} class} +\setcounter{sbolCtr}{13801} + +\printValid{A \sbol{UnitMultiplication} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Unit}{symbol}, \sbolmult{alternativeSymbols:Unit}{alternativeSymbols}, \sbolmult{label:Unit}{label},\\ +\sbolmult{alternativeLabels:Unit}{alternativeLabels}, \sbolmult{comment:Unit}{comment}, \sbolmult{longcomment:Unit}{longcomment}, \sbol{hasTerm1}, and \sbol{hasTerm2}.\\ Reference: \sec{sec:UnitMultiplication}} + +\printValid{The \sbol{hasTerm1} property of a \sbol{UnitMultiplication} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:UnitMultiplication}} + +\printValid{The \sbol{hasTerm2} property of a \sbol{UnitMultiplication} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:UnitMultiplication}} + +\printValid{The \sbol{URI} contained by the \sbol{hasTerm1} property of a \sbol{UnitMultiplication} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:UnitMultiplication}} + +\printValid{The \sbol{URI} contained by the \sbol{hasTerm2} property of a \sbol{UnitMultiplication} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:UnitMultiplication}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasTerm1} property of a \sbol{UnitMultiplication} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:UnitMultiplication}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasTerm2} property of a \sbol{UnitMultiplication} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:UnitMultiplication}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{UnitDivision} class} +\setcounter{sbolCtr}{14001} + +\printValid{A \sbol{UnitDivision} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Unit}{symbol}, \sbolmult{alternativeSymbols:Unit}{alternativeSymbols}, \sbolmult{label:Unit}{label},\\ +\sbolmult{alternativeLabels:Unit}{alternativeLabels}, \sbolmult{comment:Unit}{comment}, \sbolmult{longcomment:Unit}{longcomment}, \sbol{hasNumerator}, and \sbol{hasDenominator}.\\ Reference: \sec{sec:UnitDivision}} + +\printValid{The \sbol{hasNumerator} property of a \sbol{UnitDivision} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:UnitDivision}} + +\printValid{The \sbol{hasDenominator} property of a \sbol{UnitDivision} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:UnitDivision}} + +\printValid{The \sbol{URI} contained by the \sbol{hasNumerator} property of a \sbol{UnitDivision} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:UnitDivision}} + +\printValid{The \sbol{URI} contained by the \sbol{hasDenominator} property of a \sbol{UnitDivision} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:UnitDivision}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasNumerator} property of a \sbol{UnitDivision} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:UnitDivision}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasDenominator} property of a \sbol{UnitDivision} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:UnitDivision}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{UnitExponentiation} class} +\setcounter{sbolCtr}{14101} + +\printValid{A \sbol{UnitExponentiation} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Unit}{symbol}, \sbolmult{alternativeSymbols:Unit}{alternativeSymbols}, \sbolmult{label:Unit}{label},\\ +\sbolmult{alternativeLabels:Unit}{alternativeLabels}, \sbolmult{comment:Unit}{comment}, \sbolmult{longcomment:Unit}{longcomment}, \sbol{hasBase}, and \sbol{hasExponent}.\\ Reference: \sec{sec:UnitExponentiation}} + +\printValid{The \sbol{hasBase} property of a \sbol{UnitExponentiation} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:UnitExponentiation}} + +\printValid{The \sbol{hasExponent} property of a \sbol{UnitExponentiation} is REQUIRED and MUST contain an xsd:integer.\\ Reference: \sec{sec:UnitExponentiation}} + +\printValid{The \sbol{URI} contained by the \sbol{hasBase} property of a \sbol{UnitExponentiation} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:UnitExponentiation}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasBase} property of a \sbol{UnitExponentiation} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:UnitExponentiation}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{PrefixedUnit} class} +\setcounter{sbolCtr}{14201} + +\printValid{A \sbol{PrefixedUnit} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Unit}{symbol}, \sbolmult{alternativeSymbols:Unit}{alternativeSymbols}, \sbolmult{label:Unit}{label},\\ +\sbolmult{alternativeLabels:Unit}{alternativeLabels}, \sbolmult{comment:Unit}{comment}, \sbolmult{longcomment:Unit}{longcomment}, \sbolmult{hasUnit:PrefixedUnit}{hasUnit}, and \sbol{hasPrefix}.\\ Reference: \sec{sec:PrefixedUnit}} + +\printValid{The \sbolmult{hasUnit:PrefixedUnit}{hasUnit} property of a \sbol{PrefixedUnit} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:PrefixedUnit}} + +\printValid{The \sbol{hasPrefix} property of a \sbol{PrefixedUnit} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:PrefixedUnit}} + +\printValid{The \sbol{URI} contained by the \sbolmult{hasUnit:PrefixedUnit}{hasUnit} property of a \sbol{PrefixedUnit} MUST NOT be identical to the \sbol{URI} contained by its \sbol{identity} property.\\ Reference: \sec{sec:PrefixedUnit}} + +\printComplete{The \sbol{URI} contained by the \sbolmult{hasUnit:PrefixedUnit}{hasUnit} property of a \sbol{PrefixedUnit} MUST refer to a \sbol{Unit}. +\\ Reference: \sec{sec:PrefixedUnit}} + +\printComplete{The \sbol{URI} contained by the \sbol{hasPrefix} property of a \sbol{PrefixedUnit} MUST refer to a \sbol{Prefix}. +\\ Reference: \sec{sec:PrefixedUnit}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{Prefix} class} +\setcounter{sbolCtr}{14301} + +\printValid{The \sbolmult{symbol:Prefix}{symbol} property of a \sbol{Prefix} is REQUIRED and MUST contain a \sbol{String}.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{alternativeSymbols:Prefix}{alternativeSymbols} property of a \sbol{Prefix} is OPTIONAL and MAY contain a set of \sbol{String}s.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{label:Prefix}{label} property of a \sbol{Prefix} is REQUIRED and MUST contain a \sbol{String}.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{alternativeLabels:Prefix}{alternativeLabels} property of a \sbol{Prefix} is OPTIONAL and MAY contain a set of \sbol{String}s.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{comment:Prefix}{comment} property of a \sbol{Prefix} is OPTIONAL and MAY contain a \sbol{String}.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{longcomment:Prefix}{longcomment} property of a \sbol{Prefix} is OPTIONAL and MAY contain a \sbol{String}.\\ Reference: \sec{sec:Prefix}} + +\printValid{The \sbolmult{hasFactor:Prefix}{hasFactor} property of a \sbol{Prefix} is REQUIRED and MUST contain an xsd:float.\\ Reference: \sec{sec:Prefix}} + +\printModeling{If both of the \sbol{name} property and \sbolmult{label:Prefix}{label} properties of a \sbol{Prefix} are non-empty, then they SHOULD contain identical \sbol{String}s.\\ Reference: \sec{sec:Prefix}} + +\printModeling{If both of the \sbol{description} property and \sbolmult{comment:Prefix}{comment} properties of a \sbol{Prefix} are non-empty, then they SHOULD contain identical \sbol{String}s.\\ Reference: \sec{sec:Prefix}} + +\printModeling{If both of the \sbolmult{comment:Prefix}{comment} property and \sbolmult{longcomment:Prefix}{longcomment} properties of a \sbol{Prefix} are non-empty, then the \sbol{String} contained by the \sbolmult{longcomment:Prefix}{longcomment} property SHOULD be longer than the \sbol{String} contained by the \sbolmult{comment:Prefix}{comment} property.\\ Reference: \sec{sec:Prefix}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{SIPrefix} class} +\setcounter{sbolCtr}{14401} + +\printValid{A \sbol{SIPrefix} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Prefix}{symbol}, \sbolmult{alternativeSymbols:Prefix}{alternativeSymbols}, \sbolmult{label:Prefix}{label},\\ +\sbolmult{alternativeLabels:Prefix}{alternativeLabels}, \sbolmult{comment:Prefix}{comment}, \sbolmult{longcomment:Prefix}{longcomment}, and \sbolmult{hasFactor:Prefix}{hasFactor}.\\ Reference: \sec{sec:SIPrefix}} +} + +\twothreezero{ +\subsubsection*{Rules for the \class{BinaryPrefix} class} +\setcounter{sbolCtr}{14501} + +\printValid{A \sbol{BinaryPrefix} MUST NOT have properties other than the following: \sbol{identity}, \\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ +\sbol{description}, \sbol{annotations}, \sbol{attachments}, \sbolmult{symbol:Prefix}{symbol}, \sbolmult{alternativeSymbols:Prefix}{alternativeSymbols}, \sbolmult{label:Prefix}{label},\\ +\sbolmult{alternativeLabels:Prefix}{alternativeLabels}, \sbolmult{comment:Prefix}{comment}, \sbolmult{longcomment:Prefix}{longcomment}, and \sbolmult{hasFactor:Prefix}{hasFactor}.\\ Reference: \sec{sec:BinaryPrefix}} +} diff --git a/complementary_standards.tex b/complementary_standards.tex new file mode 100644 index 00000000..e6918c84 --- /dev/null +++ b/complementary_standards.tex @@ -0,0 +1,1554 @@ +% ----------------------------------------------------------------------------- +\section{Complementary Standards} +\label{sec:complementaryStandards} +% ----------------------------------------------------------------------------- +\twoonezero{\subsection{Adding Provenance with PROV-O} +\label{sec:provenance} +\label{sec:wasGeneratedBys} + +\vspace{-7pt} +\-\hspace{0.8cm}[New in 2.1.0; see SEP 009: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_009.md}] + +Provenance is central to a range of 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. + +The PROV-O ontology (\url{https://www.w3.org/TR/prov-o/}) already defines a data model for provenance. PROV-O's \sbol{wasDerivedFroms} property was adopted in SBOL 2.x to describe the derivation of an SBOL entity from another in a light-weight provenance scheme. Here, a subset of PROV-O is adopted for SBOL as a best practice to describe these activities in more detail\footnote{We thank Dr Paolo Missier from the School of Computing Science, Newcastle University for discussions regarding the use of PROV-O.}. PROV-O defines three core classes: \texttt{Entity}, \texttt{Activity} and \texttt{Agent}. An Agent (for example a software or a person) runs an Activity (according to a Plan) to generate one Entity from another. Although, PROV-O provides many other classes and rich set of terms. this specification describes the minimal subset of PROV-O that a provenance-aware SBOL tool should handle. This subset (\ref{uml:provenance}) includes the PROV-O's \sbol{Activity}, \sbol{Usage}, \sbol{Association}, \sbol{Agent} and \sbol{Plan} classes. Any SBOL's \sbol{Identified} object implicitly can act as an instance of PROV-O's \texttt{Entity} class and can include provenance through relationships to different activities. Resources representing \sbol{Agent}, \sbol{Activity} and \sbol{Plan} classes should be handled as \sbol{GenericTopLevel}, whilst \sbol{Usage} and \sbol{Association} resources should be nested within their parent activities. + +%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 Figure \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 ComponentDefinition may be derived from another ComponentDefinition, but it would probably not make sense for it to be derived from a Collection. +} + +\twotwozero{ +The PROV-O specification permits that any kind of SBOL object may be used to generate another. The meaning of these relationships are specified using ontology terms for the \sbolmult{roles:U}{roles} properties on \sbol{Usage} and \sbol{Association} classes. This specification gives users the flexibility to construct and track provenance histories for their own custom applications, but this flexibility also presents an obstacle to standardized data exchange. Therefore a simple ontology (see \ref{tbl:association_roles} and \ref{tbl:usage_roles}) has been adopted to describe common provenance connections expected in synthetic biology workflows, based on the design-build-test-learn formalization of engineering. + +The design-build-test-learn cycle is a common theme in synthetic biology and engineering literature. The design-build-test-learn cycle is the scientific method applied to engineering. Stages of the cycle include designing an initial prototype, testing that prototype, analyzing its performance against specific metrics, learning what worked and what did not work, designing a new prototype based on what was learned, and completing the cycle again. Ideally each iteration of the cycle generates new understanding that feeds back into new cycles as alternative approaches or reformulated problems. Therefore, the design-build-test-learn cycle is a \textit{de facto} ontology upon which to base an SBOL data model for workflow abstraction. Other workflow activities in synthetic biology, such as analyzing, modeling, verifying, and evolving, by and large should fit into this design-build-test-learn abstraction. + +It is expected that users will develop their own ontology terms to specify how SBOL objects are used in a recipe, protocol, or computational analysis. However, these home-made ontologies will be very domain specific, and may not be intelligible to users working in another domain. For example a modeler should not be expected to understand an ontology of \sbol{Usage} \sbolmult{roles:U}{roles} for DNA assembly. The terms ``design'', ``build'', ``test'', and ``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. An example of how these terms are used is provided in \ref{images:design-build-test-learn}. + +Provenance semantics defined through \sbol{wasGeneratedBys} relationships are distinctly different from versioning semantics. 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 semantics are somewhat different from the versioning semantics defined in section \ref{sec:version}. The SBOL specification defines a new version of an object as an update of a previously published object (and therefore a previously existing object). Therefore, an SBOL object which is ``generated'' from another SHOULD BE regarded as a new entity rather than a new version of an existing entity. However, this distinction is somewhat subjective (see Theseus's paradox). Therefore, we RECOMMEND as a best practice that objects linked by Activities not be successive versions of each other, though this is left to the discretion of users and library developers. +} + +\twotwozero{ +\begin{figure}[ht] +\begin{center} +\includegraphics[scale=0.6]{uml/provenance} +\caption[]{Relationships between SBOL and PROV-O classes. The PROV-O classes \external{Activity}, \external{Plan}, and \external{Agent} are all serialized as \sbol{TopLevel} classes in an SBOL document. +\label{uml:provenance}} +\end{center} +\end{figure} +} + +\twoonezero{ +\subsubsection{Activity} +\label{sec:Activity} + +A generated \texttt{Entity} is linked through a \texttt{wasGeneratedBy} relationship to an \sbol{Activity}, which is used to describe how different \sbol{Agent}s and other entities were used. An \sbol{Activity} is linked through a \sbol{associations} to \sbol{Association}s, to describe the role of agents, and is linked through \sbol{usages} to \sbol{Usage}s to describe the role of other entities used as part of the activity. Moreover, each \sbol{Activity} includes optional startedAtTime and endedAtTime properties. When using \sbol{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 \sbol{wasInformedBys} relationship to provide dependency without explicitly specifying start and end times. + +\twothreezero{ +\paragraph{The \sbolheading{types} property}\label{sec:types:Activity} +The \sbolmult{types:Activity}{types} property is an OPTIONAL set of \sbol{URI}s that explicitly specify the type of the provenance \sbol{Activity} in more detail. If specified, it is RECOMMENDED that at least one \sbol{URI} of the \sbolmult{types:Activity}{types} property of an \sbol{Activity} refers to a \sbol{URI} from \ref{tbl:activity_types}. +} + +\begin{table}[ht] + \begin{edtable}{tabular}{ll} + \toprule + \textbf{Activity Type} & \textbf{URI} \\ + \midrule + Design & \url{http://sbols.org/v2\#design}\\ + Build & \url{http://sbols.org/v2\#build}\\ + Test & \url{http://sbols.org/v2\#test}\\ + Learn & \url{http://sbols.org/v2\#learn}\\ + \bottomrule + \end{edtable} + \caption{URIs to specify the \sbolmult{types:Activity}{types} property of an \sbol{Activity}.} + \label{tbl:activity_types} +\end{table} + +\paragraph{The \sbolheading{startedAtTime} property}\label{sec:startedAtTime} +The \sbol{startedAtTime} property is OPTIONAL and contains a DateTime (see section \ref{sec:DateTime}) value, indicating when the activity started. If this property is present, then the \sbol{endedAtTime} property is REQUIRED. + +\paragraph{The \sbolheading{endedAtTime} property}\label{sec:endedAtTime} +The \sbol{endedAtTime} property is OPTIONAL and contains a DateTime (see section \ref{sec:DateTime}) value, indicating when the activity ended. + +\paragraph{The \sbolheading{associations} property}\label{sec:associations} +The \sbol{associations} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to \sbol{Association} objects. + +\paragraph{The \sbolheading{usages} property}\label{sec:usages} +The \sbol{usages} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to \sbol{Usage} objects. + +\paragraph{The \sbolheading{wasInformedBys} property}\label{sec:wasInformedBys} +The \sbol{wasInformedBys} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to other \sbol{Activity} objects. +} + +\twothreezero{ +\paragraph{Serialization} +The serialization of an \sbol{Activity} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from identified}] ... + [\emph{zero or more}] + ... + [\emph{elements}] + [\emph{zero or more}] + ... + [\emph{elements}] + [\emph{zero or more}] [\emph{elements}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or more}] [\emph{element}] + +\end{lstlisting} + +\twotwozero{ +Note that the tags prov:qualifiedUsage and prov:qualifiedAssociation are used for \sbol{usages} and \sbol{associations}, respectively. +} + +\twoonezero{ +\subsubsection{Usage} +\label{sec:Usage} +How different entities are used in an \sbol{Activity} is specified with the \sbol{Usage} class, which is linked from an \sbol{Activity} through the \sbol{Usage} relationship. A \sbol{Usage} is then linked to an \texttt{Entity} through the \texttt{Entity}'s \sbol{URI} and the role of this entity is qualified with the \sbolmult{roles:U}{roles} property. When the \sbol{wasDerivedFroms} property is used together with the full provenance described here, the entity pointed at by the \sbol{wasDerivedFroms} property MUST be included in a \sbol{Usage}. + + +\paragraph{The \sbolheading{entity} property}\label{sec:entity} +The \sbol{entity} property is REQUIRED and MUST contain a \sbol{URI} which MAY refer to an SBOL Identified object. + +\paragraph{The \sbolheading{roles} property}\label{sec:roles:U} +\twotwozero{ +The \sbolmult{roles:U}{roles} property is an OPTIONAL set of \sbol{URI}s that refer to particular term(s) describing the usage of an \sbol{entity} referenced by the \sbol{entity} property. Recommended terms that are defined in \ref{tbl:usage_roles} can be used to indicate how the referenced \sbol{entity} is being used in this \sbol{Activity}. +} +} + +\twotwozero{ +\begin{table}[H] + \begin{edtable}{tabular}{lp{3.75in}} + \toprule + \textbf{URI for Usage roles} & \textbf{Description} \\ + \midrule + \url{http://sbols.org/v2\#design} & Design describes the process by which a conceptual representation of an engineer's imagined and intended design for a biological system is derived, possibly from a predictive model or by modifying a pre-existing design. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous design \sbol{Activity} and was used by the present \sbol{Activity} as a design for a new object.\\ + \url{http://sbols.org/v2\#build} & Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous build \sbol{Activity} and was used by the present \sbol{Activity} as a built object.\\ + \url{http://sbols.org/v2\#test} & Test describes the process of performing experimental measurements to characterize a synthetic biological construct. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous test \sbol{Activity} and is used as test data in the present \sbol{Activity}.\\ + \url{http://sbols.org/v2\#learn} & Learn describes the process of analyzing experimental measurements to produce a new entity that represents biological knowledge. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous learn \sbol{Activity} and is used in the present \sbol{Activity} as a source of scientifically verified knowledge.\\ + \bottomrule + \end{edtable} + \caption{Terms to specify the \sbolmult{roles:U}{roles} property of a \sbol{Usage}.} + \label{tbl:usage_roles} +\end{table} +} + + + +\twoonezero{ +\subsubsection{Association} +\label{sec:Association} +An \sbol{Association} is linked to an \sbol{Agent} through the \sbol{agent} relationship. The \sbol{Association} includes the \sbolmult{roles:A}{roles} property to qualify the role of the \sbol{Agent} in the \sbol{Activity}. + +\paragraph{The \sbolheading{agent} property}\label{sec:agent} +The \sbol{agent} property is REQUIRED and MUST contain a \sbol{URI} that refers to an \sbol{Agent} object. + +\paragraph{The \sbolheading{roles} property}\label{sec:roles:A} +\twotwozero{ +The \sbolmult{roles:A}{roles} property is an OPTIONAL set of \sbol{URI}s that refers to particular term(s) that describes the the role of the \sbol{agent} in the parent \sbol{Activity}. +The recommended terms that are defined in \ref{tbl:association_roles} can be used to specify the kind of \sbol{Activity} performed by the \sbol{Agent}. +} +} + +\twothreezero{ +\begin{table}[H] + \begin{edtable}{tabular}{lp{3.75in}} + \toprule + \textbf{URI for Association roles} & \textbf{Description} \\ + \midrule + \url{http://sbols.org/v2\#design} & Design describes the process by which a conceptual representation of an engineer's imagined and intended design for a biological system is derived, possibly from a predictive model or by modifying a pre-existing design. In the context of an \sbol{Association}, the term design indicates that the \sbol{Agent} performed the parent \sbol{Activity} to generate a design.\\ + \url{http://sbols.org/v2\#build} & Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory. In the context of an \sbol{Association}, the term build indicates that the \sbol{Agent} performed the parent \sbol{Activity} to implement a design. More generally, the term may represent any kind of experimental manipulation of a biological sample, including propagating, passaging, or evolving cell lines.\\ + \url{http://sbols.org/v2\#test} & Test describes the process of performing experimental measurements to characterize a synthetic biological construct. In the context of an \sbol{Association}, the \sbol{Agent} performed the parent \sbol{Activity} to perform experimental measurements resulting in raw data represented by an \sbol{ExperimentalData}.\\ + \url{http://sbols.org/v2\#learn} & Learn describes the process of analyzing the experimental measurements in order to produce a new entity that represents biological knowledge. In the context of an \sbol{Association}, the \sbol{Agent} processed the raw experimental data to produce an analysis. This process generates a new entity that represents biological knowledge, including tables or graphs referenced by the \sbol{Attachment}s of an \sbol{ExperimentalData}, a \sbol{Model} produced by a fitting process, a consensus \sbol{Sequence} derived from sequencing results, etc.\\ + \bottomrule + \end{edtable} + \caption{Terms to specify the \sbolmult{roles:A}{roles} property of an \sbol{Association}.} + \label{tbl:association_roles} +\end{table} +} + +\twoonezero{ +\paragraph{The \sbolheading{plan} property}\label{sec:plan} +The \sbol{plan} property is OPTIONAL and contains a \sbol{URI} that refers to a \sbol{Plan}. + +\paragraph{Serialization} +The serialization of an \sbol{Association} MUST have the following form: + +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from identified}] ... + [\emph{zero or more}] [\emph{element}] + [\emph{zero or one}] [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +\twotwozero{ +Note that the tags prov:hadRole and prov:hadPlan are used for \sbolmult{roles:A}{roles} and \sbol{plan}, respectively. +} + +\subsubsection{Plan} +\label{sec:Plan} +\twoonezero{ + The Plan entity can be used as a place holder to describe the steps (for example scripts or lab protocols) taken when an \sbol{Agent} is used in a particular \sbol{Activity}. + +\paragraph{Serialization} +The serialization of an \sbol{Usage} MUST have the following form: + +}%\twoonezero{ end + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from identified}] ... + ... [\emph{other annotations}] ... + +\end{lstlisting} + +\subsubsection{Agent} +\label{sec:Agent} +\twoonezero{ + Examples of agents are person, organization or software. These agents should be annotated with additional information, such as software version, needed to be able to run the same software again. + +\paragraph{Serialization} +The serialization of an \sbol{Agent} MUST have the following form: + +}%\twoonezero{ end + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from identified}] ... + ... [\emph{other annotations}] ... + +\end{lstlisting} + + +\paragraph{Example - Codon optimization} +\twoonezero{ + Codon optimization is a practical real-wold example where provenance properties can be applied. Using the current specification, 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 \sbol{Activity}. This \sbol{Activity} can then include additional information, such as the \sbol{Agent} responsible (in this case, codon-optimizing software), and additional parameters. + +}%\twoonezero{ end + +\lstsetsbol +\begin{lstlisting} + + + + + codon_optimized + + + Codon optimized CDS + + + + + + non_codon_optimized + Non Codon optimized CDS + + + + + + codon_optimization_activity + Codon Optimization Activity + + + + association + + + + + + + + usage + + + + + + + + codon_optimization_software + Codon Optimization Software + + +\end{lstlisting} + +\paragraph{Example - Deriving strains} +\twoonezero{ + Bacterial strains are often derived from other strains through modifications such as gene knockouts or mutations. For example, the \texttt{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. Particularly, the 168 strain is easy to transform and is not motile, facilitating the analysis of engineered cells. The parent strain, on the other hand, is motile but more difficult to transform. The example below shows the derivation of the 168 strain using the new provenance classes. + +}%twoonezero end + +\lstsetsbol +\begin{lstlisting} + + + + + bsubtilisncimb3610 + Bacillus subtilis NCIMB3610 + + + + + + bsubtilis168 + + + Bacillus subtilis 168 + + + + + + xraymutagenesis + X-ray mutagenesis + + + + association + + + + + + + + usage + + + + + + + + x_ray + X-ray + + +\end{lstlisting} + +\paragraph{Example - Design-build-test-learn Workflow} +\twothreezero{ + This particular example represents an idealized workflow for model-based design. The workflow begins with a \sbol{Model} which describes the hypothesized behavior of a biological device. Using a computational tool, a new Design (\sbol{ModuleDefinition}) is composed of 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 some 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. This example illustrates one complete iteration through a design-build-test-learn cycle, as shown in \ref{images:design-build-test-learn}. +}%twotwozero end + +\begin{figure}[ht] +\begin{center} +\includegraphics[width=\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 + +\twotwoone{} +\lstsetsbol +\begin{lstlisting} + + + + Activity_build_generation + + 1.0.0 + + + build_generation_association + + 1.0.0 + + + + + + + + design_usage + + 1.0.0 + + + + + + + Activity_design_generation + + 1.0.0 + + + design_generation_association + + 1.0.0 + + + + + + + + predicted_usage + + 1.0.0 + + + + + + + Activity_fit_model_generation + + 1.0.0 + + + fit_model_generation_association + + 1.0.0 + + + + + + + + raw_data_usage + + 1.0.0 + + + + + + + Activity_raw_data_generation + + 1.0.0 + + + raw_data_generation_association + + 1.0.0 + + + + + + + + build_usage + + 1.0.0 + + + + + + + Attachment_characterization_protocol + + + 1.0.0 + + + Attachment_model_fitting_script + + + + 1.0.0 + + + ExperimentalData_raw_data + + + 1.0.0 + + + + + Attachment_raw_data + + + + 1.0.0 + + + Implementation_build + + 1.0.0 + + + + + Model_fit_model + + + + + 1.0.0 + + + + + Model_predicted + + + + + 1.0.0 + + + ModuleDefinition_design + + 1.0.0 + + + + + + Plan_characterization_protocol + + 1.0.0 + + + SBML to SBOL conversion + Plan_conversion + + 1.0.0 + + + DNA assembly + Plan_gibson_assembly + + 1.0.0 + + + + Plan_model_fitting + + 1.0.0 + + + + 1.0.0 + plate_reader_1 + + + Software application for the modeling, analysis, and design of genetic circuits + + 1.0.0 + ibiosim + + + Lab Technician + John Doe + + 1.0.0 + jdoe + + + Research Fellow + Joe Schmoe + + 1.0.0 + jschmoe + + +\end{lstlisting} + +\twotwoone{ + \paragraph{Example - Combinatorial Derivation} + This example illustrates how the Prov ontology should be used to reference to link a generated design to the combinatorial derivation that it was generated from. In this example, there is a top-level derivation (Promoter\_Derivation) which specifies two possible promoters for this design, as well as an additional derivation (Terminator\_Derivation) to be used for the Gen\_Component. The second derivation (Terminator\_Derivation) specifies two possible terminators to used within the Gen\_Component. The derived design (Derivation\_example\_GeneratedInstance11) has a reference in the \sbol{wasDerivedFroms} list to the \sbol{CombinatorialDerivation} that it was derived from (i.e., Promoter\_Derivation). Also, each component has reference in the \sbol{wasDerivedFroms} list to the component within the \sbol{template} that it is derived from. The Gen\_Component in this derived design refers to a derived design for it (i.e., Gen\_GeneratedInstance1). This design has a reference in the \sbol{wasDerivedFroms} list that refers to the \sbol{CombinatorialDerivation} that is used to derive it (i.e., Terminator\_Derivation). Once again, each component has a reference in the \sbol{wasDerivedFroms} list to the component 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. +} + +\begin{lstlisting} + + + + + P1 + 1 + + P1 + 2018-05-09T19:41:51.056Z + + + + + + + + + Gen + 1 + + + + + + + + RBS_Component + 1 + + + + + + + + Ter_Component + 1 + + + + + + + + CDS_Component + 1 + + + + + + + + Gen_SequenceAnnotation1 + 1 + + + + Gen_SequenceAnnotation1_Range + 1 + 34 + 636 + + + + + + + + + + Gen_SequenceAnnotation2 + 1 + + + + GenericLocation + 1 + + + + + + + + + + Gen_SequenceAnnotation + 1 + + + + Gen_SequenceAnnotation_Range + 1 + 1 + 33 + + + + + + + + + + Gen_SequenceConstraint + 1 + + + + + + + + + Gen_SequenceConstraint1 + 1 + + + + + + + + + + pAmtR + 1 + + pAmtR + 2018-05-09T19:41:51.056Z + + + + + + + + + PhlF + 1 + + PhlF + 2018-05-09T19:41:51.056Z + + + + + + + + + Gen_GeneratedInstance1 + 1 + + + + + + + + + + Ter_Component + 1 + + + + + + + + + RBS_Component + 1 + + + + + + + + + CDS_Component + 1 + + + + + + + + + Gen_SequenceConstraint1 + 1 + + + + + + + + + Gen_SequenceConstraint + 1 + + + + + + + + + + Derivation_example + 1 + + + Derivation Example + An example derivation + + + + + + Pro_Component + 1 + + + + + + + + Gen_Component + 1 + + + + + + + + Derivation_example_SequenceAnnotation1 + 1 + + + + Derivation_example_SequenceAnnotation1_Range + 1 + 1 + 636 + + + + + + + + + + Derivation_example_SequenceAnnotation + 1 + + + + GenericLocation + 1 + + + + + + + + + + Derivation_example_SequenceConstraint + 1 + + + + + + + + + + L3S3P31 + 1 + + L3S3P31 + 2018-05-09T19:41:51.056Z + + + + + + + + + Pro + 1 + + + + + + + + Derivation_example_GeneratedInstance11 + 1 + + + + + Derivation Example + An example derivation + + + + + + Pro_Component + 1 + + + + + + + + + Gen_Component + 1 + + + + + + + + + Derivation_example_SequenceConstraint + 1 + + + + + + + + + + Ter + 1 + + + + + + + + L3S2P55_sequence + 1 + + L3S2P55_sequence + 2018-05-09T19:41:51.056Z + + + CTCGGTACCAAAGACGAACAATAAGACGCTGAAAAGCGTCTTTTTTCGTTTTGGTCC + + + + + P1_sequence + 1 + + P1_sequence + 2018-05-09T19:41:51.056Z + + + CTATGGACTATGTTTGAAAGGGAGAAATACTAG + + + + + pAmtR_sequence + 1 + + pAmtR_sequence + 2018-05-09T19:41:51.056Z + + + CTTGTCCAACCAAATGATTCGTTACCAATTGACAGTTTCTATCGATCTATAGATAATGCTAGC + + + + + pBetI_sequence + 1 + + pBetI_sequence + 2018-05-09T19:41:51.056Z + + + AGCGCGGGTGAGAGGGATTCGTTACCAATTGACAATTGATTGGACGTTCAATATAATGCTAGC + + + + + Derivation_exampleSequence + 1 + + + CTATGGACTATGTTTGAAAGGGAGAAATACTAGATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCC + TGCGTAGTCCGCATACCCATAAAGCAATTCTGACCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATT + GAAAGCGTTGCACGTCGTGCCGGTGCAAGCAAACCGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTG + TATGAAAATGAAAGCGAACAGGTGCGTAAATTTCCGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGT + GGAAAGTTTGGCGTGAAACCATTTGTGGTGAAGCATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCA + GCTGAAAGATCAGTTTATGGAACGTCGTCGTGAGATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAA + GATACCAATCGTGAACTGCTGCTGGATATGATTTTTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGA + TATTGAAGAATTTACCTTCCTGCTGATTAATGGTGTTTGTCCGGGTACACAGCGTTAA + + + + + GenSequence + 1 + + + CTATGGACTATGTTTGAAAGGGAGAAATACTAGATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCCTG + CGTAGTCCGCATACCCATAAAGCAATTCTGACCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATTGAAA + GCGTTGCACGTCGTGCCGGTGCAAGCAAACCGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTGTATGA + AAATGAAAGCGAACAGGTGCGTAAATTTCCGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGTGGAAAG + TTTGGCGTGAAACCATTTGTGGTGAAGCATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCAGCTGAAA + GATCAGTTTATGGAACGTCGTCGTGAGATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAAGATACCA + ATCGTGAACTGCTGCTGGATATGATTTTTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGATATTGAA + GAATTTACCTTCCTGCTGATTAATGGTGTTTGTCCGGGTACACAGCGTTAA + + + + + L3S3P31_sequence + 1 + + L3S3P31_sequence + 2018-05-09T19:41:51.056Z + + + CCAATTATTGAACACCCTAACGGGTGTTTTTTTTTTTTTGGTCTACC + + + + + PhlF_sequence + 1 + + PhlF_sequence + 2018-05-09T19:41:51.056Z + + + ATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCCTGCGTAGTCCGCATACCCATAAAGCAATTCTGA + CCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATTGAAAGCGTTGCACGTCGTGCCGGTGCAAGCAAAC + CGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTGTATGAAAATGAAAGCGAACAGGTGCGTAAATTTC + CGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGTGGAAAGTTTGGCGTGAAACCATTTGTGGTGAAGC + ATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCAGCTGAAAGATCAGTTTATGGAACGTCGTCGTGAG + ATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAAGATACCAATCGTGAACTGCTGCTGGATATGATTT + TTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGATATTGAAGAATTTACCTTCCTGCTGATTAATGGTG + TTTGTCCGGGTACACAGCGTTAA + + + + + Promoter_Derivation + 1 + + + + + + Pro_Component_VariableComponent + 1 + + + + + + + + + + Gen_Component_VariableComponent + 1 + + + + + + + + + Terminatior_Derivation + 1 + + + + + Ter_Component_VariableComponent + 1 + + + + + + + + +\end{lstlisting} + +\twothreezero{\subsection{Adding Measures/Parameters with OM} +\label{sec:parameters} + +\vspace{-7pt} +\-\hspace{0.8cm}[New in 2.3.0; see SEP 028: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_028.md}] + +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 quantitive 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. As shown in \ref{uml:om}, SBOL leverages three of the base classes defined by the OM: \sbol{Measure}, \sbol{Unit} and \sbol{Prefix}. A \sbol{Measure} links a numerical value to a \sbol{Unit}, which may or may not have a \sbol{Prefix} (e.g. centi, milli, micro, etc.). As these classes are adopted by SBOL, \sbol{Measure} is treated as a subclass of \sbol{Identified}, while \sbol{Unit} and \sbol{Prefix} are treated as subclasses of \sbol{TopLevel}. In addition, SBOL adopts the following OM \sbol{Unit} subclasses: \sbol{SingularUnit}, \sbol{CompoundUnit}, \sbol{UnitMultiplication}, \sbol{UnitDivision}, \sbol{UnitExponentiation}, and \sbol{PrefixedUnit}. Lastly, SBOL adopts the following \sbol{Prefix} subclasses from OM: \sbol{SIPrefix} and \sbol{BinaryPrefix}. + +\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. +} + + +\twothreezero{ +\subsubsection{Measure} +\label{sec:Measure} + +The purpose of the \sbol{Measure} class is to link a numerical value to a \sbol{Unit}. + +\paragraph{The \sbolheading{hasNumericalValue} property}\label{sec:hasNumericalValue} +The \sbol{hasNumericalValue} property is REQUIRED and MUST contain a single xsd:float. + +\paragraph{The \sbolheading{hasUnit} property}\label{sec:hasUnit:Measure} +The \sbolmult{hasUnit:Measure}{hasUnit} property is REQUIRED and MUST contain a \sbol{URI} that refers to a \sbol{Unit}. The OM provides \sbol{URI}s for many existing instances of the \sbol{Unit} class for reference (for example, \url{http://www.ontology-of-units-of-measure.org/resource/om-2/gramPerLitre}). + +\paragraph{The \sbolheading{types} property}\label{sec:types:Measure} +The \sbolmult{types:Measure}{types} property is OPTIONAL and MAY contain a set of \sbol{URI}s. It is RECOMMENDED that one of these \sbol{URI}s identify a term from the Systems Biology Ontology (SBO) (\url{http://www.ebi.ac.uk/sbo/main/}). This \sbolmult{types:Measure}{types} property of the \sbol{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/biomodels.sbo/SBO:0000612}). + +\paragraph{Serialization} +The serialization of a \sbol{Measure} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from Identified}] ... + [\emph{one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + [\emph{zero or more}] [\emph{element}] + +\end{lstlisting} + +\twothreezero{ +The example below shows the serialization of a \sbol{Measure} that describes the Michaelis constant for an enzymatic reaction. +} +\lstsetsbol +\begin{lstlisting} + + + + + ribonuclease_michaelis_constant + Ribonuclease Michaelis Constant + "7.9"^^xsd:float + + + + +\end{lstlisting} +\label{ser:Measure} + + +\twothreezero{ +\subsubsection{Unit} +\label{sec:Unit} + +As adopted by SBOL, \sbol{Unit} is an abstract class that is extended by other classes to describe units of measure using a shared set of properties. + +\paragraph{The \sbolheading{symbol} property}\label{sec:symbol:Unit} +The \sbolmult{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''. + +\paragraph{The \sbolheading{alternativeSymbols} property}\label{sec:alternativeSymbols:Unit} +The \sbolmult{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 \sbolmult{symbol:Unit}{symbol} property. + +\paragraph{The \sbolheading{label} property}\label{sec:label:Unit} +The \sbolmult{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}. + +\paragraph{The \sbolheading{alternativeLabels} property}\label{sec:alternativeLabels:Unit} +The \sbolmult{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 \sbolmult{label:Unit}{label} property. + +\paragraph{The \sbolheading{comment} property}\label{sec:comment:Unit} +The \sbolmult{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}. + +\paragraph{The \sbolheading{longcomment} property}\label{sec:longcomment:Unit} +The \sbolmult{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 \sbolmult{comment:Unit}{comment} property. +} + +\twothreezero{ +\subsubsection{SingularUnit} +\label{sec:SingularUnit} + +The purpose of the \sbol{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 \sbol{SingularUnit}, but it is equivalent to the multiplication of a newton and a meter. + +\paragraph{The \sbolheading{hasUnit} property}\label{sec:hasUnit:SingularUnit} +The \sbolmult{hasUnit:SingularUnit}{hasUnit} is OPTIONAL and MAY contain a \sbol{URI}. This \sbol{URI} MUST refer to another \sbol{Unit}. The \sbolmult{hasUnit:SingularUnit}{hasUnit} propery can be used in conjunction with the \sbolmult{hasFactor:SingularUnit}{hasFactor} property to specify whether a \sbol{SingularUnit} is equivalent to another \sbol{Unit} multiplied by a factor. For example, an angstrom is equivalent to $10^{-10}$ meters. + +\paragraph{The \sbolheading{hasFactor} property}\label{sec:hasFactor:SingularUnit} +The \sbolmult{hasFactor:SingularUnit}{hasFactor} property is OPTIONAL and MAY contain a xsd:float. If the \sbolmult{hasFactor:SingularUnit}{hasFactor} property of a \sbol{SingularUnit} is non-empty, then its \sbolmult{hasUnit:SingularUnit}{hasUnit} property SHOULD also be non-empty. + +\paragraph{Serialization} +The serialization of a \sbol{SingularUnit} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] [\emph{element}] + [\emph{zero or one}] [\emph{element}] + +\end{lstlisting} + +\twothreezero{ +The example below shows the serialization of a \sbol{SingularUnit} that describes a genetic unit of length not present in the OM: the base pair (bp). One bp is equivalent to 3.4 angstroms. +} +\lstsetsbol +\begin{lstlisting} + + + + + base_pair + Base Pair + bp + Base Pair + + 3.4 + + +\end{lstlisting} +\label{ser:SingularUnit} + + +\twothreezero{ +\subsubsection{CompoundUnit} +\label{sec:CompoundUnit} +} + +As adopted by SBOL, \sbol{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. + + +\twothreezero{ +\subsubsection{UnitMultiplication} +\label{sec:UnitMultiplication} + +The purpose of the \sbol{UnitMultiplication} class is to describe a unit of measure that is the multiplication of two other units of measure. + +\paragraph{The \sbolheading{hasTerm1} property}\label{sec:hasTerm1} +The \sbol{hasTerm1} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. This \sbol{Unit} is the first multiplication term. + +\paragraph{The \sbolheading{hasTerm2} property}\label{sec:hasTerm2} +The \sbol{hasTerm2} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. This \sbol{Unit} is the second multiplication term. It is okay if the \sbol{Unit} referred to by \sbol{hasTerm1} is the same as that referred to by \sbol{hasTerm2}. + +\paragraph{Serialization} +The serialization of a \sbol{UnitMultiplication} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +% \twothreezero{ +% The example below shows the serialization of a \sbol{UnitMultiplication} that captures . +% } +% \lstsetsbol +% \begin{lstlisting} +% +% +% +% +% +% +% +% +% +% +% +% +% \end{lstlisting} +% \label{ser:UnitMultiplication} + +\twothreezero{ +\subsubsection{UnitDivision} +\label{sec:UnitDivision} + +The purpose of the \sbol{UnitDivision} class is to describe a unit of measure that is the division of one unit of measure by another. + +\paragraph{The \sbolheading{hasNumerator} property}\label{sec:hasNumerator} +The \sbol{hasNumerator} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. + +\paragraph{The \sbolheading{hasDenominator} property}\label{sec:hasDenominator} +The \sbol{hasDenominator} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. + +\paragraph{Serialization} +The serialization of a \sbol{UnitDivision} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +\twothreezero{ +The example below shows the serialization of a \sbol{UnitDivision} that describes a unit of cell density not present in the OM: colony forming unit (CFU) per centimeter squared. +} +\lstsetsbol +\begin{lstlisting} + + + + + cfu_per_centimeter_squared + CFU per Centimeter Squared + CFU/cm2 + CFU per Centimeter Squared + + + + +\end{lstlisting} +\label{ser:UnitDivision} + +\twothreezero{ +\subsubsection{UnitExponentiation} +\label{sec:UnitExponentiation} + +The purpose of the \sbol{UnitExponentiation} class is to describe a unit of measure that is raised to an integer power. + +\paragraph{The \sbolheading{hasBase} property}\label{sec:hasBase} +The \sbol{hasBase} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. + +\paragraph{The \sbolheading{hasExponent} property}\label{sec:hasExponent} +The \sbol{hasExponent} property is REQUIRED and MUST contain an xsd:integer. + +\paragraph{Serialization} +The serialization of a \sbol{UnitExponentiation} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + [\emph{one}] ... [\emph{element}] + +\end{lstlisting} + +% \twothreezero{ +% The example below shows the serialization of a \sbol{UnitExponentiation} that captures . +% } +% \lstsetsbol +% \begin{lstlisting} +% +% +% +% +% +% +% +% +% +% +% +% +% \end{lstlisting} +% \label{ser:UnitExponentiation} + +\twothreezero{ +\subsubsection{PrefixedUnit} +\label{sec:PrefixedUnit} + +The purpose of the \sbol{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. + +\paragraph{The \sbolheading{hasUnit} property}\label{sec:hasUnit:PrefixedUnit} +The \sbolmult{hasUnit:PrefixedUnit}{hasUnit} property is REQUIRED and MUST contain a \sbol{URI} that refers to another \sbol{Unit}. + +\paragraph{The \sbolheading{hasPrefix} property}\label{sec:hasPrefix} +The \sbol{hasPrefix} property is REQUIRED and MUST contain a \sbol{URI} that refers to a \sbol{Prefix}. + +\paragraph{Serialization} +The serialization of a \sbol{PrefixedUnit} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +\twothreezero{ +The example below shows the serialization of a \sbol{PrefixedUnit} that describes an absolute unit of fluorescence not present in the OM: the kilo-Molecules of Equivalent Fluorescein (kilo-MEFL). +} +\lstsetsbol +\begin{lstlisting} + + + + + kiloMEFL + kilo-Molecules of Equivalent Fluorescein + kMEFL + kilo-Molecules of Equivalent Fluorescein + + + + +\end{lstlisting} +\label{ser:PrefixedUnit} + +\twothreezero{ +\subsubsection{Prefix} +\label{sec:Prefix} + +As adopted by SBOL, \sbol{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.'' + +\paragraph{The \sbolheading{symbol} property}\label{sec:symbol:Prefix} +The \sbolmult{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.'' + +\paragraph{The \sbolheading{alternativeSymbols} property}\label{sec:alternativeSymbols:Prefix} +The \sbolmult{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 \sbolmult{symbol:Prefix}{symbol} property. + +\paragraph{The \sbolheading{label} property}\label{sec:label:Prefix} +The \sbolmult{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}. + +\paragraph{The \sbolheading{alternativeLabels} property}\label{sec:alternativeLabels:Prefix} +The \sbolmult{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 \sbolmult{label:Prefix}{label} property. + +\paragraph{The \sbolheading{comment} property}\label{sec:comment:Prefix} +The \sbolmult{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}. + +\paragraph{The \sbolheading{longcomment} property}\label{sec:longcomment:Prefix} +The \sbolmult{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 \sbolmult{comment:Prefix}{comment} property. + +\paragraph{The \sbolheading{hasFactor} property}\label{sec:hasFactor:Prefix} +The \sbolmult{hasFactor:Prefix}{hasFactor} property is REQUIRED and MUST contain an xsd:float. +} + +\twothreezero{ +\subsubsection{SIPrefix} +\label{sec:SIPrefix} + +The purpose of the \sbol{SIPrefix} class is to describe standard SI prefixes such as ``milli,'' ``centi,'' ``kilo,'' etc. + +\paragraph{Serialization} +The serialization of a \sbol{SIPrefix} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +\twothreezero{ +\subsubsection{BinaryPrefix} +\label{sec:BinaryPrefix} + +The purpose of the \sbol{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.'' + +\paragraph{Serialization} +The serialization of a \sbol{BinaryPrefix} MUST have the following form: +} + +\lstsetsbol +\begin{lstlisting} + + ... [\emph{properties inherited from TopLevel}] ... + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{one}] ... [\emph{element}] + [\emph{zero or more}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{zero or one}] ... [\emph{element}] + [\emph{one}] [\emph{element}] + +\end{lstlisting} + +\paragraph{Example - Growth Media Recipe} +\twothreezero{ + \ref{uml:media_example} shows an example of using instances of the \sbol{Measure} and \sbol{Unit} classes in conjunction with instances of the SBOL \sbol{ModuleDefinition} and \sbol{ComponentDefinition} classes to specify a growth media recipe. Note that this specification for M9 Glucose CAA media is partly composed from the specification of another growth media, Teknova M1902. Namespace abbreviations used in this example include om for \url{http://www.ontology-of-units-of-measure.org/resource/om-2/}, obo for \url{http://purl.obolibrary.org/obo/}, chebi for \url{http://identifiers.org/chebi/}, and sbo for \url{http://identifiers.org/biomodels.sbo/}. For specifying \sbol{ModuleDefinition} \sbolmult{roles:MD}{roles}, MC85504 codes for the term "growth medium" in the National Cancer Institute Thesaurus (NCIT). For specifying \sbol{Measure} \sbolmult{types:Measure}{types} with the SBO, 0000196 codes for ``concentration of an entity pool'', 0000226 codes for ``density of an entity pool'', and 0000470 codes for ``mass fraction.'' +} + +\twothreezero{ +\begin{figure}[ht] +\begin{center} +\includegraphics[width=\linewidth]{uml/media_example} +\caption[]{Growth media recipe represented using instances of the \sbol{Measure} and \sbol{Unit} classes from the OM. +\label{uml:media_example}} +\end{center} +\end{figure} +} \ No newline at end of file diff --git a/model.tex b/model.tex index 5c215092..c8788523 100644 --- a/model.tex +++ b/model.tex @@ -589,6 +589,13 @@ \subsubsection{ComponentInstance} In some cases, a designer might want to set the \sbol{access} property of a \sbol{ComponentInstance} such that others cannot map to the \sbol{ComponentInstance} when they reuse its parent \sbol{ComponentDefinition}. For example, a designer who is concerned about retroactivity might set the \sbol{access} of the \sbol{ComponentInstance} to ``private'' in order to prevent its mapping to another \sbol{ComponentInstance} that participates in a new \sbol{Interaction} as part of a composite design. +\twothreezero{ +\paragraph{The \sbolheading{measures} property} +\label{sec:measures:CI} + +The \sbolmult{measures:CI}{measures} property is OPTIONAL and MAY contain a set of \sbol{Measure} objects. \ref{sec:Measure} contains a more detailed description of the \sbol{Measure} class. +} + \paragraph{Serialization} No serialization is defined for the \sbol{ComponentInstance} class, since this class is only used indirectly through the \sbol{Component} and \sbol{FunctionalComponent} subclasses. @@ -1272,6 +1279,13 @@ \subsubsection{Module} \ref{sec:MapsTo} contains a detailed description of the \sbol{MapsTo} class. +\twothreezero{ +\paragraph{The \sbolheading{measures} property} +\label{sec:measures:M} + +The \sbolmult{measures:M}{measures} property is OPTIONAL and MAY contain a set of \sbol{Measure} objects. \ref{sec:Measure} contains a more detailed description of the \sbol{Measure} class. +} + \paragraph{Serialization} The serialization of \sbol{Module}s has the following form. \lstsetsbol @@ -1403,6 +1417,13 @@ \subsubsection{Interaction} Even though an \sbol{Interaction} generally contains at least one \sbol{Participation}, the case of zero \sbol{Participation} objects is allowed because it is plausible that a designer might want to specify that an \sbol{Interaction} will exist, even if its \sbol{participant}s have not yet been determined. +\twothreezero{ +\paragraph{The \sbolheading{measures} property} +\label{sec:measures:I} + +The \sbolmult{measures:I}{measures} property is OPTIONAL and MAY contain a set of \sbol{Measure} objects. \ref{sec:Measure} contains a more detailed description of the \sbol{Measure} class. +} + \paragraph{Serialization} The serialization of an \sbol{Interaction} has the following form. @@ -1494,6 +1515,12 @@ \subsubsection{Participation} The \sbol{participant} property MUST specify precisely one \sbol{FunctionalComponent} object that plays the designated role in its parent \sbol{Interaction} object. +\twothreezero{ +\paragraph{The \sbolheading{measures} property} +\label{sec:measures:P} + +The \sbolmult{measures:P}{measures} property is OPTIONAL and MAY contain a set of \sbol{Measure} objects. \ref{sec:Measure} contains a more detailed description of the \sbol{Measure} class. +} \paragraph{Serialization} diff --git a/practices.tex b/practices.tex index 2892ec81..b7d7027c 100644 --- a/practices.tex +++ b/practices.tex @@ -131,1105 +131,3 @@ \subsection{Recommended Ontologies for External Terms} ... \end{lstlisting} - - -\twoonezero{\subsection{Adding Provenance} -\label{sec:provenance} -\label{sec:wasGeneratedBys} - -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.1.0; see SEP 009: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_009.md}] - -Provenance is central to a range of 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. - -The PROV-O ontology (https://www.w3.org/TR/prov-o/) already defines a data model for provenance. PROV-O's \sbol{wasDerivedFroms} property was adopted in SBOL 2.x to describe the derivation of an SBOL entity from another in a light-weight provenance scheme. Here, a subset of PROV-O is adopted for SBOL as a best practice to describe these activities in more detail\footnote{We thank Dr Paolo Missier from the School of Computing Science, Newcastle University for discussions regarding the use of PROV-O.}. PROV-O defines three core classes: \texttt{Entity}, \texttt{Activity} and \texttt{Agent}. An Agent (for example a software or a person) runs an Activity (according to a Plan) to generate one Entity from another. Although, PROV-O provides many other classes and rich set of terms. this specification describes the minimal subset of PROV-O that a provenance-aware SBOL tool should handle. This subset (\ref{uml:provenance}) includes the PROV-O's \sbol{Activity}, \sbol{Usage}, \sbol{Association}, \sbol{Agent} and \sbol{Plan} classes. Any SBOL's \sbol{Identified} object implicitly can act as an instance of PROV-O's \texttt{Entity} class and can include provenance through relationships to different activities. Resources representing \sbol{Agent}, \sbol{Activity} and \sbol{Plan} classes should be handled as \sbol{GenericTopLevel}, whilst \sbol{Usage} and \sbol{Association} resources should be nested within their parent activities. - -%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 Figure \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 and 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 ComponentDefinition may be derived from another ComponentDefinition, but it would probably not make sense for it to be derived from a Collection. -} - -\twotwozero{ -The PROV-O specification permits that any kind of SBOL object may be used to generate another. The meaning of these relationships are specified using ontology terms for the \sbolmult{roles:U}{roles} properties on \sbol{Usage} and \sbol{Association} classes. This specification gives users the flexibility to construct and track provenance histories for their own custom applications, but this flexibility also presents an obstacle to standardized data exchange. Therefore a simple ontology (see \ref{tbl:association_roles} and \ref{tbl:usage_roles}) has been adopted to describe common provenance connections expected in synthetic biology workflows, based on the design-build-test-learn formalization of engineering. - -The design-build-test-learn cycle is a common theme in synthetic biology and engineering literature. The design-build-test-learn cycle is the scientific method applied to engineering. Stages of the cycle include designing an initial prototype, testing that prototype, analyzing its performance against specific metrics, learning what worked and what did not work, designing a new prototype based on what was learned, and completing the cycle again. Ideally each iteration of the cycle generates new understanding that feeds back into new cycles as alternative approaches or reformulated problems. Therefore, the design-build-test-learn cycle is a \textit{de facto} ontology upon which to base an SBOL data model for workflow abstraction. Other workflow activities in synthetic biology, such as analyzing, modeling, verifying, and evolving, by and large should fit into this design-build-test-learn abstraction. - -It is expected that users will develop their own ontology terms to specify how SBOL objects are used in a recipe, protocol, or computational analysis. However, these home-made ontologies will be very domain specific, and may not be intelligible to users working in another domain. For example a modeler should not be expected to understand an ontology of \sbol{Usage} \sbolmult{roles:U}{roles} for DNA assembly. The terms ``design'', ``build'', ``test'', and ``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. An example of how these terms are used is provided in \ref{images:design-build-test-learn}. - -Provenance semantics defined through \sbol{wasGeneratedBys} relationships are distinctly different from versioning semantics. 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 semantics are somewhat different from the versioning semantics defined in section \ref{sec:version}. The SBOL specification defines a new version of an object as an update of a previously published object (and therefore a previously existing object). Therefore, an SBOL object which is ``generated'' from another SHOULD BE regarded as a new entity rather than a new version of an existing entity. However, this distinction is somewhat subjective (see Theseus's paradox). Therefore, we RECOMMEND as a best practice that objects linked by Activities not be successive versions of each other, though this is left to the discretion of users and library developers. -} - -\twotwozero{ -\begin{figure}[ht] -\begin{center} -\includegraphics[scale=0.6]{uml/provenance} -\caption[]{Relationships between SBOL and PROV-O classes. The PROV-O classes \external{Activity}, \external{Plan}, and \external{Agent} are all serialized as \sbol{TopLevel} classes in an SBOL document. -\label{uml:provenance}} -\end{center} -\end{figure} -} - -\twoonezero{ -\subsubsection{Activity} -\label{sec:Activity} - -A generated \texttt{Entity} is linked through a \texttt{wasGeneratedBy} relationship to an \sbol{Activity}, which is used to describe how different \sbol{Agent}s and other entities were used. An \sbol{Activity} is linked through a \sbol{associations} to \sbol{Association}s, to describe the role of agents, and is linked through \sbol{usages} to \sbol{Usage}s to describe the role of other entities used as part of the activity. Moreover, each \sbol{Activity} includes optional startedAtTime and endedAtTime properties. When using \sbol{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 \sbol{wasInformedBys} relationship to provide dependency without explicitly specifying start and end times. - -\twothreezero{ -\paragraph{The \sbolheading{types} property}\label{sec:activity_types} -The \texttt{\hyperref[sec:activity_types]{types}} property is an OPTIONAL set of \sbol{URI}s that explicitly specify the type of the provenance \sbol{Activity} in more detail. If specified, it is RECOMMENDED that at least one \sbol{URI} of the \texttt{\hyperref[sec:activity_types]{types}} property of an \sbol{Activity} refers to a \sbol{URI} from \ref{tbl:activity_types}. -} - -\begin{table}[ht] - \begin{edtable}{tabular}{ll} - \toprule - \textbf{Activity Type} & \textbf{URI} \\ - \midrule - Design & \url{http://sbols.org/v2\#design}\\ - Build & \url{http://sbols.org/v2\#build}\\ - Test & \url{http://sbols.org/v2\#test}\\ - Learn & \url{http://sbols.org/v2\#learn}\\ - \bottomrule - \end{edtable} - \caption{URIs to specify the \texttt{\hyperref[sec:activity_types]{types}} property of an \sbol{Activity}.} - \label{tbl:activity_types} -\end{table} - -\paragraph{The \sbolheading{startedAtTime} property}\label{sec:startedAtTime} -The \sbol{startedAtTime} property is OPTIONAL and contains a DateTime (see section \ref{sec:DateTime}) value, indicating when the activity started. If this property is present, then the \sbol{endedAtTime} property is REQUIRED. - -\paragraph{The \sbolheading{endedAtTime} property}\label{sec:endedAtTime} -The \sbol{endedAtTime} property is OPTIONAL and contains a DateTime (see section \ref{sec:DateTime}) value, indicating when the activity ended. - - -\paragraph{The \sbolheading{associations} property}\label{sec:associations} -The \sbol{associations} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to \sbol{Association} objects. - -\paragraph{The \sbolheading{usages} property}\label{sec:usages} -The \sbol{usages} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to \sbol{Usage} objects. - -\paragraph{The \sbolheading{wasInformedBys} property}\label{sec:wasInformedBys} -The \sbol{wasInformedBys} property is OPTIONAL and MAY contain a set of \sbol{URI}s that refers to other \sbol{Activity} objects. - -\paragraph{Serialization} -\twothreezero{ -The serialization of an \sbol{Activity} MUST have the following form: -} -} - -\lstsetsbol -\begin{lstlisting} - - ... [\emph{properties inherited from identified}] ... - [\emph{zero or more}] - ... - [\emph{elements}] - [\emph{zero or more}] - ... - [\emph{elements}] - [\emph{zero or more}] [\emph{elements}] - [\emph{zero or one}] ... [\emph{element}] - [\emph{zero or one}] ... [\emph{element}] - [\emph{zero or more}] [\emph{element}] - -\end{lstlisting} - -\twotwozero{ -Note that the tags prov:qualifiedUsage and prov:qualifiedAssociation are used for \sbol{usages} and \sbol{associations}, respectively. -} - -\twoonezero{ -\subsubsection{Usage} -\label{sec:Usage} -How different entities are used in an \sbol{Activity} is specified with the \sbol{Usage} class, which is linked from an \sbol{Activity} through the \sbol{Usage} relationship. A \sbol{Usage} is then linked to an \texttt{Entity} through the \texttt{Entity}'s URI and the role of this entity is qualified with the \sbolmult{roles:U}{roles} property. When the \sbol{wasDerivedFroms} property is used together with the full provenance described here, the entity pointed at by the \sbol{wasDerivedFroms} property MUST be included in a \sbol{Usage}. - - -\paragraph{The \sbolheading{entity} property}\label{sec:entity} -The \sbol{entity} property is REQUIRED and MUST contain a \sbol{URI} which MAY refer to an SBOL Identified object. - -\paragraph{The \sbolheading{roles} property}\label{sec:roles:U} -\twotwozero{ -The \sbolmult{roles:U}{roles} property is an OPTIONAL set of \sbol{URI}s that refer to particular term(s) describing the usage of an \sbol{entity} referenced by the \sbol{entity} property. Recommended terms that are defined in \ref{tbl:usage_roles} can be used to indicate how the referenced \sbol{entity} is being used in this \sbol{Activity}. -} -} - -\twotwozero{ -\begin{table}[H] - \begin{edtable}{tabular}{lp{3.75in}} - \toprule - \textbf{URI for Usage roles} & \textbf{Description} \\ - \midrule - \url{http://sbols.org/v2\#design} & Design describes the process by which a conceptual representation of an engineer's imagined and intended design for a biological system is derived, possibly from a predictive model or by modifying a pre-existing design. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous design \sbol{Activity} and was used by the present \sbol{Activity} as a design for a new object.\\ - \url{http://sbols.org/v2\#build} & Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous build \sbol{Activity} and was used by the present \sbol{Activity} as a built object.\\ - \url{http://sbols.org/v2\#test} & Test describes the process of performing experimental measurements to characterize a synthetic biological construct. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous test \sbol{Activity} and is used as test data in the present \sbol{Activity}.\\ - \url{http://sbols.org/v2\#learn} & Learn describes the process of analyzing experimental measurements to produce a new entity that represents biological knowledge. In the context of a \sbol{Usage}, the term indicates that the referenced \sbol{entity} was generated by some previous learn \sbol{Activity} and is used in the present \sbol{Activity} as a source of scientifically verified knowledge.\\ - \bottomrule - \end{edtable} - \caption{Terms to specify the \sbolmult{roles:U}{roles} property of a \sbol{Usage}.} - \label{tbl:usage_roles} -\end{table} -} - - - -\twoonezero{ -\subsubsection{Association} -\label{sec:Association} -An \sbol{Association} is linked to an \sbol{Agent} through the \sbol{agent} relationship. The \sbol{Association} includes the \sbolmult{roles:A}{roles} property to qualify the role of the \sbol{Agent} in the \sbol{Activity}. - -\paragraph{The \sbolheading{agent} property}\label{sec:agent} -The \sbol{agent} property is REQUIRED and MUST contain a \sbol{URI} that refers to an \sbol{Agent} object. - -\paragraph{The \sbolheading{roles} property}\label{sec:roles:A} -\twotwozero{ -The \sbolmult{roles:A}{roles} property is an OPTIONAL set of \sbol{URI}s that refers to particular term(s) that describes the the role of the \sbol{agent} in the parent \sbol{Activity}. -The recommended terms that are defined in \ref{tbl:association_roles} can be used to specify the kind of \sbol{Activity} performed by the \sbol{Agent}. -} -} - -\twothreezero{ -\begin{table}[H] - \begin{edtable}{tabular}{lp{3.75in}} - \toprule - \textbf{URI for Association roles} & \textbf{Description} \\ - \midrule - \url{http://sbols.org/v2\#design} & Design describes the process by which a conceptual representation of an engineer's imagined and intended design for a biological system is derived, possibly from a predictive model or by modifying a pre-existing design. In the context of an \sbol{Association}, the term design indicates that the \sbol{Agent} performed the parent \sbol{Activity} to generate a design.\\ - \url{http://sbols.org/v2\#build} & Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory. In the context of an \sbol{Association}, the term build indicates that the \sbol{Agent} performed the parent \sbol{Activity} to implement a design. More generally, the term may represent any kind of experimental manipulation of a biological sample, including propagating, passaging, or evolving cell lines.\\ - \url{http://sbols.org/v2\#test} & Test describes the process of performing experimental measurements to characterize a synthetic biological construct. In the context of an \sbol{Association}, the \sbol{Agent} performed the parent \sbol{Activity} to perform experimental measurements resulting in raw data represented by an \sbol{ExperimentalData}.\\ - \url{http://sbols.org/v2\#learn} & Learn describes the process of analyzing the experimental measurements in order to produce a new entity that represents biological knowledge. In the context of an \sbol{Association}, the \sbol{Agent} processed the raw experimental data to produce an analysis. This process generates a new entity that represents biological knowledge, including tables or graphs referenced by the \sbol{Attachment}s of an \sbol{ExperimentalData}, a \sbol{Model} produced by a fitting process, a consensus \sbol{Sequence} derived from sequencing results, etc.\\ - \bottomrule - \end{edtable} - \caption{Terms to specify the \sbolmult{roles:A}{roles} property of an \sbol{Association}.} - \label{tbl:association_roles} -\end{table} -} - -\twoonezero{ -\paragraph{The \sbolheading{plan} property}\label{sec:plan} -The \sbol{plan} property is OPTIONAL and contains a URI that refers to a \sbol{Plan}. - -\paragraph{Serialization} -The serialization of an \sbol{Association} MUST have the following form: - -} - -\lstsetsbol -\begin{lstlisting} - - ... [\emph{properties inherited from identified}] ... - [\emph{zero or more}] [\emph{element}] - [\emph{zero or one}] [\emph{element}] - [\emph{one}] [\emph{element}] - -\end{lstlisting} - -\twotwozero{ -Note that the tags prov:hadRole and prov:hadPlan are used for \sbolmult{roles:A}{roles} and \sbol{plan}, respectively. -} - -\subsubsection{Plan} -\label{sec:Plan} -\twoonezero{ - The Plan entity can be used as a place holder to describe the steps (for example scripts or lab protocols) taken when an \sbol{Agent} is used in a particular \sbol{Activity}. - -\paragraph{Serialization} -The serialization of an \sbol{Usage} MUST have the following form: - -}%\twoonezero{ end - -\lstsetsbol -\begin{lstlisting} - - ... [\emph{properties inherited from identified}] ... - ... [\emph{other annotations}] ... - -\end{lstlisting} - -\subsubsection{Agent} -\label{sec:Agent} -\twoonezero{ - Examples of agents are person, organization or software. These agents should be annotated with additional information, such as software version, needed to be able to run the same software again. - -\paragraph{Serialization} -The serialization of an \sbol{Agent} MUST have the following form: - -}%\twoonezero{ end - -\lstsetsbol -\begin{lstlisting} - - ... [\emph{properties inherited from identified}] ... - ... [\emph{other annotations}] ... - -\end{lstlisting} - - -\paragraph{Example - Codon optimization} -\twoonezero{ - Codon optimization is a practical real-wold example where provenance properties can be applied. Using the current specification, 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 \sbol{Activity}. This \sbol{Activity} can then include additional information, such as the \sbol{Agent} responsible (in this case, codon-optimizing software), and additional parameters. - -}%\twoonezero{ end - -\lstsetsbol -\begin{lstlisting} - - - - - codon_optimized - - - Codon optimized CDS - - - - - - non_codon_optimized - Non Codon optimized CDS - - - - - - codon_optimization_activity - Codon Optimization Activity - - - - association - - - - - - - - usage - - - - - - - - codon_optimization_software - Codon Optimization Software - - -\end{lstlisting} - -\paragraph{Example - Deriving strains} -\twoonezero{ - Bacterial strains are often derived from other strains through modifications such as gene knockouts or mutations. For example, the \texttt{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. Particularly, the 168 strain is easy to transform and is not motile, facilitating the analysis of engineered cells. The parent strain, on the other hand, is motile but more difficult to transform. The example below shows the derivation of the 168 strain using the new provenance classes. - -}%twoonezero end - -\lstsetsbol -\begin{lstlisting} - - - - - bsubtilisncimb3610 - Bacillus subtilis NCIMB3610 - - - - - - bsubtilis168 - - - Bacillus subtilis 168 - - - - - - xraymutagenesis - X-ray mutagenesis - - - - association - - - - - - - - usage - - - - - - - - x_ray - X-ray - - -\end{lstlisting} - -\paragraph{Example - Design-build-test-learn Workflow} -\twothreezero{ - This particular example represents an idealized workflow for model-based design. The workflow begins with a \sbol{Model} which describes the hypothesized behavior of a biological device. Using a computational tool, a new Design (\sbol{ModuleDefinition}) is composed of 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 some 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. This example illustrates one complete iteration through a design-build-test-learn cycle, as shown in \ref{images:design-build-test-learn}. -}%twotwozero end - -\begin{figure}[ht] -\begin{center} -\includegraphics[width=\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 - -\twotwoone{} -\lstsetsbol -\begin{lstlisting} - - - - Activity_build_generation - - 1.0.0 - - - build_generation_association - - 1.0.0 - - - - - - - - design_usage - - 1.0.0 - - - - - - - Activity_design_generation - - 1.0.0 - - - design_generation_association - - 1.0.0 - - - - - - - - predicted_usage - - 1.0.0 - - - - - - - Activity_fit_model_generation - - 1.0.0 - - - fit_model_generation_association - - 1.0.0 - - - - - - - - raw_data_usage - - 1.0.0 - - - - - - - Activity_raw_data_generation - - 1.0.0 - - - raw_data_generation_association - - 1.0.0 - - - - - - - - build_usage - - 1.0.0 - - - - - - - Attachment_characterization_protocol - - - 1.0.0 - - - Attachment_model_fitting_script - - - - 1.0.0 - - - ExperimentalData_raw_data - - - 1.0.0 - - - - - Attachment_raw_data - - - - 1.0.0 - - - Implementation_build - - 1.0.0 - - - - - Model_fit_model - - - - - 1.0.0 - - - - - Model_predicted - - - - - 1.0.0 - - - ModuleDefinition_design - - 1.0.0 - - - - - - Plan_characterization_protocol - - 1.0.0 - - - SBML to SBOL conversion - Plan_conversion - - 1.0.0 - - - DNA assembly - Plan_gibson_assembly - - 1.0.0 - - - - Plan_model_fitting - - 1.0.0 - - - - 1.0.0 - plate_reader_1 - - - Software application for the modeling, analysis, and design of genetic circuits - - 1.0.0 - ibiosim - - - Lab Technician - John Doe - - 1.0.0 - jdoe - - - Research Fellow - Joe Schmoe - - 1.0.0 - jschmoe - - -\end{lstlisting} - -\twotwoone{ - \paragraph{Example - Combinatorial Derivation} - This example illustrates how the Prov ontology should be used to reference to link a generated design to the combinatorial derivation that it was generated from. In this example, there is a top-level derivation (Promoter\_Derivation) which specifies two possible promoters for this design, as well as an additional derivation (Terminator\_Derivation) to be used for the Gen\_Component. The second derivation (Terminator\_Derivation) specifies two possible terminators to used within the Gen\_Component. The derived design (Derivation\_example\_GeneratedInstance11) has a reference in the \sbol{wasDerivedFroms} list to the \sbol{CombinatorialDerivation} that it was derived from (i.e., Promoter\_Derivation). Also, each component has reference in the \sbol{wasDerivedFroms} list to the component within the \sbol{template} that it is derived from. The Gen\_Component in this derived design refers to a derived design for it (i.e., Gen\_GeneratedInstance1). This design has a reference in the \sbol{wasDerivedFroms} list that refers to the \sbol{CombinatorialDerivation} that is used to derive it (i.e., Terminator\_Derivation). Once again, each component has a reference in the \sbol{wasDerivedFroms} list to the component 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. -} - -\begin{lstlisting} - - - - - P1 - 1 - - P1 - 2018-05-09T19:41:51.056Z - - - - - - - - - Gen - 1 - - - - - - - - RBS_Component - 1 - - - - - - - - Ter_Component - 1 - - - - - - - - CDS_Component - 1 - - - - - - - - Gen_SequenceAnnotation1 - 1 - - - - Gen_SequenceAnnotation1_Range - 1 - 34 - 636 - - - - - - - - - - Gen_SequenceAnnotation2 - 1 - - - - GenericLocation - 1 - - - - - - - - - - Gen_SequenceAnnotation - 1 - - - - Gen_SequenceAnnotation_Range - 1 - 1 - 33 - - - - - - - - - - Gen_SequenceConstraint - 1 - - - - - - - - - Gen_SequenceConstraint1 - 1 - - - - - - - - - - pAmtR - 1 - - pAmtR - 2018-05-09T19:41:51.056Z - - - - - - - - - PhlF - 1 - - PhlF - 2018-05-09T19:41:51.056Z - - - - - - - - - Gen_GeneratedInstance1 - 1 - - - - - - - - - - Ter_Component - 1 - - - - - - - - - RBS_Component - 1 - - - - - - - - - CDS_Component - 1 - - - - - - - - - Gen_SequenceConstraint1 - 1 - - - - - - - - - Gen_SequenceConstraint - 1 - - - - - - - - - - Derivation_example - 1 - - - Derivation Example - An example derivation - - - - - - Pro_Component - 1 - - - - - - - - Gen_Component - 1 - - - - - - - - Derivation_example_SequenceAnnotation1 - 1 - - - - Derivation_example_SequenceAnnotation1_Range - 1 - 1 - 636 - - - - - - - - - - Derivation_example_SequenceAnnotation - 1 - - - - GenericLocation - 1 - - - - - - - - - - Derivation_example_SequenceConstraint - 1 - - - - - - - - - - L3S3P31 - 1 - - L3S3P31 - 2018-05-09T19:41:51.056Z - - - - - - - - - Pro - 1 - - - - - - - - Derivation_example_GeneratedInstance11 - 1 - - - - - Derivation Example - An example derivation - - - - - - Pro_Component - 1 - - - - - - - - - Gen_Component - 1 - - - - - - - - - Derivation_example_SequenceConstraint - 1 - - - - - - - - - - Ter - 1 - - - - - - - - L3S2P55_sequence - 1 - - L3S2P55_sequence - 2018-05-09T19:41:51.056Z - - - CTCGGTACCAAAGACGAACAATAAGACGCTGAAAAGCGTCTTTTTTCGTTTTGGTCC - - - - - P1_sequence - 1 - - P1_sequence - 2018-05-09T19:41:51.056Z - - - CTATGGACTATGTTTGAAAGGGAGAAATACTAG - - - - - pAmtR_sequence - 1 - - pAmtR_sequence - 2018-05-09T19:41:51.056Z - - - CTTGTCCAACCAAATGATTCGTTACCAATTGACAGTTTCTATCGATCTATAGATAATGCTAGC - - - - - pBetI_sequence - 1 - - pBetI_sequence - 2018-05-09T19:41:51.056Z - - - AGCGCGGGTGAGAGGGATTCGTTACCAATTGACAATTGATTGGACGTTCAATATAATGCTAGC - - - - - Derivation_exampleSequence - 1 - - - CTATGGACTATGTTTGAAAGGGAGAAATACTAGATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCC - TGCGTAGTCCGCATACCCATAAAGCAATTCTGACCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATT - GAAAGCGTTGCACGTCGTGCCGGTGCAAGCAAACCGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTG - TATGAAAATGAAAGCGAACAGGTGCGTAAATTTCCGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGT - GGAAAGTTTGGCGTGAAACCATTTGTGGTGAAGCATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCA - GCTGAAAGATCAGTTTATGGAACGTCGTCGTGAGATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAA - GATACCAATCGTGAACTGCTGCTGGATATGATTTTTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGA - TATTGAAGAATTTACCTTCCTGCTGATTAATGGTGTTTGTCCGGGTACACAGCGTTAA - - - - - GenSequence - 1 - - - CTATGGACTATGTTTGAAAGGGAGAAATACTAGATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCCTG - CGTAGTCCGCATACCCATAAAGCAATTCTGACCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATTGAAA - GCGTTGCACGTCGTGCCGGTGCAAGCAAACCGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTGTATGA - AAATGAAAGCGAACAGGTGCGTAAATTTCCGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGTGGAAAG - TTTGGCGTGAAACCATTTGTGGTGAAGCATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCAGCTGAAA - GATCAGTTTATGGAACGTCGTCGTGAGATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAAGATACCA - ATCGTGAACTGCTGCTGGATATGATTTTTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGATATTGAA - GAATTTACCTTCCTGCTGATTAATGGTGTTTGTCCGGGTACACAGCGTTAA - - - - - L3S3P31_sequence - 1 - - L3S3P31_sequence - 2018-05-09T19:41:51.056Z - - - CCAATTATTGAACACCCTAACGGGTGTTTTTTTTTTTTTGGTCTACC - - - - - PhlF_sequence - 1 - - PhlF_sequence - 2018-05-09T19:41:51.056Z - - - ATGGCACGTACCCCGAGCCGTAGCAGCATTGGTAGCCTGCGTAGTCCGCATACCCATAAAGCAATTCTGA - CCAGCACCATTGAAATCCTGAAAGAATGTGGTTATAGCGGTCTGAGCATTGAAAGCGTTGCACGTCGTGCCGGTGCAAGCAAAC - CGACCATTTATCGTTGGTGGACCAATAAAGCAGCACTGATTGCCGAAGTGTATGAAAATGAAAGCGAACAGGTGCGTAAATTTC - CGGATCTGGGTAGCTTTAAAGCCGATCTGGATTTTCTGCTGCGTAATCTGTGGAAAGTTTGGCGTGAAACCATTTGTGGTGAAGC - ATTTCGTTGTGTTATTGCAGAAGCACAGCTGGACCCTGCAACCCTGACCCAGCTGAAAGATCAGTTTATGGAACGTCGTCGTGAG - ATGCCGAAAAAACTGGTTGAAAATGCCATTAGCAATGGTGAACTGCCGAAAGATACCAATCGTGAACTGCTGCTGGATATGATTT - TTGGTTTTTGTTGGTATCGCCTGCTGACCGAACAGCTGACCGTTGAACAGGATATTGAAGAATTTACCTTCCTGCTGATTAATGGTG - TTTGTCCGGGTACACAGCGTTAA - - - - - Promoter_Derivation - 1 - - - - - - Pro_Component_VariableComponent - 1 - - - - - - - - - - Gen_Component_VariableComponent - 1 - - - - - - - - - Terminatior_Derivation - 1 - - - - - Ter_Component_VariableComponent - 1 - - - - - - - - -\end{lstlisting} diff --git a/sbol2.tex b/sbol2.tex index b91302dc..5f265abb 100644 --- a/sbol2.tex +++ b/sbol2.tex @@ -65,7 +65,10 @@ \lstdefinelanguage{sbol} {morekeywords={xmlns:sbol,xmlns:prov,xmlns:rdf,xmlns:dcterms,xmlns:myapp,rdf:RDF,rdf:resource,rdf:about,sbol:displayId,sbol:persistentIdentity,sbol:version,sbol:timeStamp,sbol:name,sbol:description,sbol:member,sbol:Collection,sbol:type, sbol:role, sbol:roleIntegration, sbol:ComponentDefinition, sbol:MapsTo, sbol:sequence,sbol:wasDerivedFrom,sbol:Component,sbol:subComponent,sbol:SequenceAnnotation,sbol:component,sbol:location, sbol:sourceLocation, sbol:sequenceAnnotation, sbol:Range, sbol:start, sbol:end, sbol:orientation,sbol:SequenceConstraint, sbol:restriction, sbol:subject, sbol:object,sbol:Sequence, sbol:elements, sbol:encoding,sbol:Model, sbol:source, sbol:language, sbol:framework,sbol:FunctionalComponent, sbol:Module, sbol:Interaction, sbol:interaction, sbol:module, sbol:model,sbol:Model,sbol:definition, sbol:access, sbol:direction, sbol:mapsTo, sbol:refinement, sbol:local, sbol:remote, sbol:participation, sbol:Participation, sbol:participant,sbol:sequenceConstraint,sbol:at,sbol:Cut,sbol:functionalComponent,sbol:ModuleDefinition,prov:wasDerivedFrom,dcterms:title,dcterms:description,sbol:Implementation,sbol:built,sbol:CombinatorialDerivation,sbol:template,sbol:strategy,sbol:variableComponent,sbol:VariableComponent,sbol:operator,sbol:variable,sbol:variant,sbol:variantCollection,sbol:variantDerivations,sbol:format,sbol:size,sbol:hash,sbol:Attachment,prov:wasGeneratedBy,prov:Activity,prov:startedAtTime,prov:endedAtTime,prov:wasInformedBy,prov:qualifiedUsage,prov:Usage,prov:entity,prov:qualifiedAssociation,prov:Association,prov:hadRole,prov:hadPlan,prov:Plan,prov:agent,prov:Agent, -sbol:experimentalData,sbol:Experiment,sbol:ExperimentalData,sbol:attachment}, +sbol:experimentalData,sbol:Experiment,sbol:ExperimentalData,sbol:attachment,om:hasNumericalValue,om:symbol,om:alternativeSymbol,om:alternativeLabel,om:longcomment,om:hasFactor, +om:hasTerm1,om:hasTerm2,om:hasNumerator,om:hasDenominator,om:hasBase,om:hasExponent,om:hasUnit,om:hasPrefix,rdfs:comment,rdfs:label, +om:Measure,om:Unit,om:SingularUnit,om:CompoundUnit,om:om:UnitMultiplication,om:UnitDivision,om:Exponentiation,om:PrefixedUnit,om:Prefix,om:SIPrefix, +om:BinaryPrefix,xlmns:om,xlmns:rdfs,xlmns:xsd,xml:lang}, basicstyle=\fontsize{7}{9}\selectfont\ttfamily, backgroundcolor=\color{light-gray}, keywordstyle=\color{blue}, @@ -269,6 +272,8 @@ \input{practices} +\input{complementary_standards} + \newpage \bibliography{sbol} diff --git a/uml/component_instance.pdf b/uml/component_instance.pdf index e7fd6e9e..7d0fc952 100644 Binary files a/uml/component_instance.pdf and b/uml/component_instance.pdf differ diff --git a/uml/interaction.pdf b/uml/interaction.pdf index 21619d57..7df3bacc 100644 Binary files a/uml/interaction.pdf and b/uml/interaction.pdf differ diff --git a/uml/media_example.pdf b/uml/media_example.pdf new file mode 100644 index 00000000..375ae32f Binary files /dev/null and b/uml/media_example.pdf differ diff --git a/uml/module.pdf b/uml/module.pdf index dd797dd9..386e3c19 100644 Binary files a/uml/module.pdf and b/uml/module.pdf differ diff --git a/uml/om.pdf b/uml/om.pdf new file mode 100644 index 00000000..f4077f6e Binary files /dev/null and b/uml/om.pdf differ diff --git a/uml/participation.pdf b/uml/participation.pdf index b8066e7a..152e787c 100644 Binary files a/uml/participation.pdf and b/uml/participation.pdf differ diff --git a/umlet_source/component_instance_2.3.uxf b/umlet_source/component_instance_2.3.uxf new file mode 100644 index 00000000..7f60a45a --- /dev/null +++ b/umlet_source/component_instance_2.3.uxf @@ -0,0 +1,175 @@ + + + 10 + + com.baselet.element.old.element.Class + + 590 + 390 + 180 + 50 + + *FunctionalComponent* +-- +-direction[1] : URI + + + + + + com.baselet.element.old.element.Class + + 390 + 390 + 180 + 70 + + *Component* +-- +-roles[0..*] : URI +-roleIntegration[0..1] : URI + + + + + + com.baselet.element.old.element.Relation + + 450 + 310 + 150 + 100 + + lt=<<- + 130;30;130;60;30;60;30;80 + + + com.baselet.element.old.element.Relation + + 570 + 310 + 130 + 100 + + lt=<<- + 30;30;30;60;110;60;110;80 + + + com.baselet.element.old.element.Class + + 510 + 250 + 170 + 90 + + */ComponentInstance/* +-- +-access[1] : URI + + + + + + + com.baselet.element.old.element.Class + + 540 + 190 + 100 + 30 + + /*Identified*/ + + + + com.baselet.element.old.element.Relation + + 560 + 190 + 50 + 80 + + lt=<<- + 30;30;30;60 + + + com.baselet.element.old.element.Class + + 800 + 270 + 90 + 30 + + *MapsTo* + + + + + + + + com.baselet.element.old.element.Relation + + 650 + 230 + 170 + 94 + + lt=<<<<-> +mapsTos +0..* + 30;50;150;50 + + + com.baselet.element.old.element.Relation + + 310 + 250 + 220 + 110 + + lt=<<<-> +definition + 1 + 200;50;60;50;60;90 + + + com.baselet.element.old.element.Class + + 290 + 340 + 170 + 30 + + *ComponentDefinition* + + + + com.baselet.element.old.element.Relation + + 650 + 280 + 170 + 94 + + lt=<<<<-> +measures +0..* + 30;50;150;50 + + + com.baselet.element.old.element.Class + + 800 + 320 + 90 + 30 + + *Measure* + + + + + + + diff --git a/umlet_source/interaction_2.3.uxf b/umlet_source/interaction_2.3.uxf new file mode 100644 index 00000000..ab6fcc44 --- /dev/null +++ b/umlet_source/interaction_2.3.uxf @@ -0,0 +1,101 @@ + + + 10 + + com.baselet.element.old.element.Class + + 750 + 420 + 140 + 50 + + *Interaction* +-- +-types[1..*] : URI + + + + + + com.baselet.element.old.element.Relation + + 860 + 400 + 190 + 94 + + lt=<->>>> +participations +0..* + + 170;50;30;50 + + + com.baselet.element.old.element.Relation + + 790 + 360 + 50 + 80 + + lt=<<- + 30;30;30;60 + + + com.baselet.element.old.element.Class + + 770 + 360 + 100 + 30 + + /*Identified*/ + + + + com.baselet.element.old.element.Class + + 1030 + 440 + 120 + 30 + + *Participation* + + + + + + + + + com.baselet.element.old.element.Relation + + 600 + 400 + 170 + 94 + + lt=<->>>> +measures +0..* + + 30;50;150;50 + + + com.baselet.element.old.element.Class + + 540 + 440 + 90 + 30 + + *Measure* + + + + + + + + diff --git a/umlet_source/media_example.uxf b/umlet_source/media_example.uxf new file mode 100644 index 00000000..e71cde73 --- /dev/null +++ b/umlet_source/media_example.uxf @@ -0,0 +1,416 @@ + + + 10 + + com.baselet.element.old.element.Class + + 780 + 480 + 80 + 30 + + *Module* + + + + com.baselet.element.old.element.Class + + 1000 + 730 + 230 + 80 + + *ComponentDefinition* +-- +-name : "Thiamine Hydrochloride" +-types : [chebi:CHEBI:49105] +... + + + + com.baselet.element.old.element.Class + + 510 + 730 + 230 + 80 + + *ComponentDefinition* +-- +-name : "Dextrose (D-Glucose)" +-types : [chebi:CHEBI:17634] +... + + + + com.baselet.element.old.element.Class + + 770 + 730 + 200 + 80 + + *ComponentDefinition* +-- +-name : "Casamino Acids" +-types : [chebi:CHEBI:33709] +... + + + + com.baselet.element.old.element.Class + + 1030 + 590 + 200 + 80 + + *ComponentDefinition* +-- +-name : "MgSO4" +-types : [chebi:CHEBI:32599] +... + + + + com.baselet.element.old.element.Class + + 530 + 590 + 190 + 80 + + *ComponentDefinition* +-- +-name : "CaCl2" +-types : [chebi:CHEBI:3312] +... + + + + com.baselet.element.old.element.Class + + 750 + 590 + 200 + 80 + + *ModuleDefinition* +-- +-name : "Teknova M1902" +-roles : [obo:NCIT_C85504] +... + + + + com.baselet.element.old.element.Class + + 560 + 480 + 90 + 30 + + *Func.Comp.* + + + + com.baselet.element.old.element.Class + + 540 + 380 + 670 + 150 + + *ModuleDefinition* +-- +-name : "M9 Glucose CAA" +-role : [obo:NCIT_C85504] +... + + + + com.baselet.element.old.element.Class + + 670 + 480 + 90 + 30 + + *Func.Comp.* + + + + com.baselet.element.old.element.Class + + 880 + 480 + 90 + 30 + + *Func.Comp.* + + + + com.baselet.element.old.element.Class + + 990 + 480 + 90 + 30 + + *Func.Comp.* + + + + com.baselet.element.old.element.Class + + 1100 + 480 + 90 + 30 + + *Func.Comp.* + + + + com.baselet.element.old.element.Relation + + 430 + 480 + 220 + 270 + + lt=<<<-> +definition + 170;30;170;80;60;80;60;220;200;220;200;250 + + + com.baselet.element.old.element.Relation + + 1080 + 480 + 244 + 270 + + lt=<<<-> +definition + 60;30;60;80;190;80;190;220;30;220;30;250 + + + com.baselet.element.old.element.Relation + + 600 + 480 + 130 + 130 + + lt=<<<-> +definition + 110;30;110;80;30;80;30;110 + + + com.baselet.element.old.element.Relation + + 1000 + 480 + 130 + 130 + + lt=<<<-> +definition + 30;30;30;80;110;80;110;110 + + + com.baselet.element.old.element.Relation + + 780 + 480 + 130 + 130 + + lt=<<<-> +definition + 30;30;30;80;110;80;110;110 + + + com.baselet.element.old.element.Relation + + 840 + 480 + 204 + 270 + + lt=<<<-> +definition + 90;30;90;80;150;80;150;220;30;220;30;250 + + + com.baselet.element.old.element.Class + + 770 + 250 + 200 + 100 + + *Measure* +-- +-hasNum.Value : 11.28 +-hasUnit : om:gramPerLitre +-types : [sbo:SBO:0000226] +... + + + + com.baselet.element.old.element.Class + + 1060 + 250 + 190 + 100 + + *Measure* +-- +-hasNum.Value : 0.34 +-hasUnit : om:gramPerLitre +-types : [sbo:SBO:0000226] +... + + + + com.baselet.element.old.element.Class + + 1060 + 90 + 190 + 100 + + *Measure* +-- +-hasNum.Value : 2 +-hasUnit : om:millimolair +-types : [sbo:SBO:0000196] +... + + + + com.baselet.element.old.element.Class + + 490 + 90 + 190 + 100 + + *Measure* +-- +-hasNum.Value : 0.1 +-hasUnit : om:millimolair +-types : [sbo:SBO:0000196] +... + + + + com.baselet.element.old.element.Class + + 770 + 90 + 200 + 100 + + *Measure* +-- +-hasNum.Value : 0.2 +-hasUnit : om:gramPerGram +-types : [sbol:SBO:0000470] +... + + + + com.baselet.element.old.element.Class + + 490 + 250 + 190 + 100 + + *Measure* +-- +-hasNum.Value : 0.4 +-hasUnit : om:gramPerGram +-types : [sbo:SBO:0000470] + +... + + + + com.baselet.element.old.element.Relation + + 1120 + 170 + 212 + 340 + + lt=<<<<-> +measure + 70;320;160;320;160;50;30;50;30;80 + + + com.baselet.element.old.element.Relation + + 1000 + 10 + 170 + 490 + + lt=<<<<-> +measure + 30;470;30;50;150;50;150;80 + + + com.baselet.element.old.element.Relation + + 400 + 170 + 210 + 340 + + lt=<<<<-> +measure + 160;320;60;320;60;50;190;50;190;80 + + + com.baselet.element.old.element.Relation + + 560 + 10 + 170 + 490 + + lt=<<<<-> +measure + 150;470;150;50;30;50;30;80 + + + com.baselet.element.old.element.Relation + + 840 + 30 + 212 + 470 + + lt=<<<<-> +measure + 90;450;90;410;160;410;160;30;30;30;30;60 + + + com.baselet.element.old.element.Relation + + 680 + 190 + 210 + 310 + + lt=<<<<-> +measure + 130;290;130;250;60;250;60;30;190;30;190;60 + + diff --git a/umlet_source/module_2.3.uxf b/umlet_source/module_2.3.uxf new file mode 100644 index 00000000..f44df63b --- /dev/null +++ b/umlet_source/module_2.3.uxf @@ -0,0 +1,122 @@ + + + 10 + + com.baselet.element.old.element.Class + + 570 + 280 + 100 + 90 + + *Module* +-- + + + + + + + + com.baselet.element.old.element.Relation + + 590 + 220 + 50 + 80 + + lt=<<- + 30;30;30;60 + + + com.baselet.element.old.element.Class + + 570 + 220 + 100 + 30 + + /*Identified*/ + + + + com.baselet.element.old.element.Relation + + 640 + 260 + 170 + 94 + + lt=<<<<-> +mapsTos +0..* + 30;50;150;50 + + + com.baselet.element.old.element.Class + + 790 + 300 + 90 + 30 + + *MapsTo* + + + + + + + + com.baselet.element.old.element.Relation + + 410 + 280 + 180 + 110 + + lt=<<<-> +definition + 1 + 160;50;60;50;60;90 + + + com.baselet.element.old.element.Class + + 390 + 370 + 160 + 30 + + *ModuleDefinition* + + + + com.baselet.element.old.element.Class + + 790 + 350 + 90 + 30 + + *Measure* + + + + + + + + com.baselet.element.old.element.Relation + + 640 + 310 + 170 + 94 + + lt=<<<<-> +measures +0..* + 30;50;150;50 + + diff --git a/umlet_source/om.uxf b/umlet_source/om.uxf new file mode 100644 index 00000000..fe068164 --- /dev/null +++ b/umlet_source/om.uxf @@ -0,0 +1,368 @@ + + + 10 + + com.baselet.element.old.element.Class + + 240 + 210 + 220 + 70 + + *Measure* +-- +-hasNumericalValue[1] : xsd:float +-types[0..*] : URI + + + + + com.baselet.element.old.element.Class + + 590 + 90 + 100 + 30 + + */Identified/* + + + + com.baselet.element.old.element.Relation + + 630 + 90 + 320 + 100 + + lt=<<- + 30;30;30;60;300;60;300;80 + + + com.baselet.element.old.element.Class + + 880 + 170 + 100 + 30 + + */TopLevel/* + + + + com.baselet.element.old.element.Relation + + 640 + 170 + 290 + 100 + + lt=<<- + 270;30;270;60;30;60;30;80 + + + com.baselet.element.old.element.Class + + 560 + 250 + 220 + 130 + + */Unit/* +-- +-symbol[1] : String +-alternativeSymbols[0..*] : String +-label[1] : String +-alternativeLabels[0..*] : String +-comment[0..1] : String +-longcomment[0..1] : String + + + + com.baselet.element.old.element.Relation + + 320 + 90 + 320 + 140 + + lt=<<- + 300;30;300;60;30;60;30;120 + + + com.baselet.element.old.element.Relation + + 430 + 450 + 220 + 110 + + lt=<<- + 200;30;200;70;30;70;30;90 + + + com.baselet.element.old.element.Class + + 370 + 540 + 180 + 70 + + *UnitMultiplication* +-- +-hasTerm1[1] : Unit +-hasTerm2[1] : Unit + + + + com.baselet.element.old.element.Class + + 790 + 540 + 200 + 70 + + *UnitExponentiation* +-- +-hasBase[1] : Unit +-hasExponent[1] : xsd:integer + + + + com.baselet.element.old.element.Class + + 580 + 540 + 180 + 70 + + *UnitDivision* +-- +-hasNumerator[1] : Unit +-hasDenominator[1] : Unit + + + + com.baselet.element.old.element.Class + + 770 + 430 + 180 + 70 + + *PrefixedUnit* +-- + + + + com.baselet.element.old.element.Relation + + 640 + 450 + 50 + 110 + + lt=<<- + 30;30;30;90 + + + com.baselet.element.old.element.Class + + 1080 + 480 + 220 + 150 + + */Prefix/* +-- +-symbol[1] : String +-alternativeSymbols[0..*] : String +-label[1] : String +-alternativeLabels[0..*] : String +-comment[0..1] : String +-longcomment[0..1] : String +-hasFactor[1] : xsd:float + + + + com.baselet.element.old.element.Relation + + 920 + 170 + 290 + 330 + + lt=<<- + 30;30;30;60;270;60;270;310 + + + com.baselet.element.old.element.Relation + + 1080 + 600 + 90 + 100 + + lt=<<- + 70;30;70;30;70;60;30;60;30;80 + + + com.baselet.element.old.element.Relation + + 1200 + 600 + 90 + 100 + + lt=<<- + 30;30;30;30;30;60;70;60;70;80 + + + com.baselet.element.old.element.Class + + 390 + 430 + 180 + 50 + + *SingularUnit* +-- +-hasFactor[0..1] : xsd:float + + + + com.baselet.element.old.element.Relation + + 430 + 210 + 150 + 94 + + lt=<<<-> +hasUnit +1 + 30;50;130;50 + + + com.baselet.element.old.element.Class + + 1210 + 680 + 120 + 50 + + *BinaryPrefix* +-- + + + + + com.baselet.element.old.element.Class + + 600 + 430 + 140 + 50 + + */CompoundUnit/* +-- + + + + + com.baselet.element.old.element.Relation + + 680 + 450 + 220 + 110 + + lt=<<- + 30;30;30;70;200;70;200;90 + + + com.baselet.element.old.element.Relation + + 450 + 350 + 200 + 100 + + lt=<<- + 180;30;180;60;30;60;30;80 + + + com.baselet.element.old.element.Relation + + 680 + 350 + 200 + 100 + + lt=<<- + 30;30;30;60;180;60;180;80 + + + com.baselet.element.old.element.Class + + 1050 + 680 + 120 + 50 + + *SIPrefix* +-- + + + + + com.baselet.element.old.element.Relation + + 640 + 350 + 50 + 100 + + lt=<<- + 30;30;30;80 + + + com.baselet.element.old.element.Relation + + 920 + 440 + 180 + 94 + + lt=<<<-> +hasPrefix +1 + 30;50;160;50 + + + com.baselet.element.old.element.Relation + + 290 + 280 + 290 + 200 + + lt=<<<-> + hasUnit + 0..1 + 100;180;60;180;60;30;270;30 + + + com.baselet.element.old.element.Relation + + 750 + 230 + 286 + 250 + + lt=<<<-> + hasUnit + 1 + 200;230;240;230;240;30;30;30 + + diff --git a/umlet_source/participation_2.3.uxf b/umlet_source/participation_2.3.uxf new file mode 100644 index 00000000..93782cb0 --- /dev/null +++ b/umlet_source/participation_2.3.uxf @@ -0,0 +1,104 @@ + + + 10 + + com.baselet.element.old.element.Class + + 660 + 350 + 120 + 50 + + *Participation* +-- +-roles[1..*] : URI + + + + + + + + com.baselet.element.old.element.Relation + + 690 + 290 + 50 + 80 + + lt=<<- + 30;30;30;60 + + + com.baselet.element.old.element.Class + + 670 + 290 + 100 + 30 + + +/*Identified*/ + + + + + + + com.baselet.element.old.element.Class + + 800 + 420 + 180 + 30 + + *FunctionalComponent* + + + + + + com.baselet.element.old.element.Relation + + 750 + 330 + 192 + 110 + + lt=<->>> +participant + 1 + + 140;90;140;50;30;50 + + + com.baselet.element.old.element.Class + + 550 + 420 + 90 + 30 + + *Measure* + + + + + + + + + com.baselet.element.old.element.Relation + + 540 + 330 + 140 + 110 + + lt=<->>>> +measures +0..* + + 60;90;60;50;120;50 + +