Ian,
> Perhaps someone from one of the PDB deposition sites
> could comment and verify my reading of this?
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.
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.
Best,
Eugene.
On Mon, 17 Aug 2009, Ian Tickle wrote:
> Tim, Garib,
>
> Sorry, maybe I'm missing something here but how does the user specify
> that (s)he wants a TRANS link between standard amino-acids (ASN-GLY) in
> this case? Isn't that the default? I always thought the answer was to
> add a LINK record for those two residues in the PDB file using the
> format specified in the PDB guide, e.g.
>
> LINK C ASN B 729 N GLY B 741
>
> (or just paste the LINKR record from the output PDB file and change
> LINKR to 'LINK ').
>
> But this raises an important issue. The PDB entries contain many
> examples of this, i.e. where there's a gap in the numbering but not in
> the sequence, and the PDB guide on the LINK record states:
>
> "The LINK records specify connectivity between residues *that is not
> implied
> by the primary structure*." (my emphasis).
>
> My reading of this is that it's the primary structure (i.e. the SEQRES
> records) that specify that the residues are contiguous, *not* the
> residue numbering. Perhaps someone from one of the PDB deposition sites
> could comment and verify my reading of this? If this is the case then
> Refmac is ignoring a perfectly valid PDB format, and requiring that the
> user supplies a non-agreed format! - but of course I could be wrong in
> my interpretation (in which case of course I withdraw from the
> argument!). But if I'm right then it seems to me that refinement
> programs should at the very minimum be able to treat completely valid
> PDB entries correctly, and not require the user to make non-standard
> changes.
>
> Cheers
>
> -- Ian
>
>> -----Original Message-----
>> From: [log in to unmask] [mailto:[log in to unmask]]
> On
>> Behalf Of Garib Murshudov
>> Sent: 16 August 2009 22:09
>> To: Tim Fenn
>> Cc: [log in to unmask]
>> Subject: Re: [ccp4bb] LINKR in refmac
>>
>> Tim is right. The link you want is TRANS. And if you want link between
>> alternative position then you need to add alt codes before residue
> names.
>> Llink ids must be defined in the dictionary. There are definitions for
>> standard links in the dictionary: $CLIBD_MON/list/mon_lib_list.cif.
>>
>> For templates how to use various forms of links please have a look:
>> http://www.ysbl.york.ac.uk/refmac/data/template_link.txt
>>
>> If you experience further difficulties please let me know and I will
> try
>> to sort this out.
>>
>> regards
>> Garib
>>
>>
>>
>> 2009/8/14 Tim Fenn <[log in to unmask]>
>>
>>
>> On Fri, 14 Aug 2009 13:24:16 -0700
>> Jan Abendroth <[log in to unmask]> wrote:
>>
>> > How can I tell refmac to maintain the peptide link?
>> > Here is what I tried - the numbers above just for orientation
>> >
>> > 1 2 3 4 5 6
>> > 7 8
>> >
>>
> 123456789012345678901234567890123456789012345678901234567890123456789012
> 34
>> 567890
>> > LINKR C ASN B 729 N GLY B 741
> ASN-GLY
>> >
>> > refmac comments in the log file ... however, still pulls the
>> residues
>> > apart. WARNING : description of link:ASN-GLY is not in the
>> dictionary
>> > link will be created with bond_lenth = 1.260
>> >
>> > So, in my understanding it comes down to the question:
>> > how is a peptide bond referenced to in the dictionary?
>> >
>>
>>
>> take a look at the data_link_list loop in mon_lib_list.cif
> (there
>> may
>> be an easier way to view this info):
>>
>> TRANS . . peptide . . peptide
>> default-peptide-link
>> PTRANS . . peptide PRO . .
>> default-peptide-link_pro
>> NMTRANS . . peptide PRO . .
>> default-peptide-link_cn
>> CIS . . peptide . . peptide
>> cis-peptide-link
>> PCIS . . peptide PRO . .
>> cis-peptide-link_pro
>> NMCIS . . peptide PRO . .
>> cis-peptide-link_cn
>>
>>
>> so you probably want TRANS.
>>
>> HTH,
>> Tim
>>
>> --
>> ---------------------------------------------------------
>>
>> Tim Fenn
>> [log in to unmask]
>> Stanford University, School of Medicine
>> James H. Clark Center
>> 318 Campus Drive, Room E300
>> Stanford, CA 94305-5432
>> Phone: (650) 736-1714
>> FAX: (650) 736-1961
>>
>> ---------------------------------------------------------
>>
>>
>
>
>
> 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
>
|