[BBF Standards] data exchange issue 1: Abstraction

[Drew Endy]

A BioBrick part is any basic biological function that can be encoded  
as DNA.

More specifically, I believe that there are already parts in the  
Registry encoding components from the Fim system, as well as sites  
recognized and acted on by invertases.

I'll try to dig up the part numbers once I get back from teaching class.

Expect more emails from me today about Saturday's workshop too!



On Feb 26, 2008, at 10:59 AM, Deepak Chandran wrote:

> Concerning systems such as Fim, I don't think that they are individual
> parts. Rather, they are a composition of parts (i.e. "devices").  
> Hence,
> the whole Fim system should not be stored as a single part. Other
> systems, such as the Sin operon, also have multiple coding regions  
> with
> promoters in between them -- I don't think that they should be
> considered "parts".
>
> Ralph Santos wrote:
>> Sorry, I should have responded initially by responding to your  
>> direct question rather than trying to rethink everything.   
>> Regardless of what you think of alternative strategies, the current  
>> representation should be explored fully, and pretty much any data  
>> exchange system regarding biobricks has to deal with sequences at  
>> some point.
>>
>> Considering the unresolved questions:
>>
>>> From the way I read your points, it seems that whether points (A)  
>>> and (B) are related depends upon how one defines the relationship  
>>> between a biobrick and its sequence.
>>
>> With part (A), it occurs to me that there's several ways to deal  
>> with the unresolved question.  One can directly attack it and  
>> resolve it here and now, or one can find a way to allow the process  
>> to move forward without resolving it.
>>
>> As you rightly point out, defining a biobrick in terms of its  
>> sequence raises a bunch of issues, but is it absolutely necessary  
>> to define a biobrick in terms of its sequence?  If we define the  
>> standard to demand this assertion, then the answer is yes, but one  
>> can define the data exchange process so that one can dance around  
>> the issue.
>>
>> One simple way to dance around the issue is to stipulate that  
>> biobrick data exchange systems must assign every sequence its own  
>> accession ID so that it can be identified independently from the  
>> biobrick with which it's associated.  For the sake of simplicity,  
>> we can bury this ID so that you don't have to deal with it if you  
>> don't want to, while still providing some means to get these  
>> sequence ID's if you want them.
>>
>> In this scheme, the rules for managing biobrick sequences would be  
>> governed by the principle that you should be able to pretend  
>> there's only one sequence associated with a biobrick.  So no matter  
>> how many sequences are associated with a biobrick, only one will be  
>> regarded as primary, to be returned with standard queries.  Digging  
>> into the other sequences should require some sort of specialized  
>> call specifically defined to retrieve these other sequences.  Of  
>> course, deleting a biobrick should imply that all of the sequences  
>> associated with it are deleted.
>>
>> I guess this solution most closely resembles what you refer to as a  
>> 'biobrick implementation' layer underneath.  I like this way of  
>> handling it because it allows folks who wish to assume a simple one- 
>> to-one relationship between bricks and sequences to think that way,  
>> but it allows the distinction to be monitored and dealt with behind  
>> the scenes.
>>
>> Having said all that, there is a situation worth thinking about,  
>> because it favors the family concept and it forces one to think  
>> about what the sequence means.  There are systems like the "fim"  
>> system in E. Coli:
>>
>>  http://jb.asm.org/cgi/content/full/182/10/2953
>>
>> Basically it activates transcription for one of two genes depending  
>> upon its orientation.  If one thinks of a sequence as defining a  
>> molecule, something like the fim system causes some headaches.  Two  
>> people could put in what amounts to the same molecule in two  
>> different orientations and the system would not be able to  
>> recognize it as such.  Of course if one imagines biobricks being  
>> made incorporating multiple fim elements one can see the number of  
>> possible sequences for the same brick growing combinatorially.  It  
>> may be rare enough that the issue may be safely ignored (I don't  
>> know myself).  One may wish to use the brick family idea to try and  
>> capture all the possible sequence states or configurations.
>>
>> If in part (B) by "format" you're referring to the actual file  
>> format (i.e. FASTA vs. GENBANK vs. EMBL etc.) I'd prefer to see us  
>> deal with that as a matter of presentation to the user, and not  
>> consider sequence formatting as part of the definition of a  
>> sequence (or biobrick for that matter).  As far as tools go, It  
>> would simplify things if we focused on tools doing most of their  
>> processing in a single canonical format, and stipulate that there  
>> will be conversion tools to preprocess inputs into that canonical  
>> format and postprocess them however the user wishes to see them.   
>> That would also fit well with the IETF's principle of being liberal  
>> with what one accepts for input, being conservative with what one  
>> emits for output.
>>
>>
>>
>> ----- Original Message -----
>> From: Raik Gruenberg <raik.gruenberg at crg.es>
>> Date: Monday, February 25, 2008 3:18 pm
>> Subject: [BBF Standards] data exchange issue 1: Abstraction
>> To: standards at biobricks.org
>>
>>
>>> 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
>>>
>>> -- 
>>> ________________________________
>>>
>>> Dr. Raik Gruenberg
>>> http://www.raiks.de/contact.html
>>> ________________________________
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Standards at biobricks.org
>>> http://biobricks.org/mailman/listinfo/standards_biobricks.org
>>>
>>>
>>
>> _______________________________________________
>> Standards mailing list
>> Standards at biobricks.org
>> http://biobricks.org/mailman/listinfo/standards_biobricks.org
>>
>
> _______________________________________________
> Standards mailing list
> Standards at biobricks.org
> http://biobricks.org/mailman/listinfo/standards_biobricks.org