diff --git a/.gitignore b/.gitignore index 9ac33f7a..1ac7b0ed 100755 --- a/.gitignore +++ b/.gitignore @@ -1,10 +1,10 @@ .DS_Store -sbol2.aux -sbol2.bbl -sbol2.blg -sbol2.cb -sbol2.cb2 -sbol2.log -sbol2.out -sbol2.pdf -sbol2.toc +sbol3.aux +sbol3.bbl +sbol3.blg +sbol3.cb +sbol3.cb2 +sbol3.log +sbol3.out +sbol3.pdf +sbol3.toc diff --git a/apdx-validation.tex b/apdx-validation.tex index fa5f058d..4102acd1 100644 --- a/apdx-validation.tex +++ b/apdx-validation.tex @@ -15,7 +15,6 @@ \section{Validation Rules} following symbols next to the rule numbers: -\twozeroone{ \begin{description} \item[\hspace*{6.5pt}\vSymbol\vsp] A \vSymbolName indicates a strong REQUIRED condition for SBOL conformance. If a SBOL document does not follow this rule, it does not conform to the SBOL @@ -38,7 +37,7 @@ \section{Validation Rules} \item[\hspace*{6.5pt}\cSymbol\csp] A \cSymbolName indicates a weak REQUIRED condition for SBOL conformance. While this rule MUST be followed, it is not possible in practice for a machine to automatically check whether the rule has been followed. % (Mnemonic intention behind the choice of symbol: ``This is a cause for warning.'') \end{description} -} + The validation rules listed in the following subsections are all believed to be stated or implied in the rest of this specification document. They @@ -62,33 +61,29 @@ \subsubsection*{General rules for an SBOL document} \printValid{An SBOL document MUST declare the use of the following XML namespace: \\ \textls[-25]{\uri{http://sbols.org/v2\#}}.\\ Reference: \sec{sec:serialization}} -\twozeroone{ + \printValid{\st{An SBOL document MUST declare the use of the following XML namespace: \\ {\tt http://www.w3.org/1999/02/22-rdf-syntax-ns\#}. \\ Reference: Section 10 on page 54}} -} -\twozeroone{ + \printValid{\st{ If an SBOL document includes any name or description properties, then it MUST declare the use of the following XML namespace: \\ {\tt http://purl.org/dc/terms/}. \\ Reference: Section 10 on page 54}} -} -\twozeroone{ + \printValid{\st{ If an SBOL document includes any wasDerivedFrom properties, then it MUST declare the use of the following XML namespace: \\ {\tt http://www.w3.org/ns/prov\#}. \\ Reference: Section 10 on page 54}} -} -\twozeroone{ + \printValid{An SBOL document MUST be serialized as a well-formed RDF/XML file that adheres to the grammar defined by:\\ \uri{https://www.w3.org/TR/rdf-syntax-grammar/}.\\ Reference: \sec{sec:serialization}} -} -\twotwoone{ + \printValid{All namespaces specified in an SBOL document MUST end with a delimiter ('/', '\#', or ':').\\ Reference: \sec{sec:serialization}} -} + \subsubsection*{Rules for the \class{Identified} class} \setcounter{sbolCtr}{10201} @@ -97,10 +92,10 @@ \subsubsection*{Rules for the \class{Identified} class} \uri{http://www.w3.org/TR/xmlschema11-2/\#anyURI}\\ Reference: \sec{sec:Identified}} -\twozeroone{ + \printComplete{The \sbol{identity} property of an \sbol{Identified} object MUST be globally unique. \\ Reference: \sec{sec:Identified}} -} + \printValid{The \sbol{persistentIdentity} property of an \sbol{Identified} object is OPTIONAL and MAY contain a \sbol{URI} that MUST adhere to the syntax defined by:\\ \uri{http://www.w3.org/TR/xmlschema11-2/\#anyURI}\\ @@ -108,37 +103,36 @@ \subsubsection*{Rules for the \class{Identified} class} \printValid{The \sbol{displayId} property of an \sbol{Identified} object is OPTIONAL and MAY contain a \sbol{String} that MUST be composed of only alphanumeric or underscore characters and MUST NOT begin with a digit.\\ Reference: \sec{sec:Identified}} -\twozeroone{ + \printModeling{\st{The displayId property of an Identified object SHOULD be locally unique. \\ Reference: Section 7.4 on page 16}} -} + \printValid{The \sbol{version} property of an \sbol{Identified} object is OPTIONAL and MAY contain a \sbol{String} that MUST be composed of only alphanumeric characters, underscores, hyphens, or periods and MUST begin with a digit.\\ Reference: \sec{sec:Identified}} %\printModeling{The \sbol{version} property of an \sbol{Identified} object SHOULD follow the conventions of semantic versioning as implemented by Maven. \\ %Reference: \sec{sec:Identified}} -\twozeroone{\printModeling{(moved to sbol-10302)}} +\printModeling{(moved to sbol-10302)} + -\twotwozero{ \printValid{The \sbol{wasDerivedFroms} property of an \sbol{Identified} object is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:Identified}} -} -\twozeroone{ + \printValid{(moved to sbol-10303)} \printComplete{(moved to sbol-10304)} \printWarning{(moved to sbol-10305)} -} + \printValid{The \sbol{name} property of an \sbol{Identified} object is OPTIONAL and MAY contain a \sbol{String}. \\ Reference: \sec{sec:Identified}} \printValid{The \sbol{description} property of an \sbol{Identified} object is OPTIONAL and MAY contain a \sbol{String}. \\ Reference: \sec{sec:Identified}} -\twozeroone{ + \printWarning{The \sbol{annotations} property of an \sbol{Identified} object is OPTIONAL and MAY contain a set of \sbol{Annotation} objects.\\ Reference: \sec{sec:Identified}} -} + \printModeling{The \sbol{displayId} property of a compliant \sbol{Identified} object is REQUIRED. \\ Reference: \sec{sec:compliant}} @@ -151,26 +145,21 @@ \subsubsection*{Rules for the \class{Identified} class} \printModeling{The \sbol{version} property of a compliant \sbol{Identified} object that is not also a \sbol{TopLevel} object is REQUIRED to contain the same \sbol{String} as the \sbol{version} property of the compliant object's parent.\\ Reference: \sec{sec:compliant}} -\twozeroone{ + \printValid{Objects with the same \sbol{persistentIdentity} MUST be instances of the same class.\\ Reference: \sec{sec:Identified}} -} -\twotwozero{ + \printValid{The \sbol{wasGeneratedBys} property of an \sbol{Identified} object is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:provenance}} -} -\twotwozero{ + \printComplete{Each \sbol{URI} contained by the \sbol{wasGeneratedBys} property of an \sbol{Identified} object MUST refer to an \sbol{Activity} object.\\ Reference: \sec{sec:provenance}} -} -\twotwoone{ + \printComplete{Provenance history formed by \sbol{wasGeneratedBys} properties of \sbol{Identified} objects and\\ \sbol{entity} references in \sbol{Usage} objects MUST NOT form circular reference chains. \\ Reference: \sec{sec:wasGeneratedBys}} -} -\twotwozero{ \printModeling{An \sbol{Identified} with a \sbol{wasGeneratedBys} property that includes a reference to an \sbol{Activity} with a child \sbol{Association} that has a \sbolmult{roles:A}{roles} property that contains the \sbol{URI}~\url{http://sbols.org/v2\#design} SHOULD be a \sbol{TopLevel} object other than \sbol{Implementation}.\\ Reference: \sec{sec:provenance}} @@ -182,46 +171,43 @@ \subsubsection*{Rules for the \class{Identified} class} \printModeling{An \sbol{Identified} with a \sbol{wasGeneratedBys} property that includes a reference to an \sbol{Activity} with a child \sbol{Association} that has a \sbolmult{roles:A}{roles} property that contains the \sbol{URI}~\url{http://sbols.org/v2\#learn} SHOULD not be an \sbol{Implementation}.\\ Reference: \sec{sec:provenance}} -} -\twotwoone{ + \printValid{An \sbol{Identified} object must have no more than one \sbol{rdfType} property in each of the\\ \uri{http://sbols.org/v2\#} and \uri{http://www.w3.org/ns/prov\#} namespaces. \\ Reference: \sec{sec:Identified}} -} + \subsubsection*{Rules for the \class{TopLevel} class} \setcounter{sbolCtr}{10301} -\twozeroone{ + \printValid{\st{A TopLevel object MUST inherit all properties of the Identified class. \\ Reference: Section 7.5 on page 19}} -\printModeling{If the \twotwozero{\sbol{wasDerivedFroms}} property of one \sbol{TopLevel} object refers to another \sbol{TopLevel} object with the same \sbol{persistentIdentity} property, then the \sbol{version} property of the second \sbol{TopLevel} object SHOULD precede that of the first if both objects have a \sbol{version} and it is assumed that these \sbol{version}s follow the conventions of semantic versioning.\\ Reference: \sec{sec:Identified}} +\printModeling{If the \sbol{wasDerivedFroms} property of one \sbol{TopLevel} object refers to another \sbol{TopLevel} object with the same \sbol{persistentIdentity} property, then the \sbol{version} property of the second \sbol{TopLevel} object SHOULD precede that of the first if both objects have a \sbol{version} and it is assumed that these \sbol{version}s follow the conventions of semantic versioning.\\ Reference: \sec{sec:Identified}} -\printValid{The \twotwozero{\sbol{wasDerivedFroms}} property of an \sbol{TopLevel} object MUST NOT contain a \sbol{URI} reference to the \sbol{TopLevel} object itself.\\ Reference: \sec{sec:Identified}} +\printValid{The \sbol{wasDerivedFroms} property of an \sbol{TopLevel} object MUST NOT contain a \sbol{URI} reference to the \sbol{TopLevel} object itself.\\ Reference: \sec{sec:Identified}} -\printComplete{\sbol{TopLevel} objects MUST NOT form circular reference chains via their \twotwozero{\sbol{wasDerivedFroms}} properties.\\ Reference: \sec{sec:Identified}} +\printComplete{\sbol{TopLevel} objects MUST NOT form circular reference chains via their \sbol{wasDerivedFroms} properties.\\ Reference: \sec{sec:Identified}} + +\printWarning{If the \sbol{wasDerivedFroms} property of one \sbol{TopLevel} object refers to another \sbol{TopLevel} object with the same \sbol{persistentIdentity} property, then \sbol{version} property of the second \sbol{TopLevel} object MUST precede that of the first if both objects have a \sbol{version}.\\ Reference: \sec{sec:Identified}} -\printWarning{If the \twotwozero{\sbol{wasDerivedFroms}} property of one \sbol{TopLevel} object refers to another \sbol{TopLevel} object with the same \sbol{persistentIdentity} property, then \sbol{version} property of the second \sbol{TopLevel} object MUST precede that of the first if both objects have a \sbol{version}.\\ Reference: \sec{sec:Identified}} -} -\twotwoone{ \printValid{The \sbol{attachments} property of a \sbol{TopLevel} is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:TopLevel}} -} -\twotwoone{ + \printComplete{Each \sbol{URI} contained by the \sbol{attachments} property of a \sbol{TopLevel} MUST refer to an \sbol{Attachment} object. \\ Reference: \sec{sec:TopLevel}} -} + \subsubsection*{Rules for the \class{Sequence} class} \setcounter{sbolCtr}{10401} -\twozeroone{ -\printValid{A \sbol{Sequence} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name},\\ \sbol{description}, \sbol{annotations}, \sbol{elements}, and \sbol{encoding}.\\ Reference: \sec{sec:Sequence}} + +\printValid{A \sbol{Sequence} 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{elements}, and \sbol{encoding}.\\ Reference: \sec{sec:Sequence}} % A \sbol{Sequence} MUST inherit all properties of the \sbol{TopLevel} class. -} + \printValid{The \sbol{elements} property of a \sbol{Sequence} is REQUIRED and MUST contain a \sbol{String}.\\ Reference: \sec{sec:Sequence}} @@ -229,24 +215,22 @@ \subsubsection*{Rules for the \class{Sequence} class} \printWarning{The \sbol{encoding} property of a \sbol{Sequence} MUST indicate how the \sbol{elements} property of the \sbol{Sequence} is to be formed and interpreted.\\ Reference: \sec{sec:Sequence}} -\twozeroone{ + \printComplete{The \sbol{elements} property of a \sbol{Sequence} MUST be consistent with its \sbol{encoding} property.\\ Reference: \sec{sec:Sequence}} -} + \printWarning{The \sbol{encoding} property of a \sbol{Sequence} MUST contain a \sbol{URI} from \ref{tbl:sequence_encodings} if it is well-described by this \sbol{URI}.\\ Reference: \sec{sec:Sequence}} -\twozeroone{ + \printModeling{The \sbol{encoding} property of a \sbol{Sequence} SHOULD contain a \sbol{URI} from \ref{tbl:sequence_encodings}.\\ Reference: \sec{sec:Sequence}} -} + \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{10501} -\twozeroone{ -\printValid{A \sbol{SubComponent} MUST NOT have properties other than the following: \sbol{identity}, \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{types:CD}{types}, \sbolmult{roles:CD}{roles}, \sbol{components}, \sbol{sequences}, \\ \sbol{sequenceAnnotations}, and \sbol{sequenceConstraints}.\\ +\printValid{A \sbol{SubComponent} 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:CD}{types}, \sbolmult{roles:CD}{roles}, \sbol{components}, \sbol{sequences}, \\ \sbol{sequenceAnnotations}, and \sbol{sequenceConstraints}.\\ Reference: \sec{sec:SubComponent}} %A \sbol{SubComponent} MUST inherit all properties of the \sbol{TopLevel} class.} -} \printValid{The \sbolmult{types:CD}{types} property of a \sbol{SubComponent} is REQUIRED and MUST contain a non-empty set of \sbol{URI}s.\\ Reference: \sec{sec:Component}} @@ -266,19 +250,17 @@ \subsubsection*{Rules for the \class{SubComponent} class} \printWarning{The \sbolmult{roles:CD}{roles} property of a \sbol{SubComponent} MUST contain a \sbol{URI} from \ref{tbl:component_roles} if it is well-described by this \sbol{URI}.\\ Reference: \sec{sec:Component}} -\twozeroone{ + \printModeling{ The \sbolmult{roles:CD}{roles} property of a \sbol{SubComponent} SHOULD NOT contain a \sbol{URI} that refers to a term from the sequence feature branch of the SO unless its \sbolmult{types:CD}{types} property contains the DNA or RNA type \sbol{URI} listed in \ref{tbl:component_types}. %The \sbolmult{roles:CD}{roles} property of a \sbol{SubComponent} SHOULD only contain a \sbol{URI} provided in \ref{tbl:component_roles} if one of its \sbolmult{types:CD}{types} is cross-listed with this \sbol{URI}. \\ Reference: \sec{sec:Component}} %\\ Reference: \sec{sec:recomm_ontologies}} -} + \printValid{The \sbol{sequences} property of a \sbol{SubComponent} is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:Component}} -\twozeroone{ \printComplete{Each \sbol{URI} contained by the \sbol{sequences} property of a \sbol{SubComponent} MUST refer to a \sbol{Sequence} object.\\ Reference: \sec{sec:Component}} -} \printWarning{The \sbol{Sequence} objects referred to by the \sbol{sequences} property of a \sbol{SubComponent} MUST be consistent with each other, such that well-defined mappings exist between their \sbol{elements} properties in accordance with their \sbol{encoding} properties.\\ Reference: \sec{sec:Component}} @@ -287,13 +269,12 @@ \subsubsection*{Rules for the \class{SubComponent} class} % Redundant since subsumed by previous rule of equivalent strength % \printWarning{The \sbol{sequences} property of a \sbol{SubComponent} MUST NOT refer to \sbol{Sequence} objects with conflicting \external{IUPAC} \sbol{encoding} \external{URI}s from \ref{tbl:sequence_encodings}.\\ Reference: \sec{sec:Component}} -\twozeroone{ \printComplete{If the \sbol{sequences} property of a \sbol{SubComponent} refers to one or more \sbol{Sequence} objects, and one of the \sbolmult{types:CD}{types} of this \sbol{SubComponent} comes from \ref{tbl:component_types}, then one of the \sbol{Sequence} objects MUST have the \sbol{encoding} that is cross-listed with this type in \ref{tbl:sequence_encodings}.\\ Reference: \sec{sec:Component}} \printWarning{\st{If the sequences property of a Component refers to a Sequence with an encoding from Table 1, then the types property of the Component MUST contain the type from Table 2 that is cross-listed with this encoding in Table 1. \\ Reference: Section 7.7 on page 21}} -} + \printModeling{If a \sbol{SubComponent} refers to more than one \sbol{Sequence} with the same \sbol{encoding}, then the \sbol{elements} of these \sbol{Sequence} objects SHOULD have equal lengths.\\ Reference: \sec{sec:Component}} @@ -309,7 +290,6 @@ \subsubsection*{Rules for the \class{SubComponent} class} \printValid{The \sbol{sequenceConstraints} property of a \sbol{SubComponent} is OPTIONAL and MAY contain a set of \sbol{SequenceConstraint} objects. \\ Reference: \sec{sec:Component}} -\twozeroone{ \printModeling{The \sbolmult{types:CD}{types} property of a \sbol{SubComponent} SHOULD contain a \sbol{URI} from \ref{tbl:component_types}.\\ Reference: \sec{sec:Component}} \printValid{If multiple \sbol{MapsTo}s belonging to the \sbol{SubComponent}s of a \sbol{SubComponent} have \sbol{local} properties that refer to the same \sbol{SubComponent}, then there MUST NOT be more than one such \sbol{MapsTo} that has a \sbol{refinement} property that contains the \sbol{URI}~\url{http://sbols.org/v2\#useRemote}.\\ Reference: \sec{sec:MapsTo}} @@ -319,12 +299,9 @@ \subsubsection*{Rules for the \class{SubComponent} class} \printModeling{If the \sbolmult{types:CD}{types} property of a \sbol{SubComponent} contains the DNA or RNA type \sbol{URI}, then its \sbolmult{types:CD}{roles} property SHOULD contain exactly one \sbol{URI} that refers to a term from the sequence feature branch of the SO.\\ Reference: \sec{sec:Component}} -} -\twoonezero{ \printModeling{If the \sbolmult{types:CD}{types} property of a \sbol{SubComponent} contains the DNA or RNA type \sbol{URI}, then its \sbolmult{types:CD}{types} property SHOULD also contain at most one \sbol{URI} that refers to a term from the topology attribute branch of the SO.\\ Reference: \sec{sec:Component}} -} %\printModeling{If the \sbolmult{types:CD}{types} property of %a \sbol{SubComponent} contains the DNA type \sbol{URI}, then it SHOULD @@ -333,15 +310,11 @@ \subsubsection*{Rules for the \class{SubComponent} class} %Reference: \sec{sec:Component}} %} -\twoonezero{ \printModeling{ The \sbolmult{roles:CD}{types} property of a \sbol{SubComponent} SHOULD NOT contain a \sbol{URI} that refers to a term from the topology attribute or strand attribute branches of the SO unless its \sbolmult{types:CD}{types} property contains the DNA or RNA type \sbol{URI} listed in \ref{tbl:component_types}. Reference: \sec{sec:Component}} -} -\twoonezero{ \printWarning{If the \sbolmult{types:CD}{types} property of a \sbol{SubComponent} contains the DNA or RNA type \sbol{URI}, then its \sbolmult{types:CD}{types} property MUST contain a \sbol{URI} that refers to a term from the topology attribute branch of the SO, if the topology is known.\\ Reference: \sec{sec:Component}} -} %\twoonezero{ %\printValid{If the \sbolmult{types:CD}{types} property of @@ -355,20 +328,18 @@ \subsubsection*{Rules for the \class{SubComponent} class} \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{10601} -\twozeroone{ + \printValid{\st{A ComponentInstance MUST inherit all properties of the Identified class. \\ Reference: Section 7.7.1 on page 24}} -} + \printValid{The \sbolmult{instanceOf:CI}{instanceOf} property of a \sbol{SubComponent} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:ComponentInstance}} \printValid{The \sbolmult{instanceOf:CI}{instanceOf} property of a \sbol{SubComponent} MUST NOT contain a \sbol{URI} reference to the \sbol{SubComponent} that contains the \sbol{SubComponent}.\\ Reference: \sec{sec:ComponentInstance}} -\twozeroone{ \printComplete{The \sbol{URI} contained by the \sbolmult{instanceOf:CI}{instanceOf} property MUST refer to a \sbol{SubComponent} object.\\ Reference: \sec{sec:ComponentInstance}} \printComplete{\sbol{SubComponent} objects MUST NOT form circular reference chains via their \sbolmult{instanceOf:CI}{instanceOf} properties and parent \sbol{SubComponent} objects.\\ Reference: \sec{sec:ComponentInstance}} -} \printValid{The \sbolmult{mapsTos:CI}{mapsTos} property of a \sbol{SubComponent} is OPTIONAL and MAY contain a set of \sbol{MapsTo} objects.\\ Reference: \sec{sec:ComponentInstance}} @@ -377,57 +348,39 @@ \subsubsection*{Rules for the \class{SubComponent} class} \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{10701} -\twoonezero{ -\printValid{A \sbol{SubComponent} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, +\printValid{A \sbol{SubComponent} 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{access}, \sbolmult{instanceOf:CI}{instanceOf}, \sbolmult{mapsTos:CI}{mapsTos}, \sbolmult{roles:C}{roles}, and\\ \sbolmult{roleIntegration:C}{roleIntegration}.\\ Reference: \sec{sec:SubComponent}} % A \sbol{SubComponent} MUST inherit all properties of the \sbol{SubComponent} class. -} -\twoonezero{ \printValid{The \sbolmult{roles:C}{roles} property of a \sbol{SubComponent} is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printWarning{Each \sbol{URI} contained by the \sbolmult{roles:C}{roles} property of a \sbol{SubComponent} MUST refer to an ontology term that clarifies the potential function of the \sbol{SubComponent} in a biochemical or physical context.\\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printWarning{Each \sbol{URI} contained by the \sbolmult{roles:C}{roles} property of a \sbol{SubComponent} MUST refer to an ontology term that is consistent with the \sbolmult{types:CD}{types} property of the \sbol{SubComponent} referred to by its \sbolmult{instanceOf:CI}{instanceOf} property.\\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printWarning{The \sbolmult{roles:C}{roles} property of a \sbol{SubComponent} MUST contain a \sbol{URI} from \ref{tbl:component_roles} if it is well-described by this \sbol{URI}.\\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printModeling{ The \sbolmult{roles:C}{roles} property of a \sbol{SubComponent} SHOULD NOT contain a \sbol{URI} that refers to a term from the sequence feature branch of the SO unless the \sbolmult{types:CD}{types} property of the \sbol{SubComponent} referred to by its \sbolmult{instanceOf:CI}{instanceOf} property contains the DNA or RNA type \sbol{URI} listed in \ref{tbl:component_types}. \\ Reference: \sec{sec:SubComponent}} } -\twoonezero{ \printModeling{If the \sbolmult{types:CD}{types} property of the \sbol{SubComponent} referred to by its \sbolmult{instanceOf:CI}{instanceOf} contains the DNA or RNA type \sbol{URI}, then its \sbolmult{roles:C}{roles} property SHOULD contain no more than one \sbol{URI} that refers to a term from the sequence feature branch of the SO.\\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printValid{The \sbolmult{roleIntegration:C}{roleIntegration} property of a \sbol{SubComponent}, if provided, MUST contain a \sbol{URI} from \ref{tbl:component_roleIntegration}. \\ Reference: \sec{sec:SubComponent}} -} -\twoonezero{ \printValid{The \sbolmult{roleIntegration:C}{roleIntegration} property of a \sbol{SubComponent} is REQUIRED, if \sbolmult{roles:C}{roles} property includes one or more roles. \\ Reference: \sec{sec:SubComponent}} -} \subsubsection*{Rules for the \class{MapsTo} class} \setcounter{sbolCtr}{10801} -\twozeroone{ \printValid{A \sbol{MapsTo} MUST NOT have properties other than the following: \sbol{identity}, \\ -\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{refinement}, \sbol{local}, and \sbol{remote}\\ Reference: \sec{sec:MapsTo}} +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{refinement}, \sbol{local}, and \sbol{remote}\\ Reference: \sec{sec:MapsTo}} %A \sbol{MapsTo} MUST inherit all properties of the \sbol{Identified} class. -} + \printValid{The \sbol{local} property of a \sbol{MapsTo} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:MapsTo}} @@ -437,7 +390,7 @@ \subsubsection*{Rules for the \class{MapsTo} class} \printValid{The \sbol{remote} property of a \sbol{MapsTo} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:MapsTo}} -\twozeroone{ + \printWarning{\st{The remote property of a MapsTo MUST refer to a ComponentInstance. \\ Reference: Section 7.7.3 on page 26}} @@ -452,17 +405,15 @@ \subsubsection*{Rules for the \class{MapsTo} class} \printValid{The \sbol{refinement} property of a \sbol{MapsTo} is REQUIRED and MUST contain a \sbol{URI} from \ref{tbl:mapsto_refinement}. \\ Reference: \sec{sec:MapsTo}} -\twozeroone{ \printComplete{If the \sbol{refinement} property of a \sbol{MapsTo} contains the \sbol{URI}\\ \url{http://sbols.org/v2\#verifyIdentical}, then the \sbol{SubComponent} objects referred to by \sbol{local} and \sbol{remote} properties of the \sbol{MapsTo} MUST refer to the same \sbol{SubComponent} via their \sbolmult{instanceOf:CI}{instanceOf} properties.\\ Reference: \sec{sec:MapsTo}} -} \subsubsection*{Rules for the \class{SequenceAnnotation} class} \setcounter{sbolCtr}{10901} -\twoonezero{ -\printValid{A \sbol{SequenceAnnotation} MUST NOT have properties other than the following: \sbol{identity}, \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{component}, \sbol{locations}, and \sbolmult{roles:SA}{roles}.\\ Reference: \sec{sec:SequenceAnnotation}} + +\printValid{A \sbol{SequenceAnnotation} 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{component}, \sbol{locations}, and \sbolmult{roles:SA}{roles}.\\ Reference: \sec{sec:SequenceAnnotation}} %A \sbol{SequenceAnnotation} MUST inherit all properties of the \sbol{Identified} class. -} + \printValid{The \sbol{locations} property of a \sbol{SequenceAnnotation} is REQUIRED and MUST contain a non-empty set of \sbol{Location} objects.\\ Reference: \sec{sec:SequenceAnnotation}} @@ -472,48 +423,39 @@ \subsubsection*{Rules for the \class{SequenceAnnotation} class} \printValid{The \sbol{SubComponent} referenced by the \sbol{component} property of a \sbol{SequenceAnnotation} MUST be contained by the \sbol{SubComponent} that contains the \sbol{SequenceAnnotation}.\\ Reference: \sec{sec:SequenceAnnotation}} -\twoonezero{ \printValid{The \sbolmult{roles:SA}{roles} property of a \sbol{SequenceAnnotation} is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:SequenceAnnotation}} -} -\twoonezero{ + \printWarning{Each \sbol{URI} contained by the \sbolmult{roles:SA}{roles} property of a \sbol{SequenceAnnotation} MUST refer to an ontology term that clarifies the potential function of the \sbol{SequenceAnnotation} in a biochemical or physical context.\\ Reference: \sec{sec:SequenceAnnotation}} -} -\twoonezero{ \printWarning{The \sbolmult{roles:SA}{roles} property of a \sbol{SequenceAnnotation} MUST contain a \sbol{URI} from \ref{tbl:component_roles} if it is well-described by this \sbol{URI}.\\ Reference: \sec{sec:SequenceAnnotation}} -} -\twoonezero{ + \printValid{A \sbol{SequenceAnnotation} MUST NOT include both a \sbol{component} property and a \sbolmult{roles:SA}{roles} property.\\ Reference: \sec{sec:SequenceAnnotation}} -} + \subsubsection*{Rules for the \class{Location} class} \setcounter{sbolCtr}{11001} -\twozeroone{ \printValid{\st{A Location MUST inherit all properties of the Identified class. \\ Reference: Section 7.7.5 on page 30}} -} + \printValid{The \sbol{orientation} property of a \sbol{Location} is OPTIONAL and MAY contain a \sbol{URI} from \ref{tbl:orientation_types}. \\ Reference: \sec{sec:GenericLocation}} -\twothreezero{ \printComplete{The \sbol{sequence} property of a \sbol{Location} is OPTIONAL. If present, it MUST contain the URI of a \sbol{Sequence} referenced by the \sbol{SubComponent} containing the \sbol{Location}.\\ Reference: \sec{sec:sequence} -} -} \subsubsection*{Rules for the \class{Range} class} \setcounter{sbolCtr}{11101} -\twozeroone{ + \printValid{A \sbol{Range} MUST NOT have properties other than the following: \sbol{identity}, \\ -\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \twothreezero{\sbol{sequence},} \sbol{orientation}, \sbol{start}, and \sbol{end}.\\ Reference: \sec{sec:Range}} +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{sequence}, \sbol{orientation}, \sbol{start}, and \sbol{end}.\\ Reference: \sec{sec:Range}} % A \sbol{Range} MUST inherit all properties of the \sbol{Location} class. -} + \printValid{The \sbol{start} property of a \sbol{Range} is REQUIRED and MUST contain an \sbol{Integer} greater than zero.\\ Reference: \sec{sec:Range}} @@ -521,53 +463,43 @@ \subsubsection*{Rules for the \class{Range} class} \printValid{The value of the \sbol{end} property of a \sbol{Range} MUST be greater than or equal to the value of its \sbol{start} property.\\ Reference: \sec{sec:Range}} -\twothreezero{ \printComplete{The \sbol{sequence} property of a \sbol{Range} is OPTIONAL. If present, it MUST contain the URI of a \sbol{Sequence} referenced by the \sbol{SubComponent} containing the \sbol{Range}.\\ Reference: \sec{sec:sequence} -} -} \subsubsection*{Rules for the \class{Cut} class} \setcounter{sbolCtr}{11201} -\twozeroone{ -\printValid{A \sbol{Cut} MUST NOT have properties other than the following: \sbol{identity}, \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \\ -\sbol{annotations}, \sbol{orientation}, \twothreezero{\sbol{sequence},} and \sbol{at}.\\ Reference: \sec{sec:Cut}} -} + +\printValid{A \sbol{Cut} 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{orientation}, \sbol{sequence}, and \sbol{at}.\\ Reference: \sec{sec:Cut}} + \printValid{The \sbol{at} property of a \sbol{Cut} is REQUIRED and MUST contain an \sbol{Integer} greater than or equal to zero. \\ Reference: \sec{sec:Cut}} -\twothreezero{ \printComplete{The \sbol{sequence} property of a \sbol{Cut} is OPTIONAL. If present, it MUST contain the URI of a \sbol{Sequence} referenced by the \sbol{SubComponent} containing the \sbol{Cut}.\\ Reference: \sec{sec:sequence} -} -} \subsubsection*{Rules for the \class{GenericLocation} class} \setcounter{sbolCtr}{11301} -\twozeroone{ + \printValid{A \sbol{GenericLocation} MUST NOT have properties other than the following: \sbol{identity},\\ -\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \twothreezero{\sbol{sequence},} and \sbol{orientation}.\\ +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{sequence}, and \sbol{orientation}.\\ Reference: \sec{sec:GenericLocation}} %A \sbol{GenericLocation} MUST inherit all properties of the \sbol{Location} class. -} -\twothreezero{ \printComplete{The \sbol{sequence} property of a \sbol{GenericLocation} is OPTIONAL. If present, it MUST contain the URI of a \sbol{Sequence} referenced by the \sbol{SubComponent} containing the \sbol{GenericLocation}.\\ Reference: \sec{sec:sequence} -} -} \subsubsection*{Rules for the \class{SequenceConstraint} class} \setcounter{sbolCtr}{11401} -\twozeroone{ -\printValid{A \sbol{SequenceConstraint} MUST NOT have properties other than the following: \sbol{identity}, \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{restriction}, \sbol{subject}, and \sbol{object}.\\ Reference: \sec{sec:SequenceConstraint}} + +\printValid{A \sbol{SequenceConstraint} 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{restriction}, \sbol{subject}, and \sbol{object}.\\ Reference: \sec{sec:SequenceConstraint}} %A \sbol{SequenceConstraint} MUST inherit all properties of the \sbol{Identified} class. -} + \printValid{The \sbol{subject} property of a \sbol{SequenceConstraint} is REQUIRED and MUST contain a \sbol{URI} reference to a \sbol{SubComponent}.\\ Reference: \sec{sec:SequenceConstraint}} @@ -585,7 +517,6 @@ \subsubsection*{Rules for the \class{SequenceConstraint} class} \printWarning{The \sbol{URI} contained by the \sbol{restriction} property of a \sbol{SequenceConstraint} MUST indicate the type of structural restriction on the relative, sequence-based positions or orientations of the \sbol{SubComponent} objects referred to by the \sbol{subject} and \sbol{object} properties of the \sbol{SequenceConstraint}. \\ Reference: \sec{sec:SequenceConstraint}} -\twozeroone{ \printComplete{If the \sbol{restriction} property of a \sbol{SequenceConstraint} contains the \sbol{URI}~\url{http://sbols.org/v2\#precedes}, then the position of the \sbol{SubComponent} referred to by the \sbol{subject} property of the \sbol{SequenceConstraint} MUST precede that of the \sbol{SubComponent} referred to by its \sbol{object} property. \\ Reference: \sec{sec:SequenceConstraint}} @@ -594,34 +525,29 @@ \subsubsection*{Rules for the \class{SequenceConstraint} class} \printComplete{If the \sbol{restriction} property of a \sbol{SequenceConstraint} contains the \sbol{URI}~\url{http://sbols.org/v2\#oppositeOrientationAs}, then the orientation of the \sbol{SubComponent} referred to by the \sbol{subject} property of the \sbol{SequenceConstraint} MUST be opposite that of the \sbol{SubComponent} referred to by its \sbol{object} property. \\ Reference: \sec{sec:SequenceConstraint}} -} + \printModeling{The \sbol{URI} contained by the \sbol{restriction} property SHOULD come from \ref{tbl:restriction_types}. \\ Reference: \sec{sec:SequenceConstraint}} -\twotwozero{ \printValid{If the \sbol{restriction} property of a \sbol{SequenceConstraint} contains the \sbol{URI}~\url{http://sbols.org/v2\#differentFrom}, then the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{subject} \sbol{SubComponent} of the \sbol{SequenceConstraint} MUST NOT refer to the the same \sbol{URI} as the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{object} \sbol{SubComponent} of the \sbol{SequenceConstraint}. \\ Reference: \sec{sec:SequenceConstraint}} -} -\twotwoone{ \printComplete{If the \sbol{restriction} property of a \sbol{SequenceConstraint} contains the \sbol{URI}~\url{http://sbols.org/v2\#differentFrom}, then the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{subject} \sbol{SubComponent} of the \sbol{SequenceConstraint} MUST NOT refer to the same object as the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{object} \sbol{SubComponent} of the \sbol{SequenceConstraint}. \\ Reference: \sec{sec:SequenceConstraint}} -} -\twotwoone{ \printComplete{If the \sbol{restriction} property of a \sbol{SequenceConstraint} contains the \sbol{URI}~\url{http://sbols.org/v2\#differentFrom}, then the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{subject} \sbol{SubComponent} of the \sbol{SequenceConstraint} MUST NOT refer to the same object as the \sbolmult{instanceOf:CI}{instanceOf} property of the \sbol{object} \sbol{SubComponent} of the \sbol{SequenceConstraint}. \\ Reference: \sec{sec:SequenceConstraint}} -} + \subsubsection*{Rules for the \class{Model} class} \setcounter{sbolCtr}{11501} -\twozeroone{ + \printValid{A \sbol{Model} MUST NOT have properties other than the following: \sbol{identity}, \\ -\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{source:M}{source}, \sbol{language}, and \sbol{framework}.\\ Reference: \sec{sec:Model}} +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{source:M}{source}, \sbol{language}, and \sbol{framework}.\\ Reference: \sec{sec:Model}} %A \sbol{Model} MUST inherit all properties of the \sbol{TopLevel} class. -} + \printValid{The \sbolmult{source:M}{source} property of a \sbol{Model} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:Model}} @@ -646,10 +572,8 @@ \subsubsection*{Rules for the \class{Model} class} \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{11601} -\twozeroone{ -\printValid{A \sbol{SubComponent} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{roles:MD}{roles}, \sbol{modules}, \sbol{interactions}, \sbol{functionalComponents}, and\\ \sbol{models}.\\ Reference: \sec{sec:Component}} +\printValid{A \sbol{SubComponent} 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{roles:MD}{roles}, \sbol{modules}, \sbol{interactions}, \sbol{functionalComponents}, and\\ \sbol{models}.\\ Reference: \sec{sec:Component}} % A \sbol{SubComponent} MUST inherit all properties of the \sbol{TopLevel} class. -} \printValid{The \sbolmult{roles:MD}{roles} property is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:Component}} @@ -663,7 +587,6 @@ \subsubsection*{Rules for the \class{SubComponent} class} \printValid{The \sbol{models} property is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:Component}} -\twozeroone{ \printComplete{Each \sbol{URI} contained by the \sbol{models} property of a \sbol{SubComponent} MUST refer to a \sbol{Model}.\\ Reference: \sec{sec:Component}} \printValid{If multiple \sbol{MapsTo}s belonging to the \sbol{SubComponent}s and \sbol{SubComponent}s of a \\ @@ -672,33 +595,25 @@ \subsubsection*{Rules for the \class{SubComponent} class} \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{11701} -\twozeroone{ \printValid{A \sbol{SubComponent} MUST NOT have properties other than the following: \sbol{identity}, \\ -\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{instanceOf:M}{instanceOf}, and \sbolmult{mapsTos:M}{mapsTos}.\\ Reference: \sec{sec:SubComponent}} -} +\sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{instanceOf:M}{instanceOf}, and \sbolmult{mapsTos:M}{mapsTos}.\\ Reference: \sec{sec:SubComponent}} \printValid{The \sbolmult{instanceOf:M}{instanceOf} property of a \sbol{SubComponent} is REQUIRED and MUST contain a \sbol{URI}. \\ Reference: \sec{sec:SubComponent}} -\twozeroone{ \printComplete{The \sbol{URI} contained by the \sbolmult{instanceOf:M}{instanceOf} property of \sbol{SubComponent} MUST refer to a\\ \sbol{SubComponent}.\\ Reference: \sec{sec:SubComponent}} -} \printValid{The \sbolmult{instanceOf:CI}{instanceOf} property of a \sbol{SubComponent} MUST NOT contain a \sbol{URI} reference to the\\ \sbol{SubComponent} that contains the \sbol{SubComponent}.\\ Reference: \sec{sec:SubComponent}} -\twozeroone{ \printComplete{\sbol{SubComponent} objects MUST NOT form circular reference chains via their \sbolmult{instanceOf:CI}{instanceOf} properties and parent \sbol{SubComponent} objects.\\ Reference: \sec{sec:SubComponent}} -} \printValid{The \sbolmult{mapsTos:M}{mapsTos} property is OPTIONAL and MAY contain a set of \sbol{MapsTo} objects.\\ Reference: \sec{sec:SubComponent}} \subsubsection*{Rules for the \class{SubComponent} class} \setcounter{sbolCtr}{11801} -\twozeroone{ -\printValid{A \sbol{SubComponent} MUST NOT have properties other than the following: \sbol{identity}, \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbol{access}, \sbolmult{instanceOf:M}{instanceOf}, and \sbolmult{mapsTos:M}{mapsTos}, and \sbol{direction}.\\ Reference: \sec{sec:ComponentInstance}} +\printValid{A \sbol{SubComponent} 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{access}, \sbolmult{instanceOf:M}{instanceOf}, and \sbolmult{mapsTos:M}{mapsTos}, and \sbol{direction}.\\ Reference: \sec{sec:ComponentInstance}} %A \sbol{SubComponent} MUST inherit all properties of the \sbol{SubComponent} class. -} \printValid{The \sbol{direction} property of a \sbol{SubComponent} is REQUIRED and MUST contain a \sbol{URI} from \ref{tbl:functionalcomponent_directions}. \\ Reference: \sec{sec:SubComponent}} @@ -706,11 +621,11 @@ \subsubsection*{Rules for the \class{SubComponent} class} \subsubsection*{Rules for the \class{Interaction} class} \setcounter{sbolCtr}{11901} -\twozeroone{ -\printValid{An \sbol{Interaction} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, + +\printValid{An \sbol{Interaction} 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:I}{types}, and \sbol{participations}.\\ Reference: \sec{sec:Interaction}} %An \sbol{Interaction} MUST inherit all properties of the \sbol{Identified} class. -} + \printValid{The \sbolmult{types:I}{types} property of an \sbol{Interaction} is REQUIRED and MUST contain a non-empty set of \sbol{URI}s.\\ Reference: \sec{sec:Interaction}} @@ -718,78 +633,76 @@ \subsubsection*{Rules for the \class{Interaction} class} \printWarning{All \sbol{URI}s contained by the \sbolmult{types:I}{types} property of an \sbol{Interaction} MUST refer to non-conflicting ontology terms.\\ Reference: \sec{sec:Interaction}} -\twozeroone{ + \printModeling{Exactly one \sbol{URI} contained by the \sbolmult{types:I}{types} property of an \sbol{Interaction} SHOULD refer to a term from the occurring entity relationship branch of the SBO.\\ Reference: \sec{sec:Interaction}} -} + \printValid{The \sbol{participations} property of an \sbol{Interaction} is OPTIONAL and MAY contain a set of \sbol{Participation} objects.\\ Reference: \sec{sec:Interaction}} -\twozeroone{ + \printModeling{If the \sbol{participations} property of an \sbol{Interaction} refers to one or more \sbol{Participation} objects, and one of the \sbolmult{types:I}{types} of this \sbol{Interaction} comes from \ref{tbl:interaction_types}, then the \sbol{Participation} objects SHOULD have a role from the set of \sbolmult{roles:P}{roles} that is cross-listed with this type in \ref{tbl:participant_roles}.\\ 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} -\twozeroone{ -\printValid{A \sbol{Participation} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, \sbol{annotations}, \sbolmult{roles:P}{roles}, and \sbol{participant}.\\ Reference: \sec{sec:Participation}} + +\printValid{A \sbol{Participation} 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{roles:P}{roles}, and \sbol{participant}.\\ Reference: \sec{sec:Participation}} % A \sbol{Participation} MUST inherit all properties of the \sbol{Identified} class. -} + \printValid{The \sbol{participant} property of a \sbol{Participation} is REQUIRED and MUST contain a \sbol{URI} reference to a \sbol{SubComponent}.\\ Reference: \sec{sec:Participation}} \printValid{The \sbol{SubComponent} referenced by the \sbol{participant} property of a \sbol{Participation} MUST be contained by the \sbol{SubComponent} that contains the \sbol{Interaction} which contains the \sbol{Participation}.\\ Reference: \sec{sec:Participation}} -\twozeroone{ + \printValid{The \sbolmult{roles:P}{roles} property of a \sbol{Participation} is REQUIRED and MUST contain a non-empty set of \sbol{URI}s.\\ Reference: \sec{sec:Participation}} -} + \printWarning{Each \sbol{URI} contained by the \sbolmult{roles:P}{roles} property of an \sbol{Participation} MUST refer to an ontology term that describes the behavior represented by the \sbol{Participation}.\\ Reference: \sec{sec:Participation}} \printWarning{All \sbol{URI}s contained by the \sbolmult{roles:P}{roles} property of an \sbol{Participation} MUST refer to non-conflicting ontology terms.\\ Reference: \sec{sec:Participation}} -\twozeroone{ + \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} -\twozeroone{ -\printValid{A \sbol{Collection} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys},} \sbol{name}, \sbol{description}, \sbol{annotations}, and \sbol{members}.\\Reference: \sec{sec:Collection}} -} + +\printValid{A \sbol{Collection} 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}, and \sbol{members}.\\Reference: \sec{sec:Collection}} + \printValid{The \sbol{members} property of a \sbol{Collection} is OPTIONAL and MAY contain a set of \sbol{URI}s.\\ Reference: \sec{sec:Collection}} -\twozeroone{ + \printComplete{Each \sbol{URI} contained by the \sbol{members} property of a \sbol{Collection} MUST reference a \sbol{TopLevel} object.\\ Reference: \sec{sec:Collection}} -} + \subsubsection*{Rules for the \class{Annotation} class} \setcounter{sbolCtr}{12201} -\twotwozero{ + \printValid{The name property of an Annotation is REQUIRED and MUST contain a QName. \\ Reference: \sec{sec:Annotations}} -} -\twozeroone{ + \printValid{\st{The value property of an Annotation is REQUIRED and MUST contain an AnnotationValue. \\ Reference: Section 7.11 on page 46}} -} -\twotwozero{ + + \printValid{An \sbol{AnnotationValue} MUST be a \sbol{literal} (a \sbol{String}, \sbol{Integer}, \sbol{Double}, or \sbol{Boolean}), \sbol{URI}, or a \sbol{NestedAnnotations} object.\\ Reference: \sec{sec:Annotations}} \printValid{The \sbol{nestedQName} property of a \sbol{NestedAnnotations} object is REQUIRED and MUST contain a \sbol{QName}. \\ Reference: \sec{sec:Annotations}} @@ -797,27 +710,29 @@ \subsubsection*{Rules for the \class{Annotation} class} \printValid{The \sbol{nestedURI} property of a \sbol{NestedAnnotations} object is REQUIRED and MUST contain a \sbol{URI}. \\ Reference: \sec{sec:Annotations}} \printValid{The \sbol{annotations} property of a \sbol{NestedAnnotations} object is OPTIONAL and MAY contain a set of \sbol{Annotation} objects. \\ Reference: \sec{sec:Annotations}} -} + \subsubsection*{Rules for the \class{GenericTopLevel} class} \setcounter{sbolCtr}{12301} -\twozeroone{ -\printValid{A \sbol{GenericTopLevel} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}}, \sbol{name}, \sbol{description}, and \sbol{annotations}.\\Reference: \sec{sec:GenericTopLevel}} -} + +\printValid{A \sbol{GenericTopLevel} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name}, \sbol{description}, and \sbol{annotations}.\\Reference: \sec{sec:GenericTopLevel}} + \printValid{The \sbol{rdfType} property of a \sbol{GenericTopLevel} object is REQUIRED and MUST contain a \sbol{QName}.\\ Reference: \sec{sec:GenericTopLevel}} -\twotwoone{ + \printValid{The \sbol{rdfType} property of a \sbol{GenericTopLevel} object MUST NOT contain a \sbol{QName} in the {\uri{http://sbols.org/v2\#}} namespace. \\ Reference: \sec{sec:GenericTopLevel}} -} -\twotwozero{ + + \subsubsection*{Rules for the \class{Activity} class} \setcounter{sbolCtr}{12401} -\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}, \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\\ \sbol{DateTime}. \\ Reference: \sec{sec:Activity}} @@ -843,9 +758,9 @@ \subsubsection*{Rules for the \class{Activity} class} \printModeling{An \sbol{Activity} with a child \sbol{Association} that has a \sbolmult{roles:A}{roles} property that contains the \sbol{URI}~\url{http://sbols.org/v2\#test} SHOULD NOT have child \sbol{Usage} objects that have \sbolmult{roles:U}{roles} properties that contain the \sbol{URI}s~\url{http://sbols.org/v2\#design} or~\url{http://sbols.org/v2\#learn}.\\ Reference: \sec{sec:Activity}} \printModeling{An \sbol{Activity} with a child \sbol{Association} that has a \sbolmult{roles:A}{roles} property that contains the \sbol{URI}~\url{http://sbols.org/v2\#learn} SHOULD NOT have child \sbol{Usage} objects that have \sbolmult{roles:U}{roles} properties that contain the \sbol{URI}s~\url{http://sbols.org/v2\#design} or~\url{http://sbols.org/v2\#build}.\\ Reference: \sec{sec:Activity}} -} -\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 \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}} @@ -853,9 +768,9 @@ \subsubsection*{Rules for the \class{Activity} class} \printModeling{If an \sbol{Activity} has a types value of ~\url{http://sbols.org/v2\#test} and also contains an \\ \sbol{Association}, then that \sbol{Association} MUST have a roles value of ~\url{http://sbols.org/v2\#test}. \\ Reference: \sec{sec:Activity}} \printModeling{If an \sbol{Activity} has a types value of ~\url{http://sbols.org/v2\#learn} and also contains an \sbol{Association}, then that \sbol{Association} MUST have a roles value of ~\url{http://sbols.org/v2\#learn}. \\ Reference: \sec{sec:Activity}} -} -\twotwozero{ + + \subsubsection*{Rules for the \class{Usage} class} \setcounter{sbolCtr}{12501} @@ -887,23 +802,20 @@ \subsubsection*{Rules for the \class{Association} class} \printValid{The \sbol{agent} property of an \sbol{Association} is REQUIRED and MUST contain a \sbol{URI}.\\ Reference: \sec{sec:Association}} \printComplete{The \sbol{URI} contained by the \sbol{agent} property MUST refer to an \sbol{Agent} object.\\ Reference: \sec{sec:Association}} -} -\twotwozero{ + \subsubsection*{Rules for the \class{Plan} class} \setcounter{sbolCtr}{12701} \printValid{A \sbol{Plan} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ \sbol{description}, and \sbol{annotations}.\\ Reference: \sec{sec:Plan}} -} -\twotwozero{ + \subsubsection*{Rules for the \class{Agent} class} \setcounter{sbolCtr}{12801} \printValid{An \sbol{Agent} MUST NOT have properties other than the following: \sbol{identity},\\ \sbol{persistentIdentity}, \sbol{displayId}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{wasGeneratedBys}, \sbol{name},\\ \sbol{description}, and \sbol{annotations}.\\ Reference: \sec{sec:Agent}} -} -\twotwozero{ + \subsubsection*{Rules for the \class{CombinatorialDerivation} class} \setcounter{sbolCtr}{12901} @@ -955,14 +867,13 @@ \subsubsection*{Rules for the \class{CombinatorialDerivation} class} \printModeling{If the \sbol{wasDerivedFroms} property of a \sbol{Collection} refers to a \sbol{CombinatorialDerivation}, then the \sbol{wasDerivedFroms} properties of the objects that are referred to by its \sbol{members} property SHOULD also refer to the \sbol{CombinatorialDerivation}. \\ Reference: \sec{sec:CombinatorialDerivation}} -} -\twotwoone{ + \printValid{The \sbol{strategy} property of an \sbol{CombinatorialDerivation} is OPTIONAL and MAY contain a \sbol{URI}. \\ Reference: \sec{sec:CombinatorialDerivation}} -} -\twotwozero{ + + \subsubsection*{Rules for the \class{VariableComponent} class} \setcounter{sbolCtr}{13001} @@ -981,15 +892,13 @@ \subsubsection*{Rules for the \class{VariableComponent} class} \printComplete{The \sbol{URI} contained by the \sbol{variable} property of a \sbol{VariableComponent} MUST refer to a \sbol{SubComponent} contained by the \sbol{components} property of the template \sbol{SubComponent} of the \sbol{CombinatorialDerivation} that contains the \sbol{VariableComponent}. \\ Reference: \sec{sec:VariableComponent}} -} -\twotwoone{ + \printModeling{At least one of the \sbol{variants} property, \sbol{variantCollections} property, or\\ \sbol{variantDerivations} property of a \sbol{VariableComponent} MUST NOT be empty. \\ Reference: \sec{sec:VariableComponent}} -} -\twotwozero{ + \printValid{The \sbol{variants} property of a \sbol{VariableComponent} is OPTIONAL and MAY contain a set of \sbol{URI}s. \\ Reference: \sec{sec:VariableComponent}} @@ -1016,18 +925,14 @@ \subsubsection*{Rules for the \class{VariableComponent} class} \printComplete{\sbol{VariableComponent} objects MUST NOT form circular reference chains via their\\ \sbol{variantDerivations} properties and parent \sbol{CombinatorialDerivation} objects. \\ Reference: \sec{sec:VariableComponent}} -} -\twotwoone{ \printComplete{If the \sbol{wasDerivedFroms} property of a \sbol{SubComponent} refers to a \sbol{SubComponent} in the \sbol{template} \sbol{SubComponent} of a \sbol{CombinatorialDerivation}, and the second \sbol{SubComponent} is referred to by the \sbol{variable} property of any \sbol{VariableComponent} in the \\ \sbol{CombinatorialDerivation}, then the \sbolmult{instanceOf:CI}{instanceOf} property of the first \sbol{SubComponent} MUST refer to a \sbol{SubComponent} specified by the \sbol{variants} property, a \sbol{SubComponent} that is one of the \sbol{members} of a \sbol{Collection} specified by the \sbol{variantCollections} property, or a \sbol{SubComponent} with a \sbol{wasDerivedFroms} property that refers to a\\ \sbol{CombinatorialDerivation} specified by the \sbol{variantDerivations} property of the\\ \sbol{VariableComponent}. \\ Reference: \sec{sec:VariableComponent}} -} -\twotwozero{ \printComplete{If the \sbol{wasDerivedFroms} property of a \sbol{SubComponent} refers to a \sbol{SubComponent} in the \sbol{template} \sbol{SubComponent} of a \sbol{CombinatorialDerivation}, and the second \sbol{SubComponent} is not referred to by the \sbol{variable} property of any \sbol{VariableComponent} in the\\ \sbol{CombinatorialDerivation}, then the \sbolmult{instanceOf:CI}{instanceOf} property of the first \sbol{SubComponent} MUST refer to the same \sbol{SubComponent} as the \sbolmult{instanceOf:CI}{instanceOf} property of the second \sbol{SubComponent}. \\ Reference: \sec{sec:VariableComponent}} @@ -1058,9 +963,7 @@ \subsubsection*{Rules for the \class{VariableComponent} class} \sbol{SubComponent}. \\ Reference: \sec{sec:VariableComponent}} -} -\twotwozero{ \subsubsection*{Rules for the \class{Implementation} class} \setcounter{sbolCtr}{13101} @@ -1070,10 +973,9 @@ \subsubsection*{Rules for the \class{Implementation} class} \printValid{The \sbol{built} property of an \sbol{Implementation} is OPTIONAL and MAY contain a \sbol{URI}.\\ Reference: \sec{sec:Implementation}} -\printComplete{The \sbol{built} property \sbol{URI}, if specified, MUST refer to either a \sbol{SubComponent} or a \sbol{SubComponent}.\\ Reference: \sec{sec:Implementation}} -} +\printComplete{The \sbol{built} property \sbol{URI}, if specified, MUST refer to a \sbol{Component}.\\ Reference: \sec{sec:Implementation}} + -\twotwozero{ \subsubsection*{Rules for the \class{Attachment} class} \setcounter{sbolCtr}{13201} @@ -1095,18 +997,18 @@ \subsubsection*{Rules for the \class{Attachment} class} \printValid{The \sbol{size} property of an \sbol{Attachment} is OPTIONAL and MAY contain a \sbol{Long}.\\ Reference: \sec{sec:Attachment}} \printValid{The \sbol{hash} property of an \sbol{Attachment} is OPTIONAL and MAY contain a \sbol{String}.\\ Reference: \sec{sec:Attachment}} -} -\twothreezero{ + + \subsubsection*{Rules for the \class{ExperimentalData} class} \setcounter{sbolCtr}{13301} \printValid{An \sbol{ExperimentalData} 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}, and \sbol{attachments}.\\ Reference: \sec{sec:ExperimentalData}} -} -\twothreezero{ + + \subsubsection*{Rules for the \class{Experiment} class} \setcounter{sbolCtr}{13401} @@ -1118,9 +1020,9 @@ \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} @@ -1138,9 +1040,7 @@ \subsubsection*{Rules for the \class{Measure} class} \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} @@ -1161,9 +1061,8 @@ \subsubsection*{Rules for the \class{Unit} class} \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} @@ -1182,9 +1081,8 @@ \subsubsection*{Rules for the \class{SingularUnit} class} \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} @@ -1206,9 +1104,8 @@ \subsubsection*{Rules for the \class{UnitMultiplication} class} \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} @@ -1230,9 +1127,8 @@ \subsubsection*{Rules for the \class{UnitDivision} class} \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} @@ -1249,9 +1145,9 @@ \subsubsection*{Rules for the \class{UnitExponentiation} class} \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} @@ -1271,9 +1167,8 @@ \subsubsection*{Rules for the \class{PrefixedUnit} class} \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} @@ -1296,9 +1191,8 @@ \subsubsection*{Rules for the \class{Prefix} class} \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} @@ -1306,9 +1200,8 @@ \subsubsection*{Rules for the \class{SIPrefix} class} \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} @@ -1316,4 +1209,4 @@ \subsubsection*{Rules for the \class{BinaryPrefix} class} \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 index bc785693..2375be74 100644 --- a/complementary_standards.tex +++ b/complementary_standards.tex @@ -2,12 +2,10 @@ \section{Complementary Standards} \label{sec:complementaryStandards} % ----------------------------------------------------------------------------- -\twoonezero{\subsection{Adding Provenance with PROV-O} +\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. @@ -16,9 +14,7 @@ \section{Complementary Standards} %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 Component may be derived from another Component, 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. @@ -30,9 +26,9 @@ \section{Complementary Standards} ...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} @@ -40,18 +36,16 @@ \section{Complementary Standards} \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} @@ -82,12 +76,10 @@ \subsubsection{Activity} \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} @@ -106,11 +98,10 @@ \subsubsection{Activity} \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}. @@ -120,12 +111,9 @@ \subsubsection{Usage} 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 @@ -140,11 +128,8 @@ \subsubsection{Usage} \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}. @@ -152,14 +137,11 @@ \subsubsection{Association} \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{ +\paragraph{The \sbolheading{roles} property}\label{sec:roles:A} 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 @@ -174,16 +156,14 @@ \subsubsection{Association} \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} @@ -195,19 +175,17 @@ \subsubsection{Association} \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} @@ -219,13 +197,12 @@ \subsubsection{Plan} \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} @@ -237,10 +214,9 @@ \subsubsection{Agent} \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} @@ -292,10 +268,10 @@ \subsubsection{Agent} \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 +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. + + \lstsetsbol \begin{lstlisting} @@ -347,9 +323,7 @@ \subsubsection{Agent} \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{Component}) 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} @@ -363,7 +337,7 @@ \subsubsection{Agent} %% proposed by issue #137 \clearpage -\twotwoone{} + \lstsetsbol \begin{lstlisting} @@ -576,10 +550,10 @@ \subsubsection{Agent} \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} @@ -1102,11 +1076,9 @@ \subsubsection{Agent} \end{lstlisting} -\twothreezero{\subsection{Adding Measures/Parameters with OM} +\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. @@ -1121,10 +1093,8 @@ \subsubsection{Agent} \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} @@ -1141,7 +1111,7 @@ \subsubsection{Measure} \paragraph{Serialization} The serialization of a \sbol{Measure} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1153,9 +1123,9 @@ \subsubsection{Measure} \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} @@ -1173,7 +1143,6 @@ \subsubsection{Measure} \label{ser:Measure} -\twothreezero{ \subsubsection{Unit} \label{sec:Unit} @@ -1196,9 +1165,8 @@ \subsubsection{Unit} \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} @@ -1212,7 +1180,7 @@ \subsubsection{SingularUnit} \paragraph{Serialization} The serialization of a \sbol{SingularUnit} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1229,9 +1197,9 @@ \subsubsection{SingularUnit} \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} @@ -1250,15 +1218,13 @@ \subsubsection{SingularUnit} \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} @@ -1272,7 +1238,7 @@ \subsubsection{UnitMultiplication} \paragraph{Serialization} The serialization of a \sbol{UnitMultiplication} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1309,7 +1275,7 @@ \subsubsection{UnitMultiplication} % \end{lstlisting} % \label{ser:UnitMultiplication} -\twothreezero{ + \subsubsection{UnitDivision} \label{sec:UnitDivision} @@ -1323,7 +1289,7 @@ \subsubsection{UnitDivision} \paragraph{Serialization} The serialization of a \sbol{UnitDivision} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1340,9 +1306,9 @@ \subsubsection{UnitDivision} \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} @@ -1360,7 +1326,6 @@ \subsubsection{UnitDivision} \end{lstlisting} \label{ser:UnitDivision} -\twothreezero{ \subsubsection{UnitExponentiation} \label{sec:UnitExponentiation} @@ -1374,7 +1339,7 @@ \subsubsection{UnitExponentiation} \paragraph{Serialization} The serialization of a \sbol{UnitExponentiation} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1411,7 +1376,7 @@ \subsubsection{UnitExponentiation} % \end{lstlisting} % \label{ser:UnitExponentiation} -\twothreezero{ + \subsubsection{PrefixedUnit} \label{sec:PrefixedUnit} @@ -1425,7 +1390,7 @@ \subsubsection{PrefixedUnit} \paragraph{Serialization} The serialization of a \sbol{PrefixedUnit} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1442,9 +1407,9 @@ \subsubsection{PrefixedUnit} \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} @@ -1462,7 +1427,7 @@ \subsubsection{PrefixedUnit} \end{lstlisting} \label{ser:PrefixedUnit} -\twothreezero{ + \subsubsection{Prefix} \label{sec:Prefix} @@ -1488,9 +1453,8 @@ \subsubsection{Prefix} \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} @@ -1498,7 +1462,7 @@ \subsubsection{SIPrefix} \paragraph{Serialization} The serialization of a \sbol{SIPrefix} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1514,7 +1478,7 @@ \subsubsection{SIPrefix} \end{lstlisting} -\twothreezero{ + \subsubsection{BinaryPrefix} \label{sec:BinaryPrefix} @@ -1522,7 +1486,7 @@ \subsubsection{BinaryPrefix} \paragraph{Serialization} The serialization of a \sbol{BinaryPrefix} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1539,11 +1503,9 @@ \subsubsection{BinaryPrefix} \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{Component} class 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{Component} \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} diff --git a/compliance.tex b/compliance.tex index f5b0e19c..f53eb73e 100644 --- a/compliance.tex +++ b/compliance.tex @@ -1,6 +1,6 @@ \section{SBOL Compliance} -\twozeroone{ + There are different types of software compliance with respect to the SBOL specification. First, a software tool can either support all classes of the SBOL 2.x data model or only its structural subset. The structural subset includes the following classes: \begin{itemize} \item \sbol{Sequence} @@ -25,5 +25,5 @@ \section{SBOL Compliance} This validator can also be used to check lossless import/export support, since it can compare the data content of files imported and exported by a software tool. Finally, developers of SBOL-compliant tools are encouraged to notify the SBOL editors\\(sbol-editors@googlegroups.com) when they have determined that their tool is SBOL compliant, so their tool can be publicly categorized as such on the SBOL website. -} + diff --git a/examples_model.tex b/examples_model.tex index 168e7089..d1cd6f21 100644 --- a/examples_model.tex +++ b/examples_model.tex @@ -11,7 +11,7 @@ \section{Data Model Examples} With repressors LacI and TetR, this results in a bi-stable system that will tend to settle into a state where precisely one of the two repressors is strongly expressed, repressing the other. Each of these repressors can have its activity disrupted by a small molecule (IPTG for LacI, aTc for TetR), which enables the system to be ``toggled'' from one state to the other by dosing it with the appropriate small molecule. -\twotwozero{ + \begin{figure}[ht] \begin{center} \includegraphics[width=0.33\textwidth]{images/toggle-highlevel2.pdf} @@ -31,7 +31,7 @@ \section{Data Model Examples} \label{images:toggleswitch_modular} \end{center} \end{figure} -} + The LacI/TetR toggle switch is modeled in SBOL as two parallel hierarchies of structure and function. The structural hierarchy of the toggle switch is represented using \sbol{Component}s: \begin{itemize} @@ -47,7 +47,7 @@ \section{Data Model Examples} \end{center} \end{figure} -\twozeroone{ + \begin{figure}[ht] \begin{center} \includegraphics[width=\textwidth]{example_uml/toggle_2} @@ -55,7 +55,7 @@ \section{Data Model Examples} \label{uml:ex_comp_def_compo} \end{center} \end{figure} -} + The functional hierarchy of the toggle switch is represented using \sbol{Component}s: @@ -64,7 +64,7 @@ \section{Data Model Examples} \item Base elements are composed to form the toggle switch at the top of the hierarchy. As an example, \ref{uml:ex_mod_def_compo} is a UML diagram of the \sbol{Component} that represents the toggle switch. \end{itemize} -\twozeroone{ + \begin{figure}[ht] \begin{center} \includegraphics[width=\textwidth]{example_uml/toggle_3} @@ -81,7 +81,7 @@ \section{Data Model Examples} \label{uml:ex_mod_def_compo} \end{center} \end{figure} -} + % Each \sbol{Component} also contains the \sbol{SubComponent}s that participate in \sbol{Interaction}s and are defined by the same \sbol{Component}s as the parallel \sbol{SubComponent}s in the structural hierarchy of the toggle switch. Finally, \sbol{MapsTo} entities are used to refine which \sbol{SubComponent}s of the functional hierarchy are identical or map them to \sbol{SubComponent}s in the structural hierarchy. diff --git a/model.tex b/model.tex index 7c6a0f99..0a1103e4 100644 --- a/model.tex +++ b/model.tex @@ -63,8 +63,8 @@ \subsection{Data Types} {\em Example: ``LacI coding sequence''} \item \sbol{Integer}: \url{http://www.w3.org/TR/xmlschema11-2/#integer}\\ {\em Example: 3} -\item \twotwozero{\sbol{Long}:} \url{http://www.w3.org/TR/xmlschema11-2/#long}\\ - \twotwozero{{\em Example: 9223372036854775806}} +\item \sbol{Long}: \url{http://www.w3.org/TR/xmlschema11-2/#long}\\ + {\em Example: 9223372036854775806} \item \sbol{Double}: \url{http://www.w3.org/TR/xmlschema11-2/#double}\\ {\em Example: 3.14159} \item \sbol{Boolean}: \url{http://www.w3.org/TR/xmlschema11-2/#boolean}\\ @@ -90,7 +90,7 @@ \subsection{Identified} All SBOL-defined classes are directly or indirectly derived from the \sbol{Identified} abstract class. This inheritance means that all SBOL objects are uniquely identified using \sbol{URI}s that uniquely refer to these objects within an SBOL document or at locations on the World Wide Web. -As shown in \ref{uml:identified}, the \sbol{Identified} class includes the following properties: \sbol{identity}, \sbol{persistentIdentity}, \sbol{version}, \twotwozero{\sbol{wasDerivedFroms}}, \sbol{name}, \sbol{description}, and \sbol{annotations}. The latter property is described separately in \ref{sec:Annotations}. +As shown in \ref{uml:identified}, the \sbol{Identified} class includes the following properties: \sbol{identity}, \sbol{persistentIdentity}, \sbol{version}, \sbol{wasDerivedFroms}, \sbol{name}, \sbol{description}, and \sbol{annotations}. The latter property is described separately in \ref{sec:Annotations}. When an SBOL resource reference takes the form of a \sbol{URI}, that \sbol{URI} can either be the value of an \sbol{identity} property or the value of a \sbol{persistentIdentity} property. If the \sbol{URI} is equal to the value of an \sbol{identity} property, then it is guaranteed to be unique, and it refers to precisely one SBOL object with that \sbol{URI}. @@ -117,7 +117,7 @@ \subsubsection*{The \sbolheading{identity} property} \subsubsection*{The \sbolheading{persistentIdentity} property} \label{sec:persistentIdentity} -The \sbol{persistentIdentity} property is OPTIONAL and has a data type of \sbol{URI}. This \sbol{URI} serves to uniquely refer to a set of SBOL objects \twozeroone{of the same class} that are different versions of each other. +The \sbol{persistentIdentity} property is OPTIONAL and has a data type of \sbol{URI}. This \sbol{URI} serves to uniquely refer to a set of SBOL objects of the same class that are different versions of each other. An \sbol{Identified} object MUST be referred to using either its \sbol{identity} \sbol{URI} or its \sbol{persistentIdentity} \sbol{URI}. @@ -125,7 +125,7 @@ \subsubsection*{The \sbolheading{displayId} property} \label{sec:displayId} The \sbol{displayId} property is an OPTIONAL identifier with a data type of \sbol{String}. This property is intended to be an intermediate between \sbol{name} and \sbol{identity} that is machine-readable, but more human-readable than the full \sbol{URI} of an \sbol{identity}. -If the \sbol{displayId} property is used, then its \sbol{String} value \twozeroone{\st{SHOULD be locally unique (global uniqueness is not necessary) and}} MUST be composed of only alphanumeric or underscore characters and MUST NOT begin with a digit. +If the \sbol{displayId} property is used, then its \sbol{String} value MUST be composed of only alphanumeric or underscore characters and MUST NOT begin with a digit. % compliant with the type \external{http://www.w3.org/TR/xmlschema-2/\#NCName}, except that it MUST not include the characters "-" and ".". @@ -141,13 +141,13 @@ \subsubsection*{The \sbolheading{version} property} \subsubsection*{The \sbolheading{wasDerivedFroms} property} \label{sec:wasDerivedFroms} -\twotwozero{ - The \sbol{wasDerivedFroms} property is OPTIONAL and MAY specify a set of \sbol{URI}s. An SBOL object with this property refers to one or more SBOL objects or non-SBOL resources from which this object was derived. -\twozeroone{The \sbol{wasDerivedFroms} property of a \sbol{TopLevel} SBOL object is subject to the following rules.} +The \sbol{wasDerivedFroms} property is OPTIONAL and MAY specify a set of \sbol{URI}s. An SBOL object with this property refers to one or more SBOL objects or non-SBOL resources from which this object was derived. + +The \sbol{wasDerivedFroms} property of a \sbol{TopLevel} SBOL object is subject to the following rules. If any members of the \sbol{wasDerivedFroms} property of an SBOL object $A$ that refers to an SBOL object $B$ has an identical \sbol{persistentIdentity}, and both $A$ and $B$ have a \sbol{version}, then the \sbol{version} of $B$ MUST precede that of $A$. In addition, an SBOL object MUST NOT refer to itself via its own \sbol{wasDerivedFroms} property or form a cyclical chain of references via its \sbol{wasDerivedFroms} property and those of other SBOL objects. For example, the reference chain ``$A$ was derived from $B$ and $B$ was derived from $A$'' is cyclical. -} + \subsubsection*{The \sbolheading{name} property} \label{sec:name} @@ -196,7 +196,7 @@ \subsubsection*{Serialization} namespace, but are mapped to standardized terms defined elsewhere: \begin{itemize} \item \sbol{identity} is serialized as \external{rdf:about} -\item \twotwozero{\sbol{wasDerivedFroms} are} serialized as \external{prov:wasDerivedFrom} +\item \sbol{wasDerivedFroms} are serialized as \external{prov:wasDerivedFrom} \item \sbol{name} is serialized as \external{dcterms:title} \item \sbol{description} is serialized as \external{dcterms:description} \end{itemize} @@ -225,7 +225,7 @@ \subsubsection*{Serialization} \label{sec:TopLevel} \sbol{TopLevel} is an abstract class that is extended by any \sbol{Identified} class that can be found at the top level of an SBOL document or file. In other words, \sbol{TopLevel} objects are not nested inside any other object via a composite aggregation or black diamond arrow association property. Instead of nesting, composite \sbol{TopLevel} objects refer to subordinate \sbol{TopLevel} objects by their \sbol{URI}s using shared aggregation or white diamond arrow association properties. The \sbol{TopLevel} classes defined in this specification are \sbol{Sequence}, \sbol{Component}, \sbol{Model}, \sbol{Collection}, \sbol{GenericTopLevel}, \sbol{CombinatorialDerivation}, and \sbol{Implementation}(\ref{uml:toplevel}). -\twotwoone{ + \begin{figure}[ht] \begin{center} \includegraphics[width=\textwidth]{uml/toplevel} @@ -233,7 +233,7 @@ \subsubsection*{Serialization} \label{uml:toplevel} \end{center} \end{figure} -} + \subsubsection*{The attachments property} \label{sec:attachments} @@ -267,7 +267,7 @@ \subsubsection*{The \sbolheading{encoding} property} For example, the \sbol{elements} property of a \sbol{Sequence} with an \external{IUPAC DNA} encoding property MUST contain characters that represent nucleotide bases, such as {\tt a}, {\tt t}, {\tt c}, and {\tt g}. The \sbol{elements} property of a \sbol{Sequence} with a \external{Simplified Molecular-Input Line-Entry System (SMILES)} encoding, on the other hand, MUST contain characters that represent atoms and chemical bonds, such as {\tt C}, {\tt N}, {\tt O}, and {\tt =}. -\ref{tbl:sequence_encodings} provides a list of possible \sbol{URI} values for the \sbol{encoding} property. The terms in \ref{tbl:sequence_encodings} are organized by the type of \sbol{Component} (see \ref{tbl:component_types}) that typically refer to a \sbol{Sequence} with such an \sbol{encoding}. \twozeroone{It is RECOMMENDED that the encoding property of a Sequence contains a URI from \ref{tbl:sequence_encodings}.} When the \sbol{encoding} of a \sbol{Sequence} is well described by one of the \sbol{URI}s in \ref{tbl:sequence_encodings}, it MUST contain that \sbol{URI}. +\ref{tbl:sequence_encodings} provides a list of possible \sbol{URI} values for the \sbol{encoding} property. The terms in \ref{tbl:sequence_encodings} are organized by the type of \sbol{Component} (see \ref{tbl:component_types}) that typically refer to a \sbol{Sequence} with such an \sbol{encoding}. It is RECOMMENDED that the encoding property of a Sequence contains a URI from \ref{tbl:sequence_encodings}. When the \sbol{encoding} of a \sbol{Sequence} is well described by one of the \sbol{URI}s in \ref{tbl:sequence_encodings}, it MUST contain that \sbol{URI}. More information on IUPAC encoding can be found at \url{http://www.bioinformatics.org/sms2/iupac.html}. @@ -403,8 +403,8 @@ \subsubsection*{The \sbolheading{roles} property} The \sbolmult{roles:CD}{roles} property is an OPTIONAL set of \sbol{URI}s that clarifies the potential function of the entity represented by a \sbol{Component} in a biochemical or physical context. The \sbolmult{roles:CD}{roles} property of a \sbol{Component} MAY contain one or more \sbol{URI}s that MUST identify terms from ontologies that are consistent with the \sbolmult{types:CD}{types} property of the \sbol{Component}. -For example, the \sbolmult{roles:CD}{roles} property of a DNA or RNA \sbol{Component} could contain URIs identifying terms from the Sequence Ontology (SO). \twozeroone{As a best practice, a DNA or RNA \sbol{Component} SHOULD contain exactly one \sbol{URI} that refers to a term from the sequence feature branch of the SO.} -\twotwoone{Similarly, the roles property of a Protein and SmallMolecule \sbol{Component} SHOULD respectively contain \sbol{URI}s identifying terms from the \texttt{MolecularFunction} branch (\texttt{GO:0003674}) of the Gene Ontology (GO) and the \texttt{role} branch (\texttt{CHEBI:50906}) of the CHEBI ontology.} +For example, the \sbolmult{roles:CD}{roles} property of a DNA or RNA \sbol{Component} could contain URIs identifying terms from the Sequence Ontology (SO). As a best practice, a DNA or RNA \sbol{Component} SHOULD contain exactly one \sbol{URI} that refers to a term from the sequence feature branch of the SO. +Similarly, the roles property of a Protein and SmallMolecule \sbol{Component} SHOULD respectively contain \sbol{URI}s identifying terms from the \texttt{MolecularFunction} branch (\texttt{GO:0003674}) of the Gene Ontology (GO) and the \texttt{role} branch (\texttt{CHEBI:50906}) of the CHEBI ontology. \ref{tbl:component_roles} contains a list of possible ontology terms for the \sbolmult{roles:CD}{roles} property and their \sbol{URI}s. These terms are organized by the type of \sbol{Component} to which they SHOULD apply (see \ref{tbl:component_types}). Any \sbol{Component} that can be well-described by one of the terms in \ref{tbl:component_roles} MUST use the \sbol{URI} for that term as one of its \sbolmult{roles:CD}{roles}. These \sbol{URI}s might identify descriptive biological roles, such as ``metabolic pathway'' and ``signaling cascade,'' but they can also identify identify ``logical'' roles, such as ``inverter'' or ``AND gate'', or other abstract roles for describing the function of design. Interpretation of the meaning of such roles currently depends on the software tools that read and write them. @@ -604,9 +604,8 @@ \subsubsection{Interaction} The \sbolmult{types:I}{types} property is a REQUIRED set of \sbol{URI}s that describes the behavior represented by an \sbol{Interaction}. -The \sbolmult{types:I}{types} property MUST contain one or more \sbol{URI}s that MUST identify terms from appropriate ontologies. It is RECOMMENDED that \twozeroone{exactly one \sbol{URI}} contained by the \sbolmult{types:I}{types} property refer to a term from the occurring entity branch of the Systems Biology Ontology (SBO). (See \url{http://www.ebi.ac.uk/sbo/main/}) \ref{tbl:interaction_types} provides a list of possible SBO terms for the \sbolmult{types:I}{types} property and their corresponding \sbol{URI}s. +The \sbolmult{types:I}{types} property MUST contain one or more \sbol{URI}s that MUST identify terms from appropriate ontologies. It is RECOMMENDED that exactly one \sbol{URI} contained by the \sbolmult{types:I}{types} property refer to a term from the occurring entity branch of the Systems Biology Ontology (SBO). (See \url{http://www.ebi.ac.uk/sbo/main/}) \ref{tbl:interaction_types} provides a list of possible SBO terms for the \sbolmult{types:I}{types} property and their corresponding \sbol{URI}s. -\twozeroone{ \begin{table}[ht] \begin{edtable}{tabular}{ll} \toprule @@ -624,7 +623,6 @@ \subsubsection{Interaction} \caption{SBO terms to specify the \sbolmult{types:I}{types} property of an \sbol{Interaction}.} \label{tbl:interaction_types} \end{table} -} If an \sbol{Interaction} is well described by one of the terms from \ref{tbl:interaction_types}, then its \sbolmult{types:I}{types} property MUST contain the \sbol{URI} that identifies this term. Lastly, if the \sbolmult{types:I}{types} property of an \sbol{Interaction} contains multiple \sbol{URI}s, then they MUST identify non-conflicting terms. For example, the SBO terms ``stimulation'' and ``inhibition'' would conflict. @@ -669,7 +667,6 @@ \subsubsection{Interaction} \end{lstlisting} -\twozeroone{ \begin{figure}[ht] \begin{center} \includegraphics[scale=0.6]{uml/participation} @@ -677,7 +674,6 @@ \subsubsection{Interaction} \label{uml:participation} \end{center} \end{figure} -} \subsubsection{Participation} \label{sec:Participation} @@ -687,9 +683,9 @@ \subsubsection{Participation} \paragraph{The \sbolheading{roles} property}\label{sec:roles:P} -\twozeroone{The \sbolmult{roles:P}{roles} property is a REQUIRED set of \sbol{URI}s that describes the behavior of a \sbol{Participation} (and by extension its referenced \sbol{SubComponent}) in the context of its parent \sbol{Interaction}. +The \sbolmult{roles:P}{roles} property is a REQUIRED set of \sbol{URI}s that describes the behavior of a \sbol{Participation} (and by extension its referenced \sbol{SubComponent}) in the context of its parent \sbol{Interaction}. -The \sbolmult{roles:P}{roles} property MUST contain one or more \sbol{URI}s that MUST identify terms from appropriate ontologies. It is RECOMMENDED that exactly one \sbol{URI} contained by the \sbolmult{roles:P}{roles} property refer to a term from the participant role branch of the SBO.} \ref{tbl:participant_roles} provides a list of possible SBO terms for the \sbolmult{roles:P}{roles} property and their corresponding \sbol{URI}s. +The \sbolmult{roles:P}{roles} property MUST contain one or more \sbol{URI}s that MUST identify terms from appropriate ontologies. It is RECOMMENDED that exactly one \sbol{URI} contained by the \sbolmult{roles:P}{roles} property refer to a term from the participant role branch of the SBO. \ref{tbl:participant_roles} provides a list of possible SBO terms for the \sbolmult{roles:P}{roles} property and their corresponding \sbol{URI}s. \begin{table}[ht] \begin{edtable}{tabular}{lll} @@ -717,7 +713,7 @@ \subsubsection{Participation} \end{table} If a \sbol{Participation} is well described by one of the terms from \ref{tbl:participant_roles}, then its \sbolmult{roles:P}{roles} property MUST contain the \sbol{URI} that identifies this term. -\twozeroone{Also, if a \sbol{Participation} belongs to an \sbol{Interaction} that has a type listed in \ref{tbl:interaction_types}, then the \sbol{Participation} SHOULD have a role that is cross-listed with this type in \ref{tbl:participant_roles}.} +Also, if a \sbol{Participation} belongs to an \sbol{Interaction} that has a type listed in \ref{tbl:interaction_types}, then the \sbol{Participation} SHOULD have a role that is cross-listed with this type in \ref{tbl:participant_roles}. Lastly, if the \sbolmult{roles:P}{roles} property of a \sbol{Participation} contains multiple \sbol{URI}s, then they MUST identify non-conflicting terms. For example, the SBO terms ``stimulator'' and ``inhibitor'' would conflict. @@ -802,11 +798,8 @@ \subsubsection{SubComponent} In some cases, a designer might want to set the \sbol{access} property of a \sbol{SubComponent} such that others cannot map to the \sbol{SubComponent} when they reuse its parent \sbol{Component}. For example, a designer who is concerned about retroactivity might set the \sbol{access} of the \sbol{SubComponent} to ``private'' in order to prevent its mapping to another \sbol{SubComponent} that participates in a new \sbol{Interaction} as part of a composite design. -\twoonezero{ - \paragraph{The \sbolheading{roles} property}\label{sec:roles:C} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.1.0; see SEP 004: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_004.md}] + The expected purpose and function of a genetic part are described by the \sbolmult{roles:CD}{roles} property of \sbol{Component}. However, the same building block might be used for a different purpose in an actual design. In other words, purpose and function are sometimes determined by context. @@ -817,11 +810,10 @@ \subsubsection{SubComponent} It is RECOMMENDED that these \sbolmult{roles:C}{role} \sbol{URI}s identify terms that are compatible with the \sbolmult{types:CD}{type} properties of both this \sbol{SubComponent}'s parent \sbol{Component} and its included sub-\sbol{Component}. For example, a \sbolmult{roles:C}{role} of a \sbol{SubComponent} which belongs to a \sbol{Component} of type DNA and includes a sub-\sbol{Component} of type DNA might refer to terms from the Sequence Ontology. A table of recommended ontology terms for \sbolmult{roles:C}{roles} is given in \ref{tbl:component_roles}. } -\twoonezero{ + + \paragraph{The \sbolheading{roleIntegration} property}\label{sec:roleIntegration:C} -\vspace{-7pt} -\-\hspace{0.8cm} -[New in 2.1.0; see SEP 004: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_004.md}] + A \sbolmult{roleIntegration:C}{roleIntegration} specifies the relationship between a \sbol{SubComponent} instance's own set of \sbolmult{roles:C}{roles} and the set of \sbolmult{roles:CD}{roles} on the included sub-\sbol{Component}. @@ -830,7 +822,7 @@ \subsubsection{SubComponent} It is RECOMMENDED to specify a set of \sbol{SubComponent} \sbolmult{roles:C}{roles} only if the integrated result set of roles would differ from the set of \sbolmult{roles:CD}{roles} belonging to this \sbol{SubComponent}'s included sub-\sbol{Component}. } -\twoonezero{ + \begin{table}[ht] \begin{edtable}{tabular}{lp{4in}} \toprule @@ -844,8 +836,6 @@ \subsubsection{SubComponent} sub-\sbol{Component}'s roles.} \label{tbl:component_roleIntegration} \end{table} -} - \begin{table}[ht] @@ -871,7 +861,7 @@ \subsubsection{SubComponent} \paragraph{Serialization} -\twoonezero{The serialization of a \sbol{SubComponent} MUST have the following form:} +The serialization of a \sbol{SubComponent} MUST have the following form: \lstsetsbol \begin{lstlisting} @@ -950,7 +940,7 @@ \subsubsection{MapsTo} \paragraph{The \sbolheading{refinement} property}\label{sec:refinement} The \sbol{refinement} property is REQUIRED and has a data type of \sbol{URI}. Each \sbol{MapsTo} object MUST specify the relationship between its \sbol{local} and \sbol{remote} \sbol{SubComponent} objects using one of the REQUIRED \sbol{refinement} \sbol{URI}s provided in \ref{tbl:mapsto_refinement}. -\twozeroone{Note that if multiple \sbol{MapsTo}s belonging to the \sbol{SubComponent}s of a \sbol{Component} have \sbol{local} properties that refer to the same \sbol{SubComponent}, then there MUST NOT be more than one such \sbol{MapsTo} that has a \sbol{refinement} property that contains the \sbol{URI} \url{http://sbols.org/v2\#useRemote}. Similarly, if multiple \sbol{MapsTo}s belonging the \sbol{SubComponent}s and \sbol{SubComponent}s of a \sbol{Component} have \sbol{local} properties that refer to the same \sbol{SubComponent}, then there MUST NOT be more than one such \sbol{MapsTo} that has a \sbol{refinement} property that contains the \sbol{URI} \url{http://sbols.org/v2\#useRemote}.} +Note that if multiple \sbol{MapsTo}s belonging to the \sbol{SubComponent}s of a \sbol{Component} have \sbol{local} properties that refer to the same \sbol{SubComponent}, then there MUST NOT be more than one such \sbol{MapsTo} that has a \sbol{refinement} property that contains the \sbol{URI} \url{http://sbols.org/v2\#useRemote}. Similarly, if multiple \sbol{MapsTo}s belonging the \sbol{SubComponent}s and \sbol{SubComponent}s of a \sbol{Component} have \sbol{local} properties that refer to the same \sbol{SubComponent}, then there MUST NOT be more than one such \sbol{MapsTo} that has a \sbol{refinement} property that contains the \sbol{URI} \url{http://sbols.org/v2\#useRemote}. \begin{table}[ht] @@ -1016,11 +1006,8 @@ \subsubsection{SequenceAnnotation} \paragraph{The \sbolheading{SubComponent} property}\label{sec:component} The \sbol{SubComponent} property is OPTIONAL and has a data type of \sbol{URI}. This \sbol{URI} MUST refer to a \sbol{SubComponent} that is contained by the same parent \sbol{Component} that contains the \sbol{SequenceAnnotation}. In this way, the properties of the \sbol{SequenceAnnotation}, such as its \sbol{description} and \sbol{locations}, are associated with part of the substructure of its parent \sbol{Component}. -\twoonezero{ + \paragraph{The \sbolheading{roles} property}\label{sec:roles:SA} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.1.0; see SEP 004: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_004.md}]\\ -\-\hspace{0.8cm}[New in 2.1.0; see SEP 010: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_010.md}] Alternatively to describing substructure, a \sbol{SequenceAnnotation} can be utilized to identify a feature, such as a GenBank feature, of a specified \sbol{Sequence}. In this use case, the \sbol{SequenceAnnotation} MUST NOT have a \sbol{SubComponent} property, but instead it would have a \sbolmult{roles:SA}{roles} property. @@ -1031,9 +1018,9 @@ \subsubsection{SequenceAnnotation} \paragraph{Serialization} -\twoonezero{ + The serialization of a \sbol{SequenceAnnotation} MUST have the form below. In this template, {\tt A\_LOCATION\_SUBCLASS} represents one of the \sbol{Location} subclasses. -} + \lstsetsbol \begin{lstlisting} @@ -1081,7 +1068,6 @@ \subsubsection{Location} \label{sec:orientation} The \sbol{orientation} property is OPTIONAL and has a data type of \sbol{URI}. All subclasses of \sbol{Location} share this property, which can be used to indicate how the region specified by the \sbol{SequenceAnnotation} and any associated double-stranded \sbol{SubComponent} is oriented on the \sbol{elements} of a \sbol{Sequence} from their parent \sbol{Component}. \ref{tbl:orientation_types} provides a list of REQUIRED \sbol{orientation} \sbol{URI}s. If a \sbol{Location} object has an \sbol{orientation}, then it MUST come from \ref{tbl:orientation_types}. -\twothreezero{ \paragraph{The \sbolheading{sequence} property} \label{sec:sequence} The \sbol{sequence} property is OPTIONAL and MAY contain the \sbol{URI} of a \sbol{Sequence} object. All subclasses of \sbol{Location} share this property, which indicates which \sbol{Sequence} object referenced by the containing \sbol{Component} is referenced by the \sbol{Location}. @@ -1228,7 +1214,6 @@ \subsubsection{SequenceConstraint} % Note: With regards to SBOL Version 1.1., this is a generalization of former \sbol{SequenceAnnotation} property \external{precedes}. -\twotwozero{ \begin{table}[ht] \begin{edtable}{tabular}{lp{3.25in}} \toprule @@ -1243,7 +1228,7 @@ \subsubsection{SequenceConstraint} \caption{RECOMMENDED \sbol{URI}s for the \sbol{restriction} property.} \label{tbl:restriction_types} \end{table} -} + \paragraph{Serialization} @@ -1406,11 +1391,9 @@ \subsubsection*{Serialization} \end{lstlisting} \label{ser:Collection} -\twotwozero{ + \subsection{CombinatorialDerivation} \label{sec:CombinatorialDerivation} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.2.0; see SEP 007: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_007.md}] The purpose of the \sbol{CombinatorialDerivation} class is to specify combinatorial genetic designs without having to specify every possible design variant. For example, a \sbol{CombinatorialDerivation} can be used to specify a library of reporter gene variants that include different promoters and RBSs without having to specify a \sbol{Component} for every possible combination of promoter, RBS, and CDS in the library. \sbol{Component} objects that realize a \sbol{CombinatorialDerivation} can be derived in accordance with the class properties \sbol{template}, \\ \sbol{variableComponents}, and \sbol{strategy} (see \ref{uml:combinatorial_derivation}). @@ -1445,7 +1428,6 @@ \subsubsection*{ The \sbolheading{variableComponents} property}\label{sec:variab \subsubsection*{ The \sbolheading{strategy} property}\label{sec:strategy} The \sbol{strategy} property is OPTIONAL and has a data type of URI. \ref{tbl:strategy} provides a list of REQUIRED \sbol{strategy} URIs. If the \sbol{strategy} property is not empty, then it MUST contain a URI from \ref{tbl:strategy}. This property recommends how many \sbol{Component} objects a user SHOULD derive from the template \sbol{Component}. -} \begin{table}[ht] \begin{edtable}{tabular}{lp{4in}} @@ -1460,12 +1442,12 @@ \subsubsection*{ The \sbolheading{strategy} property}\label{sec:strategy} \label{tbl:strategy} \end{table} -\twotwozero{ + \subsubsection*{Serialization} The serialization of a \sbol{CombinatorialDerivation} MUST have the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1479,10 +1461,8 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ The example below shows the serialization of a \sbol{CombinatorialDerivation} that specifies the combinatorial design for a library of GFP reporter variants. Each GFP reporter \sbol{Component} sampled from this\\ \sbol{CombinatorialDerivation} would be driven by one of two possible glucose-sensitive promoters and contain one GFP variant from a library of CDSs. -} \lstsetsbol \begin{lstlisting} @@ -1515,7 +1495,7 @@ \subsubsection*{Serialization} %\label{ser:Attachment} -\twotwozero{ + \subsubsection{VariableComponent} \label{sec:VariableComponent} @@ -1553,7 +1533,6 @@ \subsubsection*{ The \sbolheading{operator} property}\label{sec:operator} The \sbol{operator} property is REQUIRED and has a data type of URI. This property specifies how many \sbol{SubComponent} objects SHOULD be derived from the template \sbol{SubComponent} during the derivation of a new \sbol{Component}. The URI value of this property MUST come from the URIs provided in~\ref{tbl:operator}. -} \begin{table}[ht] \begin{edtable}{tabular}{lp{4in}} @@ -1570,12 +1549,11 @@ \subsubsection*{ The \sbolheading{operator} property}\label{sec:operator} \label{tbl:operator} \end{table} -\twotwozero{ + \subsubsection*{Serialization} The serialization of a \sbol{VariableComponent} MUST have the following form: -} \lstsetsbol \begin{lstlisting} @@ -1589,10 +1567,9 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ + The example below shows the serialization of a \sbol{VariableComponent} that specifies a choice of one or more operator sites from a library of variants for the derivation of a synthetic CMV promoter. -} \lstsetsbol \begin{lstlisting} @@ -1603,11 +1580,10 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ + \subsection{Implementation} \label{sec:Implementation} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.2.0; see SEP 019: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_019.md}] + An \sbol{Implementation} represents an instance of a synthetic biological construct, and describes the build phase of a design-built-test-learn workflow. Importantly, an \sbol{Implementation} can be associated with a laboratory sample that was already built, or that is to be built in the future. An \sbol{Implementation} can also represent virtual and simulated instances. An \sbol{Implementation} may be linked back to its original design (either a \sbol{Component} or \sbol{Component}) using the \sbol{wasDerivedFroms} property inherited from the \sbol{Identified} superclass. An \sbol{Implementation} may also link to a \sbol{Component} or \sbol{Component} that specifies its realized structure and/or function. % as described in Section2.1.1. @@ -1624,11 +1600,12 @@ \subsubsection*{ The \sbolheading{built} property}\label{sec:built} The \sbol{built} property is OPTIONAL and MAY contain a URI that MUST refer to a \sbol{TopLevel} object that is either a \sbol{Component} or \sbol{Component}. This \sbol{Component} or \sbol{Component} is intended to describe the actual physical structure and/or functional behavior of the \sbol{Implementation}. When the built property refers to a \sbol{Component} or \sbol{Component} that is also linked to the \sbol{Implementation} via PROV-O properties such as \sbol{wasDerivedFroms} (see \ref{sec:provenance}), it can be inferred that the actual structure and/or function of the \sbol{Implementation} matches its original design. When the \sbol{built} property refers to a different \sbol{Component} or \sbol{Component}, it can be inferred that the \sbol{Implementation} has deviated from the original design. For example, the latter could be used to document when the DNA sequencing results for an assembled construct do not match the original target sequence. } -\twotwozero{ + + \subsubsection*{Serialization} The serialization of an \sbol{Implementation} has the following form: -} + \lstsetsbol \begin{lstlisting} @@ -1637,9 +1614,7 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ In the example below, an \sbol{Implementation} links back to its target design via the \sbol{wasDerivedFroms} property. Since this particular sample did not match its target structure when synthesized in the lab, a \sbol{Component} representing its mutated structure is linked by the \sbol{built} field. -} \lstsetsbol \begin{lstlisting} @@ -1652,11 +1627,9 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ \subsection{Attachment} \label{sec:Attachment} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.2.0; see SEP 018: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_018.md}] + \begin{figure}[ht] \begin{center} @@ -1687,7 +1660,6 @@ \subsubsection*{Serialization} The serialization of an \sbol{Attachment} MUST have the following form: -} \lstsetsbol \begin{lstlisting} @@ -1700,9 +1672,9 @@ \subsubsection*{Serialization} \end{lstlisting} -\twotwozero{ + The example below shows the serialization of an \sbol{Attachment} object that refers to a PNG file containing a plot of simulation data. The attachment in this example can be retrieved from a repository via its \sbolmult{source:A}{source} \sbol{URI}, which is a \external{URL}. -} + \lstsetsbol \begin{lstlisting} @@ -1720,11 +1692,9 @@ \subsubsection*{Serialization} \end{lstlisting} \label{ser:Attachment} -\twothreezero{ \subsection{ExperimentalData} \label{sec:ExperimentalData} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.3.0; see SEP 021: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_021.md}] + \begin{figure}[ht] \begin{center} @@ -1742,7 +1712,6 @@ \subsubsection*{Serialization} The serialization of an \sbol{ExperimentalData} MUST have the following form: -} \lstsetsbol \begin{lstlisting} @@ -1751,9 +1720,9 @@ \subsubsection*{Serialization} \end{lstlisting} -\twothreezero{ + The example below shows the serialization of an \sbol{ExperimentalData} that refers to a pair of \sbol{Attachment} objects for FASTQ files from a paired-end DNA sequencing experiment. -} + \lstsetsbol \begin{lstlisting} @@ -1770,11 +1739,10 @@ \subsubsection*{Serialization} \end{lstlisting} \label{ser:ExperimentalData} -\twothreezero{ + \subsection{Experiment} \label{sec:Experiment} -\vspace{-7pt} -\-\hspace{0.8cm}[New in 2.3.0; see SEP 021: \url{https://github.com/SynBioDex/SEPs/blob/master/sep_021.md}] + \begin{figure}[ht] \begin{center} @@ -1795,7 +1763,6 @@ \subsubsection*{Serialization} The serialization of an \sbol{Experiment} MUST have the following form: -} \lstsetsbol \begin{lstlisting} @@ -1805,9 +1772,9 @@ \subsubsection*{Serialization} \end{lstlisting} -\twothreezero{ + The example below shows the serialization of an \sbol{Experiment} that aggregates the DNA sequencing results for related samples (e.g. that implement related variants of the same genetic design). -} + \lstsetsbol \begin{lstlisting} diff --git a/practices.tex b/practices.tex index 0d9ea0e0..8d203b4f 100644 --- a/practices.tex +++ b/practices.tex @@ -2,9 +2,9 @@ \section{Recommended Best Practices} \label{sec:bestpractices} % ----------------------------------------------------------------------------- -\twozeroone{\subsection{SBOL Namespaces} +\subsection{SBOL Namespaces} -Namespaces for different versions of SBOL SHOULD NOT be semantically mixed in the same document. For example, an SBOL 3.x \sbol{SubComponent} SHOULD NOT refer to an SBOL 1.x DNAComponent. However, namespaces for different versions MAY be present in the same document so long as they are semantically independent (that is, so long as objects belonging to these namespaces do not refer to each other). When multiple SBOL namespaces are present in a document, libraries SHOULD default to interpreting as SBOL only those objects belonging to the namespace for the most recent version of SBOL in the document. Any remaining objects belonging to any other SBOL namespace SHOULD be interpreted as \sbol{GenericTopLevel}s and custom \sbol{Annotation}s.} +Namespaces for different versions of SBOL SHOULD NOT be semantically mixed in the same document. For example, an SBOL 3.x \sbol{ComponentInstance} SHOULD NOT refer to an SBOL 1.x DNAComponent. However, namespaces for different versions MAY be present in the same document so long as they are semantically independent (that is, so long as objects belonging to these namespaces do not refer to each other). When multiple SBOL namespaces are present in a document, libraries SHOULD default to interpreting as SBOL only those objects belonging to the namespace for the most recent version of SBOL in the document. Any remaining objects belonging to any other SBOL namespace SHOULD be interpreted as \sbol{GenericTopLevel}s and custom \sbol{Annotation}s. \subsection{Use of the Version Property} @@ -98,10 +98,10 @@ \subsection{Recommended Ontologies for External Terms} \label{tbl:preferred_external_resources} \end{table} -\twoonezero{The URIs for ontological terms SHOULD come from identifiers.org. However, it is acceptable to use terms from purl.org as an alternative, for example when RDF tooling requires URIs to be represented as compliant QNames. SBOL software may convert between these forms as required.} +The URIs for ontological terms SHOULD come from identifiers.org. However, it is acceptable to use terms from purl.org as an alternative, for example when RDF tooling requires URIs to be represented as compliant QNames. SBOL software may convert between these forms as required. -\twozeroone{\subsection{Annotating Entities with Date \& Time}\label{sec:DateTime} -Entities in an SBOL document can be annotated with creation and modification date. It is RECOMMENDED that predicates, or properties, from DCMI Metadata Terms SHOULD be used to include date and time information. The \texttt{created} and \texttt{modified} terms SHOULD respectively be used to annotate SBOL entities with creation and modification dates. Date and time values SHOULD be expressed using the XML Schema \texttt{DateTime} datatype~\citep{Biron2004}. For example, "\texttt{2016-03-16T20:12:00Z}" specifies that the day is 16 March 2016 and the time is 20:12pm in UTC (Coordinated Universal Time). An example serialization is shown below:} +\subsection{Annotating Entities with Date \& Time}\label{sec:DateTime} +Entities in an SBOL document can be annotated with creation and modification date. It is RECOMMENDED that predicates, or properties, from DCMI Metadata Terms SHOULD be used to include date and time information. The \texttt{created} and \texttt{modified} terms SHOULD respectively be used to annotate SBOL entities with creation and modification dates. Date and time values SHOULD be expressed using the XML Schema \texttt{DateTime} datatype~\citep{Biron2004}. For example, "\texttt{2016-03-16T20:12:00Z}" specifies that the day is 16 March 2016 and the time is 20:12pm in UTC (Coordinated Universal Time). An example serialization is shown below: \lstsetsbol \begin{lstlisting} @@ -116,9 +116,9 @@ \subsection{Recommended Ontologies for External Terms} \end{lstlisting} -\twotwoone{\subsection{Annotating Entities with Authorship information}\label{sec:Authorship} +\subsection{Annotating Entities with Authorship information}\label{sec:Authorship} Authorship information should ideally be added to \sbol{TopLevel} entities, where possible. It is RECOMMENDED that the \texttt{creator} DCMI Metadata term SHOULD be used to annotate SBOL entities with authorship information. This property can be repeated for each author. The example below shows the use of this property for two authors and the values shown are free text \texttt{String} literals. -} + \lstsetsbol \begin{lstlisting} @@ -132,3 +132,65 @@ \subsection{Recommended Ontologies for External Terms} \end{lstlisting} +\subsection{Host Context / Ontologies for Experiments} + +\subsubsection{Mixtures via Components} + +Any \sbol{Component} can be interpreted as specifying a mixture of the \sbol{SubComponent}s that it includes. + +The amount of each such instance included in the mixture SHOULD be specified by attaching a \sbol{Measure} with a \sbolmult{types:Measure}{type} set to the appropriate SBO term. The SBO terms that are RECOMMENDED as appropriate are members of the Systems Description Parameter (SBO:0000545) branch of SBO. Examples include: +\begin{itemize} +\item SBO:0000540: fraction of an entity pool (e.g., 1/3 CHO cells, 2/3 HEK cells) +\item SBO:0000472: molar concentration of an entity (e.g., 1 mM Arabinose) +\item SBO:0000361: amount of an entity pool (e.g., 200 uL M9 media) +\end{itemize} + +\subsubsection{Media, Inducers, and Other Reagents} + +An ``atomic'' reagent, which is not expected to be divided further in designs, SHOULD be represented as a \linebreak \sbol{Component}. Examples: Arabinose, Kanamycin, Rainbow bead control + +A ``composite'' reagent, which might be defined as a mixture of other reagents, SHOULD be represented as a \sbol{Component} that defines it as a mixture of other reagents. This might be recursive, with mixtures of mixtures of mixtures, etc. Examples: M9 media, LB broth + +The roles of reagents may vary in context: for example, Arabinose may serve as an inducer or as a media carbon source. As such, role SHOULD be indicated by an NCI Thesaurus (NCIT) term in a \sbolmult{roles:MD}{role} property of the \sbol{SubComponent}. Examples include: +\begin{itemize} +\item NCIT:C64356: Positive Control +\item NCIT:C48694: Cell +\item NCIT:C85504: Media +\item NCIT:C14419: Strain +\item NCIT:C120268: Inducer +\end{itemize} + +Note that this also implies that the \sbolmult{roles:C}{role} property should be promoted from \sbol{SubComponent} to \sbol{ComponentInstance} (so it can be used for \sbol{FunctionalComponent} as well) and also added to \sbol{Module}. + +\subsubsection{Strains, Genomes, and Plasmids} + +A cell strain SHOULD be represented as a \sbol{Component} containing at least: +\begin{itemize} +\item A \sbol{SubComponent} for the cell, which is RECOMMENDED to have \sbolmult{types:CD}{type} cell (GO:0005623) and \sbolmult{roles:MD}{role} physical compartment (SBO:0000290). +\item A representation of its genetic material (genome, plasmids, etc.) as a collection of \sbol{SubComponent} instances. +\item An \sbol{Interaction} of type \texttt{FunctionalCompartment} (SBO:0000289) with the cell participating as physical compartment (SBO: 0000290) and the genetic material participating as contained entity (SBO:0000664). +\end{itemize} + +\subsubsection{Samples} + +A complete specification of a sample SHOULD be a \sbol{Component} that includes at least: +\begin{itemize} +\item A \sbol{Module} instantiating each strain in the sample +\item A \sbol{SubComponent} for the media or buffer +\item A \sbol{SubComponent} for each additional reagent added to the media (e.g., inducers, antibiotics) +\item \sbol{Measure}s on each of these specifying the amount in the sample +\item \sbol{Measure}s on the \sbol{Component} for each environmental parameter (e.g., temperature, pH, culturing time) +\end{itemize} + +\subsubsection{Other Experimental Parameters} + +In order to deal with parameters associated with the context in general but not specific instances, e.g., temperature, pH, total sample volume, we need to add a \texttt{measures} property to \sbol{Component} (in addition to the ones already on \sbol{SubComponent}) and to \sbol{ComponentDefinition}. + +The distinction is that the \texttt{measures} of a \texttt{Component} provide context-free information (e.g., the pH of M9 media, the GC-content of a GFP coding sequence), while the \texttt{measures} on an \texttt{SubComponent} provide a measurement in context (e.g., the dosage of Arabinose in a sample). + +Values of these parameters SHOULD be specified by attaching a \sbol{Measure} with a \sbolmult{types:Measure}{type} set to the appropriate SBO term. The SBO terms that are RECOMMENDED as appropriate are members of the Systems Description Parameter (SBO:0000545) branch of SBO. Examples include: +\begin{itemize} +\item SBO:0000147: thermodynamic temperature (e.g., culturing at 27 C) +\item SBO:0000332: half-life of an exponential decay (e.g., decay rate of a gRNA) +\item SBO:0000304: pH (e.g., pH of M9 media) +\end{itemize} diff --git a/purpose.tex b/purpose.tex index 65761dae..8e194ea0 100644 --- a/purpose.tex +++ b/purpose.tex @@ -25,14 +25,14 @@ \section{Purpose} %Goksel: Removed this sentence: The ultimate utility of URIs in the SBOL standard is the ability to support flexible annotation with appropriate metadata while associating an authority with that annotation. The definition of the data model and associated format, the rules on the addition of data within the format and the representation of this in electronic data files are intended to make the SBOL standard a useful means of promoting global data exchange between laboratories and between software programs. -\twothreezero{ + This document details version 2.3 of SBOL that builds upon the previous version 2.2. In particular, SBOL 2.3 includes means of succinctly representing sequence modifications (such as insertion, deletion, and replacement), an extension to support organization and attachment of experimental data derived from designs, and an extension for describing numerical parameters of design elements. The new version also includes typing of activities, unambiguous locations for sequences with multiple encodings, refinement of a number of validation rules, improved figures and examples, and clarification on a number of issues related to ontology terms. -} -\twotwozero{Version 2.2 of SBOL in turn builds upon SBOL version 2.1. SBOL 2.2 included improved description and validation rules for genetic design provenance, an extension to support combinatorial genetic designs, a new class to add non-SBOL data as attachments, a new class for genetic design implementations, and a description of a methodology to describe the entire design-build-test-learn cycle within the SBOL data model.} -\twoonezero{Version 2.1 included improved rules for what constitutes a valid SBOL document, new role fields to simplify the expression of sequence features and how components are used in context, and new best practices descriptions to improve the exchange of basic sequence topology information and the description of genetic design provenance.} +Version 2.2 of SBOL in turn builds upon SBOL version 2.1. SBOL 2.2 included improved description and validation rules for genetic design provenance, an extension to support combinatorial genetic designs, a new class to add non-SBOL data as attachments, a new class for genetic design implementations, and a description of a methodology to describe the entire design-build-test-learn cycle within the SBOL data model. + +Version 2.1 included improved rules for what constitutes a valid SBOL document, new role fields to simplify the expression of sequence features and how components are used in context, and new best practices descriptions to improve the exchange of basic sequence topology information and the description of genetic design provenance. SBOL 2.x builds upon SBOL 1.1, which focused on representing the structural aspects of genetic designs. Users of the standard were able to exchange information on DNA designs, but they could not represent molecules other than DNA or the functional aspects of designs beyond DNA sequence features. The SBOL 2 data model defined in this specification extends the version 1.1 data model to provide for the most pressing data exchange needs identified by the SBOL community. In particular, the extended data model can: \begin{itemize} @@ -48,14 +48,13 @@ \section{Purpose} \end{itemize} Taken together, these extensions enable SBOL to support the description and exchange of hierarchical, modular representations of both the intended structure and function of designed biological systems. -\twotwozero{ \begin{figure}[htbp] \centering \includegraphics[width=\textwidth]{images/standard-evolution.pdf} \caption{SBOL 2 extends prior sequence description formats to represent both the structure and function of a genetic design in a modular, hierarchical manner.} \label{f:sequence} \end{figure} -} + While the ultimate goal of SBOL is to describe synthetic biological designs such that they can be reproduced in the lab with a high degree of fidelity, SBOL 2 does not yet provide a complete catalog of the different classes of data that are necessary to achieve this goal. For example, SBOL 2 does not yet include data on environmental and host context, or details on how the performance of a design is measured. diff --git a/sbmlpkgspec.cls b/sbmlpkgspec.cls index e5984ff7..8237b4bf 100644 --- a/sbmlpkgspec.cls +++ b/sbmlpkgspec.cls @@ -953,7 +953,7 @@ Package Specification Style] \newcommand{\notice}{\marginpar{\hspace*{34pt}\raisebox{-0.5ex}{\color{black}\Large\ding{43}}}} \newcommand{\version}[1]{\marginpar{\hspace*{34pt}\raisebox{-3.0ex}{\color{blue}\small #1}}} -\newcommand{\warning}{\marginpar{\hspace*{34pt}{\color{red}\large\danger}}} +%\newcommand{\warning}{\marginpar{\hspace*{34pt}{\color{red}\large\danger}}} % Margin notes. % diff --git a/sbol3.synctex.gz b/sbol3.synctex.gz new file mode 100644 index 00000000..8592e3b4 Binary files /dev/null and b/sbol3.synctex.gz differ diff --git a/serialization.tex b/serialization.tex index e8d6edd2..dc42425d 100644 --- a/serialization.tex +++ b/serialization.tex @@ -46,6 +46,6 @@ \section{SBOL RDF Serialization} Other objects can refer to this entity through their annotations by reference, and this generic top-level entity can refer to other entities via references. For example, a \sbol{Component} might use an annotation to refer to the data sheet \sbol{GenericTopLevel} that documents its properties. -\twozeroone{As previously stated, XML is the preferred RDF serialization for SBOL files, and these files should use the ".xml" file extension. While any RDF serialization is valid, as the contents of the triples and not their format determine the validity, restriction to XML enhances human ability to classify a document as SBOL easily. Furthermore, documents can be human-examined by using XML formatting tools and syntax highlighters. It should be noted that XML was chosen for no particular reason than the simple fact of its widespread use in the community and by existing libraries. The proposers are aware that many of these benefits apply to several serializations of SBOL. The choice of XML is simply a codification of the existent standard and practice.} +As previously stated, XML is the preferred RDF serialization for SBOL files, and these files should use the ".xml" file extension. While any RDF serialization is valid, as the contents of the triples and not their format determine the validity, restriction to XML enhances human ability to classify a document as SBOL easily. Furthermore, documents can be human-examined by using XML formatting tools and syntax highlighters. It should be noted that XML was chosen for no particular reason than the simple fact of its widespread use in the community and by existing libraries. The proposers are aware that many of these benefits apply to several serializations of SBOL. The choice of XML is simply a codification of the existent standard and practice. By adopting this paradigm of RDF/XML serialization, SBOL is able to adapt to future changes in the standard without requiring large-scale alterations to the RDF files. Since exactly the same scheme is used to serialize annotations as is used to serialize specification-defined properties and associations, it is possible to update the SBOL standard to recognize a different range of properties and associations. Those properties not recognized by the specification will always be available through the API as annotations. Similarly, by allowing arbitrary top-level entities in a SBOL file, we enable future specifications or extensions to ratify the structure of other top-level objects. These entities would then become part of the explicit data model, but the identical RDF serialization would be used. Applications lacking support for a given extension can safely read in, manipulate, and write out the top-level data that is not understood, treating it as a top-level structured annotation, without data loss or corruption. Finally, the very regimented control of nesting versus referencing also allows the XML structure to be very predictable, enabling XML/DOM-based tooling to work with SBOL RDF/XML files safely.