"Best" way of referencing chemicals in databases [closed]








**Closed**. This question is [opinion-based](/help/closed-questions). It is not currently accepting answers.
 
 






---








**Want to improve this question?** Update the question so it can be answered with facts and citations by [editing this post](/posts/171933/edit).




Closed 6 months ago.








[Improve this question](/posts/171933/edit) 



What is considered the "best" way of referencing chemicals in a database ? As far as I understand CAS nr. is a specific type of hash whereas something like smiles stores structural information too. Is there any possible overlap between identifiers (I know there is for SMILES) ? If so which one has the least overlap ? Im not quite sure I understand exactly the purpose of each of these




TL,DR: If your database is about organic molecules with less than 1024 atoms per entry, each described in the .sdf file format, and your structure-related identifier is not used to recover the underlying structure, I recommend *non-standard InChI keys assigned with the optional fixed H layer*. This is a 27 character long hash with high collision resistance.


The ***CAS number*** is a book keeping *register* number of a chemical compound; neither the first, nor the only attempt to index chemicals in a database - in the particular case, to offer an eventually machine readable tag for [Chemical Abstracts](https://en.wikipedia.org/wiki/Chemical_Abstracts_Service) and subsequent products. *Outside* the ecosystem of the American Chemical Society, it equally is used by other databases and catalogues of chemical suppliers, in many of the about 20k chemicals indexed in Wikipedia' property boxes. Its use is advantageous e.g. because different to the *systematic name*, or *generic names*, CAS number(s) assigned to a chemical do not change in natural languages and scripts (English, Japanese, Arabic, etc.). Though the formatting is known (see e.g., [here](https://en.wikipedia.org/wiki/CAS_Registry_Number#Format)), and a small public *sub set* of about 500k entries (see [here](https://commonchemistry.cas.org/)), eventually, the assignment of CAS numbers is up to the ACS.


There is no way to predict the CAS number for a new structure, nor to reconstruct a chemical structure with the CAS registry number in hand. Because the present form of your question does not specify further what chemicals your database covers: different crystal structures of the same compound get different CAS RN, e.g., [1317-80-2](https://commonchemistry.cas.org/detail?cas_rn=1317-80-2&search=rutile) about [rutile](https://en.wikipedia.org/wiki/Rutile), and [1317-70-0](https://commonchemistry.cas.org/detail?cas_rn=1317-70-0&search=anatase) about [anatase](https://en.wikipedia.org/wiki/Anatase) - yet both about [titanium dioxide](https://en.wikipedia.org/wiki/Titanium_dioxide), $\ce{TiO2}$. This variation, described as [polymorphism](https://en.wikipedia.org/wiki/Polymorphism_(materials_science)), equally is observed for organic materials.




---


***SMILES*** is a *notation* to retain *some* chemical information (see for example [Wikipedia's article](https://en.wikipedia.org/wiki/Simplified_molecular-input_line-entry_system), and [Daylight's tutorial](https://www.daylight.com/dayhtml_tutorials/languages/smiles/index.html)). Accepted for file input and output e.g., by [openbabel](https://github.com/openbabel/openbabel), or [RDKit](https://github.com/rdkit/rdkit) it is possible to simplify a 3D structure of a molecule into such a string, and recover *a reasonable* 3D structure from this string. (The input 3D structure need not to match the reconstructed 3D structure in the *absolute* atomic positions, but typically does for the *relative* spatial arrangement of the atoms.)


While you have the advantage to assign a SMILES string to a structure on your computer, independent from a curator of a database, the SMILES string's complexity increases with the complexity of the structure they describe. There is no fixed string length of SMILES strings. If the structures are "complex enough", different implementations may assign one structure different SMILES strings, too. An example for this is [pyridine](https://en.wikipedia.org/wiki/Pyridine); it can be described in a kekulized form with alternating single and double bonds `C1=CC=NC=C1` (e.g., [Marvin](https://marvinjs-demo.chemaxon.com/latest/demo.html)) and `C1=CN=CC=C1` (e.g., [ChemDraw](https://chemdrawdirect.perkinelmer.cloud/js/sample/index.html#)), or in a form where all atoms concerned are described as equals in an aromatic system, hence as `c1ccncc1` (e.g., OpenBabel). Sometimes, the kekulized form has an advantage, in other case it does not. Further, [openbabel](https://open-babel.readthedocs.io/en/latest/FileFormats/SMILES_format.html) alone allows the export of *canonical*, *universal*, and *inchified* SMILES - equally see Noel O'Boyle's paper about this. Hence if you elect SMILES as a chemical reference in a database, test your tools to assign SMILES (e.g., with [cipvalidationsuite](https://cipvalidationsuite.github.io/ValidationSuite/)) before deployment and document how it fits into your intended workflow.




---


A younger approach is the assignment of *International Chemical Identifiers* (InChI) by an algorithm curated by the [InChI trust](https://www.inchi-trust.org/). Similar like a SMILES string, the InChI string is a simplified representation of the chemical structure submitted in layers (Hill formula, connectivity of skeleton atoms, charges, stereochemistry, ...) and it is possible to recover *one plausible* 3D structure from this string - for examples with their [executables](https://www.inchi-trust.org/download-here/). Further on, one can assign the ***InChI key*** a string of fixed length (27 ASCII characters), though (checksum like *practically*) you are no longer can retrieve the original structure submitted to the algorithm. Hence, InChI keys *can* represent an computational affordable approach to reference chemicals in databases. There are suppliers and databases which describe their chemicals both by SMILES, as well as InChI / InChI key.


Note this approach equally has some caveats:


* *For now*, the algorithm to assign *standard* InChI (and InChI key)
focuses on small molecules with less than 1024 atoms (Heller *et al.*).
For larger molecules (current limit 32766 atoms, e.g. polymers) you have
to assign InChI not yet considered as standard (as by current release 1.06,
distributed since December 2021).
* The present *default* algorithm to yield *standard* InChI (and *standard*
InChI key) does not discern [tautomers](https://en.wikipedia.org/wiki/Tautomer).
A consequence is e.g., [2-hydroxypyridine](https://en.wikipedia.org/wiki/2-Pyridone) (`Oc1ccccn1`) and its tautomeric
pyridone (`O=c1cccc[nH]1`) *both* yield *standard* InChI string
`InChI=1S/C5H5NO/c7-5-3-1-2-4-6-5/h1-4H,(H,6,7)` (note `1S`!) and
*standard* InChI key `UBQKCCHYAOITMY-UHFFFAOYSA-N`.


The assignment with the optional (additional) *fixed H layer* however
yields for 2-hydroxypyridine
`InChI=1/C5H5NO/c7-5-3-1-2-4-6-5/h1-4H,(H,6,7)/f/h7H` (note the now
*absent* `S`, and added sub string following `f`) and InChI key
`UBQKCCHYAOITMY-QDQILVOLNA-N` vs.
`1/C5H5NO/c7-5-3-1-2-4-6-5/h1-4H,(H,6,7)/f/h6H` and
`UBQKCCHYAOITMY-BRMMOCHJNA-N` for the isomeric pyridone. Consider the
second approach if your database *might* or indeed *does* contain such
compounds and document your choice for future users of the database.
* Beside InChI trust's [executables](https://www.inchi-trust.org/download-here/) for Windows, or Linux, your operation system / tool of preference
might/might not reflect the current version 1.06. The CLI executable
`inchi_main` provided by [DebiChem](https://tracker.debian.org/pkg/inchi)
for example is stuck in version 1.03 (represents the state of the art
by 2010) because InChI trust later adopted a bespoken license,
underwent/undergoes reorganization after the death of the lead developer.  

Hence, depending on the route you take, some of the more recent corrections
and improvements might not be available to you, or you compile the
executable with the [source code](https://www.inchi-trust.org/wp/download/106/INCHI-1-SRC.zip)
shared by the InChI trust.


In case of DebiChem, `inchi_main` already includes the optional assignment
of the fixed H layer, hence can discern tautomers. However, it processes
only `.sdf` of the elder V2000 format, and not `.sdf` V3000 (See e.g.,
[Biovia's definition](https://web.archive.org/web/20210219065450/https://discover.3ds.com/sites/default/files/2020-08/biovia_ctfileformats_2020.pdf)
of this file format. To some degree a conversion between the two dialects
is possible, e.g. thanks to openbabel).


Literature references:


O'Boyle, N. Towards a Universal SMILES representation - A standard method to generate canonical SMILES based on the InChI. *J. Cheminform.* **2012**, *4*, 22. [doi 10.1186/1758-2946-4-22](https://doi.org/10.1186/1758-2946-4-22), open access


Hanson, R. M; Musacchio, S.; Mayfield, J. W.; Vainio, M. J.; Yerin, A.; Redkin, D. Algorithmic Analysis of Cahn–Ingold–Prelog Rules of Stereochemistry: Proposals for Revised Rules and a Guide for Machine Implementation. *J. Chem. Inf. Model.* **2018**, *58*, 1755-1765. [doi 10.1021/acs.jcim.8b00324](https://doi.org/10.1021/acs.jcim.8b00324) and <https://github.com/CIPValidationSuite/ValidationSuite>


Heller, S.; McNaught, A.; Stein, S.; Tchekhovskoi, D.; Pletnev I. InChI - the worldwide chemical structure identifier standard. *J. Cheminform.* **2013**, *5*, 7. [doi 10.1186/1758-2946-5-7](https://doi.org/10.1186/1758-2946-5-7), open access.


Pletnev, I.; Erin, A.; McNaught, A.; Blinov, K.; Tchekhovskoi, D.; Heller, S. InChIKey collision resistance: an experimental testing. *J. Cheminform.* **2012**, *4*, 39. [doi 10.1186/1758-2946-4-39](https://doi.org/10.1186/1758-2946-4-39), open access.


 2