[Biopython-dev] Bio.PDB.Residue.id

[Kristian Rother]

Hi,

In our group, we've been discussing the PDB.Residue.id issue a couple of
times. The current notation is fine but it is unintuitive and hard to
learn for newbies.
We therefore use a wrapper that allows to access residues by one-string
ids = str(identifier + icode), like '101', '101A', '3B' etc.

I'm sure changing ids in PDB.Residue would break a lot of scripts people
use. I could imagine some workarounds that allow ignoring the HETERO flag
though. Would work for me. How about you?

Best regards,
   Kristian


> By redundant, I mean that a residue can be unambiguously determined by
> using
> (PDB code, model id, chain id, residue sequence identifier+icode) .
> HETERO-flag itself is definitely not redundant information for a residue.
> But it seems to be redundant in residue ID according to the small test on
> ~22,000 remediated PDB files.
>
> This redundancy sometimes causes unnecessary problems. For example, in
> DSSP,
> residues are determined by using sequence identifier+icode. When parsing
> DSSP output, some residues cannot be located the PDB structure stored in
> Bio.PDB.Structure because sequence identifier + icode is not enough for
> determining the residues in BioPython. One example is:
> 3jui 0 A 547
> In the protein structure, using sequence identifier + icode, this residue
> is
> unambiguously determined. But in BioPython, one has to specify ('H_MSE',
> 547, ' ') to locate this residue. (Note that we can also simply use 547
> without icode to locate it. But we don't want to accidentally forget icode
> in our script, do we :).
>
> Peter pointed out that the existence of hetero-flag in residue ID might be
> due to the mistakes in the old PDB files before remediation. If it is the
> case, hetero-flag should better be retained for backwards compatibility.
>
> regards,
> hongbo
>
> On Tue, Jan 25, 2011 at 12:23 AM, João Rodrigues <anaryin at gmail.com>
> wrote:
>
>> To be really honest, I don't understand the problem with the flag. I
>> don't
>> really see it as redundant. Could you please explain better?
>>
>>
>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>
>