[BBF Standards] Questions about functional composition, functional definition, data exchange

[Ralph Santos]

I have several questions about an earlier discussion thread, and I 
suppose it centers around this definition from Raik Gruenberg's email of 
4 February ["Biobrick data exchange format"]. He writes:

------- 8< -- cut here -- 8< --------

For data exchange purposes 
we adopt the following draft:

* BioBrick™ are standard DNA parts that encode basic biological function.
* A BioBrick has a unique DNA sequence.
* Basic parts are defined by this DNA sequence.
* Composite parts are defined as "sequence" of Basic BioBricks, along with 
intervening "scar" sequences.


------- 8< -- cut here -- 8< --------

the discussion about data exchange that has followed since (at least as 
far as I have followed it from digests and archives) seems heavily 
focused on describing the specifics of biobricks and paying less 
attention to providing a workable abstraction of biobricks. To 
illustrate what I mean, consider the difference between two part 
descriptions: JC Anderson's library of tuned promoters (BBa_J23100) 
versus the signaling part Drew Endy cited earlier today in a discussion 
of input/output (BBa_F2620).

Notice how BBa_J23100 describes (elegantly, if I might add) the 
relationships among the parts in the family, there is little explicit 
mention of its behavior which is separable from the actual composition 
of the parts beyond the mention that the part is a promoter in the part 
title. On the other hand, BBa_F2620's part description is mostly about 
its external behavior. F2620's page lays out a simple abstraction on 
several levels quite elegantly using the set of figures at the top: on 
the left a simple citation of input and output, at center a black box 
graphical representation relating input and output leaving the part 
itself completely abstract, and at right a graphical overview of the 
part's internal composition.

While it is critical to effectively describe the internal composition of 
parts, it seems equally critical to provide an abstraction allowing 
users to completely abstract a part away and focus on its behavior in 
terms of some external job to be done. Both have their place in an 
engineering community. By way of analogy, consider the two attached 
diagrams both describing NAND gates taken from the ON Semiconductor TTL 
data book (shamelessly acquired from the following URL):

http://ece-www.colorado.edu/~mcclurel/ON_Semiconductor_LSTTL_Data_DL121-D.pdf

"74LS00_circuitdiagram.png" is a perfectly reasonable description of a 
NAND gate describing its behavior in terms of discrete components, for 
those who need to pay careful attention to the analog behavior of a 
circuit using one of these gates. On the other hand, 
"74LS00_chipdiagram.png" is a completely abstract description where the 
"NAND" gate symbol (familiar to those who have studied digital design) 
would be more of use to an engineer actually trying to use one of these 
chips (or, more generally, any digital designer trying to put together a 
system needing some combinatorial logic). The "NAND" symbol says nothing 
about the internals but is in fact intimately related to the other 
diagram, at least for those components built by ON semiconductor.

Anyhow, back to the questions. It seems that to address the data 
exchange issue one must not only be able to describe parts in a 
machine-processable fashion, but one must also be able to describe the 
parts one has in a way more similar to BBa_F2620, and furthermore do it 
in a way that is machine-processable so that users could mechanistically 
query for parts functionally compatible to a part of interest or for 
particular dynamic behaviors. I don't wish to detract from current 
efforts, but I just wanted to make sure this matter stayed in the 
discussion.

Come to think of it, the whole matter of data exchange sort of begs the 
question of who is exchanging data and what those people are attempting 
to accomplish. Beyond the definition of a biobrick, could the BBF data 
exchange standards articulate the tasks and scenarios it is trying to 
cover with its data exchange standards and how it's trying to realize 
them? It would be useful not only to define what the standards want to 
accomplish, but help people understand not only the thinking that goes 
into the standard but help describe a line of attack for how the 
standard may be put together and help focus thinking on the matter and 
allow others to pitch in. That way as the scenarios become clarified it 
becomes clearer what the requirements are to get the job done and as the 
standard evolves it can be easier to check the standard against those 
requirements and see how things are developing.

---ralf