-
Notifications
You must be signed in to change notification settings - Fork 9
/
compliance.tex
29 lines (23 loc) · 1.65 KB
/
compliance.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
\section{SBOL Compliance}
There are different types of software compliance with respect to the SBOL specification. First, a software tool can either support all classes of the SBOL 3 data model or only its structural subset. The structural subset includes the following classes:
\begin{itemize}
\item \sbol{Sequence}
\item \sbol{Component}
\begin{itemize}
\item \sbol{SubComponent}
\item \sbol{ComponentReference}
\item \sbol{LocalSubComponent}
\item \sbol{SequenceFeature}
\item \sbol{Location}
\item \sbol{Constraint}
\end{itemize}
\item \sbol{Collection}
\end{itemize}
Second, an SBOL-compliant software tool can support import of SBOL, export of SBOL, or both.
If it supports both import and export, it can do so in either a lossy or lossless fashion.
In order to test import compliance, developers are encouraged to use the SBOL test files found here:\\ {\url{https://github.com/SynBioDex/SBOLTestSuite}}\\
Examples of every meaningful subset of objects are provided, including both structural-only SBOL (that is, annotated DNA sequence data) and complete tests.
In order to test export compliance, developers are encouraged to validate SBOL files generated by their software with the SBOL Validator found here:\\
\url{https://validator.sbolstandard.org}\\
This validator can also be used to check lossless import/export support, since it can compare the data content of files imported and exported by a software tool.
Finally, developers of SBOL-compliant tools are encouraged to notify the SBOL editors\\([email protected]) when they have determined that their tool is SBOL compliant, so their tool can be publicly categorized as such on the SBOL website.