Dear Colleagues,
Warren makes a good point, but let me recast it slightly. We are
all part of the structural biology community, and we, as a community,
need to get together and explore our options for interchange of
information. Some of us already have a proposal pending with the
NSF for a collaboration on Management of Experimental Data in Structural
Biology (MEDSBIO) to institutionalize that process for our raw
experimental data. The wwPDB, as a member of the community, is
cooperating in that effort. Perhaps it is time for another formal
collaboration, say, a collaboration of Management of Derived
Information in Structural Biology (MDISBIO) that would focus on
coordinates and other derived information. I hope and believe
that the wwPDB would cooperate in that effort, and I am certain the
MEDSBIO would cooperate as well.
I am not proposing a standardization effort. There are too many
valid, but diverse, needs and the pace of change is too rapid for one
representation to satisfy everybody, but we could work to reduce
the current chaos to more manageable levels and work to achieve
clean, well-documented interoperability among the necessary minimum
number of standards.
In the computer science community, we have learned to live with
multiple programming languages, and to treat the "standards" for
those languages as living documents to be studied and considered
in an open and collaborative manner and to revise those standards
every few years. This practice might serve the structural biology
community as well.
Regards,
Herbert
At 6:19 PM -0700 9/19/07, Warren DeLano wrote:
>Nevertheless, there is a huge problem with interoperability between
>software packages, and this core issue greatly frustrates everyone, not
>only Joe.
>
>Frankly, it is a disgrace that even in 2007, software users in
>structural biology and computational chemistry still cannot reliably
>exchange basic molecular structure information between programs.
>
>But we can only blame ourselves for this: it is *WE SOFTWARE DEVELOPERS*
>who must pick up where the PDB mandate lets off in order to create
>robust and workable interchange systems between our various packages.
>We cannot expect to the PDB to do something only we, collectively, know
>how to do, and likewise, the PDB should not continue to be scapegoated
>for our own failings (as Joe may be doing, at some level).
>
>Hijacking the PDB format may not be the best way to go, but without
>question, something must be done. The status quo IS A MESS!
>
>Whether it is a virtual gathering via Wiki, or an old-fashioned
>round-up, there are several dozen key molecular software developers who
>need to be "locked in a cell together" until some minimum reasonable
>solution shakes out for representing and sharing molecular structure
>information: something that we can all live with, and something that we
>will all commit to adopting.
>
>But how? when? & where? And what would actually motivate participation?
>
>I don't yet have those answers, and perhaps the wwPDB could indeed play
>a key role in this process. But ultimately, this isn't their job or
>their burden.
>
>It is ours, collectively, as developers of molecular software.
>
>Sincerely,
>
>Warren L. DeLano, Ph.D.
>DeLano Scientific LLC
>
>-----Original Message-----
>From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of
>Paul D. Adams
>Sent: Wednesday, September 19, 2007 1:17 PM
>To: [log in to unmask]
>Subject: Re: [ccp4bb] Why wwPDB and members are doing a poor job.
>
>Joe,
>
> I think this is neither a constructive or accurate statement. I
>have collaborated with the PDB (both the RCSB and the EBI) for many
>years and I believe that they are doing a very good job under very
>difficult circumstances. They have been tasked with curating an ever
>increasing volume of data from a community that, as you point out, is
>constantly developing new methods. As a community we need to
>communicate and collaborate with the PDB, not try to sideline them. I
>know that they are willing to listen so we should take that opportunity.
>
> Cheers,
> Paul
>
>On Aug 29, 2007, at 8:08 AM, Joe Krahn wrote:
>
>> This is a reply to the below message posted under "[ccp4bb] The
>> importance of USING our validation tool", which is a rather long
>> thread now.
>>
>> This is part of why I claim that wwPDB and its members are doing a bad
>> job. They have worked to systematically remove "general purpose"
>> information that does not fit their pre-defined schemes, which are
>> developed with out much interaction with the user community. the
>> problem
>> is that we are doing RESEARCH, which means that we will continue to
>> develop new methods over time. The sensible thing to do is to allow
>> unformatted user-defined information, and eventually work it in to a
>> properly formatted, standard item if that information is seen as
>> generally useful by the user community.
>>
>> I think that the lack of community involvement by the database
>> administrations should be a clear indication of why we should NOT
>> switch
>> from PDB to mmCIF format for coordinate files. Instead, we should take
>> this opportunity of wwPDB members abandoning the PDB format to take
>> over
>> management of the format ourselves. I was quite irate with them for
>> going against our wishes on several features of the PDB format, like
>> supporting the SegID. Instead, I think we should realize that "modern
>> database" management goals are different from experimentalist
>> goals, and
>> that we should not rely on them to decide how our own data should be
>> represented.
>>
>> I think that we should intentionally avoid mmCIF for coordinate files,
>> and stick to the PDB format. The wwPDB has absolutely no policy for
>> user
>> involvement, and RCSB has clearly dropped the previously establish
>> PDB-format change policy. Their task was never to manage a public file
>> format standard. This is an opportunity to turn the PDB file format
>> into
>> a public standard.
>>
>> I have started a PDB Format Wiki, running on my home computer, at
>> http://pdb.homeunix.org. If it gains interest, I will see about moving
>> it to a proper Internet host.
>>
>> Joe Krahn
>>
>> Miller, Mitchell D. wrote:
>>> Hi Boaz,
>>> We were informed by an RCSB annotator in April 2006 that the
>>> RCSB had suspended including REMARK 42 records in PDB files
>>> pending the review of the process by the wwPDB.
>>>
>>> In looking at the new annotation guidelines, it looks
>>> like the result of that review was to reject the REMARK 42
>>> record and the listing of additional validation items.
>>> See page 23 of the July 2007 "wwPDB Processing Procedures
>>> and Policies Document"
>>> http://www.wwpdb.org/documentation/wwPDB-A-20070712.pdf
>>>
>>> "REMARK 42 and use of other programs for validation Use of REMARK
>>> 42 is
>>> discontinued.
>>>
>>> If authors wish to indicate presubmission validation and other
>>> programs used before
>>> deposition, the programs may be listed in a new remark, REMARK 40.
>>> This remark will
>>> list the software name, authors and function of the program.
>>> Results of the software will
>>> not be listed. Use of this remark is voluntary."
>>>
>>> It seems that the wwPDB only allows the inclusion of validation
>>> statistics output by the refinement program but not from additional
>>> validation programs. So for additional statistics to be included
>>> in the PDB header, they will either need to be implemented by the
>>> refinement package or the wwPDB annotators.
>>>
>>> Regards,
>>> Mitch
>
>--
>Paul Adams
>Senior Scientist, Physical Biosciences Division, Lawrence Berkeley Lab
>Adjunct Professor, Department of Bioengineering, U.C. Berkeley
>Head, Berkeley Center for Structural Biology
>Deputy Principal Investigator, Berkeley Structural Genomics Center
>
>Building 64, Room 248
>Tel: 510-486-4225, Fax: 510-486-5909
>http://cci.lbl.gov/paul
>
>Lawrence Berkeley Laboratory
>1 Cyclotron Road
>BLDG 64R0121
>Berkeley, CA 94720, USA.
>--
--
=====================================================
Herbert J. Bernstein, Professor of Computer Science
Dowling College, Kramer Science Center, KSC 121
Idle Hour Blvd, Oakdale, NY, 11769
+1-631-244-3035
[log in to unmask]
=====================================================
|
