[BBF Standards] Registry exchange format

[Timothy Ham]

Hi Raik,

You are absolutely right, a shared infrastructure would have many
advantages. I have taken a closer look at django and am very
impressed. As I am using python already, it shouldn't be too hard to
transition into it, but  I have to study it some more.

Regards,
Tim


On Sun, Apr 13, 2008 at 11:48 PM, Raik Gruenberg <raik.gruenberg at crg.es> wrote:
> 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
>  ________________________________
>