[BBF Standards] data exchange issue 1: Abstraction

[Deepak Chandran]

Hello Raik, John, Ralf, and the rest,

I agree that that predictability is important. If we consider the 
analogy of a screw (a "part"), I can look at the size/shape/width/etc of 
a screw and identify whether or not it is appropriate for a particular 
hole. There are certain characteristic features of a screw that allow me 
to do this, i.e. its head-size, length, diameter, etc. I think that a 
BioBrick should be defined similarly. Different types of BioBricks (eg. 
promoter, RBS, coding region) would have different set of characteristic 
features, just as screws and nuts have different characteristic 
features. However, since knowledge about biological parts is still 
expanding, it might be a good idea to keep this list of characteristic 
features flexible, so that it can be modified later.

As for devices (and anything larger than a device), I think the problem 
is quite different. Using an analogy once again, a pulley can be 
considered a device. To describe a pulley, it is not sufficient to say 
"a pulley is composed of a rope and a wheel". I think that the integral 
part is to describe exactly how the rope is connected to the wheel, and 
where the input and output forces are. Similarly, a biological device 
should contain a list of the components and how they are connected 
together. The input/output concept of a biological device is a little 
different because there is always the possibility of cross-talk. I am 
not sure how cross-talk can be represented in the input/output mode of 
abstraction.

--Deepak

Josh Perfetto wrote:
> 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
>
>