Synthetic biology open language (SBOL) version 3.1.0

Abstract Synthetic biology builds upon genetics, molecular biology, and metabolic engineering by applying engineering principles to the design of biological systems. When designing a synthetic system, synthetic biologists need to exchange information about multiple types of molecules, the intended behavior of the system, and actual experimental measurements. The Synthetic Biology Open Language (SBOL) has been developed as a standard to support the specification and exchange of biological design information in synthetic biology, following an open community process involving both bench scientists and scientific modelers and software developers, across academia, industry, and other institutions. This document describes SBOL 3.1.0, which improves on version 3.0.0 by including a number of corrections and clarifications as well as several other updates and enhancements. First, this version includes a complete set of validation rules for checking whether documents are valid SBOL 3. Second, the best practices section has been moved to an online repository that allows for more rapid and interactive of sharing these conventions. Third, it includes updates based upon six community approved enhancement proposals. Two enhancement proposals are related to the representation of an object’s namespace. In particular, the Namespace class has been removed and replaced with a namespace property on each class. Another enhancement is the generalization of the CombinatorialDeriviation class to allow direct use of Features and Measures. Next, the Participation class now allow Interactions to be participants to describe higher-order interactions. Another change is the use of Sequence Ontology terms for Feature orientation. Finally, this version of SBOL has generalized from using Unique Reference Identifiers (URIs) to Internationalized Resource Identifiers (IRIs) to support international character sets.


Purpose
1 Synthetic biology builds upon genetics, molecular biology, and metabolic engineering by applying engineering 2 principles to the design of biological systems. When designing a synthetic system, synthetic biologists need 3 to exchange information about multiple types of molecules, the intended behavior of the system, and actual 4 experimental measurements. Furthermore, there are often multiple aspects to a design such as a specified nucleic 5 acid sequence (e.g., a sequence that encodes an enzyme or transcription factor), the molecular interactions that 6 a designer intends to result from the introduction of this sequence (e.g., chemical modification of metabolites or 7 regulation of gene expression), and the experiments and data associated with the system. All these perspectives 8 need to be connected together to facilitate the engineering of biological systems. 9 The Synthetic Biology Open Language (SBOL) has been developed as a standard to support the specification and 10 exchange of biological design information in synthetic biology, following an open community process involving 11 both "wet" bench scientists and "dry" scientific modelers and software developers, across academia, industry, and 12 other institutions. Previous nucleic acid sequence description formats lack key capabilities relative to SBOL, as 13 shown in Figure 1. Simple sequence encoding formats such as FASTA encode little besides sequence information. 14 More sophisticated formats such as GenBank and Swiss-Prot provide a flat annotation of sequence features that is 15 well suited to describing natural systems but unable to represent the functional relations and multi-layered design 16 structure common to engineered systems. Modeling languages, such as the Systems Biology Markup Language 17 (SBML) Hucka et al. (2003), can be used to represent biological processes, but are not sufficient to represent the 18 associated nucleotide or amino acid sequences. SBOL covers both of these needs, by providing a modular and 19 hierarchical representation of the structure and function of a genetic design, as well as its relationship to and use 20 within experiment plans, data, models, etc.

21
SBOL uses existing Semantic Web practices and resources, such as Uniform Resource Identifiers (IRIs) and ontologies, 22 to unambiguously identify and define biological system elements, and to provide serialization formats for encoding 23 this information in electronic data files. The SBOL standard further describes the rules and best practices on how to 24 use this data model and populate it with relevant design details. The definition of the data model, the rules on the 25 addition of data within the format, and the representation of this in electronic data files are intended to make the 26 SBOL standard a useful means of promoting data exchange between laboratories and between software programs.    The SBOL effort was started in 2006 with the goal of developing a data exchange standard for genetic designs.  Toolchains, and Zymergen.

19
Discussions related to SBOL 3 began at the COMBINE meetings and on the mailing list beginning in the summer 20 of 2018. Over the next year and a half, several SBOL Enhancement Proposals (SEPs) were written and discussed.

21
During the early months of 2020, these SEPs were voted on and approved by the SBOL community. The initial 22 version of the SBOL 3 specification was drafted during HARMONY 2020 at the European Bioinformatics Institute 23 (EBI) in Hinxton, United Kingdom in March 2020.

24
The authors would also like to thank Michael Hucka for developing the LaTeX style file used to develop this 25 document (Hucka, 2017). Synthetic biology designs can be described using: 2 ■ Structural terms, e.g., a set of annotated sequences or information about the chemical makeup of components.
3 ■ Functional terms, e.g., the way that components might interact with each other.

4
As an example, consider an expression cassette, such as the one found in the plasmid pUC18 Norrander et al. (1983).

