Expand ComponentInstance:definition cardinality to support libraries

[jakebeal]

We need a way of supporting library constructions, e.g., "tune by assembling this construct using these 10 promoter variants x these 8 5'UTR variants". Right now, we don't have a good way of doing this.

I believe that a simple way to support this is by allowing the ComponentInstance "definition" property to have an unrestricted cardinality rather than a cardinality restricted to precisely 1.

[drdozer]

Hi Jake,

Is the functionality you need in essence the ability to say "choose exactly
1 from this set"?

If so I would prefer to leave this cardinality 1:1 and I can expand upon
why if you like, but instead add a component definition type that is a
choice set. We need this in any case for e.g. describing a protein that
bins one of 3 +2 ions.

Matthew

Matthew
On 16 Sep 2015 17:42, "Jacob Beal" notifications@github.com wrote:

We need a way of supporting library constructions, e.g., "tune by
assembling this construct using these 10 promoter variants x these 8 5'UTR
variants". Right now, we don't have a good way of doing this.

I believe that a simple way to support this is by allowing the
ComponentInstance "definition" property to have an unrestricted cardinality
rather than a cardinality restricted to precisely 1.

—
Reply to this email directly or view it on GitHub
#31.

[cjmyers]

Hi,

I agree with Matthew that we need to be careful with cardinality changes. The cardinality change on Sequences for ComponentDefinition had a number of unintended consequences. I would need to see more details though of Matthew’s proposal to know whether or not it is a better approach though.

Chris

On Sep 18, 2015, at 1:39 AM, Matthew Pocock notifications@github.com wrote:

Hi Jake,

Is the functionality you need in essence the ability to say "choose exactly
1 from this set"?

If so I would prefer to leave this cardinality 1:1 and I can expand upon
why if you like, but instead add a component definition type that is a
choice set. We need this in any case for e.g. describing a protein that
bins one of 3 +2 ions.

Matthew

Matthew
On 16 Sep 2015 17:42, "Jacob Beal" notifications@github.com wrote:

We need a way of supporting library constructions, e.g., "tune by
assembling this construct using these 10 promoter variants x these 8 5'UTR
variants". Right now, we don't have a good way of doing this.

I believe that a simple way to support this is by allowing the
ComponentInstance "definition" property to have an unrestricted cardinality
rather than a cardinality restricted to precisely 1.

—
Reply to this email directly or view it on GitHub
#31.

—
Reply to this email directly or view it on GitHub #31 (comment).

[jakebeal]

A third possibility is that we could allow Collection to be a target of both ComponentInstance and Module definitions (thereby allowing choice at a functional level as well). Or perhaps create a Choice class as a child of Modules?

Here are some use cases that I'm thinking about, all of which need to be served:

