[BBF Standards] Notes from Saturday Afternoon Workshop Discussion on White Board

Thu May 1 00:32:07 EDT 2008

Seeded
http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/PoBoLwith
the basic test cases and medium-range goals.

Mac

On Tue, Apr 29, 2008 at 5:09 PM, Ralph Santos <rasantos at lbl.gov> wrote:

> Vincent,
>
> I think your suggestion is a good one.  It would be quite valuable to
> have a test data set established.  In fact, it has uses beyond
> challenging the data model.  It could be used to.  Also, as they would
> be defined outside of any repository it would form the beginnings of a
> clear test of and standard for interoperability.  If we want to have
> multiple independent repositories, the functionality of individual
> repositories becomes less important than consistency of operation across
> different repositories.  So defining the test in terms of responses to a
> reference data set, it becomes a consistent target anyone can shoot for,
> and it keeps any one repository or any one platform from dominating the
> field excessively.
>
> That said, to properly establish a test set it would help to know the
> protocol for interaction, since it would clarify how the test data
> should be formatted, and how both success and error responses would be
> presented.
>
> However, there's no reason one can't continue the outline you've started
> even ahead of that.  The outline as you've started in your original
> message would provide a tangible set of use cases which would be
> extremely valuable to both figure out and document what we want out of a
> protocol, and by filling them out as test cases it would build upon the
> capability questions started on the standards wiki as well as providing
> material for evaluating actual implementations.
>
> So, to build upon the outline you started:
>
> For category (I), your example has clear implications for looking up
> pre-existing parts, but what about registering a new part?  It's not
> clear how to do this in POBOL since the part ID is required in the data
> model, which leads one to believe that absent any other stipulation the
> part ID would be a required field in any POBOL exchange document
> format.  There seems several ways to resolve this:
> (1) Relax the exchange document format.  Registering a part involves
> leaving the part ID blank, successful registration returns the assigned
> part ID.
> (2) Part ID requests are done under a separate transaction.  This may be
> an "official" part ID (i.e. BBx_X######) or some other accession ID, be
> it provisional or permanent (as suggested at
> http://parts.mit.edu/registry/index.php/Help:Registry_2.0 among other
> places)
>
> For category (II), returning composite sequences containing a specific
> Biobrick is a clearly defined test, but I'm less sanguine about the
> promoter case.  I realize it's important to be able to support that kind
> of query, but that's high enough level that it's less a direct test of
> the POBOL data model than a higher registry function.
>
> For category (III), there's a couple of different ways one could share
> parts.
> (1) Don't try.  Registries only know their own parts.
> (2) Share ID's with other registries but not data.  Non-owning
> registries forward requests to home registry.
> (3) Share ID's and data.  Non-owning registries have option to forward,
> share cached copy, or both.
> It's worth noting that different registries might pick to do any of
> these for their own reasons.  One might refuse to cache or forward for
> policy or traffic reasons, or out of simple laziness.  Another might
> wish to act as a "one stop shop" portal and try to mirror everyone
> else.  This brings to mind a couple of thoughts.
> --> A repository interaction protocol might want to include some way to
> declare what features it supports (think of the "Accept" headers in HTTP).
> --> Forwarding and caching might lead to situations complicated enough
> that we may want to establish conventions to preclude certain kinds of
> erroneous or even malicious behavior.  For instance, there are cases
> where applications have been tricked or co-opted to participate
> unwittingly in DDOS attacks (notably DNS servers have been used in
> several such cases).
>
> However, I can't think through all the ramifications but having a good
> outline from which to build test cases would be valuable, since it would
> allow a lot of eyeballs to check it out and think it through from a
> variety of different angles.
>
> Could we start this list someplace on the standards wiki?
>
> ---ralf
>
>
>
> Vincent Rouilly wrote:
> > Hi All,
> >
> > alongside the development of a data model for BioBrick parts, would it
> > be useful to work on a series of test cases to evaluate each aspect of
> > the standard.
> >
> > Those test cases could be designed independently of the data model,
> > with only in mind the practical and functional requirements.
> > Then, those test cases would be used to challenge the proposed data
> > model to make sure that it fulfills our needs.
> >
> > In terms of methodology, it would be very close to what engineers use
> > when doing unit testing.
> >
> > Later, those same test cases could also be useful to assess the degree
> > of compliance of a given implementation with regards to the agreed
> > standard.
> >
> > At this point in time, I am not too sure about the structure to adopt,
> > any ideas ?
> > For now I can only imagine 3 main categories:
> >
> > *I/ Data Entry test cases:*
> > ex:  each BB should should have a unique ID, or list
> > of required/optinal fields.
> >
> > *II /Search test cases:*
> > ex: return all BB being a constitutive promoter in E.Coli, or return
> > all composite sequences having a specific BB
> >
> > *III/ Data Flow and Data Exchange test cases:*
> >
> > Environment 1:  1 Person /  N Parts / 1 Registry
> > - ...
> >
> > Environment 2:  X Persons /  N Parts / 1 Registry
> > - ...
> >
> > Environment 3:  X Persons /  N Parts / M Registries
> > - Registry 1 wants to import n1 parts from Registry 2
> >
> > best,
> >
> > Vincent.
> >
> >
> > On 28 Apr 2008, at 15:41, Raik Gruenberg wrote:
> >
> >> Hi Drew,
> >>
> >> this was more of an appetizer, we are in the process of preparing a
> >> better draft. In brief, the data model will provide a  (1) *minimal*
> >> description of a Biobrick and the DNA contained in an actual Sample
> >> and (2) a way to group Biobricks into families.
> >> The idea is to lay the foundation but leave things open for extension
> >> with more specialized vocabulary and data.
> >>
> >> stay tuned...
> >> Greetings,
> >> Raik
> >>
> >> On Mon, Apr 28, 2008 at 3:02 PM, Drew Endy <endy at mit.edu
> >> <mailto:endy at mit.edu>> wrote:
> >>
> >>     Mike,
> >>
> >>     Could you provide a one paragraph narrative summary of what the
> >>     purpose of this standard is?  Something that would help frame or
> >>     direct any comments or discussion?  Also, where there any specific
> >>     questions or issues that came up that you would like feedback on?
> >>
> >>     Thanks,
> >>     Drew
> >>
> >>
> >>
> >>     On Apr 27, 2008, at 2:22 PM, Michal Galdzicki wrote:
> >>
> >>     > Attached is a pdf of a data model, which was discussed as a
> group.
> >>     > Please make comments and discuss.
> >>     > mike galdzicki
> >>     > <BioBrock proposed data
> >>     > model.pdf>_______________________________________________
> >>     > Standards mailing list
> >>     > Standards at biobricks.org <mailto:Standards at biobricks.org>
> >>     > http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >>
> >>
> >>     _______________________________________________
> >>     Standards mailing list
> >>     Standards at biobricks.org <mailto:Standards at biobricks.org>
> >>     http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >>
> >>
> >> _______________________________________________
> >> Standards mailing list
> >> Standards at biobricks.org <mailto: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
> >
>
>
> _______________________________________________
> 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/20080501/64a2fb33/attachment.html 