[BBF Standards] data exchange/pobol: BiobrickFamily versus Biobrick

Raik Gruenberg raik.gruenberg at crg.es
Sun Jun 1 16:07:33 EDT 2008


The current Pobol draft defines a BiobrickFamily as something that is different 
from a Biobrick but can have the same properties (except sequence) so that it 
can provide common annotations for a group of related Biobricks. I think, it 
would be more intuitive to unite the BiobrickFamily and the Biobrick concept 
under one roof.

The basic principle would remain the same -- 'subBiobrickOf' relations would 
group Biobricks into flexible hierarchies but each group / family would itself 
already be considered as a (abstract) Biobrick. Actual Biobricks could be 
distinguished from the rest by classification as either BasicBiobrick or 
CompositeBiobrick.

IMO, this would simplify the life of developers (e.g. no separate forms for 
BiobrickFamilies and Biobricks). Registries would have the choice to query 
against existing Biobricks and more abstract groups of Biobricks at the same 
time or separately. Tools based on triple stores or semantic web parsing 
libraries would benefit automatically, but also tools based on more classic 
back-ends should be able to handle this with little effort.

A tentative class hierarchy could look like this (please switch your e-mail view 
to courier or another fixed-width font):
option A

          Biobrick (abstract)
          /      \
         /        \
BasicBiobrick    CompositeBiobrick
(sequence)       (sequence of BasicBiobricks)

Or more sophisticated option B:

          Biobrick (abstract or not)
          /      \
         /        \
BiobrickGroup    BiobrickImplementation
(abstract)       (single instance guaranteed)
                        /         \
                       /           \
             BasicBiobrick        CompositeBiobrick


Specialized Biobrick classes, e.g for Vectors and SelectiveMarkers, could still 
be derived from the top Biobrick concept. A *group* of Biobrick Vectors would 
then look like this:

:pSB1
    rdfs:type  BiobrickGroup;
    rdfs:type  BiobrickVector.

That means it would combine the group type with the Vector type. An *actual* 
Vector Biobrick would instead combine the CompositeBiobrick type with a the 
Vector type:

:pSB1AC3
    rdfs:type  BiobrickComposite;
    rdfs:type  BiobrickVector;
    bbf:subParts  [ BBa_P1010, BBa_I0001, BBa_J1000, ...];
    bbf:sequence  "ATG...".

So there is no need to duplicate concepts for groups and single Biobricks 
because we can mix in special-purpose types by multiple inheritance.

Any opinions on this proposal? If positive, any preferences for option A or B?

Greetings,
/Raik


-- 
________________________________

Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________



More information about the Standards mailing list