Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
SEP V001: Bounding box, interior, backbone alignment, and relative scale #4
SEP V001: Bounding box, interior, backbone alignment, and relative scale
Glyphs need some additional information about how they are to be used, as failing to specify this has caused confusion. In particular:
Table of Contents
We've run into problems with ambiguity in some glyphs, in which people are confused about how to use a glyph in several areas. This aims to add explicit guidance on how to resolve these issues to the specification of each glyph.
2.1 Relative scale
Glyphs are RECOMMENDED to use the same relative scale to one another as found in the specification.
This just makes formal something that has been informally interpreted in this way already. All of the original SBOL Visual 1.0 glyphs were specified on a 0.5 x 0.5 inch template, so this should probably be the base for future glyph design as well.
2.2 Bounding Box
Every glyph specification MUST include a grey rectangular bounding box. Glyph interactions with one another and with the nucleic acid backbone are defined in terms of the bounding box, not the lines of the glyph.
This allows "gaps" at the edge of a glyph to be part of its expected specification.
When a glyph has an intended interior (i.e., spaces within the boundary that may be filled with color or pattern), the interior MUST be specified as a grey filled area.
This avoids ambiguity in which spaces are intended to be "inside" versus which may simply be closed lines.
2.4 Recommended Backbone alignment
Every glyph for representing a Component MUST have exactly one grey horizontal line indicating the RECOMMENDED vertical positioning of the glyph on a nucleic acid backbone.
Note that it is only recommended, and thus people can continue using alternate placements if they have good reason for doing so. Additional recommendations for best practices in alignment beyond this may be added to glyphs if desired as well.
For most glyphs, the bounding box, interior and alignment are obvious.
Changes implied by this SEP are drafted in https://github.com/SynBioDex/SBOLv-realizations/tree/feature/glyph-specs
One of the purposes of bounding boxes is to let us meaningfully talk about the p1/r1 vs. p2/r2 in your example. No specific proposal for what, exactly, to do with bounding boxes is attached to this proposal: that will come up in a later proposal.
In that proposal we will suggest that overlapping glyphs should generally be interpreted to mean overlapping positions on the backbone (as is often the convention already), and thus RECOMMEND that bounding boxes overlap if and only if positions overlap.
I'd also suggest editing abstract as follows: "How the glyph is recommended to be aligned with the nucleic acid backbone (and other glyphs if appropriate)." @swapnilb raises an important point, that is probably more relevant for some glyphs that almost always overlap with others (primer binding sites are a good example). Would be good to recommend that alignment to both backbone and other parts is provided in the definition.
@chofski Can you please give an example of a additional alignment information that would be useful to include, besides the vertical alignment of the backbone and the bounding box? I am reluctant to add this in without an example, because it changes the specification away from the simplicity of "one RECOMMENDED vertical alignment rule"
If the part is commonly overlapping, then the additional alignment information would be in respect to existing part bounding boxes at its position. So for a forward facing primer binding site, vertical alignment would be for the bottom edge of the bounding box to touch the backbone when no other parts present, or for the bottom edge of the bounding box to touch the upper most top edge of any overlapping parts. This sort of statement should be optional as most parts won't need to worry about it, but it should be suggested I believe for those that are commonly annotated within others (e.g. recognition sites, operator sites, etc).
Agree with @chofski suggestion above.
And in addition, would like to repeat/remind that "non overlapping bounding boxes" should not be a mandatory constraint,
but, only that colocated parts must have x-aligned bounding boxes or something along those lines.