Indeed LINKR replaces the length of the LINK (superfluous) with the identifier of the LINK type (useful info). Unfortunately, it is non-standard. mmCIF allows a better description of the type of LINK type, but as it has a fixed vocabulary it does not allow actual identifiers that would connect it to a restraint dictionary.

The auto addition of LINKs at the PDB seems better than before. At least now there are no LINKs between mutually exclusive alternate conformations of ligands ;)

 

Cheers,

Robbie

 

Sent from my Windows 10 phone

 


From: Clemens Vonrhein <[log in to unmask]>
Sent: Tuesday, May 15, 2018 6:21:35 PM
To: Robbie Joosten
Cc: [log in to unmask]
Subject: Re: [ccp4bb] Problems with HEC in CCP4
 
Hi,

On Tue, May 15, 2018 at 02:21:59PM +0000, Robbie Joosten wrote:
> A link describes a chemical bond between two residues. With each
> LINK modifications of the residues are described (e.g. leaving atoms
> and, in this case, changes of local chemistry such as bond orders).

I guess that is not strictly true for the official PDB format
description e.g. at

  http://www.wwpdb.org/documentation/file-format-content/format33/sect6.html#LINK

where we have

  The LINK records specify connectivity between residues that is not
  implied by the primary structure. Connectivity is expressed in terms
  of the atom names. They also include the distance associated with
  the each linkage following the symmetry operations at the end of
  each record.

"Connectivity" doesn't explicitly mean a "chemical bond", although
further down we have

  The atoms involved in bonds between HET groups or between a HET
  group and standard residue are listed.

and other points talk about "linkages" and "bonding". So maybe not
completely clear what is meant here - but let's assume that some kind
of chemical relation is intended (bond, coordination, salt bridge).

However, PDB entries themselves contain a vast amount of LINK records
that are clearly auto-generated by some software step after
deposition: this step seems to use a simple 3.5A cut-off criteria to
list all atoms in close contact. That's why there are all those LINK
records involving HOH waters - and we clearly don't want to introduce
a bond restraint to those waters.

Anyway, apart from the potential issues with LINK records in deposited
PDB entries, those records in PDB files under active refinement don't
really hold a description about the linkage type - only if a program
is either writing content beyond the default length of 78 characters
or by writing non-standard LINK records, i.e. missing the SymOP items
and putting something else there. This can make those LINK records
quite problematic when moving between different programs - the
non-standard LINKR record used by REFMAC (?) seems a cleaner way to
me, being obviously non-standard.

Cheers

Clemens


> Each LINK type has a unique identifier that points to the descriptions in the CCP4 dictionary. Did you add those names (HEC-something, I donít know them by hart)? And is your CCP4 up to date?
>
> Cheers,
> Robbie
>
> Sent from my Windows 10 phone
>
> ________________________________
> From: CCP4 bulletin board <[log in to unmask]> on behalf of Eugene Osipov <[log in to unmask]>
> Sent: Tuesday, May 15, 2018 2:53:49 PM
> To: [log in to unmask]
> Subject: Re: [ccp4bb] Problems with HEC in CCP4
>
> Hi Robbie,
> I thought LINK just adds another bond restrain to the refinement procedure and does not affect already existing restrains in library cif file. Am I wrong?
> Also, what do you mean by "modify the chemistry"?
> Just to test your suggestion, I have added LINKs for heme c vynil groups in 4qo5 and ran refinement in refmac 5.8. I took F(+) from deposited cif file as F and SigF(+) as SIGF. After refinement HEC601 and HEC604 have incorrect position of CBC atom.
> Note: I took 4qo5 just as example of cytochrome c to show issues with HEC and do not intend to insult authors of original paper.
>
> 2018-05-15 12:00 GMT+03:00 Robbie Joosten <[log in to unmask]<mailto:[log in to unmask]>>:
> Addendum:
>
> 4qo5 actually lacks the right LINK records altogether. It will only work if you add these by hand. Perhaps you should ask the depositors or the PDB to add the appropriate LINK records.
>
> Cheers,
> Robbie
>
> > -----Original Message-----
> > From: CCP4 bulletin board <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Robbie
> > Joosten
> > Sent: Tuesday, May 15, 2018 10:51
> > To: [log in to unmask]<mailto:[log in to unmask]>
> > Subject: Re: [ccp4bb] Problems with HEC in CCP4
> >
> > Hi Eugene,
> >
> > The problem is not in the HEC.cif file but with the LINKs which modify the
> > chemistry. These were fixed a while ago and the LINKs were added to the
> > CCP4 dictionary. I thought these were released already. If not, they will be
> > soon.
> >
> > Cheers,
> > Robbie
> >
> > > -----Original Message-----
> > > From: CCP4 bulletin board <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of
> > Eugene
> > > Osipov
> > > Sent: Tuesday, May 15, 2018 10:36
> > > To: [log in to unmask]<mailto:[log in to unmask]>
> > > Subject: [ccp4bb] Problems with HEC in CCP4
> > >
> > > Dear CCP4 developers,
> > > please fix errors with heme c dictionary file HEC.cif.
> > > Edward Berry described this problem in detail 4 years ago:
> > > [log in to unmask]"> https:[log in to unmask]
> > > This error already affects deposited entries, e.g.: 4QO5 clearly
> > > contains errors in vynil groups of heme c.
> > >
> > >
> > > --
> > >
> > > Eugene Osipov
> > > Junior Research Scientist
> > > Laboratory of Enzyme Engineering
> > > A.N. Bach Institute of Biochemistry
> > > Russian Academy of Sciences
> > > Leninsky pr. 33, 119071 Moscow, Russia
> > > e-mail: [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]<mailto:[log in to unmask]>>
>
>
>
> --
> Eugene Osipov
> Junior Research Scientist
> Laboratory of Enzyme Engineering
> A.N. Bach Institute of Biochemistry
> Russian Academy of Sciences
> Leninsky pr. 33, 119071 Moscow, Russia
> e-mail: [log in to unmask]<mailto:[log in to unmask]>

--

*--------------------------------------------------------------
* Clemens Vonrhein, Ph.D.     vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park
* Cambridge CB3 0AX, UK                   www.globalphasing.com
*--------------------------------------------------------------