[BBF Standards] Initial Draft Documents for PICA

[Ralph Santos]

Raik,

It is my hope that one can work on a standard to bring before the working group without being seen as trying to discredit, usurp or distract from other efforts.  I hope to contact others who might find the effort of interest who would be willing to provide input and review and possibly participate in other ways, but I would like to think that these things can be done without hurting other development efforts.  I would like to find some way to engage the working group (those who are interested, that is) without interfering with the main discussion or disrupting the priorities you state.  I don't want to present an interference with the group's activities.  If this is the case, please accept my apologies.

Your points are quite valid.  I would like to think some of your concerns are my fault in presenting bits and pieces of sometihng long before they're actually ready for proper presentation.  In my enthusiasm at the workshop I gave myself a week after the meeting to put out some drafts and I didn't even make that target.

It was my hope that the annotation guide provided a very slim biobrick description.  It boils down to five yes/no questions and some simple lists and ordered pairs to describe what's in a brick and how it behaves.  Unfortunately the selection of part descriptions cloud the issue since they were intentionally picked to demonstrate screw cases and expressive range in an attempt to allay concerns that the framework was too simplistic to be of practical use.  I thought that was about as simple as it could be made while still supporting lots of real valid questions and concerns, like being able to classify bricks, query for parts that have certain features or functions or respond to certain signals, etc.  The ontology terms from the perspective of annotators is basically just a pick list for predefined terms.  The whole intent was to arrange things so that annotators and application developers did not need to be cognizant of the ontologies except as a source of terms with standar
d definitions, not to make part builders learn OWL and make every application incorporate a reasoner.  The hope is that the language framework would mostly be a concern for standard maintainers to help give them tools to manage the evolution of the framework as new things get incorporated.

Though it might not be evident in what I've tried to present, I share your desire for a simple basic description that gets developed incrementally over time with the support of data, testing and tools.  It was precisely that desire that led me in the direction of thinking about it as a language, because I wanted to do more than blindly trust that extensions could be made without thinking about how, but to work into the full standard proposal provisions that lay out specific rules for extending part descriptions so developers have readily available options to experiment and develop new annotations or features without worrying whether some tool or server will choke on or corrupt the additions.  Of course this doesn't account for every possible extension scenario, but it can be valuable to provide one or two ready-made options.  (then again, the extension proposals are among the docs I'm still working on).

In any case, it is not my desire to interfere with ongoing working group activities.  I'm working on setting up a sourceforge project to get this out of the way of the group.  I'm sorry for any distraction or disruption I have presented.

---ralf

----- Original Message -----
From: Raik Gruenberg <raik.gruenberg at crg.es>
Date: Wednesday, March 12, 2008 2:39 am
Subject: Re: [BBF Standards] Initial Draft Documents for PICA
To: Ralph Santos <RASantos at lbl.gov>
Cc: standards at biobricks.org

> Hi guys,
> 
> I haven't been attending the workshop. Perhaps my opinion would be 
> completely 
> different if I would have witnessed your discussions and 
> perhaps/likely I am 
> getting all wrong but here is my birds-eye first impression on the 
> PICA proposal 
> from just browsing over the documents:
> 
> I think it fails in several respects:
> 
> 1) It is too complicated. Pulling in all those outside ontologies 
> means you are 
> directly from the start juggling with vocabularies comprising 
> hundreds of terms 
> and relations at extreme detail level. Basically we are starting 
> with more terms 
> than Biobricks. Which also means that two annotators will probably 
> not use the 
> same terms for the same thing.
> 
> 2) It fails to solve the immediate problem at hand. I don't see a 
> suggestion how 
> to communicate a new biobrick to the Registry with the minimal 
> information that 
> we are used to expect already right now (sequence, format, user, 
> experience, 
> chassis, classification, etc)
> 
> 3) It deters outside developers. What may be interesting as a 
> research topic for 
> a group of full-time bioinformaticians who are specialising in 
> ontology 
> building, looks certainly not inviting to a weekend hacker with a 
> funny Biobrick 
> idea (like, say, link Biobricks to Freebase or Facebook).
> 
> I would prefer to start with a very slim core biobrick description -
> - after the 
> discussions we already had on the mailing list, an owl definition 
> of this could 
> be hacked up by two people in 2 days. Any further relations should 
> be developed 
> *together* with the actual data and tools, tested, and may be step-
> by-step 
> incorporated into the core if they turn out to be useful in practice.
> 
> Links to outside vocabularies should of course be possible and its 
> a good idea 
> to borrow concepts or ensure compatibility where appropriate but 
> this shouldn't 
> be the most important goal right now. A "owl:sameAs" link can be 
> added anytime 
> later.
> 
> Greetings,
> Raik
>