[BBF Standards] Initial Draft Documents for PICA

[Raik Gruenberg]

Mea culpa Ralph,

my intention was to polarize and spark some debate not to attack anyone in
person. The way I (mis)understood the draft, I thought this was the general
conclusion of the workshop and I thus expected the whole list to fiercely fire
back at me and explain the issues along the way. Sorry that I put things so 
bluntly! That was not the first time, I am afraid, but probably the most blatant 
case.

Providing some working code on sourceforge is an excellent idea. The discussion 
should rather remain on the mailing list though...

Thanks also for great work of documenting PICA on OWW. I think you could improve 
the draft by shortening it -- perhaps move the explanations / motivations into 
another page or something like that to make it easier to grasp the overall picture.

To the list: Are there any other data exchange-related documents coming out of 
the workshop? Any general conclusions about questions that where discussed here?

Again, apologies for the rough previous email
Greetings,
Raik

Ralph Santos wrote:
> 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
>> 
> 
> 
> 

-- 
________________________________

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