[BBF Standards] Sequences and Formats and Devices, oh my! [Re: data exchange issue 1: Abstraction]

[Ralph Santos]

Ah, now I see what you mean by format, and I see I misunderstood what 
you meant by a device the first time around as well...

I think the way the community talks about and thinks about biobricks 
works against basing a biobrick definition in its sequence.  Look at the 
parts registry itself.  You don't look for a biobrick by pasting a 
sequence into a search box like on a BLAST web page, you navigate it by 
having a particular function in mind and searching on that.  The whole 
concept is about packaging something a particular function or behavior 
in an easily handled format.

But one has to consider how one defines a biobrick and how one handles 
biobrick ID's as two separate questions.

I think it's easiest to think of a Biobrick as a transformation of some 
sort which takes a pre-existing functional unit of DNA and packages it, 
so one can think about the 'raw' and 'packaged' sequence of a biobrick.  
Another way to talk about it is one can borrow from email terminology 
and think of the format as the 'envelope' of the biobrick and the 
functional part can be thought of as the body.

Actually, there's a possibly useful analogy there.  In email systems, 
the programs are divided into MTA's and MUA's, message transport agents 
and message user agents.  The message envelope (the headers) are free to 
be handled and manipulated by the mail system, but the responsibility of 
MTA's is to keep the message body unchanged.  MUA's are free to 
manipulate the message body for reformatting, printing, etc.

Having said all that, there's a complicating real-world factor, which is 
the physical existence of biobricks in old formats in freezers.  They'll 
be associated with the current ID.  It seems there are  several options 
to resolve the matter:

(1) Associate the ID numbers with the precise sequences
* pro: ID's of classic biobricks keep their identity
* con: same function registered under multiple ID's for repackagings in 
different formats
* con: forces folks who've repackaged existing bricks in non-classic 
formats to reidentify their samples

(2) Biobrick ID's associated with function
* pro: functional classifications of biobricks remain the same
* con: will lead to mixups between people because formats might not match

I think (1) is the most pragmatic alternative because although we think 
about biobricks functionally, one must still think about pre-existing 
biobrick ID's written on tubes in freezers and buried in lab notebooks.  
One could salvage or recapture (2) by coming up with a new "function 
code" to ascribe an ID purely to a biobrick's function or behavior, but 
at least at this point the whole thing is new enough and complicated 
enough that we might be better off waiting a while before we try to 
precisely codify biobrick functions.

---ralf