[BBF Standards] data exchange issue 1: Abstraction
Deepak Chandran
deepakc at u.washington.edu
Tue Feb 26 14:39:45 EST 2008
If a part can be both a "part" (basic part) and a "device", then the
hierarchy of parts->devices->systems is not quite a hierarchy. Would it
not be more organized to have a solid hierarchy by disallowing such an
overlap?
Further, is it sufficient to define basic parts as 'basic biological
functions than can be encoded as a DNA'? There are lots of things that
one can encode into a single plasmid. The word 'basic' implies that this
function cannot be broken down into sub-functions. A promoter cannot be
sub-divided into two components, but a protein coding region or an
operon can be sub-divided; should these be considered "parts" (basic
parts)? If no, then what are they? If they are devices, then what are
the inputs/outputs of a complicated operon with multiple promoters?
Raik Gruenberg wrote:
> Great summary Reshma,
>
> > 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.
>
> I would add that a device is not always wrapped into a single (composite) part
> but often also distributed over many.
>
> > 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.
>
> I would continue calling a Biobrick a part...
> Looking at:
> http://parts2.mit.edu/r/parts/htdocs/AbstractionHierarchy/
> The lowest distinction between DNA and part is what we are questioning here.
>
> Greetings,
> Raik
>
> 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