-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mmCIF format, atoms addressable only via label_* fields and not via auth_* fields #95
Comments
I agree, that would be best to improve. So the following tuples should both uniquely identify an Atom right?
Also do you have any feelings about how to handle the missing Another point, is the |
I also have some problems from the API design with the So I would propose to generate these upon save, and read the correct data in while parsing. So to not use these to uniquely identify atoms in functions like |
Sorry, I might have introduced some confusion with the wrong wording... The tuple ( Similarly for the tuple ( In some mmCIF files, The residue numbers Because of these two reasons, it would be great to identify a residue either by its "label" tuple or its "auth" tuple. |
After some consideration I made the Residue numbers always equal to For the As I am enjoying holidays around now I will be slower to implement changes for a while. |
In general, PDB's |
I used the same trick as used for the |
In mmCIF, every atom is addressable in two ways:
label_asym_id
,label_seq_id
) e.g. ('A', 1)auth_asym_id
,auth_seq_id
,pdbx_PDB_ins_code
) e.g. ('A', -1, 'X')mmCIF guarantees that
label_seq_id
starts at 1 and increases by 1 without gaps, so an insertion code is not required here.But structural biologists sometimes use "strange" numbering schemes to adjust to what other researchers are used to (for example, the nucleotide numbers in ribosomes are meaningful for ribosome biologists). The second tuple is excellent here because the numbering can be negative or zero and may have gaps or insertion codes.
In the legacy PDB format, we only had the second addressing scheme: (chain, number, icode). So most (if not all) of the tools supporting mmCIF input, provide results using the tuple (
auth_asym_id
,auth_seq_id
,pdbx_PDB_ins_code
). Unfortunately, pdbtbx supports (label_asym_id
,label_seq_id
) addressing only, so I cannot match what the other tools provide with what pdbtbx parses.Can we have the
Residue
structure holding both tuples?The text was updated successfully, but these errors were encountered: