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:[EMAIL PROTECTED] On Behalf Of Paul D. Adams Sent: Wednesday, September 19, 2007 1:17 PM To: CCP4BB@JISCMAIL.AC.UK 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. --
