Skip to content
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

Part extracts that include backbones #39

Open
jakebeal opened this issue Jul 10, 2023 · 3 comments
Open

Part extracts that include backbones #39

jakebeal opened this issue Jul 10, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@jakebeal
Copy link
Contributor

In BP011, @GC-repeat noticed that our terminology is currently awkward with respect to a digestion product that includes a backbone. Although it is technically covered by the "part extract" term, that feels wrong from the perspective of terminology.

We therefore propose to expand the terminology of digestions products to include distinctions with respect to their contents as follows:

  • If there is a SubComponent that includes an engineered_insert, but no SubComponent that includes a backbone, then it is a "part digest"
  • If there is a SubComponent that includes a backbone, but no SubComponent that includes an engineered_insert, then it is an "opened backbone"
  • If there is both a backbone and an engineered_insert, then it is an "opened part in backbone"

This is backward compatible with the current BP011, which is underspecified for "opened backbone" and "opened part in backbone"

Examples:

  • A BioBricks digest with XbaI and EcoRI produces an opened part-in-backbone that is ready to ligate a new part into on the 5' side of the current part
  • A digest on a MoClo Level 1 destination vector (backbone) produces an opened backbone ready to ligate with a set of parts to produce a Level 1 part-in-backbone
@jakebeal jakebeal added the enhancement New feature or request label Jul 10, 2023
@Gonza10V Gonza10V self-assigned this Jul 10, 2023
@Gonza10V
Copy link
Contributor

Gonza10V commented Jul 10, 2023

Hi, I agree with the idea in general.
I used the term open_backbone in the implementation of it so it makes sense to save that information.
I reached almost the same term for "opened backbone" , but "opened part in backbone" doesnt feel right to me. The name is too long and is less intuitive that "opened backbone".
Also, the term "opened part in backbone" is ambiguous. When you open a part in backbone you obtain the part and the backbone so it could represent both and the intention is to represent the former.

I would like to suggest the use of "sticky part" and "sticky backbone" given that both have sticky ends when opened or digested and they communicate that they are able to ligate to other parts. In thi way the name will include information of their state (sticky) rather than an action that happened to them (opened).
Also, I would consider the use of "sticky part" and "open/ed backbone".

@jakebeal
Copy link
Contributor Author

I don't have a strong preference between "open backbone" and "opened backbone."

I would prefer not to use the "sticky" terms though, because:

  1. that would replace "part extract", which got a lot of support,
  2. that's referring only to the ends, and
  3. some methods (though not our current targets) might turn out to involve blunt cuts

@jakebeal
Copy link
Contributor Author

Per discussion between myself and @Gonza10V, the proposal is to change to "open" from "opened" (matching the case of "extract" as opposed to "extracted"), and to keep the distinction of "open backbone" and "open part in backbone" due to the representational distinction.

Bottom line:

  • If there is a SubComponent that includes an engineered_insert, but no SubComponent that includes a backbone, then it is a "part digest"
  • If there is a SubComponent that includes a backbone, but no SubComponent that includes an engineered_insert, then it is an "open backbone"
  • If there is both a backbone and an engineered_insert, then it is an "open part in backbone"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants