[BBF Standards] Biobrick data exchange format
Raik Gruenberg
raik.gruenberg at crg.es
Wed Feb 6 04:48:51 EST 2008
Hi there,
I've started working on Mac's standards Wiki
http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical
Please have a look at / discuss the first section:
"What is a Biobrick?"
A final definition is beyond the scope of this group. For data exchange purposes
we adopt the following draft:
* BioBrick™ are standard DNA parts that encode basic biological function.
* A BioBrick has a unique DNA sequence.
* Basic parts are defined by this DNA sequence.
* Composite parts are defined as "sequence" of Basic BioBricks, along with
intervening "scar" sequences.
I've also included part of the e-mail discussion for people to catch up on.
Please, add your comments / corrections directly to the Wiki or send them to
this list!
I'll try to update the two core sections (data model, format / technology) later
today or tomorrow -- except anyone beats me to it. Deepak, could you please
paste your file format draft into the wiki (or mail it)?
Greetings,
Raik
Raik Gruenberg wrote:
> Mackenzie Cowell wrote:
>> 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.
>
> That sounds indeed like the most practical solution. Rather than blurring up the
> definition of a biobrick, we create a layer of relations on top of it (e.g.
> families and devices?). That would also mean we can focus on the basic/minimal
> definition first -- I guess, a biobrick either has a sequence (= basic part) or
> is defined as a "sequence" of other Biobricks (=composite part).
>
> The issue of different formats (different prefix/suffix while equal sequence in
> between) may still deserve special treatment though. In order to reconstruct the
> exact DNA sequence of a composite part, we also need to know the scars in
> between. The brickit data model currently records either an explicitly given
> non-default scar sequence or falls back on a default scar (deducted from the
> parts' format). That implies that each biobrick has exactly one format though...
>
> /Raik
>
>> 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
>
--
________________________________
Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________
More information about the Standards
mailing list