is it time to retire "dative bonds"?

[nbehrnd]

With Organometallics with dative bonds, the cookbook includes an example how to process coordination compounds. The more I read about it, the more I think this type of bonds is a concept of the past and the use of single bonds instead might be better.

I was happy (and still I am) RDKit's cookbook provides the example; with minor adjustments only, it is used to visualize members of a template library for Avogadro (see here). In the course of a subsequent discussion in the forum of openbabel (link) I however became aware of two points which may merit a revision:

• In his compilation of rules of structure representations,[1] Brecher labels the use of arrows between the ligand and ion to be complexed as not acceptable (rule GR 1.7.1, page 292). If RDKit would elect the adoption of this rule, the visual representation would require a change. The visual result were indiscernible from the one of a single bond (i.e., no arrow).

• IUPAC' online version of the Gold Book includes an entry about coordination. At present, I understand its current revision (February 24, 2014) in lines of «dative bonds represent a concept of the past which should be not be used anymore» because of the following statement:

  «The synonym 'dative bond' is obsolete. (The origin of the bonding electrons has by itself no bearing on the character of the bond formed. Thus, the formation of methyl chloride from a methyl cation and a chloride ion involves coordination; the resultant bond obviously differs in no way from the C–Cl bond in methyl chloride formed by any other path, e.g. by colligation of a methyl radical and a chlorine atom.)»

Do you equally think the example in RDKit's cookbook merits an update according to the points above?

[1] Graphical representation standards for chemical structure diagrams (IUPAC Recommendations 2008), Pure Appl. Chem., Vol. 80, No. 2, pp. 277–410, 2008. https://doi.org/10.1351/pac200880020277 published open access

[greglandrum]

This is an interesting idea, thanks for starting the discussion. Some quick thoughts

Completely getting rid of dative bonds is not an option because, despite the IUPAC recommendations, some software requires them. And they are often (but not always) a useful computationally.

We could think about providing a representation in the RDKit where all dative bonds are converted to single bonds. This would require some thinking about how to handle the electron counts on atoms which are bound to the metal (and would almost certainly require us to stop perceiving implicit Hs on atoms bound to a metal), but it could still be useful

We definitely could relatively easily support a drawing mode where dative bonds are just drawn as single bonds. This would get us closer to complying to the IUPAC drawing recommendations. This could be accompanied by a function which actually converts dative bonds to single bonds so that we could save "complaint" mol files. These might already be useful steps.

[schatzsc]

An inorganic chemist's dream come true (-:=

But how is it internally represented in the molfile - could you post an example?!?

[eloyfelix]

they seemed to have progressed quite a lot on it. Last Tuesday there was a "Progress and plans for InChI" update and things looked quite promising.

edit: The roadmap image doesn't seem avaiable anymore from their site so removing it from here.

[schatzsc]

Where is this roadmap from - seems like you know even more than me?!?

[eloyfelix]

edit: roadmap image not avaiable anymore from their site so I dropped it from here as well.

[nbehrnd]

@schatzsc No .explicit .mol file is used to generate the previews. Per group of denticity, there is an annotated list of SMILES in a file groups.smi, for instance with an entry reading

[CH3]C([O][*]1)=CC(=[O]1)[CH3] a acac-acetylacetonate

processed by RDKit by a dedicated script depict_ligands.py. The SMILES is the result drawing the ligand in a complex wit Zn on Marvin's test page; export as SMILES (floppy disk) read by Avogadro. There, export as .cjson file where the only entry about atomic number 30 is substituted by 0. Read again, export Avogadro's SMILES for groups.smi the equally storing a marker (a, or m for automatic/script based, or manual preparation of the preview) and a name.

About 40+ of 54 ligands get their preview this way; difficult cases like flexible EDTA and cyclam, and every haptic ligand (an other 16) are manually prepared with ChemDraw, ChemDoodle, etc.

But I notice my doc string to function reset_dative_bonds requires an edit.

[schatzsc]

What would be even more beneficial, in my opinion, would be a "don't touch" option individually adjustable each atom in the sense that atoms labelled this way will not be subject to any "impicit hydrogen" and "standard valence" routines.

[schatzsc]

We could think about providing a representation in the RDKit where all dative bonds are converted to single bonds. This would require some thinking about how to handle the electron counts on atoms which are bound to the metal (and would almost certainly require us to stop perceiving implicit Hs on atoms bound to a metal), but it could still be useful

In our TUCAN demonstrator, we have called this approach "simple bonds" in the sense that such bonds only indicate a bonding interaction but do not carry any implications in terms of electron counting.

Also, Brecher in rule GR-1.7.1 Coordination bonds to single atoms mentions that

"Any hydrogen atoms bonded to the atoms at either end of such a coordination bond must be shown clearly, even if that produces a diagram where some atoms appear to have non-standard valences, such as a nitrogen atom with four attached bonds."