[BBF Standards] outrule emergent properties

Fri Feb 1 16:18:09 EST 2008

That was exactly what I was thinking, much like in VLSI.  It may be a while
until we can realize this, but without processes we are likely to see a
limit to the size of useful systems we can build.  Even in EE there is not
perfect compartmentalization with design rules saying how close things can
be, though admittedly the situation in biology is far worse.  Actually if we
can truly achieve success at the parts level-specifying what each part does
and its interactions with others, some of this may follow naturally.

By NxN I was referring to the number of tests needed to state the
compatibility between any 2 parts in a parts catalog (actually this is NxN/2
but still O(N^2)).  The problem of emergent properties between multiple
BioBricks is much worse as you mention-I can't see how this is going to be
solved by exhaustive testing.  I'm not really sure how common a problem this
is as I mostly played with small systems so far.  What types of emergent
properties have others been seeing?

-Josh

From: standards-bounces at biobricks.org
[mailto:standards-bounces at biobricks.org] On Behalf Of Markus Schmidt
Sent: Friday, February 01, 2008 8:59 AM
To: standards at biobricks.org
Subject: Re: [BBF Standards] outrule emergent properties

The combinatorial power of N biobricks is actually not NxN, but factorial:
N! 

with e.g.  20 biobricks you have a total of 2*10 to the power of 18 ways of
possible interaction. And by that we don't talk about things like pH and so
on (which prohibits a system that modifies the pH, and so on)

The lack of physical separation of signals, as is the case in
microelectronics, could be one of the biggest limitations to the
standardized bioparts concept. 

Ways to limit the combinatorial power for testing are necessary, as you
said.

Actually this could lead to a design process where you operate e.g. on a
system level and design your nice circuit, but depending on the circuit the
design computer programme chooses one of different devices (and finally
parts) that interact in the way you like. That means that one system can be
realised by multiple devices and a device by multiple parts. This is clearly
not perfect, and not what is envisaged,  but a possible and path-dependend
solution. 

Markus

Am 31.01.2008 um 23:34 schrieb Josh Perfetto:

Makes sense.  Two things on plays nice:

1.       While it may not be currently possible to say with certainty which
parts will work well together through modeling, NxN combinatorial testing is
not practical.  It is therefore of great value to know which parts would not
be expected to work together through the use of modeling.  Information to
help us do that (i.e. information about the small molecules used internally
for starters) should be included in the data model of a part.

2.       I'm not entirely sure about this, but I think we should consider
modeling part interactions, especially when empirical data is involved, as
separate entities than the parts themselves.  We also need to think about
how to model such interactions-is it binary works/doesn't, or are there
caveats that should be incorporated into the model?  When an interaction is
defined, are there conditions (i.e. pH range etc.) that should be attached
to that interaction definition?

-Josh

From: Julius B. Lucks [mailto:julius at younglucks.com] 
Sent: Thursday, January 31, 2008 10:30 AM
To: Raik Gruenberg
Cc: Josh Perfetto; standards at biobricks.org
Subject: Re: [BBF Standards] functional composition of BioBrick parts?

Hi All,

I agree with the separation of the task at hand:

1) What is the minimal data set needed to describe a biobrick? (including
What 

is a Biobrick?)

2) What is the best format / technology for exchange?

But I would rephrase #1 to say

1.) What is the data model needed to describe a biobrick?

Once the data model is firmly in place, the format should follow as the one
that best implements that data model.  For example, if we settle on an
RDF-like 'everything is a relationship triplet' approach, then some format
that can handle these triplets would be most appropriate.  In addition, with
a model like this, there are XML-based and more human-readable formats that
can both implement the model equally well.

I think that tying our selves to a format too early will make us not have a
clear model in mind, and will cause us to hack up the format.  It is best to
do model, then format.

So things to think about in a model are what type of relationships to we
want to convey?

* Inheritance (where was a particular part derived from, and by who = link +
data)

* Characterization (something quantitative about that part by itself = data)

* Plays well with others (what other parts can this one interact with - with
possible data associated with this interaction = link + data)

* ...

Other ideas?

Cheers,

Julius

It would be good if we could capture the main suggestions and arguments on a

wiki page -- I would be happy to take care of that but didn't manage to
create 

one on http://parts.mit.edu/registry. Could someone with the permissions
please 

add some empty page to the community portal box (like the ones for the other
RFC 

groups)?

Anyway, we have started discussing 2). Suggestions were roughly:

a) create a new XML format

b) adapt existing CellML, SBML XML formats

c) create a custom file format

d) use Turtle/N3 notation for semantic web documents

If we get a wiki page, we could put up a little section on each possibility
and 

collect pro's and cons.

Does anyone have the needed permissions to create a page on the registry
wiki? 

Or perhaps i just overlooked the right link?

Greetings,

Raik

Josh Perfetto wrote:

My initial instinct is also that a separate ontology will be needed to

properly describe BioBricks.  However I would expect it would be both

-Josh

Yes definitely, there are a bunch of new ontologies coming up in systems 

biology and I think they will have some relevance here, though I suspect 

there could still be a need for something specifically related to 

synthetic biology.

The existence of these ontologies makes human readable formats difficult 

to deal with and XML is the proper place for them. However, as humans, 

we also need a human readable face and I think there has to be some kind 

of two way world, or at least each software application will present 

parts and devices in their own human readable format even if the 

back-end is ultimately XML. This is the way SBML and CellML work. We are 

Herbert Sauro

On Wednesday 30 January 2008, "Josh Perfetto" <josh at maulikai.com> wrote:

Yes, I think ease of processing and the representational power of the

format is more important nowadays than human readability.  We need

standard representations that can be adopted by software developers

to build powerful processing systems for BioBricks.  We can expect

such software to present a more human-usable interface to manipulate

the BioBricks than a file format ever could.

Have you ever heard of these 'ontologies' that have jumped up?

http://www.biomodels.net/

http://obofoundry.org/

-- 

________________________________

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

*-----------------------------------------------------*

Dr. Markus Schmidt

International Dialogue and Conflict Management

Abt-Karlg. 19/21, 1180 Vienna, Austria

office: +43 1 9900811

mobile: +43 660 6856623

email: markus.schmidt at idialog.eu 

www.idialog.eu

*------------------------------------------------------*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://biobricks.org/pipermail/standards_biobricks.org/attachments/20080201/f3293da9/attachment-0001.html 