Dear James,
 
You make a very good point. So far we only discussed the option of removing 
alls side chain atoms except for CB. What if only a few side chain atoms are 
outside the density? Should we just remove those? If we use the argument that 
we should remove the atoms we cannot see, then surely we should keep the ones 
we can see. 
A problem is that if someone else recalculates the maps and inspects them 
(which is the point of the EDS), some atoms may very well fall inside or 
outside the density differently than in the original crystallographic study: 
software changes, other reflections are included (remember the recent I/sigI 
discussion), and last (but not least) when atoms are removed the solvent mask 
changes. 
 
Anyway, I don't think that the side chain discussion will be solved in this 
thread. PDB users are not all the same and treat the options that are proposed 
differently. They are all used in the PDB and that complicates matters for the 
users. In PDB_REDO (plug, plug ;) we build all missing side chains (and rebuild 
the zero-occupancy ones) and let the B-factor sort it out. Not everyone will 
agree with this, but at least it is consistent. If anyone studies a single 
structure properly, he should use the density and there is no problem. For 
statistics studies the first thing people do is filter by resolution and 
B-factor (and sequence identity) so the really bad side chains are removed from 
the testset anyway.
 
Cheers,
Robbie
 

 
> Date: Sun, 3 Apr 2011 23:45:10 -0700
> From: jmhol...@lbl.gov
> Subject: Re: [ccp4bb] what to do with disordered side chains
> To: CCP4BB@JISCMAIL.AC.UK
> 
> At the risk of throwing a little gasoline on the flame war, what about 
> side chains that will ALWAYS poke outside of the electron density? For 
> example, pretty much any terminal aliphatic at 3.5 A resolution? I 
> first learned this about 15 years ago when I made this movie:
> 
> http://bl831.als.lbl.gov/~jamesh/movies/resolution.mpeg
> 
> For those of you whose browser no longer supports MPEG-1, this is a 
> movie of a calculated (aka noise-free) electron density map, contoured 
> at "1 sigma", but cut to the resolution shown after applying an overall 
> B factor sufficient to suppress series-termination. By that I mean the 
> maps don't look all that different with or without the cutoff. The 
> coordinates shown are the "correct" model used to calculate the map. At 
> about 3.5 A you start to see side chains poking out of the density, and 
> at 6 A, all the side chains are "gone". Does this mean they should be 
> modeled with zero occupancy? ;)
> 
> -James Holton
> MAD Scientist
> 
> 
> On 4/3/2011 9:57 PM, Maia Cherney wrote:
> > I guess, most hydrophilic side chains on the surface are flexible, 
> > they don't keep the same conformation. If you cut those side chains 
> > off, the surface will be looking pretty hydrophobic and misleading 
> > (and very horrible). I prefer to see them intact. I know, most of them 
> > are flexible and don't have one exact position, but it's OK. I know 
> > they are there not far from the main chain. Usually, their exact 
> > position is irrelevant.
> >
> > Maia
> >
> >
> >
> > Jacob Keller wrote:
> >> Well, what about getting the default settings on the major molecular
> >> viewers to hide atoms with either occ=0 or b>cutoff ("novice mode?")?
> >> While the b cutoff is still be tricky, I assume we could eventually
> >> come to consensus on some reasonable cutoff (2 sigma from the mean?),
> >> and then this approach would allow each free-spirited crystallographer
> >> to keep his own preferred method of dealing with these troublesome
> >> sidechains and nary a novice would be led astray....
> >>
> >> JPK
> >>
> >> On Sun, Apr 3, 2011 at 2:58 PM, Eric Bennett <er...@pobox.com> wrote:
> >>> Most non-structural users are familiar with the sequence of the 
> >>> proteins they are studying, and most software does at least display 
> >>> residue identity if you select an atom in a residue, so usually it 
> >>> is not necessary to do any cross checking besides selecting an atom 
> >>> in the residue and seeing what its residue name is. The chance of 
> >>> somebody misinterpreting a truncated Lys as Ala is, in my 
> >>> experience, much much lower than the chance they will trust the xyz 
> >>> coordinates of atoms with zero occupancy or high B factors.
> >>>
> >>> What worries me the most is somebody designing a whole biological 
> >>> experiment around an over-interpretation of details that are implied 
> >>> by xyz coordinates of atoms, even if those atoms were not resolved 
> >>> in the maps. When this sort of error occurs it is a level of pain 
> >>> and wasted effort that makes the "pain" associated with having to 
> >>> build back in missing side chains look completely trivial.
> >>>
> >>> As long as the PDB file format is the way users get structural data, 
> >>> there is really no good way to communicate "atom exists with no 
> >>> reliable coordinates" to the user, given the diversity of software 
> >>> packages out there for reading PDB files and the historical lack of 
> >>> any standard way of dealing with this issue. Even if the file 
> >>> format is hacked there is no way to force all the existing software 
> >>> out there to understand the hack. A file format that isn't designed 
> >>> with this sort of feature from day one is not going to be fixable as 
> >>> a practical matter after so much legacy code has accumulated.
> >>>
> >>> -Eric
> >>>
> >>>
> >>>
> >>> On Apr 3, 2011, at 2:20 PM, Jacob Keller wrote:
> >>>
> >>>> To the delete-the-atom-nik's: do you propose deleting the whole
> >>>> residue or just the side chain? I can understand deleting the whole
> >>>> residue, but deleting only the side chain seems to me to be placing a
> >>>> stumbling block also, and even possibly confusing for an experienced
> >>>> crystallographer: the .pdb says "lys" but it looks like an ala? Which
> >>>> is it? I could imagine a lot of frustration-hours arising from this
> >>>> practice, with people cross-checking sequences, looking in the methods
> >>>> sections for mutations...
> >>>>
> >>>> JPK
> >>>>
> >>
> >>
> >>
                                          

Reply via email to