What are the disadvantages (if any) in producing and using the InChI format of chemical compound representation in chemoinformatics? Are there any particular problem one can face when using InChI?


1 Answer 1


You have to evaluate shortcomings as compared to something. You can make a list and say "but InChI doesn't represent X" where X is ranging around

  • mixtures
  • Markush groups
  • polymers from repeat units
  • reactions
  • toasters

The point is: so what? All representations have some limitations. But limitations aren't shortcomings unless you have a different representation that doesn't have those limitations and that is not traded off by other limitations or bloat or other disadvantages.

What do you have to compare InChI with? In my world: SMILES and with MOLFILEs. InChI is most closely related to SMILEs. SMILES is easier to just type, but it isn't canonicalized and it doesn't have the layers of specificity that allow you to find approximate equivalences so easily as with InChI. InChI connection layer is very similar to SMILEs in principle, but it is a lot harder to read because you need to replace the numbers with the atoms from the preceding formula layer. But it is easy to convert InChI to SMILES, except where InChI is better. For example, parenthesized groups, so you represent the carboxyl group -C(=O)OH as -C(O,O)H, which isn't a thing in SMILES.

Where InChI shines is that many isomerisms are abstracted or pushed into more detailed layers. There is no other format that does this as well or at all as InChI, which is why it is good. But InChI is conceived as an "identifier" and some of the details are not at all represented, most specifically the atom positions. That's where MOLFILEs are so easy to work with, if you want to just display the molecule. But in that regard, InChI is no worse than SMILES.

So, you should be more specific in terms of what your goals are that you are asking for "disadvantages" and you need to stay very critical of text that berates InChI or any other standard with a bunch of rationalizations for why not to choose standard A (because the author is committed to standard B). I know this sort of superficial argument is being made a lot in any informatics sector, people like their baby and berate the other's baby. Especially be weary of those who say "don't use InChI, InChI is bad" and then "you really should follow the work on XYZ, because XYZ will be able to represent everything including the toaster."

InChI has it's firm place when the purpose is to represent, refer to, identify basic molecular structures. That's it. If you want mixtures, reactions, polymer repeat units, consider using InChI as the core building block and then build higher order structures around it. For example, obviously there is no reason to push reactions into the InChI representation, just make a simple structure that lists the reaction participants on both sides, their stoichiometry and the enthalpy, activation energies, etc. etc., these can be done in higher order data structures much better than shoving that information into a single InChI++ string. Likewise for polymers, represent each repeat unit as an InChI and then combine them. If your goal is such higher order molecules, you would profitably use InChI as the representation of those core building blocks.

Now that said, I give you my personal pet peeve about InChI, i.e., that is in scope of current InChI where I think it has, let's say, pitfalls, not necessarily that it made the wrong choice. And that is, ionic bonds and coordination bonds. Especially ionic bonds are represented as two separate structures, recognizable with the period . in the formula separating the multiple structures. This is actually a rudimentary representation of mixtures. So in my view, it should not even have introduced this dot notation but simply forced people to represent the parts of these ionic mixes as separate InChIs. I come from the biochemical / physiology / pharmaceutical / medical world where such ionic bonds usually do not even really exist in nature, as the ions are all dissociated in solution. But all that can be disputed. Same for metal coordination or chelate bonds, you want to say where the metal ion associates with, and I think that's not in InChI. So in my world it would be better not to have any of this mixing and coordination inside InChI and we would use higher order structures for it instead, but always use InChI as the basic building blocks.

  • $\begingroup$ I object to almost everything being posted here. I find this post also written very unfriendly and not helpful to the project. Also, if you are associated with the InChI project you must disclose this association. I do not want to go into any more detail about this, but I do not think that this answers the question. There are documented limitations of the algorithm, which could have been discussed here objectively. Oh, I almost forgot: I down-voted. $\endgroup$ Commented Mar 20, 2021 at 1:22
  • $\begingroup$ I have no affiliation with InChI. If you want to give a better answer, you are free to do so. If you object but you have no details to say then you simply protest. $\endgroup$ Commented Mar 23, 2021 at 2:07
  • $\begingroup$ I cannot give an answer to the question, that is why I did not answer it. The post I linked clearly states the documented shortcomings of InChI. Something you seem to ridicule within the first paragraph of your answer attempt. Yes, I use attempt here, because I do not think it answers the question. Your attempt basically boils down to: Don't use it for something that it was not designed for. Which is legitimate, but not really an answer to the question. So in summary: Yes, I do protest. For that much text, there is - in my opinion - not enough objective discussion of the problem. $\endgroup$ Commented Mar 23, 2021 at 22:24
  • $\begingroup$ As you can tell from my answer, I'm a no-b/s kind-a guy. So, you get nasty, I get nasty back. The question was "disadvantages of using InChI" and "problems we can face when USING InChIs" Your vehement reaction was that you feel attacked by my Toaster joke. But that is because you are committing the what-about-the-Toaster mistake, and you are apparently emotionally biased, you want to find some negativity about InChI and you use the lack of Toasters. You need to check your list first "as compared to what?". E.g., InChI doesn't NORMALIZE tautomers (yet) but MOLFILE doesn't normalize anything! $\endgroup$ Commented Mar 24, 2021 at 16:14
  • $\begingroup$ I am neither attacked nor offended by the remark about the toaster, even though it is an odd comparison. I see purpose and benefits in using InChI as a system, algorithm, software. I am also quite positive that future version will address the current limitations. They are still limitations and they should be discussed as such. Just stating don't use it for situations it is not designed for without addressing which situations these are is in my opinion not helpful. It is (objectively) a problem that InChI cannot distinguish tautomers and one should be aware of that when working with these. $\endgroup$ Commented Mar 24, 2021 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.