[BBF Standards] data exchange issue 1: Abstraction
Ralph Santos
rasantos at lbl.gov
Tue Feb 26 22:10:34 EST 2008
Reshma,
Thanks for posting this, it clarifies a lot. Do you think it would be
appropriate to add your answer to Herbert's questions to the biobrick
definition under "What is a biobrick?" on the web page? I think your
answer adds some useful points and important details.
---ralf
Reshma Shetty wrote:
> Hey all,
>
> First off, great discussions going on on the list. Specifically, to
> answer Herbert's questions ...
>
> *A biological part is a DNA sequence that encodes a basic biological function.
>
> *Biological parts that conform to prescribed technical standards are
> standard biological parts.
>
> *Parts that conform to the BioBrick assembly standard are BioBrick
> standard biological parts. Additional technical standards defining
> BioBrick standard biological parts will be set via an open standards
> setting process led by The BioBricks Foundation.
>
> [Note: parts do not include either the plasmid that propagates that
> part or sequences whose function is to help physically compose parts
> (e.g., the BioBrick prefix and suffix). Parts can come in different
> formats (the BioBrick standard, the BamHI/BglII standard promulgated
> by folks at Berkeley, no "scar" sequences whatsoever because of direct
> synthesis etc.)]
>
> *Devices are combinations of one or more parts that have a
> human-defined function. I prefer an even more specific definition in
> which devices not only have human-defined function but also are
> functionally composable using common signal carriers such as
> transcription rate (PoPS), translation rate (RiPS), phosphorylations
> per second etc. Devices can have an input of a common signal carrier,
> an output of a common signal carrier or both. For instance, a
> promoter is both a part (its basic biological function is to initiate
> transcription) and a device (its human-defined function is a PoPS
> source and it produces the common signal carrier PoPS). A
> transcriptional inverter is a device since logical "NOT" is a
> human-defined operation and an inverter has an input of PoPS and an
> output of PoPS.
>
> Some confusion arises because in the Registry of Standard Biological
> Parts, everything with a BioBrick part number is called a part. The
> Registry distinguishes between basic parts (equivalent to "biological
> part" definition above) and composite parts (combinations of two or
> more basic parts). Based on the definitions above, a device can be
> either a basic part or a composite part. But not all basic or
> composite parts are devices.
>
> It is not clear whether we need to reconcile the Registry's
> terminology with that of parts versus devices described above or if
> both sets of definitions can stand in parallel since they serve
> slightly different purposes.
>
> -Reshma
>
> On Tue, Feb 26, 2008 at 11:12 AM, Herbert Sauro <hsauro at u.washington.edu> wrote:
>
>> Drew, I'm not try to be difficult here, but can you also indicate what
>> you mean by a basic biological function. The other thing that confuses
>> me is what is the difference between a device and a part because if a
>> part can also be a composite then what is a device?
>>
>> Herbert
>>
>>
>>
>> Drew Endy wrote:
>> > 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
>> >
>> >
>> > _______________________________________________
>> > 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
>
More information about the Standards
mailing list