[BBF Standards] Notes from Saturday Afternoon Workshop Discussion on White Board
Ralph Santos
rasantos at lbl.gov
Tue Apr 29 17:09:34 EDT 2008
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
>
More information about the Standards
mailing list