| SEP | |
|---|---|
| Title | Use existing SO terms for Feature orientation |
| Authors | James Scott-Brown ([email protected]) |
| Editor | |
| Type | Data Model |
| SBOL Version | SBOL 3.0.1 |
| Replaces | |
| Status | Draft |
| Created | 25-Mar-2021 |
| Last modified | 25-Mar-2021 |
| Issue | #111 |
The current specification (v3.0.1) states that:
If a Feature object has an orientation, then it MUST come from Table 5
Table 5 lists http://sbols.org/v3#inline and http://sbols.org/v3#reverseComplement.
However, we have a general principle of reusing existing identifiers where possible, and only introducing our own identifiers when necessary.
Sequence Ontology contains the relevant terms as SO:0001030 (forward) and SO:0001031 (reverse); we should therefore be preferentially using these terms.
Replace:
Table 5 provides a list of REQUIRED orientation URIs. If a Featureobject has an orientation, then it MUST come from Table 5
With:
If a Feature object has an orientation, then it is RECOMMENDED that it come from Table 5; for reasons of backwards compatibility it MAY instead come from Table 6.
Table 5 would list the SO terms SO:0001030 (forward) (https://identifiers.org/SO:0001030) and SO:0001031 (reverse) (https://identifiers.org/SO:0001030). The caption would be "RECOMMENDED URIs for the orientation property".
Table 6 would list the terms listed Table 5 of the current specification (http://sbols.org/v3#inline and http://sbols.org/v3#reverseComplement). The caption would be "Permitted alternative URIs for the orientation property. The URIs listed in Table 5 are preferred and SHOULD be used instead where possible".
N/A
Backwards compatability is achieved by suggesitng the use of SO URIs with a SHOULD rather than MUST statement, and continuing to accept the previously-required URIs as valid (but recommended against).
None.
To the extent possible under law,
SBOL developers
has waived all copyright and related or neighboring rights to
SEP 002.
This work is published from:
United States.