Hi Ian,

I may be wrong here, in which case Jawahar will correct me.

> I understand that to mean that it's the *order* of residues that must be
> identical, not the residues themselves, i.e. it's valid for residues to
> be omitted from the co-ordinate section (but not of course from the
> SEQRES section!).

- correct, however:

I thought that primary purpose of LINKs in PDB is to specify
"extra" connectivity like between ligands and polypeptides,
also when polypeptides loop up and make SS or other bonding
etc.

If I were to deal with your example, I would look into distance
profile between residues in coordinate section, which then
gives answer to your question.

> It's not the presence of LINKR records that really concerns me: as you
> say there's no harm done if they are only used locally - and as long as
> users are not confused into thinking that the LINKR records are valid
> for deposition!

LINKR simply wouldn't validate at deposition

> My concern is that in cases (such as my first example above) where the
> residue numbers are non-contiguous but no atoms have actually been
> omitted, users are required to insert additional LINK records in order
> to re-refine already perfectly valid and unambiguous PDB entries.  This
> makes automated refinement of PDB entries very difficult!

Obviously LINKR will help where distance profile is insufficient to
reliably derive linking. I believe this is what Garib says in his
e-mail. The problem, as far as I can see it, is simply that on
the refinement stage residue numbers are equivalented with residue
positions, which is wrong in general, but acceptable locally. As
in George reply of today, a generic solution would be to keep original
residue numbers merely as labels.

Hope I did not mess it up completely.

Cheers,

Eugene.



On Mon, 17 Aug 2009, Ian Tickle wrote:

>
> Hi Eugene & Jawahar
>
> Thanks for responding!
>
>> let me take the liberty. Your reading of PDB documentation is
>> absolutely correct. PDB format has got 3 types of links: SSBOND,
>> LINK and CISPEP. And indeed, residue numbers have no significance
>> in the PDB whatsoever. The connectivity is given by SEQRES and
>> by the order of residues in the coordinate section (which must
>> be identical to SEQRES). Where this order is insufficient to
>> describe (extra) connectivity, LINK etc. records are used.
>
> I understand that to mean that it's the *order* of residues that must be
> identical, not the residues themselves, i.e. it's valid for residues to
> be omitted from the co-ordinate section (but not of course from the
> SEQRES section!).
>
> Let's take a couple of concrete examples.  First, suppose the sequence
> is ...AGGA... and the co-ordinate section contains:  ... A4 G6 G7 A8 ...
> .  Then it's unambiguous from the sequence that A4-G6, G6-G7 and G7-A8
> are linked (i.e. residue no 5 is not used in this case), so a LINK
> record for A4-G6 is *not* mandatory (though I assume it's not an error
> to give it).
>
> Now, assuming the same sequence, suppose that one of the Gs could not be
> seen in the structure, so the co-ordinate section contains only ... A4
> G6 A8 ... .  Now there's an ambiguity: is the sequence actually A4 G5 G6
> A8 or is it A4 G6 G7 A8 ?  Clearly it makes a difference!  Presumably
> then a LINK record would be mandatory in order to resolve the ambiguity
> and identify the missing residue (i.e. either a G6-A8 link with G5
> missing or a A4-G6 link with G7 missing).
>
>> LINKR was never in PDB standard and for this is not admissible.
>> I think (Garib will give an exhaustive explanation if he wishes)
>> Refmac uses them for purely technical purposes from long ago.
>> In the end of processing, they should become one of the PDB's
>> link records - either at depositor or PDB side, or be removed
>> if they are redundant.
>>
>> I am sure Garib has reasons for having LINKR records in Refmac,
>> however confusing this may be. It is, indeed, not a very clean
>> practice to use self-invented additions to PDB format, but for
>> as long as they are used only locally there is no a terrible harm
>> in it as seems.
>
> It's not the presence of LINKR records that really concerns me: as you
> say there's no harm done if they are only used locally - and as long as
> users are not confused into thinking that the LINKR records are valid
> for deposition!
>
> My concern is that in cases (such as my first example above) where the
> residue numbers are non-contiguous but no atoms have actually been
> omitted, users are required to insert additional LINK records in order
> to re-refine already perfectly valid and unambiguous PDB entries.  This
> makes automated refinement of PDB entries very difficult!
>
> Cheers
>
> -- Ian
>
>
> Disclaimer
> This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [log in to unmask] and destroy all copies of the message and any attached documents.
> Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain.  Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
> Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
>
>
>