[BBF Standards] data exchange issue 1: Abstraction
Josh Perfetto
josh at maulikai.com
Tue Feb 26 18:20:06 EST 2008
I think that as a general statement the phrase "basic biological function"
is fine, but what would be most helpful in the standards setting is
precisely defining standardized basic functions which parts can have, and
that properties which must be defined for parts belonging to these
functions. There is already start at this in the parts registry, however
this needs more refining. I.e. if you look at "regulatory region" parts,
you'll see some repressible regulators, and inducible regulators, but a huge
number of "other regulators" (most of the regulators are in this category).
I think that by defining what these functions are and how parts exhibiting
these functions are to be specified, we can define a "standard part" as a
part fitting into one of these well-defined categories.
If a particular part like a promoter met the definition of a device on its
own, I don't see this as a big problem as long as it is considered as two
separate entities, with a separate part ID and device ID, as the details
needed to define it at the part level and at the device level would likely
be different (for example, the device definition might have an ordered
"composed of" relation which points to the part ID, defined PoPS out value,
etc). Viewed from this angle, this is actually not a violation of any
hierarchy, since the nodes in this information hierarchy are in fact not
identical, even though if you ordered DNA corresponding to the part ID, and
to the device ID, you may in fact have identical pieces of DNA.
-Josh
-----Original Message-----
From: standards-bounces at biobricks.org
[mailto:standards-bounces at biobricks.org] On Behalf Of Deepak Chandran
Sent: Tuesday, February 26, 2008 11:40 AM
To: standards at biobricks.org
Subject: Re: [BBF Standards] data exchange issue 1: Abstraction
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/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
>>> >>>>
>>> >>>> --
>>> >>>> ________________________________
>>> >>>>
>>> >>>> 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
>>
>>
>>
>
>
_______________________________________________
Standards mailing list
Standards at biobricks.org
http://biobricks.org/mailman/listinfo/standards_biobricks.org
More information about the Standards
mailing list