Synthetic Biology Open Language (SBOL) Version 2.0.0

Summary Synthetic biology builds upon the techniques and successes of genetics, molecular biology, and metabolic engineering by applying engineering principles to the design of biological systems. The field still faces substantial challenges, including long development times, high rates of failure, and poor reproducibility. One method to ameliorate these problems would be to improve the exchange of information about designed systems between laboratories. 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, filling a need not satisfied by other pre-existing standards. This document details version 2.0 of SBOL, introducing a standardized format for the electronic exchange of information on the structural and functional aspects of biological designs. The standard has been designed to support the explicit and unambiguous description of biological designs by means of a well defined data model. The standard also includes rules and best practices on how to use this data model and populate it with relevant design details. The publication of this specification is intended to make these capabilities more widely accessible to potential developers and users in the synthetic biology community and beyond.


Motivation
Synthetic biology is an engineering discipline where biological components, usually in the form of segments of DNA, are assembled to form devices and systems with more complex functions. A number of software tools have been developed to help synthetic biologists to design, optimize, validate and share these DNA systems, but the lack of a defined information standard for synthetic biology makes it extremely difficult to combine the appropriate applications into a refined systems process. To move the synthetic biology field towards best practices in engineering, synthetic biologists need software that can unambiguously interpret and exchange information about DNA components.

