RE: [PyMOL] DSSP

2003-11-03 Thread Warren L. DeLano
Ben,

Great response! Indeed, the PDB's limited capacity for secondary
structure does indeed represent this as one single helix, not two.

 +/- 15 degrees is pretty difficult to see - so I think that DSSPs 
 +assignment
 in this case, while liberal, is certainly acceptable.

I hardly think it acceptable that one residue with 3-10 PHI/PSI
constitutes a helix when you have so many other telltale characteristics
of a Type II' beta turn, including a Glycine in position i+1 and all
deviations within 22 deg. of ideal turn, as well as four planer CA atoms
(actually five, C-alphas 98-102 are all nearly planer).  Some turns do
look like helices, but not this one -- not even close.

 Great example of where DSSP fails, but perhaps a bit contrived.

I don't think this example is contrived.  One of the many tests
I put PYMOL through regularly is to render the entire PDB over several
hours, so I literally see thousands of structures on a routine basis.
Such objective but bogus assignments are far more common than one
would like to think.  It is a real problem.

 The reason that consistency is of paramount importance in assigning
secondary structure 
 is so that different scientists can talk about the same protein in
context.  
 If everyone uses the same definition of secondary structure - helix
1 is always helix 1. 

Good point, but I disagree.  In acknowledging the subjective and
relative nature of assignments, I think it is more reasonable to ask
scientists to define their terms rather than to perpetuate broken
conventions.  Given how evolution, crystallization, and protein
processing work, even with DSSP, Helix 3 can easily be Helix 2 or 4 in
another structure of the identical or a related protein, so the savings
in confusion is slight.   Also, keep in mind that all numbering is
relative and increasingly problematic as more and more homologous
structures are solved, and explicit conceptual labels are far more
general than numeric ones.  

But finally, do understand that I would provide DSSP as an
option if it were possible to do so, but frankly, it's not.  The paper
does not enable an exact reimplementation, and the owners of DSSP,
instead of making DSSP source code usable and redistributable as an open
standard, have decided to use the software for revenue generation
(presumed modest at best).  It is exatly this kind of short-sighted
restrictiveness that PyMOL was created to combat.  We must end this
dismal pattern of scientists developing research software that is so
drastically and artificially limited by licensing terms that it has
little or no ability to enable future scientific advances.

Computer-dependent scientific fields like structural biology and
computational chemistry will be handicapped until we can all effectively
access and improve upon existing software systems.  That will not happen
until research scientists and academic institutions stop viewing such
software programs as potentially lucrative intellectual properties and
start viewing them as the critical building blocks that will enable
future breakthroughs if and when they become widely shared.   

Imagine... What would happen if all scientists stopped
publishing their discoveries and kept all information within one lab or
institution?  Scientific progress would come to a halt.  That's
basically what has occurred with so much scientific software over the
last 20 years.  Don't get me wrong -- some great code has been written
-- and some of that code has been shared without cost to some or for a
low fee to others.  However, most of that code has almost never been
shared in such a way as to enable extension, modification, and
redistribution.  As a result, we are not making much cumulative
progress.  Software programs resemble ideas: they must be shared,
questioned, altered, and refined in order for lasting progress to occur.
Otherwise they stagnate just like old ways of thinking.  

DSSP (circa 1983) is a great example of how many
computer-dependent sciences remain trapped in the 1980s.  Whether it
works better than PyMOL or not is almost beside the point.  It is simply
not an appropriate standard for us to be using today in this age of open
standards, open source, and composite systems.  We can and should do
better than this.

My hope is that if PyMOL and enough similar projects are
successful, that governments, companies, and funding agencies will begin
to back these kinds of efforts wholeheartedly with money and policies,
and thus drive rapid progress and widespread benefits throughout the
sciences. 

Cheers,
Warren

--
mailto:war...@delanoscientific.com
Warren L. DeLano, Ph.D.
Principal Scientist
DeLano Scientific LLC
Voice (650)-346-1154 
Fax   (650)-593-4020

 -Original Message-
 From: Ben Hitz [mailto:bh...@exelixis.com] 
 Sent: Monday, November 03, 2003 11:01 AM
 To: Warren L. DeLano; pymol-users@lists.sourceforge.net
 Subject: Re: [PyMOL] DSSP
 
 
 Warren -
 
 

[PyMOL] Interface for native OS X version.

2003-11-03 Thread Florian Nachon

On 3 nov. 03, at 22:29, pymol-users-requ...@lists.sourceforge.net wrote:


2)The interface for mac is .. well.. very uncomfortable. Is there a
chance of improvement soon?


What exactly do you mean?



I guess Einat talks about the tk interface that is missing in the 
native OS X version of PyMol.
One can use the fink version to get the tk menu. But this version is 
rarely up-to-date.
The menus have to be built using cocoa or  tcl/tk aqua could be include 
in the native release.