[BBF Standards] functional composition of BioBrick parts?
Raik Gruenberg
raik.gruenberg at crg.es
Wed Feb 13 18:11:22 EST 2008
Mackenzie Cowell wrote:
> The current notion of a standard data model for biobricks has focused on
> defining the identity of each biobrick by its DNA sequence, as opposed
> to functional properties.
>
> I agree that BioBricks should be uniquely defined by their DNA
> sequence. However, the characterization, documentation, and user
> experiences that should be associated with each biobrick will
> essentially be defined by its function. I am concerned that lots of
> functionally similar but sequentially different parts will be built,
> resulting in a host of unique biobricks that will unnecessarily divide
> the attention and documentation efforts of the community. I think the
> data model must support a mechanism for collecting and sharing
> documentation among functionally-related/identical sets of parts, thus
> avoiding much redundancy.
>
Right, I agree, this probably falls into the question of "Abstraction hierarchy"
that has been raised before. The notion of shared and inherited properties
requires an extra class. We could define a BiobrickFamily with multiple
inheritance between families allowing the construction of unrestricted
hierarchies and each biobrick would then fall into several families -- which
could serve also as classification:
For example, BBFamily 'RBS' could be a sub-family of 'regulatory', which in turn
belongs to 'non-coding DNA elements'. A certain biobrick could then point to RBS
as one of its families. (Or we put a link entity in between, to have a
bidirectional relation with added evidence, references etc.).
I guess that could solve the problem, wouldn't it? Perhaps this warrants another
sub-section in the wiki?
/Raik
> I think the biobrick data standard should make provisions for
> encapsulating functionally identical (or at least closely related) but
> sequentially different parts in an abstract "ideal part". This ideal
> part should be *functionally* defined by the intended or ideal function
> common to the group of instance parts while remaining sequence agnostic
> - i.e., the ideal part is something that looks and acts like a biobrick
> in most ways, although it lacks a specific sequence (it might point to
> an exemplar biobrick that does have a specific sequence). This ideal
> part could be what is presented to a user browsing a collection like the
> registry. I think that in almost all cases, such a user would be
> browsing for a particular function, not a sequence. Once they had
> identified an ideal part they were interested in, the system could
> present all the known instances of it, each inheriting the common
> functional, characterization, and inheritance information associated
> with the ideal part, and overriding that data when more specific data to
> the instance was available.
>
> What are your thoughts?
>
> Mac
>
>
> ---------- Forwarded message ----------
> From: *Mackenzie Cowell* <macowell at gmail.com <mailto:macowell at gmail.com>>
> Date: Feb 5, 2008 12:18 PM
> Subject: Re: [BBF Standards] functional composition of BioBrick parts?
> To: Raik Gruenberg <raik.gruenberg at crg.es <mailto:raik.gruenberg at crg.es>>
> Cc: Bryan Bishop <kanzure at gmail.com <mailto:kanzure at gmail.com>>,
> standards at biobricks.org <mailto:standards at biobricks.org>
>
>
> Perhaps we could do both? Assuming a biobrick always has one and only
> one dna sequence, perhaps we could build the data model to support
> organizing biobricks into families or sets of functionally related
> parts? Each family could have one canonical biobrick associated with it
> that works, is available, and exemplifies the function that the family
> is supposed to have.
>
> I'm inspired by JC Anderson's library of tuned promoters: BBa_J23100
> <http://parts.mit.edu/registry/index.php/Part:BBa_J23100>.
>
> -mac
>
>
> On Feb 5, 2008 5:08 AM, Raik Gruenberg <raik.gruenberg at crg.es
> <mailto:raik.gruenberg at crg.es>> wrote:
>
> Thanks Mac for setting up the wiki!
>
> > And here is a BioBrick part data model question: should there be a
> > one-to-one relationship between a part 's functional definition
> and its
> > sequence? What if you introduce a silent mutation into a
> BioBrick - is
> > there a "different sequence, different part" doctrine, even if
> the two
> > are functionally equivalent? Additionally, how are codon-optimized
> > sequences for the same function related to one another? Families of
>
> Or put differently -- What *is* a biobrick?
> We right now seem to follow the unspoken rule that a part is defined
> by its
> exact DNA sequence. Any modification creates a new part, which is
> kind of
> logical to the experimentalist because it maps a biobrick to exactly
> one DNA
> fragment (which you either have in your freezer or not) and vice versa.
>
> But you are right, things are getting murky if you codon optimize a
> protein part
> (should the biobrick be defined by the amino acid sequence
> instead?). Even more
> extreme: You can have the "same" Biobrick in different formats, e.g.
> with
> prefix/suffix from one of the two suggested protein fusion formats.
> Now the
> sequence is exactly the same, but having a sample of biobrick X with
> biofusion
> flanks may be of no use if the other biobricks in you freezer are
> formatted
> differently. Or you could have a composite part A-B-C and another
> one A~B~C with
> the same parts but different scars in between.
>
> On the other hand, you don't care about format or even detailed
> sequence if you
> DNA-synthesize your whole assembly from scratch.
>
> > tuned promoters? Is this a source code vs. compiled code issue?
> ...or specification versus implementation
>
> So what shall we do?
>
> A) keep/fix the sequence-based definition but introduce relations
> like "ortholog
> to", "equivalent to", etc.
>
> A') define "reference biobricks" and link variants to them
>
> B) find a more abstract definition (still based on reference
> sequences of DNA,
> AA, or Biobrick letters?) and create the concept of BB
> 'implementation' or
> 'instance'.
>
> B may actually have some legal implications (e.g. no need to
> copyright sequence
> but copyright higher-level description and protect the whole family
> from being
> patent-snatched).
>
> Opinions?
> Raik
>
> Mackenzie Cowell wrote:
> > Hello Everyone,
> >
> > I seeded the BBF wiki page at
> >
> http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical
> > with some of the main points of the recent discussion.
> >
> > You can also navigate to a "dewikified" version of the page from
> the BBF
> > homepage at http://biobricks.org/, or directly via
> > http://bbf.openwetware.org/Standards/Technical.html.
> >
> > And here is a BioBrick part data model question: should there be a
> > one-to-one relationship between a part 's functional definition
> and its
> > sequence? What if you introduce a silent mutation into a
> BioBrick - is
> > there a "different sequence, different part" doctrine, even if
> the two
> > are functionally equivalent? Additionally, how are codon-optimized
> > sequences for the same function related to one another? Families of
> > tuned promoters? Is this a source code vs. compiled code issue?
> >
> > -Mac
> >
> > On Jan 31, 2008 10:01 PM, Bryan Bishop <kanzure at gmail.com
> <mailto:kanzure at gmail.com>
> > <mailto:kanzure at gmail.com <mailto:kanzure at gmail.com>>> wrote:
> >
> > On Thursday 31 January 2008, "Julius B. Lucks" wrote:
> > > It sounds like there needs to be an annotation system in
> place that
> > > would allow compatibility evidence to be labeled as
> experimentally or
> > > computationally generated (or both). We might even
> consider the
> > > possibility of digitally signing the annotations to associate
> > > experiments or calculations with known labs. The preliminary
> > > question would be whether or not the annotations would be
> a part of
> > > the main parts ontology, or would it be a separate
> ontology itself.
> >
> > I certainly see the need to be able to reference other
> sub-ontologies
> > related to understanding the experimental methods for testing the
> > brick, or the specifications for the computational evidence etc.
> >
> > - Bryan
> > ________________________________________
> > Bryan Bishop
> > http://heybryan.org/
> >
> > _______________________________________________
> > Standards mailing list
> > Standards at biobricks.org <mailto:Standards at biobricks.org>
> <mailto:Standards at biobricks.org <mailto:Standards at biobricks.org>>
> > http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >
> >
> >
> >
> > --
> > Mac Cowell
> > iGEM Coordinator
> > igem.org <http://igem.org> <http://igem.org>
> > 231.313.9062
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Standards mailing list
> > Standards at biobricks.org <mailto:Standards at biobricks.org>
> > http://biobricks.org/mailman/listinfo/standards_biobricks.org
>
> --
> ________________________________
>
> Dr. Raik Gruenberg
> http://www.raiks.de/contact.html
> ________________________________
>
>
>
>
> --
> Mac Cowell
> iGEM Coordinator
> igem.org <http://igem.org>
> 231.313.9062
>
>
>
> --
> Mac Cowell
> iGEM Coordinator
> igem.org <http://igem.org>
> 231.313.9062
--
________________________________
Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________
More information about the Standards
mailing list