• Combinatorial assembly
  • Small scale (e.g., promoter x 5'UTR)
  • Large scale (e.g., permutations of a many-gene refactored cluster)
• Generation of a collection of randomly mutated variants

[cjmyers]

I think this might work. Namely, you are suggesting that the Definition field of ComponentInstance and Module be allowed to point to a Collection. I would assume these Collections would be required to only include ComponentDefinitions and ModuleDefinitions, respectively. We could perhaps do the same thing for the sequence element of ComponentDefinition. This would make it clear in all cases when we have the simpler fixed option while allowing for the flexibility of higher cardinality in the use cases that require it.

On Sep 18, 2015, at 7:53 AM, Jacob Beal notifications@github.com wrote:

A third possibility is that we could allow Collection to be a target of both ComponentInstance and Module definitions (thereby allowing choice at a functional level as well). Or perhaps create a Choice class as a child of Modules?

Here are some use cases that I'm thinking about, all of which need to be served:

Combinatorial assembly
Small scale (e.g., promoter x 5'UTR)
Large scale (e.g., permutations of a many-gene refactored cluster)
Generation of a collection of randomly mutated variants
—
Reply to this email directly or view it on GitHub #31 (comment).

[jakebeal]

I suppose that the advantage of this over just allowing higher cardinality is that it gives us a point off which one might hang additional description of the choice being made. For example, "choose one" assembly from a library is different than realizing a set of permutations.

Does that match your understanding as well, Matthew?

[drdozer]

At first sight, combinatorial design is a different problem from specifying
a particular design. Are we sure that we should be trying to cover both of
these in a single data structure, rather than considering having a
combinatorix extension?

M

On 18 September 2015 at 15:10, Jacob Beal notifications@github.com wrote:

I suppose that the advantage of this over just allowing higher cardinality
is that it gives us a point off which one might hang additional description
of the choice being made. For example, "choose one" assembly from a library
is different than realizing a set of permutations.

Does that match your understanding as well, Matthew?

—
Reply to this email directly or view it on GitHub
#31 (comment)
.

Dr Matthew Pocock
Turing ate my hamster LTD
mailto: turingatemyhamster@gmail.com

Integrative Bioinformatics Group, School of Computing Science, Newcastle
University
mailto: matthew.pocock@ncl.ac.uk

gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

[jakebeal]

I'm don't have any clear proposal for which we do and which we don't cover; I just think these are all frequent use cases that we should keep in mind, such that we end up deliberately choosing to cover or not cover each.

[drdozer]

I agree Jake, combinatorial designs are very, very common, and it would be
nice to have a way to represent this. We have part of it already with the
generalisation of 'precedes', and the obvious bit we don't have is to
specify a set of replacements.

The semantics of the ComponentDefinition -> child component relationship is
currently that there is exactly one copy of the instantiated child CD
within the parent CD. This is really easy to reason over, for things like
model-checking that the resulting design is self-consistent.

There are terms in CHEBI for e.g. a +2 ion. Then this has more specific
terms for Fe+2, Mg+2 and so on. So by using this general term we can
describe a +2 ion binding protein complex without being specific about
exactly which ion by using a CD with the +2 ion term. This gives us
combinatorial design over +2 ions. You can then refine this in a derived
CD, filling in Fe+2, and you can model-check that this is a valid
substitution, purely by walking the terminologies.

The issue with DNA combinatorial design is that often the parts you are
choosing from don't correspond to a nice neat clade within a hierarchy. So
you can't use this technique to choose over them.

Thinking about it a bit more, I can imagine wanting to state that all of a
collection of alternative DNA parts share some features e.g. a primer
binding site or a DNA binding domain in a CDS. So what I think we need is a
new top-level relation on CD called something like 'alternative' that is
0-* cardinality. A CD with one or more 'alternative' values is valid if the
child components of the CD are consistent with all alternatives (e.g. if
the CD asserts a primer binding site, this primer binding site is
consistent with each of the alternatives). A CD is a valid refinement of a
CD with alternatives if it uses a subset of the same alternatives; or if
it is exactly one of the alternatives.

This is the best plan I can come up with on short notice without talking to
real people with a whiteboard. I can expand on the validity rules with
examples if needed.

Matthew

On 21 September 2015 at 16:53, Jacob Beal notifications@github.com wrote:

I'm don't have any clear proposal for which we do and which we don't
cover; I just think these are all frequent use cases that we should keep in
mind, such that we end up deliberately choosing to cover or not cover
each.

—
Reply to this email directly or view it on GitHub
#31 (comment)
.

Dr Matthew Pocock
Turing ate my hamster LTD
mailto: turingatemyhamster@gmail.com

Integrative Bioinformatics Group, School of Computing Science, Newcastle
University
mailto: matthew.pocock@ncl.ac.uk

gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

[jdiggans-twist]

The current SEP document does allow for a sampling strategy which we'd find very useful; what isn't clear from the SEP is whether this sampling allows weights per component or whether it assumes uniformity?

[cjmyers]

Isn't this addressed by the combinatorial extension @jakebeal? Can we close this one?

[jakebeal]

Yes: library support is implemented with the combinatorial extension, superseding this suggestion.