On Mon, Aug 5, 2013 at 11:11 AM, Phil Jeffrey <[email protected]>wrote:
> While alternative programs exist to do almost everything I prefer > something that works well, works quickly, and provides instant visual > feedback. CCP4 and Phenix are stuck in a batch processing paradigm that I > don't find useful for these manipulations. > Speaking as a developer, it's probably much easier and faster for us to write software that *does* do what you want, instead of piling on hacks to keep the PDB format alive another 30+ years. While PDB is limited and has a lot of redundant information it's for the > latter reason it's a rather useful format for quickly making changes in a > text editor. It's certainly far faster than using any GUI, and it's also > faster than the command line in many instances - and I have my own command > line programs for hacking PDB files (and ultimately whatever formats come > next) > Most complaints of this sort seem to be based on an unrealistic expectation that your own experiences and skills are representative of the rest of the community. The vast majority of crystallographers don't have their own command-line programs, aren't familiar with the intricacies of PDB format, and as often as not botch the job when they attempt to edit their PDB files by hand. (I get a lot of bug reports like this.) They're not going to care whether they can use 'awk' on their structures. > Using mmCIF as an archive format makes sense, but I doubt it's going to > make building structures any easier except for particularly large > structures where some extended-PDB format might work just as well or better. > There is a lot of information that can't easily be stored simply by making the ATOM records wider. Right now some of this gets crammed into the REMARK section, but usually in an unstructured and/or poorly documented format. This isn't just problematic for archival - it limits what information can be transferred between programs. mmCIF has none of these limitations. I have some reservations about the current specification (for instance, the fact that the original R-free flags are not stored separately in deposited structure factor files, and are instead mixed into the "status" flag, which can have multiple other meanings), but at least there is a clear process for extending this in a way that does not (or should not, anyway) break existing parsers. -Nat
