SEP | 015 |
---|---|
Title | Simplification of SBOL class names |
Authors | James Alastair McLaughlin (j.a.mclaughlin@ncl.ac.uk); Raik Grünberg (raik.gruenberg@gmail.com) |
Editor | |
Type | Data Model |
SBOL Version | 3.0 |
Replaces | |
Status | Draft |
Created | 28-Jun-2017 |
Last modified | 28-Jul-2019 |
Issue | #32 |
The number of classes in the SBOL data model grew sharply with the introduction of SBOL 2.0. Prior to generalizations such as turning DnaComponent into ComponentDefinition, many discussions took place about the nomenclature, and eventually a quorum was reached and the class names were accepted.
SBOL2 has been released for some time now, and the community is now familiar with using the data model in practice. This SEP suggests that, given our experience actually using SBOL2, we reconsider the nomenclature once more for SBOL3.0. The intention would be to simplify names and to convey meaning more effectively.
- Motivation
SBOL2 can be very confusing to newcomers, and the verbosity of its class names doesn't help. The most common class in SBOL is likely ComponentDefinition
, which is a verbose name usually abbreviated to "CD" or simply "component". Confusingly though, SBOL 2.x also defines a class Component
which, however, actually describes a subcomponent. Similar issues exist with ModuleDefinition
and Module
.
The rationale for this SEP, using Component as an example, are that:
-
In SBOL2,
Component
must be contained by aComponentDefinition
and is therefore always a subcomponent. Changing the name toSubComponent
is more expressive. -
This change leaves the name
Component
free forComponentDefinition
to be renamed to. Removing "Definition" makes the name less verbose and less confusing. The simplified nameComponent
matches what programmers currently use in colloqial conversations about SBOL. -
In programming languages, classes are definitions implicitly and do not need to be explicitly named as such. For example, the
File
class in Java is calledFile
, notFileDefinition
, even before an instance of it has been created. Bringing SBOL in line with this makes SBOL more intuitive.
The FunctionalComponent
class, though also confusingly named, will remain as-is for the purposes of this SEP.
- Specification
The following classes will be renamed:
ComponentDefinition
toComponent
Component
toSubComponent
ModuleDefinition
toModule
Module
toSubModule
definition
toinstanceOf
This is a major change, but only to the names of classes. (Note: a separate SEP will deal with removing FunctionalComponent). Consequently, updating the libraries should be straightforward. It is important to defer this change to SBOL 3.0 so that the namespace is different (otherwise, it would be ambiguous whether a Component was an SBOL 2.0 Component instance or a SBOL 3.0 Component).
More generally, tools solely programmed for SBOL 2.x will, in any case, run into trouble when opening an SBOL 3.0 document. SBOL2 documents use the URI prefix http://sbols.org/v2#
for terms. Presumably, SBOL3 will use the http://sbols.org/v3#
prefix, which will prevent SBOL2 and SBOL3 from clashing.
The following SEPs make complementary suggestions for further simplification of the SBOL data model:
-
SEP 10 (Issue) -- a proposal to separate sequence feature annotations from sub-component (part) compositions
-
SEP 25 (Issue) -- merge Module(Definition) with Component(Definition) and remove FunctionalComponent
Library developers may be concerned at the time cost of implementing such a significant change. However, as the proposed change is only to the nomenclature and not the semantics, it should generally be no less complicated than a find/replace operation.
SBOL2 documents use the URI prefix http://sbols.org/v2#
for terms. Presumably, SBOL3 will use the http://sbols.org/v3#
prefix, which will prevent SBOL2 and SBOL3 from clashing. This has yet to be discussed.
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 Kingdom.