[BBF Standards] data exchange issue 1: Abstraction

[Ralph Santos]

Hi Raik,

I appreciate your efforts to refocus the discussion.

I've been thinking about this subject and have I think the very 
arguments you cite make a case for taking an alternate approach to 
biobrick definition, one which focuses less on nailing down the internal 
composition of a biobrick and focusing more upon its external 
behaviors.  Your example (A) is a good example of a real-world situation 
exposing the limitations of defining a biobrick as a specific sequence.  
It's worth mentioning that defining biobricks as a DNA sequence 
inherently creates problems for those defined as RNA (BBa_J01141 et. al.).

Other virtues from focusing on behavior over composition is that it 
actually kills two birds with one stone:  Along with defining a biobrick 
in a way that avoids tying to a specific composition, it also the 
behavioral view is easily scalable from individual biobricks to biobrick 
assemblies and it gives us a foundation for thinking about querying 
biobricks, which can be used to inform both a query language and data 
exchange standards.

Considering the notion of a "Device", I'd say it would be a good idea to 
focus on the concept of a "Device" unbound to composition and let that 
subsume the biobrick concept.

I apologize if this seems like an about-face when one considers my 
initial support for the first hierarchy you posted.  It's not my intent 
to contradict that original idea.  I believe that all the goals it 
outlines are still valid.  I think we need all the things that are 
defined (standard for minimal information, a definition for biobricks, 
classification and characterization info), and I appreciate that you 
posted it, since my shift in perspective benefited greatly from studying 
what's been posted so far (and for what it's worth, thank you for 
filling out the examples for intrinsic and extrinsic classification, 
they're much better than what I could think of).

---ralf


Raik Gruenberg wrote:
> 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/Exchange#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
>
>