New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEP V001: Bounding box, interior, backbone alignment, and relative scale #4

Open
jakebeal opened this Issue Jul 2, 2017 · 14 comments

Comments

Projects
None yet
5 participants
@jakebeal
Contributor

jakebeal commented Jul 2, 2017

SEP V001: Bounding box, interior, backbone alignment, and relative scale

SEP
Authors Jacob Beal (jakebeal@ieee.org)
Editor
Type Specification
SBOL Visual Version 1.1
Status Draft
Created 01-Jul-2017
Last modified 03-Sep-2017

Abstract

Glyphs need some additional information about how they are to be used, as failing to specify this has caused confusion. In particular:

  • What their recommended relative scale is.
  • Whether they "tightly" fill their bounding box or whether there are expected to be gaps at the edges
  • Which, if any portions, are the "interior" of the glyph, to be affected by fill choices
  • How the glyph is recommended to be aligned with the nucleic acid backbone.

Table of Contents

1. Rationale

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. Specification

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.
Most significantly, a glyph can thus "hover" over the nucleic acid backbone, like primer binding sites generally do.

2.3 Interior

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.

3. Examples

CDS glyph, with interior marked and a possible recommended vertical alignment of the backbone to the bottom of the glyph:
image

Insulator with one possible interpretation of the interior marked:
image

Primer binding site, "hovering" over the nucleic acid backbone:
image

4. Backwards Compatibility

For most glyphs, the bounding box, interior and alignment are obvious.
For some, however, this is not the case, and these will need to be voted on to ensure consensus.

5. Discussion

Copyright

CC0
To the extent possible under law, SBOL developers has waived all copyright and related or neighboring rights to SEP V001. This work is published from: United States.

@bbartley

This comment has been minimized.

Show comment
Hide comment
@bbartley

bbartley Jul 3, 2017

If all of the SBOL Visual glyphs are specified on a 0.5 x 0.5 inch template, what specifies the boundary box's position within this template?

Thanks!
Bryan

bbartley commented Jul 3, 2017

If all of the SBOL Visual glyphs are specified on a 0.5 x 0.5 inch template, what specifies the boundary box's position within this template?

Thanks!
Bryan

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 3, 2017

Contributor

I have clarified my wording. The idea is that the bounding box is another box drawn on the glyph specifications --- see my examples here.

Contributor

jakebeal commented Jul 3, 2017

I have clarified my wording. The idea is that the bounding box is another box drawn on the glyph specifications --- see my examples here.

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal
Contributor

jakebeal commented Jul 6, 2017

@jakebeal jakebeal changed the title from SEP V001: Bounding box, interior, and backbone alignment to SEP V001: Bounding box, interior, backbone alignment, and relative scale Jul 6, 2017

@swapnilb

This comment has been minimized.

Show comment
Hide comment
@swapnilb

swapnilb Jul 6, 2017

I have a questions regarding the Bounding Box. Are constraints specified relating to the Bounding Box of a glyph, suggestions or mandatory? For example would it rule something like
image
as noncompliant because bounding boxes of p2 and r2 intersect?
If so, what is the benefit? If a future glyph is "bushy," might all the canopy waste valuable space? And how do bounding boxes work with visualizing current and future interactions among glyphs -- I suppose there some overlap is inevitable?

swapnilb commented Jul 6, 2017

I have a questions regarding the Bounding Box. Are constraints specified relating to the Bounding Box of a glyph, suggestions or mandatory? For example would it rule something like
image
as noncompliant because bounding boxes of p2 and r2 intersect?
If so, what is the benefit? If a future glyph is "bushy," might all the canopy waste valuable space? And how do bounding boxes work with visualizing current and future interactions among glyphs -- I suppose there some overlap is inevitable?

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 6, 2017

Contributor

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.

Contributor

jakebeal commented Jul 6, 2017

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.

@swapnilb

This comment has been minimized.

Show comment
Hide comment
@swapnilb

swapnilb Jul 6, 2017

The "if and only if" is not something I would support recommending, because there is very little benefit. I would, in the later proposal, suggest changing it to "if."

swapnilb commented Jul 6, 2017

The "if and only if" is not something I would support recommending, because there is very little benefit. I would, in the later proposal, suggest changing it to "if."

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 6, 2017

Contributor

That's fine; we can deal with that discussion in the later proposal. Right now, the plan is to make sure that bounding boxes are a thing, which is definitely necessary for supporting near-but-not-touching glyphs like primer binding site.

Contributor

jakebeal commented Jul 6, 2017

That's fine; we can deal with that discussion in the later proposal. Right now, the plan is to make sure that bounding boxes are a thing, which is definitely necessary for supporting near-but-not-touching glyphs like primer binding site.

@rsc3

This comment has been minimized.

Show comment
Hide comment
@rsc3

rsc3 Jul 9, 2017

Contributor

i dont like the definition of interior given with quotes, we should expand on what interior means for clarity

Contributor

rsc3 commented Jul 9, 2017

i dont like the definition of interior given with quotes, we should expand on what interior means for clarity

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 9, 2017

Contributor

@rsc3 I have attempted clarification.

Contributor

jakebeal commented Jul 9, 2017

@rsc3 I have attempted clarification.

@chofski

This comment has been minimized.

Show comment
Hide comment
@chofski

chofski Jul 10, 2017

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 commented Jul 10, 2017

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.

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 10, 2017

Contributor

@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"

Contributor

jakebeal commented Jul 10, 2017

@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"

@chofski

This comment has been minimized.

Show comment
Hide comment
@chofski

chofski Jul 10, 2017

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).

chofski commented Jul 10, 2017

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).

@swapnilb

This comment has been minimized.

Show comment
Hide comment
@swapnilb

swapnilb Jul 10, 2017

Agree with @chofski suggestion above.
Should add something along the lines of: "Glyph definitions may include a list of rules for x-y aligning and positioning the glyph relative to other glyphs, and must include rules for x-aligning the glyph to the DNA backbone." Follow with some examples.

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.

swapnilb commented Jul 10, 2017

Agree with @chofski suggestion above.
Should add something along the lines of: "Glyph definitions may include a list of rules for x-y aligning and positioning the glyph relative to other glyphs, and must include rules for x-aligning the glyph to the DNA backbone." Follow with some examples.

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.

@jakebeal

This comment has been minimized.

Show comment
Hide comment
@jakebeal

jakebeal Jul 10, 2017

Contributor

@chofski I have added a statement that glyphs may include additional recommended best practices for alignment, which I believe covers this.

@swapnilb Please recall that this proposal does not say anything about non-overlapping bounding boxes one way or another.

Contributor

jakebeal commented Jul 10, 2017

@chofski I have added a statement that glyphs may include additional recommended best practices for alignment, which I believe covers this.

@swapnilb Please recall that this proposal does not say anything about non-overlapping bounding boxes one way or another.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment