[BBF Standards] data exchange issue 1: Abstraction

[Josh Perfetto]

Hi Raik and all,

When this conversation first came up, I was thinking it might make sense to
define BioBricks as either a code sequence where the code included
nucleotide symbols, amino acid symbols, and possibly some others, or as a
tagged DNA code sequence, where regions could be specified protein coding,
DNA binding site, etc.  Either way this would allow precise rules to be
defined of what was allowable (i.e. any appropriate codon could be used for
an amino acid symbol), and give the BioBrick designer the flexibility to
define where sequence was important and where it was not.

This would be conceptually very elegant.  However I refrained from saying
this.  The reason is that I see the issue of predictability-- knowing
exactly how parts will behave in the system so that there need not be an
excessive amount of debugging of each system, as one of the most important
issues that need to be overcome to make BioBrick-based systems useful.
Adding this flexibility or other mechanisms to get around unique sequence =
unique part adds complexity to the system, making predictability harder to
achieve.  Furthermore if there is to be a "data sheet" of measured
properties of parts, and a "silent" mutation or even worse codon
optimization changes expression characteristics, then it seems that in
general (without specific information that indicates otherwise) all bets are
off with respect to the data sheet.  You could try to overcome this by
defining more about internal part behavior in the standard, but again this
is adding more complexity.

So in general I think we should seek to define as simple a specification of
BioBricks as possible, and expand on it later.  That's not to say it should
be simpler than required, but we should look at all options.  I.e. if we
find ourselves introducing silent mutations, then why is that?  Do we need
to reserve more restriction enzyme sequences from occurring in BioBricks?

I'm not clear on exactly what the issue is with formats, perhaps you could
elaborate.  Why does the prefix/suffix need to be part of a BioBrick part
definition?

-Josh

-----Original Message-----
From: standards-bounces at biobricks.org
[mailto:standards-bounces at biobricks.org] On Behalf Of Raik Gruenberg
Sent: Monday, February 25, 2008 3:18 PM
To: standards at biobricks.org
Subject: [BBF Standards] data exchange issue 1: Abstraction

Hi all,

your 1st of March meeting is approaching and I would like to focus the 
discussion back to more mundane data exchange problems -- let's try to have
some 
draft ready which is covering:

(1) Aim / Application scenarios for this standard
(2) What is a Biobrick?
(3) Datamodel 1 -- minimal Biobrick information

This should be doable in the remaining time (just think: "yes we can!" :-)

Let's start with (2). The current state of debate is as always here:
http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exc
hange#What_is_a_Biobrick.3F

We have two (related) unresolved questions in this section:

(A) If a Biobrick is defined by its unique sequence, already a minor
variation 
(e.g. silent mutation) of this sequence creates an entirely new biobrick. We
may 
want to create the concept of Biobrick-families on top of the Biobrick or
one 
could introduce a 'biobrick implementation' layer underneath.

(B) Even worse, what happens if I put the exactly same sequence into a
different 
format? Is that a new Biobrick? -- Only then can we include a "Format"
record in 
the minimal data model. For the experimentalist this information is
essential.

Moreover, I think we need a second definition of "Device" (built from 
biobricks). Some of the discussions we had here may overlook that a single 
Biobrick will often *not* encapsulate a self-standing function but will
often 
depend on additional biobricks that are not fused to it on the DNA level and
may 
even be distributed over different cells (e.g. the quorum sensing device). I

think we should treat this with a separate "Device" concept. Some Biobricks
may 
turn out to be self-sufficient devices, most others not. Some functional 
characterizations (Pops-in/out) only make sense for full devices, but not
for 
every single Biobrick.

Comments?
Greetings,
Raik

-- 
________________________________

Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________

_______________________________________________
Standards mailing list
Standards at biobricks.org
http://biobricks.org/mailman/listinfo/standards_biobricks.org