[BBF Standards] Registry exchange format

[Raik Gruenberg]

Hi Tim,

Timothy Ham wrote:
> Hi Raik,
> Thanks for your reply.
> 
> I have looked at brickit's data model (the nice pic on the website),
> and it looks great. But because we (JBEI)  are also dealing with
> adopting legacy systems (all the old constructs are not in biobricks,
> and will not be for a very long time), so some of your assumptions in
> the tables do not apply. For example, a host strain may have a
> selection marker on the genome.
> I will study the source code you pointed out more carefully.

well, the whole point of a data exchange format is that we don't all have to use 
the same applications / registry ;-) On the other hand, it would be good to 
promote a shared open source infrastructure that can be easily extended and 
adapted to the different situations. The Python/Django/OpenSource architecture 
of brickit should allow for that. And with the new Google App Engine (which is 
basically a google fork of Django) one could even cut out the vmware or 
web-server requirement all together. (nice side effect: afterwards you can call 
yourself an google app engine expert and open source project manager ;-) ) On 
the other hand, brickit itself contains nothing you couldn't re-create in a week 
or two from scratch. I could so far only dedicate some weekend time to it, which 
limits everything of course.
I guess you are not going to be at the meeting in Seattle, right?

> 
> As for overlapping Sequence with packaging format, I remember a debate
> some time ago where someone thought having it overlap had some neat
> advantages. I didn't want to exclude those people from storing their
> stuff in biobrick format. Or having the machine confused when the the
> desired sequence overlaps with the packaging.

Is there any example format out there doing that? If not, I would rather wait 
until it comes up. Formats may put restrains on the Biobrick sequence. Perhaps 
the overlap can be dealt with as a constraint rather than in the data format?

> 
> I think URI is a great idea. UUID is actually for internal tracking.
> If used in exchanges, it will prevent version collisions. Users should
> never see UUIDs.
> 
> I have to disagree with you on composite parts. Sadly, biological
> contsructs are mutable. So when I sequence a composite part, and find
> that it's different from the original parts, but it's good enough for
> me, where do I record it? It is often the case that what you have is

Mutations within composite parts... very good point indeed. We were talking 
about version tracking -- every modification creates a new Biobrick which would 
end up in the same version family as the original one. This may offer an 
alternative solution. The advantage of composite sequences is that you stay 
connected to annotation updates and corrections and specifications of the basic 
parts.

> slightly different from what you think you have. That is the basis of
> my emphasis on unique dna=part.

we agree on the unique dna=part. a unique sequence of basic biobricks still 
translates to unique DNA though (because the basic parts have a unique sequence 
each). But again, the mutation argument is a good one.

> 
> As for sample tracking, that is a very location specific thing so I
> don't understand the relevance of it in an exchange format.
> 
> Oh, I really don't know much about the advantages of RDF vs xml. Maybe
> you can educate me.

Mhm, that has to wait for a later mail, I've got to run now. In short: RDF is a 
W3C standard layered on top of XML which annotates data with shared ontologies 
and allows data to refer to each other across documents. It is schema-free. That 
means I can extend your data and ontology on my server and your documents can 
re-import the extended data etc.
Sounds more complicated than it is though (which has been the main hurdle of it 
for a while).

Greetings,
Raik

> 
> Tim
> 
> 
> 
> 
> 
> 
> 
> On Fri, Apr 11, 2008 at 11:05 AM, Raik Gruenberg <raik.gruenberg at crg.es> wrote:
>> Hi Tim,
>>
>>  great to get a signal from your new institute!
>>
> 
> 

-- 
________________________________

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