5
The system is designed to visually indicate whether a gene has been inserted into the plasmid: in the presence of 6 IPTG, it expresses an enzyme that hydrolyses X-gal to form a blue product, but successful insertion disrupts the 7 expression cassette and prevents the formation of this product. Internally, it has a number of parts, including a 8 promoter, the lac repressor binding site, and the lacZ coding sequence. These parts have specific component-level 9 interactions with IPTG and X-gal, as well as native host gene products, transcriptional machinery, and translational 10 machinery that collectively cause the desired system-level behavior. 11 In SBOL 3, both the structural and functional aspects are described using a class called Component, as depicted in 12 Figure 2. Namely, to represent structural aspects, a Component can include Features, some of which may be at some 13 Location within a Sequence. A Component can also include Constraints between these features. To represent 14 functional aspects, a Component can include Interactions that can refer to relationships between participating 15 Features. Finally, a Component can have its behavior described using a Model. arrow represents a reference to an object of another class. Red boxes represent structural objects, while blue boxes represent functional objects. To represent structural aspects, a Component can include Features, which may refer to Locations within a Sequence. A Component can also include Constraints between these features. To represent functional aspects, a Component can include Interactions that can refer to relationships between participating Features. Finally, a Component can have its behavior described using a Model.
To continue with the pUC18 example, the description would begin with a top-level Component that represents the can also include the actual Sequence information (if available), as well as SubComponent objects that identify the 1 Locations of the promoters, coding sequences, etc., on the Sequence. In order to specify functional information, the 2 Component can also specify Interaction objects that describe any qualitative relationships among SubComponent 3 Participations, such as how IPTG and X-gal interact with the gene products. Finally, a Component object can 4 point to a Model object that provides a reference to a complete computational model expressed in a language such 5 as SBML Hucka et al. (2003), CellML Cuellar et al. (2003), or MATLAB MathWorks (2015. 6 Whereas Figure 2 provides an overview of the classes used for describing designs within the SBOL 3 data model, 7 Figure 3 shows the rest of the classes used to describe the usage of a design within design-build-test-learn workflows 8 in general. In particular, designs can be expressed using CombinatorialDerivations, Components, and Sequences.

9
These can describe not only genetic designs, but also designs for strains, multicellular systems, media, samples, 10 etc. A CombinatorialDerivation allows one to specify a design pattern where individual SubComponents can be 11 selected from a set of variants. The Implementation class is the build class, and it is used to represent physical 12 artifacts like an actual sample of a plasmid. The Experiment and ExperimentalData classes are the test classes, 13 allowing description of a collection of data generated in an experiment. The Model class, discussed earlier, associates 14 learned information with a design. The prov:Activity class is taken from the provenance ontology (PROV-O), 15 which is described in Section A.1. For example, a build prov:Activity describes how an Implementation is 16 constructed using a Component description. On the other hand, a test prov:Activity describes how an Experiment 17 is conducted using an Implementation artifact. The Collection class has members, which can be of any of these 18 types or Collections themselves. Finally, all of these objects can refer to objects of the Attachment class, which 19 are used to link out to external data (images, spreadsheets, textual documents, etc.). The next sections provide 20 complete definitions and details for all of these classes. Green boxes represent design classes, orange boxes represent build classes, purple boxes represent test classes, yellow boxes represent learn classes, and the gray boxes represent additional utility classes. Each of these classes will be described in more detail below.

1
This section provides some preliminary information to aid in the understanding of the specification. The SBOL 2 data model is specified using Unified Modeling Language (UML) 2.0 diagrams (OMG 2005). This section reviews 3 terminology conventions, the basics of UML diagrams, and our naming conventions. This document indicates requirement levels using the controlled vocabulary specified in IETF RFC 2119. In 6 particular, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 7 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8

2119.
9 ■ The words "MUST", "REQUIRED", or "SHALL" mean that the item is an absolute requirement.

10
■ The phrases "MUST NOT" or "SHALL NOT" mean that the item is an absolute prohibition.

11
■ The word "SHOULD" or the adjective "RECOMMENDED" mean that there might exist valid reasons in 12 particular circumstances to ignore a particular item, but the full implications need to be understood and 13 carefully weighed before choosing a different course.
14 ■ The phrases "SHOULD NOT" or "NOT RECOMMENDED" mean that there might exist valid reasons in 15 particular circumstances when the particular behavior is acceptable or even useful, but the full implications 16 need to be understood and the case carefully weighed before implementing any behavior described with this 17 label.
18 ■ The word "MAY" or the adjective "OPTIONAL" mean that an item is truly optional.

20
The types of biological design data modeled by SBOL are commonly referred to as classes, especially when discussing 21 the details of software implementation. Each SBOL class can be instantiated by many SBOL objects. These objects

22
MAY contain data that differ in content, but they MUST agree on the type and form of their data as dictated by their 23 common class. Classes are represented in UML diagrams as rectangles labeled at the top with class names (see 24 Figure 4 for examples). property can possess (see below). The remaining (non-association) properties of a class are listed below its name. Each of the latter properties is labeled with its data type and cardinality. 2 In the case of an association property, the class from which the arrow originates is the owner of the association 3 property. A diamond at the origin of the arrow indicates the type of association. Open-faced diamonds indicate 4 shared aggregation, also known as a reference, in which the owner of the association property exists independently 5 of its value.

6
By contrast, filled diamonds indicate composite aggregation, also known as a part-whole relationship, in which the 7 value of the association property MUST NOT exist independently of its owner. In addition, in the SBOL data model, 8 it is REQUIRED that the value of each composite aggregation property is a unique SBOL object (that is, not the value 9 for more than one such property). Note that in all cases, composite aggregation is used in such a way that there 10 SHOULD NOT be duplication of such objects. Such objects are also commonly referred to as "child" objects, and 11 their owning objects as "parent" objects.

12
All SBOL properties are labeled with one of several restrictions on data cardinality. These are defined, per RDF, as: lower camel case, meaning that they begin lowercase (e.g., role) but if they consist of multiple words, all words 28 after the first begin with an uppercase letter (e.g., roleIntegration).

29
SBOL properties are always given singular names irrespective of their cardinality, e.g., role is used rather than 30 roles even though a component can have multiple roles. This is because each relation can potentially stand on its 31 own, irrespective of the existence of others in the set.

32
Two conventions are used for property names, name and hasName. When a property is pointing to a class using 33 the same name, it uses the hasName convention (e.g., the Component class uses hasFeature to point to a Feature 34 object). When the property uses a different name than the class of the object it points to, it uses the name convention 35 instead (e.g., the Constraint class uses subject to point to a Feature object). The term literal is used to denote an object that can be any of the five types listed above.

10
In addition to the simple types listed above, SBOL also uses objects with types Internationalized Resource Identifier 11 (IRI). It is important to realize that in RDF, a IRI might or might not be a resolvable URL (web address). A IRI is 12 always a globally unique identifier within a structured namespace. In some cases, that name is also a reference to 13 (or within) a document, and in some cases that document can also be retrieved (e.g., using a web browser).

15
All SBOL objects are given the most specific rdfType in the SBOL 3 namespace ("http://sbols.org/v3#") that conclude that there are no other displayId values, and thus its "zero or one" cardinality requirement is satisfied. 39 We further assume that any document containing an object also contains all of its child objects. In other words, 40 the fundamental unit of SBOL documents is the TopLevel object, and any document containing a TopLevel 41 also contains the complete set of information necessary to describe that TopLevel-but not necessarily any The section describes the SBOL data model in detail. Best practices when using the standard can be found in 2 Section 7. All SBOL-defined classes are directly or indirectly derived from the Identified abstract class. This inheritance 5 means that all SBOL objects are uniquely identified using IRIs that uniquely refer to these objects within an SBOL 6 document or at locations on the World Wide Web. 7 As shown in Figure 5, the Identified class includes the following properties: displayId, name, description, The displayId property is an OPTIONAL identifier with a data type of String. This property is intended to be an 11 intermediate between a IRI and the name property that is machine-readable, but more human-readable than the 12 full IRI of an object.

13
If the displayId property is used, then its String value MUST be composed of only alphanumeric or underscore 14 characters and MUST NOT begin with a digit.

15
Note that for objects whose IRI is a URL, the requirements on URL structure in Section 5.1 imply that the displayId 16 MUST be set.

17
The name property 18 The name property is OPTIONAL and has a data type of String. This property is intended to be displayed to a 19 human when visualizing an Identified object.

20
If an Identified object lacks a name, then software tools SHOULD instead display the object's displayId or IRI. It 21 is RECOMMENDED that software tools give users the ability to switch perspectives between name properties that 22 are human-readable and displayId properties that are less human-readable, but are more likely to be unique.

23
The description property 24 The description property is OPTIONAL and has a data type of String. This property is intended to contain a more 25 thorough text description of an Identified object.

26
The prov:wasDerivedFrom property 27 An Identified object MAY have zero or more prov:wasDerivedFrom properties, each of type IRI. This property 28 is defined by the PROV-O ontology and is located in the https://www.w3.org/ns/prov# namespace (Reference: 29 Section 6.2 TopLevel Section A.1).
1 An Identified object with this property refers to one or more non-SBOL resources or SBOL Identified objects 2 from which this object was derived. An Identified object MUST NOT refer to itself via its own prov:wasDerivedFrom 3 property or form a cyclical chain of references via its prov:wasDerivedFrom property and those of other Identified 4 objects. For example, the reference chain "A was derived from B and B was derived from A" is cyclical.

5
The prov:wasGeneratedBy property 6 An Identified object MAY have zero or more prov:wasGeneratedBy properties, each of type IRI. This property 7 is defined by the PROV-O ontology and is located in the https://www.w3.org/ns/prov# namespace (Reference: 8 Section A.1).

9
An Identified object with this property refers to one or more prov:Activity objects that describe how this object 10 was generated. Provenance history formed by prov:wasGeneratedBy properties of Identified objects and entity 11 references in prov:Usage objects MUST NOT form circular reference chains. prov:Activity, prov:Agent, prov:Plan (see Figure 6). Each of these classes is described in more detail below, 25 except for the classes from the provenance ontology (PROV-O), which are described in Section A.1.

26
The hasNamespace property 27 A TopLevel object MUST have precisely one hasNamespace property, which contains a URL that defines the names-28 pace portion of URLs for this object and any child objects. If the IRI for the TopLevel object is a URL, then the URL 29 of the hasNamespace property MUST prefix match that URL.

30
Note that the requirement for a hasNamespace property holds even for objects with IRIs that are not URLs, in order 31 to allow them to be copied into datastores that use URLs. In this case, however, there is no prefix requirement.

32
The hasAttachment property 33 A TopLevel object can have zero or more hasAttachment properties, each of type IRI specifying an Attachment 34 object. The Attachment class is described in more detail in Section 6.10. The elements property is an OPTIONAL String of characters that represents the constituents of a biological or 2 chemical molecule. For example, these characters could represent the nucleotide bases of a molecule of DNA, the 3 amino acid residues of a protein, or the atoms and chemical bonds of a small molecule.

4
If the elements property is not set, then it means the particulars of this Sequence have not yet been determined.

5
The encoding property 6 The encoding property has a data type of IRI, and is OPTIONAL unless elements is set, in which case it is RE-7 QUIRED. This property MUST indicate how the elements property of a Sequence are formed and interpreted. The 8 encoding property SHOULD respectively contain a IRI identifying from the textual format (https://identifiers. 9 org/edam:format_2330) branch of the EDAM ontology.

10
For example, the elements property of a Sequence with an IUPAC DNA encoding property MUST contain characters 11 that represent nucleotide bases, such as a, t, c, and g. The elements property of a Sequence with a Simplified 12 Molecular-Input Line-Entry System (SMILES) encoding, on the other hand, MUST contain characters that represent 13 atoms and chemical bonds, such as C, N, O, and =.
14 Table 1 contains a partial list of possible IRI values for the encoding property. These terms are organized by the 1 type of Component (see Table 2) that typically refer to a Sequence with such an encoding. It Table 2) that typically refer to a Sequence with such an encoding.

10
The Component class represents the structural and/or functional entities of a biological design. The primary usage 11 of this class is to represent entities with designed sequences, such as DNA, RNA, and proteins, but it can also be 12 used to represent any other entity that is part of a design, such as simple chemicals, molecular complexes, strains, 13 media, light, and abstract functional groupings of other entities.
14 As shown in Figure 8, the Component class describes a design entity using the following properties: type, role, The type properties of every Component MUST include one or more IRIs that MUST identify terms from appropriate 2 ontologies, such as the physical entity representation branch of the Systems Biology Ontology Courtot et al. (2011) 3 or the ontology of Chemical Entities of Biological Interest (ChEBI) Degtyarenko et al. (2008). In order to maximize 4 the compatibility of designs, the type property of a Component SHOULD contain a URL from the physical entity 5 representation branch of the Systems Biology Ontology Courtot et al. (2011). Table 2 provides a partial list of 6 ontology terms and their URLs, and any Component that can be well-described by one of the terms in Table 2   Any Component classified as DNA (see Table 2) is RECOMMENDED to encode circular/linear topology information 19 in an additional type field. This (topology) type field SHOULD specify a URL from the Topology Attribute branch 20 of the Sequence Ontology (SO): this is currently just 'linear' or 'circular' as given in Table 3 or if topology is genuinely unknown. For any Component classified as RNA (see Table 2), a topology type field is 24 OPTIONAL. The default assumption in this case is linear topology. In any case, conflicting topologies MUST NOT be 25 specified.

26
Any Component classified as DNA or RNA MAY also have strand information encoded in an additional (third) type 27 field using a URL from the Strand Attribute branch of the SO (currently there are only two possible terms for single 28 or double-stranded nucleic acids, given in Table 3). In absence of this field, the default strand information assumed 29 for DNA is 'double-stranded' and for RNA is 'single-stranded'.

30
Any other type of Component record (protein, simple chemical, etc.) SHOULD NOT have any type field pointing to 31 SO terms from the topology or strand attribute branches of SO.

32
Note that a circular topology instructs software to interpret the beginning / end position of a given sequence (  properties and their URLs. These terms are organized by the type of Component to which they SHOULD apply (see 14   Table 2). Any Component that can be well-described by one of the terms in Table 4 MUST use the URL for that term 15 as a role.

16
These IRIs might identify descriptive biological roles, such as "metabolic pathway" and "signaling cascade," but 17 they can also identify identify "logical" roles, such as "inverter" or "AND gate", or other abstract roles for describing    Table 4: Partial list of ontology terms to specify the role property of a Component, organized by the type of Component to which they are intended to apply (see Table 2).
The hasSequence property 32 A Component MAY have any number of hasSequence properties, each of type IRI, that MUST reference a Sequence 33 object (see Section 6.3). These objects define the primary structure or structures of the Component.

34
If a Feature of a Component refers to a Location, and this Location refers to a Sequence, then the Component

35
MUST also include a hasSequence property that refers to this Sequence.

36
Many Component objects will have exactly one hasSequence property that refers to a Sequence object. In this 37 case, if its has a type from Table 2 and there is an encoding that is cross-listed with this term in object (see Section 6.4.1). The set of relations between Feature and Component objects MUST be strictly acyclic.

3
Taking the Component class as analogous to a blueprint or specification sheet for a biological part or a system of 4 interacting biological elements, the Feature class represents the specific occurrence of a part, subsystem, or other 5 notable aspect within that design. This mechanism also allows a biological design to include multiple instances 6 of a particular part (defined by reference to the same Component). For example, the Component of a polycistronic 7 gene could contain two SubComponent objects that refer to the same Component of a CDS. As another example, 8 consider the Component for a network of two-input repressor devices in which the particular repressors have not yet 9 been chosen. This Component could contain multiple SubComponent objects that refer to the same Component of an 10 abstract two-input repressor device.

11
The hasFeature properties of Component objects can be used to construct a hierarchy of SubComponent and 12 Component objects. If a Component in such a hierarchy refers to a Location object, and there exists a Component 13 object lower in the hierarchy that refers to a Location object that refers to the same Sequence with the same 14 encoding, then the elements properties of these Sequence objects SHOULD be consistent with each other, such 15 that well-defined mappings exist from the "lower level" elements to the "higher level" elements in accordance 16 with their shared encoding properties. This mapping is also subject to any restrictions on the positions of the 17 Feature objects in the hierarchy that are imposed by the SubComponent, SequenceFeature, or Constraint objects 18 contained by the Component objects in the hierarchy.

19
For example, in a plasmid Component with a promoter SubComponent, the sequence at the promoter's Location 20 within the plasmid should be the sequence for the promoter. More concretely, consider DNA Component that 21 refers to a Sequence with an IUPAC DNA encoding and an elements String of "gattaca." In turn, this Component 22 could contain a SubComponent that refers to a "lower level" Component that also refers to a Sequence with an IUPAC 23 DNA encoding. Consequently, a consistent elements String of this "lower level" Sequence could be "gatta," or 24 perhaps "tgta" if the SubComponent is positioned by a Location with an orientation of "reverse complement"

26
The hasConstraint property 27 A Component MAY have any number of hasConstraint properties, each of type IRI, that MUST reference a 28 Constraint object (see Section 6.4.3). These objects describe, among other things, any restrictions on the relative, 29 sequence-based positions and/or orientations of the Feature objects contained by the Component, as well as spatial 30 relations such as containment and identity relations. For example, the Component of a gene might specify that 31 the position of its promoter SubComponent precedes that of its CDS SubComponent. This is particularly useful 32 when a Component lacks a Sequence and therefore cannot specify the precise, sequence-based positions of its 33 SubComponent objects using Location objects.

34
The hasInteraction property 35 A Component MAY have any number of hasInteraction properties, each of type IRI, that MUST reference an 36 Interaction object (see Section 6.4.4).

37
The Interaction class provides an abstract, machine-readable representation of behavior within a Component 38 (whereas a more detailed model of the system might not be suited to machine reasoning, depending on its im-39 plementation). Each Interaction contains Participation objects that indicate the roles of the Feature objects 40 involved in the Interaction.

41
The hasInterface property 42 A Component MAY have zero or one hasInterface property of type IRI that MUST reference an Interface object 43 (see Section 6.4.5).

44
An Interface object indicates the inputs, outputs, and non-directional points of connection to a Component.

45
The hasModel property 1 A Component MAY have any number of hasModel properties, each of type IRI, that MUST reference a Model object 2 (see Section 6.8).

3
Model objects are placeholders that link Component objects to computational models of any format. A Component 4 object can link to more than one Model since each might encode system behavior in a different way or at a different 5 level of detail. The Feature class, as shown in Figure 9 is used to compose Component objects into a structural or functional 8 hierarchy. Feature is an abstract class; only its child classes are actually instantiated. Feature in the context of its parent Component. If the role for a SubComponent is left unspecified, then the role is 12 determined by the role property of the Component that it is an instanceOf. If provided, these role property IRIs

13
MUST identify terms from appropriate ontologies. Roles are not restricted to describing biological function; they 14 may annotate a Feature's function in any domain for which an ontology exists. A table of recommended ontology 15 terms for role is given in Table 4. 16 It is RECOMMENDED that these role property IRIs identify terms that are compatible with the type properties 17 of the Feature's parent Component. For example, a role of a Feature which belongs to a Component of type DNA 18 might refer to terms from the Sequence Ontology. Likewise, for any feature that is a SubComponent, the role 19 SHOULD be compatible with the type of the Component that it links to through its instanceOf property.

20
The orientation property 21 The orientation property is OPTIONAL and has a data type of IRI. This can be used to indicate how any associated 22 double-stranded Feature is oriented on the elements of a Sequence from their parent Component. If a Feature 23 object has an orientation, then it is RECOMMENDED that it come from https://identifiers.org/SO:0001031 The region specified by this Feature or Location is on the reversecomplement mapping of the elements of a Sequence. The exact nature of this mapping depends on the encoding of the Sequence. http://sbols.org/v3#reverseComplement The region specified by this Feature or Location is on the reversecomplement mapping of the elements of a Sequence. The exact nature of this mapping depends on the encoding of the Sequence. Table 6: Permitted alternative URLs for the orientation property. The URLs listed in Table 5 are preferred and SHOULD be used instead where possible.

SubComponent 7
The SubComponent class is a subclass of the Feature class that can be used to specify structural hierarchy. For 8 example, the Component of a gene might contain four SubComponent objects: a promoter, RBS, CDS, and termi-9 nator, each linked to a Component that provides the complete definition. In turn, the Component of the promoter 10 SubComponent might itself contain SubComponent objects defining various operator sites, etc.

11
The roleIntegration property 12 A roleIntegration specifies the relationship between a SubComponent instance's own set of role properties and 13 the set of role properties on the included Component.

14
The roleIntegration property has a data type of IRI. A SubComponent instance with zero role properties MAY

15
OPTIONALLY specify a roleIntegration. A SubComponent instance with one or more role properties MUST 16 specify a roleIntegration from http://sbols.org/v3#overrideRoles In the context of this SubComponent, ignore any role given for the included Component. Instead use only the set of zero or more role properties given for this SubComponent.

23
http://sbols.org/v3#mergeRoles Use the union of the two sets: both the set of zero or more role properties given for this SubComponent as well as the set of zero or more role properties given for the included Component. The instanceOf property is a REQUIRED IRI that refers to the Component providing the definition for this 2 SubComponent. Among other things, as described in the previous section, this Component effectively provides 3 information about the type and role of the SubComponent.

4
The instanceOf property MUST NOT refer to the same Component as the one that contains the SubComponent.

5
Furthermore, SubComponent objects MUST NOT form a cyclical chain of references via their instanceOf properties 6 and the Component objects that contain them. For example, consider the SubComponent objects A and B and the 7 Component objects X and Y . The reference chain "X has feature A, A is an instance of Y , Y has feature B , and B is 8 an instance of X " is cyclical.

9
The hasLocation property 10 A SubComponent MAY have any number of hasLocation properties, each of type IRI, that MUST refer to Location 11 objects that indicates the location of the Sequence from the instanceOf Component in a Sequence of the parent 12 Component.

13
If any hasLocation is defined, then there MUST BE precisely one Sequence in the instanceOf Component, as 14 otherwise this relationship is ill-defined.

15
If no hasLocation is defined, this indicates a part / sub-part relationship for which sequence details have not (yet) 16 been determined or involving types for which sequence relationships are not relevant (e.g., inclusion of a reaction 17 chain within a larger metabolic network).

18
Allowing multiple Location objects on a single SubComponent is intended to enable representation of discontinuous 19 regions (for example, a coding sequence encoded across a set of exons with interspersed introns). As such, the 20 Location objects of a single SubComponent MUST NOT specify overlapping regions, since it is not clear what this 21 would mean. There is no such concern with different objects, however, which can freely overlap in Location (for 22 example, specifying overlapping linkers for sequence assembly).

23
The sourceLocation property 24 The sourceLocation property allows for only a portion of a Component's Sequence to be included, rather than its 25 entirety. For example, when composing parts with certain assembly methods, some bases on the boundary may be 26 removed or replaced. Another example is describing a deletion or replacement of a portion of a sequence.

27
A SubComponent MAY have any number of sourceLocation properties, each of type IRI, that MUST refer to 28 Location objects that indicate which elements of the instanceOf Component's Sequence are used in defining the 29 parent of the SubComponent.

30
If there are no sourceLocation properties, then the whole Sequence is assumed to be included. 31

32
The ComponentReference class is a subclass of Feature that can be used to reference Features within 33 SubComponents.

34
The inChildOf property 35 The inChildOf property is a REQUIRED IRI that refers to a SubComponent. The LocalSubComponent class is a subclass of Feature. This class serves as a way to create a placeholder in more 15 complex Components, such as a variable to be filled in later or a composite that exists only within the context of the 16 parent Component.

17
The type property 18 The type property is REQUIRED and contains one or more IRIs. The type property is identical to its use in 19 Component. The ExternallyDefined class has been introduced so that external definitions in databases like ChEBI or UniProt 26 can be referenced.

27
The type property 28 The type property is REQUIRED and contains one or more IRIs. The type property is identical to its use in 29 Component.

30
The definition property 31 The definition property is REQUIRED and is of type IRI that links to a canonical definition external to SBOL.

32
When possible, such definitions SHOULD use the recommended external resources in Section 7.6. For example, an 33 ExternallyDefined simple chemical might link to ChEBI and a protein might link to UniProt. The SequenceFeature class describes one or more regions of interest on the Sequence objects referred to by its 36 parent Component.

37
The hasLocation property 1 The hasLocation is REQUIRED and contains one or more IRIs, which MUST refer to Location objects. These The Location class (as shown in Figure 10) is used to represent the location of Features within Sequences. This 6 class is extended by the Range, Cut, and EntireSequence classes Location is an abstract class; only its child classes 7 are actually instantiated. The orientation property is OPTIONAL and has a data type of IRI. All subclasses of Location share this property, 10 which can be used to indicate how any associated double-stranded Feature is oriented on the elements of a 11 Sequence from their parent Component. If a Location object has an orientation, then it is RECOMMENDED that 12 it come from Table 5; for reasons of backwards compatability it MAY instead come from Table 6.

13
As is typical practice in biology, any change in orientation is applied after indices are interpreted. Thus, for example, 14 in a DNA Sequence with elements AAAAACCCCCTTTTTGGGGGTTTTTGGGGG, indices 1-6 with a reverse orientation will 15 select AAAAAC, which would then be reverse complemented to obtain GTTTTT.

16
The order property 17 The order property is OPTIONAL and has a data type of Integer. If there are multiple Location objects associated 18 with a Feature, the order property is used to specify the order (in increasing value) in which the specified Locations 19 are to be joined to form the sequence of the Feature. Note that order values MAY be non-sequential and non-20 positive, if desired.

21
The hasSequence property 22 The hasSequence property is REQUIRED and MUST contain the IRI of a Sequence object. All subclasses of 23 Location share this property, which indicates which Sequence object referenced by the containing Component is 24 referenced by the Location. Note that the index of the first location is 1, as is typical practice in biology, rather than 0, as is typical practice in 4 computer science.

5
The start property 6 The start property specifies the inclusive starting position of the Range. This property is REQUIRED and MUST 7 contain an Integer value greater than zero. The end property specifies the inclusive ending position of the Range. This property is REQUIRED and MUST 10 contain an Integer value greater than zero. In addition, this Integer value MUST be greater than or equal to that 11 of the start property.

13
The Cut class has been introduced to enable the specification of a region between two discrete positions. This 14 specification is accomplished using the at property, which specifies a discrete position that corresponds to the 15 index of a character in the elements String of a Sequence (except in the case when at is equal to zero-see below).

16
The at property 17 The at property is REQUIRED and MUST contain an Integer value greater than or equal to zero. The region 18 specified by the Cut is between the position specified by this property and the position that immediately follows 19 it. When the at property is equal to zero, the specified region is immediately before the first discrete position or 20 character in the elements String of a Sequence. The Constraint class can be used to assert restrictions on the relationships of pairs of Feature objects contained 26 by the same parent Component. Uses of this class include expressing containment (e.g., a plasmid transformed into 27 a chassis strain), identity mappings (e.g., replacing a placeholder value with a complete definition), and expressing 28 relative, sequence-based positions (e.g., the ordering of features within a template). Each Constraint includes the 29 subject, object, and restriction properties.

30
The subject property 31 The subject property is REQUIRED and MUST contain a IRI that refers to a Feature contained by the same parent 32 Component that contains the Constraint.

33
The object property 34 The object property is REQUIRED and MUST contain a IRI that refers to a Feature contained by the same parent The restriction property is REQUIRED and has a data type of IRI. This property MUST indicate the type of 2 restriction on the locations, orientations, or identities of the subject and object Feature objects in relation to 3 each other. The IRI value of this property SHOULD come from the RECOMMENDED URLs in Table 8, Table 9, and 4

30
The Interaction class (as shown in Figure 12) provides more detailed description of how the Feature objects 31 of a Component are intended to work together. For example, this class can be used to represent different forms 32 of genetic regulation (e.g., transcriptional activation or repression), processes from the central dogma of biology 33 (e.g. transcription and translation), and other basic molecular interactions (e.g., non-covalent binding or enzy-34 matic phosphorylation). Each Interaction includes type properties that refer to descriptive ontology terms and  hasParticipation properties that describe which Feature objects participate in which ways in the Interaction. The type property 26 An Interaction is REQUIRED to have one or more type properties, each of type IRI, that describes the behavior 27 represented by an Interaction.

28
Each type property MUST identify terms from appropriate ontologies. It is RECOMMENDED that exactly one IRI 29 specified by a type property refer to a term from the occurring entity branch of the Systems Biology Ontology (SBO).
30 Table 11 provides a partial list of possible SBO terms for the type property and their corresponding URLs.

31
If an Interaction is well described by one of the terms from The start of the location for subject is less than the start of the location for object (i.e., union of strictlyPrecedes, meets, and overlaps). Example: a promoter precedes a ribosome entry site, but the exact boundary between the two will be determined by sequence optimization and assembly planning.

22
http://sbols.org/v3#strictlyPrecedes The end of the location for subject is less than the start of the location for object. Example: a promoter strictly precedes a terminator (with a CDS between them).

23
http://sbols.org/v3#meets The end of the location for subject is equal to the start of the location for object. Note: this is a stronger interpretation of meets from Table 9 in the context of a linear sequence. Example: the 3' region adjacent to a blunt restriction site meets the 5' region adjacent to the site.

24
http://sbols.org/v3#overlaps The start of the location for subject is before the start of the location for object and the end of the location for subject is before the end of the location for object. Note: this is a stronger interpretation of overlaps from Table 9 in the context of a linear sequence. Example: two adjacent oligos overlap in a Gibson assembly plan.

25
http://sbols.org/v3#contains The start of the location for subject is less than or equal to the start of the location for object and the end of the location for subject is greater than or equal to the end of the location for object (i.e., union of strictlyContains, equals, finishes, and starts). Note: this is a stronger interpretation of contains from Table 9 in the context of a linear sequence. Example: a composite part contains a promoter.

26
http://sbols.org/v3#strictlyContains The start of the location for subject is before the start of the location for object and the end of the location for subject is after the end of the location for object. Note: this is a stronger interpretation of strictlyContains from Table 9 in the context of a linear sequence.
Example: an RNA transcript strictly contains an intron.

27
http://sbols.org/v3#equals The start and end of the location for subject are equal to the start and end of the location for object. Note: this is a stronger interpretation of equals from Table 9 in the context of a linear sequence.
Example: the transcribed region of a CDS part equals the entire part.
28 http://sbols.org/v3#finishes The start of the location for subject is after the start of the location for object and the end of the location for subject is equal to the end of the location for object. Example: a terminator finishes an expression cassette.

29
http://sbols.org/v3#starts The start of the location for subject is equal to the start of the location for object and the end of the location for subject is before the end of the location for object. Example: a promoter starts an expression cassette. Table 10: RECOMMENDED URLs for expressing sequential relations with the restriction property. Note that these relations are only well-defined when the subject and object can be located on the same Sequence (though this may be something that is inferred rather than known a priori). In interpreting these relations, it is important to remember that for Range objects, the start and end indices refer to whole bases/residues such that a Range with end equal to 9 meets a Range with start equal to 10, while it strictlyPrecedes a Cut with at equal to 10.
objects is allowed because it is plausible that a designer might want to specify that an Interaction will exist, even 39 if its participants have not yet been determined.  Each Participation (see Figure 13) represents how a particular Feature behaves in its parent Interaction. The role property 20 A Participation is REQUIRED to have one or more role properties, each of type IRI, that describes the behavior 21 of a Participation (and by extension its referenced Feature) in the context of its parent Interaction.

22
Each role property MUST identify terms from appropriate ontologies. It is RECOMMENDED that exactly one IRI 23 specified by a role property refer to a term from the participant role branch of the SBO. Table 12 provides a partial 24 list of possible SBO terms for the role properties and their corresponding IRIs.

25
If a Participation is well described by one of the terms from Table 12, then a role property MUST refer to the IRI 39 that identifies this term. Also, if a Participation belongs to an Interaction that has a type listed in Table 11, then 40 the Participation SHOULD have a role that is cross-listed with this type in Table 12. Lastly, if there are multiple 41 role properties for a Participation, then they MUST identify non-conflicting terms. For example, the SBO terms 42 "stimulator" and "inhibitor" would conflict.

43
The participant property 44 The participant property indicates a Feature object that plays the designated role in its parent Interaction 45 object. Precisely one value MUST be specified for precisely one of participant or higherOrderParticipant.

46
The higherOrderParticipant property 47 The higherOrderParticipant property indicates an Interaction object that plays the designated role in its parent 48 Interaction object. Precisely one value MUST be specified for precisely one of participant or higherOrderParticipant. 49

25
The Interface class (shown in Figure 14) is a way of explicitly specifying the interface of a Component.  where there are no flows (for instance -a physical interface). The purpose of the CombinatorialDerivation class is to specify combinatorial biological designs without hav-2 ing to specify every possible design variant. For example, a CombinatorialDerivation can be used to spec-3 ify a library of reporter gene variants that include different promoters and RBSs without having to specify a 4 Component for every possible combination of promoter, RBS, and CDS in the library. Component objects that realize 5 a CombinatorialDerivation can be derived in accordance with the class properties template, 6 hasVariableFeature, and strategy (see Figure 15). The template property 8 The template property is REQUIRED and MUST contain a IRI that refers to a Component. This Component is 9 expected to serve as a template for the derivation of new Component objects. Consequently, its hasFeature 10 properties SHOULD contain one or more Feature objects that will serve as the variables whose values are set during 11 derivation (referred to hereafter as template Feature objects). Its other property values describe aspects of the 12 template that will not change based on the values that may be varied. NOT contain two or more VariableFeature objects that refer to the same template 18 sbolFeature via their variable properties (i.e., do not define the same variable twice).

19
The variable properties of VariableFeature objects determined which Feature objects in the template are 20 modified in a derived Component, and which ones will not be changed. In particular, we will refer to a Feature in 21 the template Component that is referred to by some variable property as a variable Feature, and one that is not 22 referred to by any as a static Feature.

23
The strategy property 24 The strategy property is OPTIONAL and has a data type of IRI.

14
An Implementation represents a realized instance of a Component, such a sample of DNA resulting from fabricating 15 a genetic design or an aliquot of a specified reagent. Importantly, an Implementation can be associated with a 16 laboratory sample that was already built, or that is planned to be built in the future. An Implementation can also 17 represent virtual and simulated instances. An Implementation may be linked back to its original design using the 18 prov:wasDerivedFrom property inherited from the Identified superclass. An Implementation may also link to 19 a Component that specifies its realized structure and/or function. The built property is OPTIONAL and MAY contain a IRI that MUST refer to a Component. This Component is 2 intended to describe the actual physical structure and/or functional behavior of the Implementation. When 3 the built property refers to a Component that is also linked to the Implementation via PROV-O properties such 4 as prov:wasDerivedFrom (see Section A.1), it can be inferred that the actual structure and/or function of the 5 Implementation matches its original design. When the built property refers to a different Component, it can be 6 inferred that the Implementation has deviated from the original design. For example, the latter could be used to 7 document when the DNA sequencing results for an assembled construct do not match the original target sequence. The purpose of the ExperimentalData class is to aggregate links to experimental data files. An ExperimentalData 10 is typically associated with a single sample, lab instrument, or experimental condition and can be used to describe 11 the output of the test phase of a design-build-test-learn workflow. For an example of the latter, see Figure 28.

12
As shown in Figure 18, the ExperimentalData class aggregates links to experimental data files using the OPTIONAL 13 hasAttachment property that it inherits from the TopLevel class. The meta-data provided by the Model class include the following properties: the source or location of the actual 1 content of the model, the language in which the model is implemented, and the model's framework. The source property is REQUIRED and MUST contain a IRI reference to the source file for a model.

4
The language property 5 The language property is REQUIRED and MUST contain a IRI that specifies the language in which the model is 6 implemented. It is RECOMMENDED that this IRI refer to a term from the EMBRACE Data and Methods (EDAM) 7 ontology. Table 15 provides a list of a few suggested languages from this ontology and their IRIs. If the language 8 property of a Model is well-described by one these terms, then it MUST contain the IRI for this term as its value.

23
The Collection class is a class that groups together a set of TopLevel objects that have something in common.

24
Some examples of Collection objects:

25
■ Results of a query to find all Component objects in a repository that function as promoters. Sequence, and Model objects used to provide its full specification.

29
The member property 30 A Collection object can have zero or more member properties, each of type IRI specifying a TopLevel object. The purpose of the Experiment class is to aggregate ExperimentalData objects for subsequent analysis, usually 2 in accordance with an experimental design. Namely, the member properties of an Experiment MUST refer to 3 ExperimentalData objects. The purpose of the Attachment class is to serve as a general container for data files, especially experimental data 6 files. It provides a means for linking files and metadata to SBOL designs. 7 The meta-data provided by the Attachment class include the following properties: the source or location of the 8 actual file of the attachment, the format of the file, the size of the file, and the hash for the file. The source property 10 The source property is REQUIRED and MUST contain a IRI reference to the source file.

11
The format property 12 The format property is OPTIONAL and MAY contain a IRI that specifies the format of the attached file. It is 13 RECOMMENDED that this IRI refer to a term from the EMBRACE Data and Methods (EDAM) ontology. The hashAlgorithm property is OPTIONAL and MAY contain the name of the hash algorithm used to generate 5 the value of the hash property. The value of this property SHOULD be a hash name string from the IANA Named 6 Information Hash Algorithm Registry, of which sha3-256 is currently RECOMMENDED. If the hash property is set, 7 then hashAlgorithm MUST be set as well. to capture provenance (see Section A.1). Additionally, user-defined RDF can be used in conjunction with SBOL 15 objects to capture custom application-specific information that does not yet have a standardized representation.

16
This annotation and extension mechanism is designed to enable new types of data to be easily incorporated into 17 the SBOL standard once there is community consensus on their proper representation.

18
Several methods are supported for connecting the SBOL data model with other types of application-specific data:

19
■ Custom data can be added to an SBOL object by annotating that object with non-conflicting properties. These 20 properties could contain literal data types such as Strings or IRIs that require a resolution mechanism 21 to obtain external data. An example is annotating a Component with a property that contains a String 22 description and IRI for the parts registry from which its source data was originally imported.

23
■ SBOL object classes can be extended to custom classes that add additional information. This works just like 24 adding custom data via non-conflicting properties, except that the object receives both an rdf:type for the 25 SBOL class that has been extended and also an rdf:type specifying the extension class.

26
■ Custom data in the form of independent objects can participate in the SBOL data model if they are assigned 27 one of the SBOL types Identified or TopLevel. An example is an RDF object that is annotated such that it 28 represents a data sheet that describes the performance of a Component in a particular context.

29
■ Finally, just as custom objects can be embedded in an SBOL document, external documents can embed or 30 refer to SBOL objects. Support for this last case is not explicitly provided in this specification. Rather, this case 31 depends on the external non-SBOL system managing its relationship to SBOL and data serialized in RDF, and 32 is included here for completeness.

33
Each Identified object MAY be annotated with application-specific properties, which MUST be labelled using 34 RDF predicates outside of the SBOL namespace. Additionally, application-specific types may be used in conjunction 35 with the SBOL data model. These application-specific types MUST have at least two rdf:type properties: one type 36 outside of the SBOL namespace AND an additional SBOL type of either: 37 ■ TopLevel, if the object is to be considered an SBOL top level (i.e., not owned by another object) 38 ■ Identified, if the object is not to be considered an SBOL top level (i.e., is owned by another object) 39 ■ The most specific applicable SBOL type, if the object is an instance of a custom class extending an SBOL class.

40
As with SBOL Identified objects, custom Identified objects (and thus also all other custom objects) MAY also 41 include the properties displayId, name, description, etc.   8 Maintaining unique IRIs for all SBOL objects can be challenging. To reduce this burden, users of SBOL 3.x are 9 encouraged to follow a few simple rules when constructing URLs and related properties for SBOL objects. When 10 these rules are followed in constructing an SBOL object, we say that this object is compliant. These rules are as mum 〈child_type_counter〉 for each 〈child_type〉 object in the parent (e.g., "〈parent_url〉/SequenceAnnotation37").

35
Note that numbering is independent for each type, so a Component can have children "SubComponent37" and 36 "Constraint37".

37
All examples in this specification use compliant URLs. tools. This allows version information to be included in the root (e.g., GitHub style: "igem/HEAD/"), collection 3 structure (e.g., "promoters/constitutive/2/"), in tool-specific conventions on displayId (e.g., "BBa_J23101_v2") or 4 in information outside of the IRI (e.g., by attaching prov:wasRevisionOf properties). When annotating an SBOL document with additional information, there are two general methods that can be used: 7 ■ Embed the information in the SBOL document using properties outside of the SBOL namespace. 8 ■ Store the information separately and annotate the SBOL document with IRIs that point to it.

9
In theory, either method can be used in any case. (Note that a third case not discussed here is to annotate external 10 objects with links to SBOL documents, rather than annotating SBOL documents with links to external objects.) 11 In practice, embedding large amounts of non-SBOL data into SBOL documents is likely to cause problems for people 12 and software tools trying to manage and exchange such documents. Therefore, it is RECOMMENDED that small 13 amounts of information (e.g., design notes or preferred graphical layout) be embedded in the SBOL model, while 14 large amounts of information (e.g., the contents of the scientific publication from which a model was derived or flow 15 cytometry data that characterizes performance) be linked with IRIs pointing to external resources. The boundary 16 between "small" and "large" is left deliberately vague, recognizing that it will likely depend on the particulars of a 17 given SBOL application.

19
RDF documents containing serialized SBOL objects might or might not be entirely self-contained. A SBOL document 20 is self-contained or "complete" if every SBOL object referred to in the document is contained in the document. It is 21 RECOMMENDED that serializations be complete whenever practical. In order words, when serializing an SBOL providing similar terms can also be used. A summary of these external sources can be found in Table 17.

37
The IRIs for ontological terms SHOULD be URLs from identifiers.org. However, it is acceptable to use terms from 51 purl.org as an alternative, for example when RDF tooling requires URLs to be represented as compliant QNames.

52
SBOL software may convert between these forms as required.

17
Entities in an SBOL document can be annotated with creation and modification dates. It is RECOMMENDED that 18 predicates, or properties, from DCMI Metadata Terms SHOULD be used to include date and time information.

19
The created and modified terms SHOULD respectively be used to annotate SBOL entities with creation and

24
Authorship information should ideally be added to TopLevel entities where possible. It is RECOMMENDED that 25 the creator DCMI Metadata term SHOULD be used to annotate SBOL entities with authorship information using 26 free text. This property can be repeated for each author.

38
Each reagent, whether "atomic" (e.g., rainbow bead control) or mixture (e.g., M9 media), SHOULD be represented 39 as a Component and/or as a Feature of a Component in which the reagent is used. For example, a custom media 40 mixture might be defined as a Component and used as a SubComponent, while a commercially supplied reagent 1 might be used as an ExternallyDefined feature linking to its PubChem identifiers. 2 The roles of reagents may vary in context: for example, arabinose may serve as an inducer or as a media carbon In order to deal with parameters associated with the context in general but not specific instances, e.g., temperature, 20 pH, total sample volume, the hasMeasure property of Identified can be used. The hasMeasure of a Component 21 provides context-free information (e.g., the pH of M9 media, the GC-content of a GFP coding sequence), while the 22 hasMeasure of a material entity (SBO:0000240) Feature provides a measurement in context (e.g., the dosage of 23 arabinose in a sample).

24
Values of these parameters SHOULD be specified by attaching a om:Measure with a type set to the appropriate SBO biological designs are split across multiple cells to optimize the system behavior and function. Therefore, there is a 34 need to define a set of best practices so that multicellular systems can be captured using SBOL in a standard way. To represent multicellular systems using SBOL, it is first necessary to represent cells. When doing so, it is important 2 to be able to capture the following information: (i) taxonomy of the strain used, (ii) interactions occurring within cells 3 of this type, and (iii) components inside the type of cell (e.g. genomes, plasmids). The approach RECOMMENDED 4 in this section is capable of capturing this information, as shown in the example in Figure 22. It uses a Component to 5 represent a system that contains cells of the given type. The cells themselves are represented by a Feature inside 6 the Component, in this case a SubComponent that is an instanceOf a Component capturing information about the 7 species and strain of the cell in the design. This Component has a type of "cell" from the Cell Ontology (CL:0000000), 8 and a role of "physical compartment" (SBO:0000290). Taxonomic information is captured by annotating the class 9 instance with a IRI for an entry in the NCBI Taxonomy Database.

17
The same approach can be extended to represent systems with multiple types of cells. The multicellular system 18 can be represented as a Component that includes each strain of cell as a Feature, in this example a SubComponent 19 that is an instanceOf a Component defining its strain. Interactions and constraints, such as a molecule that both 20 strains interact with, are implemented using ComponentReferences to link to the definitions within each cell system 21 description. An example is shown in Figure 23. The proportion of cell types present in a multicellular system can be captured using om:Measure on the represen-24 tations of cells in the design. As a best practice, the value of these measure classes is a percentage less than or 25 equal to 100%, representing the amount of a cell type present in the system compared to all other cell types present.

26
Therefore, the sum of all these values specified in the system will typically be equal to 100%, though this may not be 27 the case if the system is not completely defined. An example is shown in Figure 24.  The Component has a type of "Cell" from the Gene Ontology (GO), and a role of "physical compartment". Another Component is used to represent a system in which the cell is implemented. Entities, including the cell, are instantiated as Features, and processes are captured using the Interaction class. Processes that are contained within the cell are represented by including the cell as a participant with a role of "physical compartment".  Figure 23: Captured here is a design involving two cells which both interact with the small molecule "Molecule A". Designs for the sender and receiver systems are captured using constraint to show that each of these cells interacts with the Molecule A contained within it. The overall multicellular system is represented by a Component with a role of "functional compartment", which is an SBO term. The two systems are included in this multicellular design as Features, and the fact that Molecule A is shared between systems is indicated with a constraint.

17
All SBOL libraries SHOULD support at least RDF/XML, N-Triples, JSON-LD, and Turtle. Other SBOL tools SHOULD 18 support at least one of these four formats.

2
■ Every Component in an SBOL 2.x ComponentDefinition with "access"="public" is listed as "nondirectional" 3 in the Interface of its SBOL 3.x Component. p If the refinement is useRemote, then the restriction is replaces, the subject is the 17 ComponentReference and the object is the SubComponent.

18
p If the refinement is useLocal, then the restriction is replaces, the subject is the SubComponent 19 and the object is the ComponentReference.

20
p If the refinement is verifyIdentical, then the restriction is verifyIdentical, the subject is 21 the ComponentReference and the object is the SubComponent.

22
p The merge refinement was never well defined and rarely if ever used, so it has been removed from 23 SBOL 3.x. If a merge is encountered, it SHOULD be handled as a useRemote.

24
• As an OPTIONAL optimization, if the SubComponent referred to by the local property of the MapsTo is a 25 "placeholder" with no significant content apart from its MapsTo relationships, then it may be eliminated, 26 all objects that pointed to it can point directly to the new ComponentReference instead, and all transitive 27 constraints using it as a bridge reduced to link the endpoints directly.   Here we discuss two complementary standards that have been adapted for use as part of SBOL representation, 2 following the pattern for extension of SBOL described in Section Section 6.11. In both cases, the extension uses the 3 pattern in which object from another ontology are also assigned to either the SBOL Identified or TopLevel types.

4
Note that this means that the object receives both an rdf:type for the SBOL class and also an rdf:type in their 5 own namespace. in SBOL documents, a subset of PROV-O is adopted as a best practice. It is advised that SBOL tools should at least 24 understand this subset, defined in Figure 27. Providers of provenance information are free to make use of more 25 of PROV-O than is described here. It is acceptable for tools that understand more than this subset to use as much 26 as they are able. Tools that only understand this subset must treat any additional data as annotations. Tools that 27 are not aware of SBOL provenance at all MUST maintain and provide access to this information as annotations.

28
This specification does not state what the newly added properties must point to. As long as they are resources that 29 are consistent with the PROV-O property domains, they are legal. For example, a Component may be derived from 30 another Component, but it would probably not make sense for it to be derived from a Collection.

31
The most basic and general type of provenance relationship can be represented using the prov:wasDerivedFrom 32 property. This relationship describes derivation of an SBOL entity from another. Any Identified object may be 33 annotated with this property. More specific provenance relationships can also be defined using PROV-O, such as 34 prov:wasGeneratedBy. Generation of a new object is defined by the W3C PROV-O specification as follows:

35
...the completion of production of a new entity by an activity. This entity did not exist before generation 36 and becomes available for usage after this generation.

37
These relationships are leveraged in SBOL tooling for describing multi-stage synthetic biology workflows.

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

4
A design-build-test-learn SBOL ontology has been adopted for use with PROV-O classes (see Table 20). The terms 5 design, build, test, and learn provide a high level workflow abstraction that allows tool-builders to quickly search for 6 and isolate provenance histories relevant to their domain, while keeping track of the flow of data between different 7 users working in different domains of synthetic biology. These terms SHOULD BE used on the type property of the 8 prov:Activity class. (Note that this property is a special property added by the SBOL specification, and is not part 9 of the original PROV-O specification.) Additionally, these terms SHOULD BE used in the prov:hadRole properties 10 on prov:Usage to qualify how the referenced prov:entity is used by the parent prov:Activity. Build describes the process by which a biological construct, sample, or clone is implemented in the laboratory.

15
Test http://sbols.org/v3#test Test describes the process of performing experimental measurements to characterize a synthetic biological construct. 16 Learn http://sbols.org/v3#learn Learn describes the process of analyzing experimental measurements to produce a new entity that represents biological knowledge. build-test-learn workflows. These rules additionally place constraints on the types of objects that may be used as 18 inputs for a particular type of prov:Activity. For example, a design prov:Usage may be used as an input for either 19 a design or build prov:Activity but SHOULD NOT be used as an input for a test prov:Activity. An example of 20 how these terms are used is provided in Figure 28. The ordering of stages and constraints on referred object type are 21 given in Table 21.  In addition to the design-build-test-learn terms, users may also wish to include more specific terms to specify how 23 SBOL objects are used in-house in their own recipes, protocols, or computational analyses. In fact, it is expected that 24 the SBOL workflow ontology will be expanded over time, as users experiment with and develop their own custom 25 ontologies. For now, however, it is RECOMMENDED that SBOL tools also include the high-level terms in Table 20 to 26 support data exchange across interdisciplinary boundaries. A generated prov:Entity is linked through a prov:wasGeneratedBy relationship to an prov:Activity, which is 2 used to describe how different prov:Agents and other entities were used. An prov:Activity is linked through a 3 prov:qualifiedAssociation to prov:Associations, to describe the role of agents, and is linked through 4 prov:qualifiedUsage to prov:Usages to describe the role of other entities used as part of the activity. Moreover, 5 each prov:Activity includes optional prov:startedAtTime and prov:endedAtTime properties. When using 6 prov:Activity to capture how an entity was derived, it is expected that any additional information needed will be 7 attached as annotations. This may include software settings or textual notes. Activities can also be linked together 8 using the prov:wasInformedBy relationship to provide dependency without explicitly specifying start and end 9 times.

10
The type property 11 An prov:Activity MAY have one or more type properties, each of type IRI that explicitly specifies the type of the 12 provenance prov:Activity in more detail. If specified, it is RECOMMENDED that at least one type property refers 13 to a URL from Table 20.  Table 20 can be used to indicate how the referenced prov:Entity is being used in this prov:Activity. The prov:agent property is REQUIRED and MUST contain a IRI that refers to an prov:Agent object.

29
The prov:hadRole property 30 An prov:Association MAY have one or more prov:hadRole properties, each of type IRI that refers to particular 31 term(s) that describes the role of the prov:Agent in the parent prov:Activity.

33
The prov:hadPlan property is OPTIONAL and contains a IRI that refers to a prov:Plan. The prov:Plan entity can be used as a place holder to describe the steps (for example scripts or lab protocols) taken 2 when an prov:Agent is used in a particular prov:Activity. Examples of agents are a person, organization, or software tool. These agents should be annotated with additional 5 information, such as software version, needed to be able to run the same prov:Activity again.

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

12
Example -Deriving strains 13 Bacterial strains are often derived from other strains through modifications such as gene knockouts or mutations.
14 For example, the Bacillus subtilis 168 strain was derived from the NCIMB3610 strain in the 1940s through x-radiation.

15
B. subtilis 168 is a laboratory strain and has several advantages as a model organism in synthetic biology. The 16 relationship between the original strain and the 168 strain can be represented using the prov:wasDerivedFrom 17 predicate or, more comprehensively, with an prov:Activity describing the protocols used. 18

Example -Design-build-test-learn Workflow
19 Figure 28 illustrates one complete iteration through a design-build-test-learn cycle. The workflow begins with a 20 Model which describes the hypothesized behavior of a biological device. Using a computational tool, a new Design 21 (Component) is composed from biological parts, which links back to its Model. A genetic construct is then produced 22 in the laboratory via an assembly protocol, and this biological sample is represented by a Build (Implementation).

23
Once constructed, the Build is then characterized in the laboratory using an automated measurement protocol 24 on a Tecan plate reader, thus generating Test data (represented by an ExperimentalData). Finally, a new Model is 25 derived from these data using a fitting algorithm implemented in the Python programming language. The final 26 Model may not match the beginning Model, as the observed behavior may not match the prediction.  Figure 28: An example data structure representing an idealized workflow for model-based design.

1
As specified in the description of CombinatorialDerivation, provenance can be used to link each generated 2 Component (or Collection thereof) back to the source form which it was derived. In particular, each derived 3 design links with prov:wasDerivedFrom to the CombinatorialDerivation that it was derived from. Also, each 4 SubComponent has a prov:wasDerivedFrom linking it to the SubComponent within the template that it is derived 5 from. The advantage of these provenance links is that they provide sufficient information to validate that this 6 derived design has been properly derived from the specified CombinatorialDerivations. already defines a data model for representing measures and their associated units. Here, a subset of OM is adopted 17 by SBOL to describe these concepts for biological design specifications, by assigning PROV-O classes to SBOL 18 Identified or TopLevel types per Section Section 6.11. As shown in Figure 29, SBOL leverages three of the base 19 classes defined by the OM: om:Measure, om:Unit and om:Prefix. A om:Measure links a numerical value to a 20 om:Unit, which may or may not have a om:Prefix (e.g. centi, milli, micro, etc.). As these classes are adopted by 21 SBOL, om:Measure is treated as a subclass of Identified, while om:Unit and om:Prefix are treated as subclasses of

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

30
SBOL-compliant tools are allowed to read, write, and modify data belonging to OM classes other than those 31 described here, but this specification does not provide any guidance for the interpretation or use of these data in 32 the context of SBOL. The purpose of the om:Measure class is to link a numerical value to a om:Unit.

35
The om:hasNumericalValue property 36 The om:hasNumericalValue property is REQUIRED and MUST contain a single xsd:float.

37
The om:hasUnit property 38 The om:hasUnit property is REQUIRED and MUST contain a IRI that refers to a om:Unit. The OM provides IRIs 39 for many existing instances of the om:Unit class for reference (for example, 40 http://www.ontology-of-units-of-measure.org/resource/om-2/gramPerLitre).  As adopted by SBOL, om:Unit is an abstract class that is extended by other classes to describe units of measure 8 using a shared set of properties.

9
The om:symbol property

10
The om:symbol property is REQUIRED and MUST contain a String. This String is commonly used to abbreviate 11 the unit of measure's name. For example, the unit of measure named "gram per liter" is commonly abbreviated 12 using the String "g/l".

13
The om:alternativeSymbols property 14 The om:alternativeSymbols property is OPTIONAL and MAY contain a set of Strings. This property can be used 15 to specify alternative abbreviations other than that specified using the om:symbol property.

16
The om:label property

17
The om:label property is REQUIRED and MUST contain a String. This String is a common name for the unit of 18 measure and SHOULD be identical to any String contained by the name property inherited from Identified.

1
The om:alternativeLabels property is OPTIONAL and MAY contain a set of Strings. This property can be used 2 to specify alternative common names other than that specified using the om:label property.

3
The om:comment property 4 The om:comment property is OPTIONAL and MAY contain a String. This String is a description of the unit 5 of measure and SHOULD be identical to any String contained by the description property inherited from 6 Identified.

7
The om:longcomment property 8 The om:longcomment property is OPTIONAL and MAY contain a String. This String is a long description of the 9 unit of measure and SHOULD be longer than any String contained by the om:comment property.

11
The purpose of the om:SingularUnit class is to describe a unit of measure that is not explicitly represented as a 12 combination of multiple units, but could be equivalent to such a representation. For example, a joule is considered 13 to be a om:SingularUnit, but it is equivalent to the multiplication of a newton and a meter.
14 The om:hasUnit property 15 The om:hasUnit is OPTIONAL and MAY contain a IRI. This IRI MUST refer to another om:Unit. The om:hasUnit 16 propery can be used in conjunction with the om:hasFactor property to specify whether a om:SingularUnit is 17 equivalent to another om:Unit multiplied by a factor. For example, an angstrom is equivalent to 10 −10 meters.

19
The om:hasFactor property is OPTIONAL and MAY contain a xsd:float. If the om:hasFactor property of a 20 om:SingularUnit is non-empty, then its om:hasUnit property SHOULD also be non-empty. The purpose of the om:UnitMultiplication class is to describe a unit of measure that is the multiplication of two 26 other units of measure.

28
The om:hasTerm1 property is REQUIRED and MUST contain a IRI that refers to another om:Unit. This om:Unit is 29 the first multiplication term.

31
The om:hasTerm2 property is REQUIRED and MUST contain a IRI that refers to another om:Unit. This om:Unit is 32 the second multiplication term. It is okay if the om:Unit referred to by om:hasTerm1 is the same as that referred to 33 by om:hasTerm2. The purpose of the om:UnitDivision class is to describe a unit of measure that is the division of one unit of measure 2 by another.

3
The om:hasNumerator property 4 The om:hasNumerator property is REQUIRED and MUST contain a IRI that refers to another om:Unit.

5
The om:hasDenominator property 6 The om:hasDenominator property is REQUIRED and MUST contain a IRI that refers to another om:Unit. The purpose of the om:UnitExponentiation class is to describe a unit of measure that is raised to an integer power.

10
The om:hasBase property is REQUIRED and MUST contain a IRI that refers to another om:Unit.

12
The om:hasExponent property is REQUIRED and MUST contain an xsd:integer.

14
The purpose of the om:PrefixedUnit class is to describe a unit of measure that is the multiplication of another unit 15 of measure and a factor represented by a standard prefix such as "milli," "centi," "kilo," etc.

17
The om:hasUnit property is REQUIRED and MUST contain a IRI that refers to another om:Unit.

19
The om:hasPrefix property is REQUIRED and MUST contain a IRI that refers to a om:Prefix. The om:symbol property is REQUIRED and MUST contain a String. This String is commonly used to abbreviate 26 the name of the unit prefix. For example, the String "m" is commonly used to abbreviate the name "milli."

28
The om:alternativeSymbols property is OPTIONAL and MAY contain a set of Strings. This property can be used 29 to specify alternative abbreviations other than that specified using the om:symbol property.

30
The om:label property

31
The om:label property is REQUIRED and MUST contain a String. This String is a common name for the unit 32 prefix and SHOULD be identical to any String contained by the name property inherited from Identified.

1
The om:alternativeLabels property is OPTIONAL and MAY contain a set of Strings. This property can be used 2 to specify alternative common names other than that specified using the om:label property.

3
The om:comment property 4 The om:comment property is OPTIONAL and MAY contain a String. This String is a description of the unit prefix 5 and SHOULD be identical to any String contained by the description property inherited from Identified.

6
The om:longcomment property 7 The om:longcomment property is OPTIONAL and MAY contain a String. This String is a long description of the 8 unit of measure and SHOULD be longer than any String contained by the om:comment property.

9
The om:hasFactor property 10 The om:hasFactor property is REQUIRED and MUST contain an xsd:float.

12
The purpose of the om:SIPrefix class is to describe standard SI prefixes such as "milli," "centi," "kilo," etc.

15
These prefixes commonly precede units of information such as "bit" and "byte."  validation rules-data encoded in SBOL MUST conform to all of them in order to be considered valid. Rules of 4 the latter kind are consistency rules that SBOL data are RECOMMENDED to adhere to as a best practice. To help 5 highlight these differences, we use the following symbols next to the rule numbers: 6 A checked box indicates a strong REQUIRED condition for SBOL conformance. If a SBOL document does not 7 follow this rule, it does not conform to the SBOL specification. 8 A circle indicates a weak REQUIRED condition for SBOL conformance. While this rule MUST be followed, 9 there are conditions under which it can only be partially checked by a machine (e.g., due to references to data 10 that is not accessible or data with an ambiguous format). Rules of this type SHOULD be checked insofar as is 11 possible given the information available in a SBOL document.

12
A star indicates a RECOMMENDED condition for following best practices. This rule is not strictly a matter of 13 SBOL conformance, but its recommendation comes from logical reasoning. If an SBOL document does not 14 follow this rule, it is still valid SBOL, but it might have degraded functionality in some tools. 15 We also include a fourth type of rule that represents a required condition for SBOL-compliance that cannot be 16 checked by a machine. Therefore, violations of these rules are not expected to be reported as errors by any of the 17 software libraries implementing SBOL 3.0. It is the user's responsibility to make sure that these validation rules are 18 followed.

19
L A triangle indicates a weak REQUIRED condition for SBOL conformance. While this rule MUST be followed, it 20 is not possible in practice for a machine to automatically check whether the rule has been followed.

21
The validation rules listed in the following subsections are all believed to be stated or implied in the rest of this 22 specification document. They are enumerated here for convenience and to provide a "master checklist" for SBOL 23 validation. In case of a conflict between this section and other portions of the specification (though there are 24 believed to be none), this section is considered authoritative for the purpose of determining the validity of an SBOL 25 document.

26
Not all classes have validation rules specific to that class. For classes whose validation is covered by the rules for all 27 SBOL objects, the type is not explicitly listed below. A range in the validation rules numbers, however, has been 28 reserved in case of future need.

sbol3-10101
The IRI of an Identified object MUST be globally unique.

sbol3-10105
The SBOL namespace MUST NOT be used for any entities or properties not defined in this 1 specification.

11
Reference: Section 5.4 on page 13 12 sbol3-10109 An object MUST NOT have properties in the "http://sbols.org/v3#" namespace other than 13 those listed for its type or parent types in Table 22. 14 Reference: Section 5.2 on page 12 15 sbol3-10110 An object MUST have a number of instances of a property that matches the cardinality restric-16 tions listed for that object type and property in Table 23.

sbol3-10112
Each property of type IRI that is listed with a reference type in Table 23 MUST refer to an 22 object of the type listed (child objects).

23
Reference: Section 5.3 on page 12 24 sbol3-10113 Each property of type IRI that is listed with a reference type in Table 23 MUST refer to an 25 object of the type listed. Each property of type IRI that is listed with a TopLevel reference type in Table 23 SHOULD 28 be able to be dereferenced to obtain an SBOL object.

sbol3-10202
An Identified object MUST NOT refer to itself via its own prov:wasDerivedFrom property.

Section
Reference: Section 6.1 on page 15 1 sbol3-10203 An Identified object MUST NOT form a cyclical chain of references via its prov:wasDerivedFrom 2 property and those of other Identified objects.
3 Reference: Section 6.1 on page 15 4 sbol3-10204 Provenance history formed by prov:wasGeneratedBy properties of Identified objects and 5 prov:entity references in prov:Usage objects MUST NOT form circular reference chains.

sbol3-10205
An Identified object with a prov:wasGeneratedBy property referring to an prov:Activity 8 with a child prov:Association that has a prov:hadRole property with a value from Table 20   9 should be of the corresponding type in Table 21.

sbol3-10501
If the elements property is set, then the encoding property of Sequence MUST be provided. The elements property of a Sequence MUST be consistent with its encoding property.

sbol3-10702
If a Feature has an orientation property, its URL MUST be drawn from Table 5 or Table 6. If a SubComponent has an roleIntegration property, its URL MUST be drawn from Table 7. The roleIntegration property of a SubComponent is REQUIRED if the SubComponent has 10 one or more role properties.

sbol3-11108
A ExternallyDefined SHOULD NOT have a type property that refers to a term from the 29 topology attribute or strand attribute branches of the SO unless it also has a type property 30 with the DNA or RNA type URL listed in Table 2. Reference: Section 6.4.1.4 on page 25 31 sbol3-11109 L The URL contained by the definition property of a ExternallyDefined SHOULD refer to an 32 external resource in Section Section 7.6 when the object is defined in one of these resources. If a Location has an orientation property, its URL MUST be drawn from Table 5 or Table 6.

sbol3-11302
For every Location that is not an EntireSequence and that is the value of a hasLocation 1 property of a Feature, the value of its hasSequence property MUST also either be a value of 2 the hasSequence property of the parent Component or else be the value of some hasSequence 3 property of an EntireSequence that is also a child of the same Component.

sbol3-11303
For every Location that is not an EntireSequence and that is the value of a sourceLocation 6 property of a SubComponent, the value of its hasSequence property MUST also either be 7 a value of the hasSequence property of the Component linked by its parent's instanceOf 8 property or else be the value of some hasSequence property of an EntireSequence that is 9 also a child of the same Component linked by instanceOf. The value of the start property of a Range MUST be greater than zero and less than or equal 13 to the length of the elements value of the Sequence referred to by its hasSequence property.

sbol3-11402
The value of the end property of a Range MUST be greater than zero and less than or equal to 16 the length of the elements value of theSequence referred to by its hasSequence property.

sbol3-11403
The value of the end property of a Range MUST be greater than or equal to the value of its 19 start property. The value of the at property of a Cut MUST be greater than or equal to zero and less than 23 or equal to the length of the elements value of the Sequence referred to by its hasSequence 24 property.

sbol3-11704
The value of the restriction property of a Constraint SHOULD be drawn from Table 8, 37

sbol3-11705
If the restriction property of a Constraint is drawn from Table 8, then the Feature objects 40 referred to by the subject and object properties MUST comply with the relation specified in 41   Table 8.

sbol3-11706
If the restriction property of a Constraint is drawn from Table 10 and if the Feature 1 objects referred to by the subject and object properties both have hasLocation properties 2 with Location objects whose hasSequence property refers to the same Sequence, then the 3 positions of the referred Location objects MUST comply with the relation specified in Table 10.

4
Rules for the Interaction class 5 sbol3-11801 L Each type property of an Interaction MUST refer to an ontology term that describes the 6 behavior represented by the Interaction. Reference: Section 6.4.4 on page 28 8 sbol3-11802 L All type properties of an Interaction MUST refer to non-conflicting ontology terms.

9
Reference: Section 6.4.4 on page 28 10 sbol3-11803 Exactly one type property of an Interaction SHOULD refer to a term from the occurring 11 entity relationship branch of the SBO.

sbol3-11804
If the hasParticipation properties of an Interaction refer to one or more Participation 14 objects, and one of the type properties of this Interaction comes from

sbol3-11902
The Feature referenced by the participant property of a Participation MUST be con-23 tained by the Component that contains the Interaction that contains the Participation. Exactly one role in the set of role properties SHOULD be a URL from the participant role 35 branch of the SBO (see Table 12).

sbol3-12002
The Feature referenced by the output property of an Interface MUST be contained by the 1 Component that contains the Interface.

sbol3-12003
The Feature referenced by the nondirectional property of an Interface MUST be con-4 tained by the Component that contains the Interface.

5
Reference: Section 6.4.5 on page 32 6 Rules for the CombinatorialDerivation class 7

sbol3-12101
The strategy property of a CombinatorialDerivation, if specified, MUST contain a URL 8 from properties.

21
Reference: Section 6.5 on page 33 If the prov:wasDerivedFrom property of a Collection refers to a CombinatorialDerivation, 27 then the prov:wasDerivedFrom properties of the objects that are referred to by its member 28 properties SHOULD also refer to the CombinatorialDerivation.

29
Reference: Section 6.5 on page 33

sbol3-12110
If the prov:wasDerivedFrom property of a Component refers to a CombinatorialDerivation, 1 then each static Feature in the template Component SHOULD be referred to by a 2 prov:wasDerivedFrom property from exactly one Feature in the derived Component.

3
Reference: Section 6.5 on page 33 4 sbol3-12111 If the prov:wasDerivedFrom property of a Component refers to a CombinatorialDerivation, 5 then each variable Feature in the template Component SHOULD be referred to by a 6 prov:wasDerivedFrom property from a number of Feature objects in the derived Component 7 that is compatible with the cardinality property of the corresponding VariableFeature.

sbol3-12203
The member properties of a Collection that is referred to by the variantCollection property 1 of a VariableFeature MUST refer only to Component objects or to Collection objects that 2 themselves contain only Component or Collection objects, recursively.

3
Reference: Section 6.5.1 on page 34 4 sbol3-12204 VariableFeature objects MUST NOT form circular reference chains via their variantDerivation 5 properties and parent CombinatorialDerivation objects.

6
Reference: Section 6.5.1 on page 34 7 Rules for the Implementation class 8 sbol3-12301 L Each prov:wasDerivedFrom property of an Implementation MUST refer to a Component 9 that contains a description of the intended nature of the actual object indicated by the 10 Implementation.

11
Reference: Section 6.6 on page 36 12 sbol3-12302 L All prov:wasDerivedFrom properties of an Implementation MUST refer to non-conflicting 13 Component descriptions.
14 Reference: Section 6.6 on page 36 15 sbol3-12303 L If the built property of an Implementation is set, then the Component it refers to MUST be a 16 faithful description of the actual object indicated by the Implementation.  Table 15 if it is well-described by 26 this URL.

27
Reference: Section 6.8 on page 37 28 sbol3-12504 The language property of a Model SHOULD contain a URL that refers to a term from the EDAM 29 ontology.

30
Reference: Section 6.8 on page 37 31 sbol3-12505 L The IRI contained by the framework property of a Model MUST specify the modeling frame-32 work of the model.

33
Reference: Section 6.8 on page 37 34 sbol3-12506 L The framework property of a Model MUST contain a URL from Table 16 if it is well-described 35 by this URL.

36
Reference: Section 6.8 on page 37 37 sbol3-12507 The framework property SHOULD contain a URL that refers to a term from the modeling 38 framework branch of the SBO.

39
Reference: Section 6.8 on page 37 40 Section Rules for the Attachment class 1 sbol3-12801 L The source property of an Attachment MUST specify the location of the model's source file.
2 Reference: Section 6.10 on page 39 3 sbol3-12802 L The IRI contained by the format property of an Attachment MUST specify the file type of the 4 attachment.

5
Reference: Section 6.10 on page 39 6 sbol3-12803 The format property of an Attachment SHOULD contain a URL that refers to a term from the 7 EDAM ontology. If the hash property is set, then the hashAlgorithm MUST be set as well.

22
Reference: Section 6.10 on page 39 23 Rules for the prov:Activity class 24 sbol3-12901 An prov:Activity with a type from

sbol3-12902
If an prov:Activity has a type property with a value from