[BBF Standards] functional composition of BioBrick parts?

[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

 

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