Computer Exchange Format
The lack of a standard exchange format means that synthetic biology information access and transfer is limited to manual efforts such as copy-and-paste and ad hoc scripts. Not only are these prohibitively lengthy approaches to data transfer, they can also be error-prone, either due to changes in the underlying architectures of the data sources or simple human error. Establishing a standard exchange format would not only save time, but would also help reduce the errors of manual transfer.
A standard exchange format would also provide a greater range of tools available to synthetic biologists. Although there is a wide variety of software tools out there, the difficulty inherent to designing interfaces between them sometimes makes it more effective for software developers to write their own applications rather than take advantage of something already out there; a standard exchange format would alleviate their need to develop interfaces or duplicate software, which in turn would free them up to develop new tools. Furthermore, if a standard format enabled programmatic access to public information resources (Galdzicki 2011), such as the Registry of Standard Biological Parts (http://partsregistry.org) and the BIOFAB Electronic Datasheets (http://biofab.org/data), software developers would be able to take advantage of these repositories directly within their applications. For example, CAD and modeling tools, such as TinkerCell (http://tinkercell.com/) and iBioSim (http://www.async.ece.utah.edu/iBioSim/), would be able to retrieve components for new designs. A gene network design created by tools such as the Proto Biocompiler (Beal 2011) could be further refined by Eugene into collections of physical implementations (Bilitchenko 2011).
In addition to improving the ability to share data across applications, a standard format would make it easier for synthetic biologists to exchange data with their collaborators at other sites. For example, synthetic biologist researchers could use software such as GD-ICE (http://code.google.com/p/gd-ice) and Clotho (http://clothocad.org) to integrate their own data from local laboratory repositories with their collaborators' designs and publicly available data. A synthetic biologist who designed new DNA constructs with a software tool such as GenoCAD (http://www.genocad.org) could send them to a collaborator who would then review and edit them using Gene Designer (https://www.dna20.com/tools/genedesigner.php).
The definition of a standard for electronic information exchange would also help the refinement of standards for the DNA components themselves, through an iterative process of feedback to synthetic biology research groups concerned with standardization.
In summary, a standard exchange format would encourage reuse of existing DNA components; it would reduce error caused by manual or ad hoc data exchange; it would aid in collaboration between researchers; and it would save time which could then be used for advancing research and the development of new software tools.
Electronic exchange of synthetic biology information in a common format and using a common vocabulary will encourage the creation of interoperable software to support the information needs of synthetic biologists. Software developers will be able to write fewer data converters and offer access to a larger number of data sources. Finally, compatibility with Semantic Web information technology will serve as leverage for the software developed by this broad community, as it will facilitate reuse of previously generated knowledge across independent research efforts.
To establish such an information standard, we have proposed the Synthetic Biology Open Language (SBOL) as a launching point for a community development effort. As software tools are adapt to progress in the synthetic biology field, we expect SBOL to evolve to meet the needs of synthetic biology researchers and engineers.

Introduction to SBOL
The first version of the Synthetic Biology Open Language (SBOL) is defined to meet the information exchange needs of synthetic biologists. SBOL is composed of: • The core data model, to structure the information used to describe DNA designs, • and the vocabulary, which defines the terminology used in the data model.
To encourage expansion of this standard's capabilities, the guiding principle is openness. Therefore SBOL allows and expects extensions to version 1.0.0, proposed by the community. This collaboration in defining the common information exchange framework is driven by the community of researchers participating in the Synthetic Biology Data Exchange Group (http://sbolstandard.org/).
The goal of this specification is to define the terminology and relationships used to describe DNA designs. In order to provide a shared understanding between engineers seeking to exchange DNA designs, SBOL provides a common definition of the concepts needed. As much as possible, we attempt to make explicit the meaning of all terminology and data structures.

Scope
Version 1.0.0 of the SBOL core data model is limited to the description of discrete segments of DNA, called DNA components. To remove ambiguity when specifying the design of synthetic DNA, the information about DNA components is structured. DNA components described using the SBOL core data model may have an associated DNA sequence, or may be left as abstract descriptions. This flexibility allows for the description of DNA component designs which have not yet been realized, as well as those which are specific implementations of that design.
This version does not, however, provide a mechanism to represent the biological complexity of complete cellular systems beyond the DNA level. Additional biological knowledge needed to engineer aspects of complete biological systems will be modeled by future SBOL extensions. Furthermore, extensions of SBOL may add the ability to describe DNA components before and after a process, such as assembly, evolution, or implementation of a design in silico. Existing tools, such as GenoCAD, Eugene, and TASBE already offer solutions for bridging the "before and after", so they can provide a basis for future specifications.

Abstraction Level
Within SBOL, we consider DNA regions as elements of design for DNA circuits (Savageau 2001), analogous to electrical circuits (Kaern 2003). This conceptualization of DNA segments as an element of design is a level of abstraction used to form the basis of engineering synthetic biological systems (Endy 2005). This level of abstraction ( Figure 1) has been shown to be useful in the practice of forward engineering of biological systems (Nandagopal 2011). Therefore, we define these elements as DNA Components (Figure 1) in the SBOL vocabulary, and represent them as computational objects in the SBOL core data model. DNA Components form the basic objects used in design, assembly, testing, and analysis. For example, DNA components can be hypothesized to have a biological function, deemed necessary for DNA assembly processes, or serve the synthetic biologist as landmarks in analysis.

Examples of Simple DNA Components
An example of the design of an expression cassette is shown in Figure 2; it illustrates DNA components along a DNA sequence. The symbols used represent their role in gene expression.

Figure 2.
Example visualization of a series of DNA components, including a promoter, a 5'UTR, a CDS, and a Terminator. Together, these DNA components constitute the design of the expression cassette which expresses GFP. The iconography used represents the types of these DNA components (see SBOL:Visual for more on this extension http://www.sbolstandard.org/initiatives/sbol-visual). Individual icons are labeled with an informal name for the specified DNA component.
An example DNA construct which fulfills the design specified in Figure 2 is the BioBrick™ Part BBa_J04430 (http://partsregistry.org) ( Figure 3). This example illustrates the representation of a DNA construct as a DNA component with annotations.  To describe BBa_B0015 in more detail a set of fields for a human readable ID, name, and text description is defined. Structured information fields will enable basic retrieval capabilities ie. type using the Sequence Ontology (Eilbeck 2005, Mungall 2010; and uri as a unique identifier.

Description of SBOL
SBOL version 1.0, focuses on the representation of DNA components as the SBOL:Core:model. SBOL:Vocabulary defines the key terms used in the core model.

SBOL Vocabulary
In version 1.0.0, SBOL:Vocabulary defines the core concepts used by SBOL in the structured description of synthetic DNA designs. SBOL:Core terms are DnaComponent, DnaSequence, and SequenceAnnotation. To provide user-defined groupings of DnaComponents, SBOL:Core also defines a Collection. Additional term definitions such as those needed to classify DnaComponents by type can be obtained from the Sequence Ontology (Eilbeck 2005, Mungall 2010). For example, a promoter region, coding sequence, and transcriptional terminator are all defined by the Sequence Ontology. Currently, terminology outside of the scope of the Sequence Ontology is being considered either for submission as new term requests to its curators, or for possible implementation as SBOL:Vocabulary extensions; examples of terminology under consideration include SBOL:Gene Expression and SBOL:DNA Construction (see the Appendix for a list of these provisional terms and their definitions).

SBOL Core Data Model
To enable electronic exchange of information, SBOL:Core:model defines the data model describing the DNA sequence and groupings of components used for biological engineering. The model specifies the object and data properties associated with instances of the concepts defined by SBOL:Core terms. SBOL:Core:model represents a consensus of the minimal information needed to describe DNA sequences used in synthetic biological designs.

Conventions
The project to define SBOL is comprised of constitutive parts. The convention for naming them takes the form SBOL:Specification Part Name[:sub specification]; for example, SBOL:Core:model is used to denote the core data model part of the SBOL as it uses the portion of SBOL:Vocabulary called SBOL:Core and specifies the data model to structure it. SBOL:Vocabulary terms are italicized in the remainder of this document to distinguish them. SBOL:Core:model Class names are written in upper CamelCase, starting with an upper case letter. For example, DnaComponent is the class or type of object that represents a 'DNA Component'. Field or property names defined within classes start with lower cases letters and follow lower camelCase. For example, bioStart is a field that specifies the position of the first base pair of a SequenceAnnotation.
Instances of SBOL:Core:model classes are written as abbreviations.

SBOL versions and releases
SBOL follows a version strategy inspired by Semantic Versioning (http://semver.org) and simplified for SBOL as a specification of a standard in contrast to a public API.
SBOL version numbers MUST take the form X.Y.Z where X, Y, and Z are integers. X is the major version, Y is the minor version, and Z is a patch version. Each element MUST increase numerically. For instance: 1.9.0 < 1.10.0 < 1.11.0. Prior to version 1.0.0 (specified by this document) a less formal version system was in place. After the ratification of this document as SBOL version 1.0.0, the following strategy MUST be followed.
• Major versions (X) correspond to releases of SBOL, the submission of the specification document to the BioBrick Foundation as a Request For Comment (BBF RFC). • Minor versions (Y) correspond to revisions to the specification as approved by the SBOL Forum, as defined by the SBOL governance document (http://www.sbolstandard.org/sbol-governance), and confirmed by the voting process. • Patch versions (Z) correspond to draft revisions made by the SBOL Editors during the specification process.
The SBOL definitions that follow this section conform to these conventions.

SBOL vocabulary
The SBOL:Vocabulary defines terms used in SBOL. Below we define terms for the Core.
Additional terms, such as those related to gene expression and DNA construction, are being considered as extensions in collaboration with the Sequence Ontology project.

Core
The SBOL:Core terms are defined to be used as concepts common to descriptions of DNA sequences in synthetic biology.

DNA Component
A DNA component represents a segment of DNA that serves to abstract the DNA sequence as an individual object, which can then be manipulated, combined, and reused in engineering new biological systems.

Definition of the SBOL Core Data Model
This section defines the structure of SBOL:Core:model. In Figure 5, the UML class diagram notation is used to describe the SBOL:Core:model classes, their properties, and the main associations between classes. Section 9 provides complete examples encoded in SBOL. There are four classes in the data model, DnaComponent, DnaSequence, SequenceAnnotation, and Collection, which correspond to the four concepts needed to unambiguously describe the DNA design of synthetic biological systems. Each instance of a DnaComponent class refers to an actual or planned DNA component. When using SBOL to describe information about DNA components, an instance of the DnaComponent class MUST be created. The DnaComponent instance MAY specify an associated DnaSequence instance that it pertains to, and MAY be described using SequenceAnnotation instances to specify the position of subcomponents (DnaComponent). Collection instances MAY have associated DnaComponent instances. These concepts are illustrated in Figure 5. Classes (rectangles) are named at the top and connected by associations (arrows). Each association is labelled with its role name, and has a range type and a plurality, such as "exactly zero or one dnaSequence" [0.
.1] or "one and only one subComponent" [1]. These can be interpreted as Sets of objects which are instances of the Class specified. An arrowhead indicates that the association can be traversed in that direction. Diamonds classify the association; open-faced diamonds are shared aggregation, meaning the object at the end of the arrow can exist independently of the source object, and filled diamonds indicate composite aggregation, or a part-whole relationship, which means that a part instance must be included in at most one whole and cannot exist independently. Data properties for objects of each class are listed in a separate compartment below, with the cardinality and corresponding data types specified.

SBOL Core Model Classes
We define each class individually and specify requirements for their intended use in the SBOL:Core data model.

DnaComponent:
Objects representing a DNA component MUST be instances of the class sbol:DnaComponent, defined as:

Context:
Instances of the DnaComponent class represent segments of DNA as defined by sbol:DnaComponent. The DnaComponent's DNA sequence can be annotated using SequenceAnnotation instances, positionally defined descriptors of the sequence which specify additional DnaComponent instances as subComponents. A DnaComponent MAY specify one DnaSequence instance it abstracts. DnaComponent instances MAY be grouped into Collections.
A DnaComponent instance MUST have the following REQUIRED data properties.

Data properties:
uri: (required) One and only one field of type URI (IETF RFC 2396). This property uniquely identifies the instance, and is intended to be used whenever a reference to the instance is needed, such as when referring to a DnaComponent stored on a server from another location.
This URI MAY be a fully qualified URI (e.g. http://sbols.org/data#P0123), which then MUST remain constant forever, or this URI MAY consist of a relative identifier only (e.g. #P0123), which then MUST be unique within the enclosing context (e.g. Collection, an XML document). This form MAY be used for the informal exchange of free-floating temporary SBOL instances. For any other purpose it is RECOMMENDED that the relative identifier can be resolved against the enclosing context (e.g. the uri of a Collection or the fixed address of an XML document) into a fully qualified URI which then, again, MUST remain constant forever.
displayId: (required) One and only one field of type xsd:string starting with a letter or underscore followed by only alphanumeric and underscore characters. The displayId is a human readable identifier for display to users. For example, users could use this identifier in combination with the namespace of the source as an unambiguous reference to the DNA construct.
OPTIONALLY a DnaComponent instance MAY have the following RECOMMENDED data and object properties.

Object properties:
dnaSequence: (optional) Zero or one value of type DnaSequence. This property specifies the DNA sequence which this DnaComponent object represents. See also: DnaSequence.
annotations: (optional) Zero or more values of type SequenceAnnotation. This property links to SequenceAnnotation instances, each of which specifies the position and direction of a DnaComponent that describes a subComponent of this DNA component.

Data properties:
name: (optional) Zero or one value of type xsd:string. The name of the DNA component is a humanreadable string providing the most recognizable identifier used to refer to this DnaComponent. It often confers meaning of what the component is in biological contexts to a human user. A name may be ambiguous, in that multiple, distinct DnaComponents may share the same name. For example, acronyms are sometimes used (eg. pLac-O1) which may have more than one instantiation in terms of exact DNA sequence composition. As these names are intended for human consumption, they SHOULD be kept short and meaningful, for as may be done by using an acronym, or re-using names that have commonly been used in literature.

description: (optional)
Zero or one value of type xsd:string. The description is a free-text field that contains text such as a title or longer free-text-based description for users. This text is used to clarify what the DnaComponent is to potential users (eg. engineered Lac promoter, repressible by LacI). The description could be lengthy, so it is the responsibility of the user application to format and allow for arbitrary length.
type: (optional) Zero or more values of type URI (IETF RFC 2396) referencing the Sequence Ontology or provisional SBOL:Vocabulary extensions. These provide a defined terminology of types of DnaComponents. This vocabulary may be extended, please contact the SBOL Editors (see section 11 for contact information).

DnaSequence:
Objects representing a DNA Sequence MUST be instances of the class sbol:DnaSequence, defined as:

Context:
Instances of the DnaSequence class contain the actual DNA sequence string. This specifies the sequence of nucleotides that comprise the DnaComponent being described.
For SBOL DnaSequence, the base pairs MUST be represented by a sequence of lowercase characters corresponding to the 5' to 3' order of nucleotides in the DNA segment described, eg. "actg". The string value MUST conform to the restrictions listed below: a. The DNA sequence will use the IUPAC ambiguity recommendation. (See http://www.genomatix.de/online_help/help/sequence_formats.html) b. Blank lines, spaces, or other symbols must not be included in the sequence text. c. The sequence text must be in ASCII or UTF-8 encoding. For the alphabets used, the two are identical.
A DnaSequence instance MUST have the following REQUIRED data properties.

Data properties:
uri: (required) One and only one field of type URI (IETF RFC 2396). This property uniquely identifies the instance, and is intended to be used whenever a reference to the instance is needed. See also DnaComponent.uri nucleotides: (required) One and only one value of type xsd:string. See requirements for value of string in the class definition.

SequenceAnnotation:
Objects representing a Sequence Annotation MUST be instances of the class sbol:SequenceAnnotation, defined as:

Context:
Individual instances of the SequenceAnnotation class provide the position and direction of subComponents (DnaComponents) that are found within the annotated DnaComponent. Location CAN be specified by the bioStart and bioEnd positions of the subComponent, along with the DNA sequence. Alternatively, the partial order of SequenceAnnotations along a DnaComponent can be specified by indicating the precedes relationship to other SequenceAnnotations. As a convention, numerical coordinates in this class use position 1 (not 0) to indicate the initial base pair of a DNA sequence. This convention is followed by the broader Molecular Biology community, especially in the relevant literature. The direction of the subComponent is specified by the strand [+/-]. Sequences used are assumed, by convention, to be specified 5' to 3', therefore the + strand is 5' to 3' and the -strand is 3' to 5'.
A SequenceAnnotation instance MUST specify a subComponent of type DnaComponent. SequenceAnnotations MUST belong to exactly 1 DnaComponent.
A SequenceAnnotation instance MUST have the following REQUIRED object properties.

Object properties:
subComponent: (required) One and only one value of type DnaComponent. This property specifies the DNA sequence feature being annotated on the DnaComponent's sequence. The DnaComponent value serves to indicate information about the subsequence at the position specified by the SequenceAnnotation's location data properties or the relative position object property.
A SequenceAnnotation instance MAY have one of the following Location Data or Relative Position Object property groups.

Location Data Group
Data properties: uri: (required) One and only one field of type URI (IETF RFC 2396). This property uniquely identifies the instance, and is intended to be used whenever a reference to the instance is needed. see also DnaComponent.uri bioStart: (optional) Zero or one value of type xsd:integer. Positive integer coordinate of the position of the first base of the subComponent on the DnaComponent. bioStart coordinate is relative to the parent sequence.
bioEnd: (optional) Zero or one value of type xsd:integer. Positive integer coordinate of the position of the last base of the subComponent on the DnaComponent. bioEnd coordinate is relative to the parent sequence.
strand: (optional) Zero or one value of type xsd:string. Strand orientation + or -of the subComponent relative to the DNA sequence of the DnaComponent being annotated. DnaSequence is by convention assumed 5' to 3', therefore the "+" strand is 5' to 3' and the "-" strand is 3' to 5'.

Relative Position Object Group
Object property: precedes: (optional) Zero or more values of type SequenceAnnotation. The precedes relation specifies the relative order of SequenceAnnotations for a given DnaComponent. It is a constraint on the order of subComponents when there is not enough information to specify exact positions. Precedes indicates the intended location by specifying that a SequenceAnnotation is to come before another when DnaSequence information becomes available. For example, you may want to say the promoter SequenceAnnotation precedes the CDS SequenceAnnotation, which precedes the terminator SequenceAnnotation. This ordering gives us the position, relative to other SequenceAnnotations (which can have a location or a relative position (using precedes)). During a validation process, the set of precedes relations on the SequenceAnnotation are required to be linearized to a sequence. Finally, a null value for a precedes property indicates the terminal SequenceAnnotation within a given DnaComponent. Absence of the precedes relation indicates this knowledge is not known.

Well-formed constraint: Location Data
The Location Data fields of SequenceAnnotation are bioStart, bioEnd. They must either both be present or absent. It is a well-formedness violation for one to be present while the other is absent.

Well-formed constraint: Relative Position
The Relative Position field of SequenceAnnotation is precedes. A relative position is valid if one of the following is true: precedes with a value of type SequenceAnnotation; or precedes with a value of null, indicating a terminal SequenceAnnotation.

Logical consistency of Location Data and Relative Position
Given sa1:SequenceAnnotation and sa2:SequenceAnnotation, where sa1 precedes sa2, they are logically consistent if: absent data: sa1.bioEnd or sa2.bioStart are not provided; or consistent data: both sa1.bioEnd and sa2.bioStart are provided and sa1.bioEnd is strictly less than sa2.bioStart

Logical consistency of the subComponent's DnaSequence value
If present, the DnaSequence value of the DnaComponent referenced by subComponent in a SequenceAnnotation with Location Data MUST be the exact sequence found in the interval specified by the Location Data.

Collection:
Instances representing a Collection MUST be instances of the class sbol:Collection, defined as:

Context:
Individual instances of the Collection class represent an organizational container which helps users and developers conceptualize a set of DnaComponents as a group. Any combination of these instances CAN be added to a Collection instance, annotated with a displayID, name, and description and be published or exchanged directly.
For example, a set of restriction enzyme recognition sites, such as the components commonly used for BBF RFC 10 BioBricks™, could be placed into a single Collection.
A Collection might contain DNA components used in a specific project, lab, or custom grouping specified by the user.
Arbitrary groupings and new Collection instances SHOULD NOT be created and named when the groupings are not defined, but also Collections SHOULD NOT be created whenever an arbitrary set is possible. Instances should only be used to represent a grouping that is useful to a user.
A Collection instance MUST have the following REQUIRED data properties.

Data Properties:
uri: (required) One and only one field of type URI (IETF RFC 2396). This property uniquely identifies the instance, and is intended to be used whenever a reference to the instance is needed. see also DnaComponent.uri displayId: (required) One and only one value of type xsd:string starting with a letter or underscore followed by only alphanumeric and underscore characters. The displayID is a humanreadable identifier for display to users. For example, users could use this identifier in combination with the namespace of the source as an unambiguous reference to the DNA construct.
A Collection instance CAN have the following OPTIONAL object and data properties. . This text SHOULD focus on an informative statement about the reason for grouping the Collection members. The result should allow users to interpret the reason for inclusion of members in this Collection (eg "Collecting parts which could be used to build honey production directly into mouse-ear cress"; "T9002 and I7101 variants from Sleight 2010, designs aim to improve stability over evolutionary time"; "Components useful when working with BBF RFC 10").

Examples
Sharing information about a variety of DnaComponents using the SBOL allows unambiguous specification of their DNA sequence-based descriptions. This section presents examples illustrative of different use cases as defined by SBOL:Core:model.

Annotated Composite DnaComponent
The first example is the SBOL:Core:model for the BioBrick™ BBa_I0462. The BBa_I0462 DnaComponent codes for the LuxR protein when inserted downstream of a promoter ( Figure 6). Information comes from the Registry of Standard Biological Parts (http://partsregistry.org) to describe this canonical composite BioBrick™ part. DnaComponents. The icons are labelled with a shorthand notation of the displayId from http://partsregistry.org.
In Figure 7a the BioBrick™ part BBa_I0462, a DnaComponent, is depicted with annotations of three DnaComponents: a ribosome binding site (BBa_B0034), the coding sequence for LuxR (BBa_C0062), and a double terminator BBa_B0015. In Figure 7b, the same DnaComponent is described using pseudocode as an example of SBOL:Core:model as text.

Multi-Tiered Annotated DnaComponent
The next example depicts the subcomposition of BBa_I0462 in terms of each of its subComponents (Figure 8).

Partially Realized Design Template
This example illustrates the partial specification of designs in terms of DnaComponent layout constraints. Figure 9 demonstrates the use of SequenceAnnotations with a Relative Position to specify the order of DnaComponents within a planned DnaComponent. Figure 9. The design template for DnaComponent DC Ø1 specifies that at least three DnaComponents must be present in this design. Their ordering is constrained, DC s2 precedes DC t3 and DC t3 precedes DC s4 . In this template the DC s2 and DC s4 already have a DnaSequence specified, however DC t3 does not, instead it specifies a type which it must me constrained to. Therefore, the DC t3 component can be filled in to match the type constraint later.

Collection
To provide an organizational container for multiple DnaComponent instances, we provide the Collection class. The example in Figure 10 shows a Collection with multiple DnaComponents grouped together and ready to be shared between software applications. Figure 10. The Collection 1 is a convenience object to group DnaComponents DC 1 , DC s2 , and DC st3 . Described collections are a natural conceptualization of a group of objects to be shared at one time or that serve a specific purpose.

Best Practices
For SBOL version 1.0.0, best practices are being maintained in a dynamic document on the web, and will be updated as the use of SBOL increases (http://www.sbolstandard.org/initiatives/best-practices) In future versions, Best Practices and Validation Criteria will be included in the specification.