<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>Molecular representations in AI-driven drug discovery: a review and practical guide</title>
        <author>Laurianne David</author>
        <author>Amol Thakkar</author>
        <author>Rocío Mercado</author>
        <author>Ola Engkvist</author>
      </titleStmt>
      <publicationStmt>
        <p>Tag layer of the DHSS Meta-Tagging Project. The article text is reproduced from the
           staged copy named in sourceDesc and is not altered; the tags are held separately in
           standOff so that overlapping and nested spans are preserved.</p>
      </publicationStmt>
      <sourceDesc>
        <bibl>
          <title>Molecular representations in AI-driven drug discovery: a review and practical guide</title>
          <date>2020</date>
          <publisher>Journal of Cheminformatics</publisher>
          <idno type="DOI">10.1186/s13321-020-00460-5</idno>
          
          <idno type="record">david2020-molecular-representations-ai-drug-discovery-review</idno>
          <note type="staged-file">david2020-molecular-representations-ai-drug-discovery-review.txt, the project's staged copy</note>
          <note type="text-sha1">c3f1f3c60af2f74593c8c7d91d62789d612c906f</note>
          <note type="rights">cc-by</note>
        </bibl>
      </sourceDesc>
    </fileDesc>
    <profileDesc>
      <textClass><keywords><term>computational chemistry</term></keywords></textClass>
      <particDesc>
        <person xml:id="paper"><p>the paper's own words</p></person>
        <person xml:id="tagger"><p>the tag layer; a sentence written by the tagger about the
          paper, always anchored to a quotation but not itself a quotation</p></person>
      </particDesc>
    </profileDesc>
    <revisionDesc>
      <change when="2026-10-06"
              who="build_paper_edition.py">205 spans located by searching the stored text for the quote's exact words, allowing any whitespace between them</change>
    </revisionDesc>
  </teiHeader>
  <standOff>
    <spanGrp type="tags">
      <span xml:id="t0" from="#a1" to="#a2" type="object_of_study" ana="#object_of_study" resp="#paper">machine-readable representations of small molecules, reactions, macromolecules, and molecular depictions used in AI-driven drug discovery</span>
      <span xml:id="t1" from="#a7" to="#a8" type="research_question" ana="#research_question" resp="#paper">what major molecular-representation families exist, what information and tradeoffs do they encode, and how are they used in contemporary AI drug discovery</span>
      <span xml:id="t2" from="#a7" to="#a8" type="contribution" ana="#contribution" resp="#paper">a practical, non-exhaustive guide linking molecular graphs, file formats, line notations, descriptors, reaction and macromolecule representations, depictions, and AI applications</span>
      <span xml:id="t3" from="#a1" to="#a2" type="claim_type" ana="#claim_type" resp="#paper">existence</span>
      <span xml:id="t4" from="#a27" to="#a28" type="phenomenon" ana="#phenomenon" resp="#paper">the plurality, task dependence, expressiveness, compactness, interoperability, and computational use of chemical representations</span>
      <span xml:id="t5" from="#a7" to="#a8" type="method" ana="#method" resp="#paper">review<term>review</term></span>
      <span xml:id="t6" from="#a11" to="#a12" type="mechanisms" ana="#mechanisms[0]" resp="#tagger" cert="0.95">Maps molecular constituents onto graph nodes and edges.<term>atom-bond mapping</term></span>
      <span xml:id="t7" from="#a19" to="#a20" type="mechanisms" ana="#mechanisms[1]" resp="#tagger" cert="0.95">Encodes whether each ordered node pair is bonded.<term>adjacency matrix</term></span>
      <span xml:id="t8" from="#a25" to="#a26" type="mechanisms" ana="#mechanisms[2]" resp="#tagger" cert="0.95">Linearizes unordered nodes with deterministic or random tie-breaking.<term>graph traversal</term></span>
      <span xml:id="t9" from="#a41" to="#a42" type="mechanisms" ana="#mechanisms[3]" resp="#tagger" cert="0.95">Stores hydrogen count as a heavy-atom property to reduce file size.<term>implicit hydrogen</term></span>
      <span xml:id="t10" from="#a53" to="#a54" type="mechanisms" ana="#mechanisms[4]" resp="#tagger" cert="0.95">Changes the initial node while retaining depth-first traversal to augment data.<term>randomized SMILES</term></span>
      <span xml:id="t11" from="#a59" to="#a60" type="mechanisms" ana="#mechanisms[5]" resp="#tagger" cert="0.95">Generalizes atom and bond patterns with logical and recursive queries.<term>SMARTS</term></span>
      <span xml:id="t12" from="#a61" to="#a62" type="mechanisms" ana="#mechanisms[6]" resp="#tagger" cert="0.95">Separates formula, connectivity, charge, stereochemistry, and isotope information.<term>InChI layering</term></span>
      <span xml:id="t13" from="#a71" to="#a72" type="mechanisms" ana="#mechanisms[7]" resp="#tagger" cert="0.95">Assigns molecule-derived structural patterns into fixed-length bits.<term>hash function</term></span>
      <span xml:id="t14" from="#a79" to="#a80" type="mechanisms" ana="#mechanisms[8]" resp="#tagger" cert="0.95">Combines SMARTS context with SMILES bond changes for generic transformations.<term>SMIRKS</term></span>
      <span xml:id="t15" from="#a81" to="#a82" type="mechanisms" ana="#mechanisms[9]" resp="#tagger" cert="0.95">Records molecules, roles, balance, steps, equilibrium, and direction.<term>RInChI layering</term></span>
      <span xml:id="t16" from="#a85" to="#a86" type="mechanisms" ana="#mechanisms[10]" resp="#tagger" cert="0.95">Superposes reactants and products while marking changed atoms and bonds.<term>condensed graph of reaction</term></span>
      <span xml:id="t17" from="#a93" to="#a94" type="mechanisms" ana="#mechanisms[11]" resp="#tagger" cert="0.95">Subtracts reactant from product fingerprints to encode structural change.<term>reaction fingerprint</term></span>
      <span xml:id="t18" from="#a101" to="#a102" type="mechanisms" ana="#mechanisms[12]" resp="#tagger" cert="0.95">Translates polymer sequences to SMILES through monomer lookup and concatenation.<term>CHUCKLES</term></span>
      <span xml:id="t19" from="#a119" to="#a120" type="mechanisms" ana="#mechanisms[13]" resp="#tagger" cert="0.95">Uses a graph network to produce an embedding for prediction or design.<term>graph representation learning</term></span>
      <span xml:id="t20" from="#a127" to="#a128" type="mechanisms" ana="#mechanisms[14]" resp="#tagger" cert="0.95">Translates 2D chemical depictions in papers and patents into standard representations.<term>OCR</term></span>
      <span xml:id="t21" from="#a5" to="#a6" type="limitations" ana="#limitations[0]" resp="#tagger" cert="0.95">An empirical formula omits connectivity and geometry and can denote several compounds.</span>
      <span xml:id="t22" from="#a7" to="#a8" type="limitations" ana="#limitations[1]" resp="#tagger" cert="0.95">The review is deliberately non-exhaustive and restricted to active AI-relevant areas.</span>
      <span xml:id="t23" from="#a13" to="#a14" type="limitations" ana="#limitations[2]" resp="#tagger" cert="0.95">Molecular graphs lack intrinsic spatial position and must encode 3D relationships as attributes.</span>
      <span xml:id="t24" from="#a31" to="#a32" type="limitations" ana="#limitations[3]" resp="#tagger" cert="0.95">Pairwise graph models fail for several delocalized and non-valence-bond structures.</span>
      <span xml:id="t25" from="#a33" to="#a34" type="limitations" ana="#limitations[4]" resp="#tagger" cert="0.95">Hypergraphs address multivalent bonds but remain uncommon.</span>
      <span xml:id="t26" from="#a35" to="#a36" type="limitations" ana="#limitations[5]" resp="#tagger" cert="0.95">Static graphs may misrepresent dynamically rearranging molecules.</span>
      <span xml:id="t27" from="#a37" to="#a38" type="limitations" ana="#limitations[6]" resp="#tagger" cert="0.95">Graph matrices are bulky, difficult to search, and grow at least quadratically with node count.</span>
      <span xml:id="t28" from="#a55" to="#a56" type="limitations" ana="#limitations[7]" resp="#tagger" cert="0.95">SMILES struggles with structures that molecular graphs themselves cannot describe.</span>
      <span xml:id="t29" from="#a57" to="#a58" type="limitations" ana="#limitations[8]" resp="#tagger" cert="0.95">Proprietary SMILES canonicalization causes toolkit-dependent implementations.</span>
      <span xml:id="t30" from="#a63" to="#a64" type="limitations" ana="#limitations[9]" resp="#tagger" cert="0.95">InChIKeys can collide and InChI cannot always regenerate its source molecular graph.</span>
      <span xml:id="t31" from="#a77" to="#a78" type="limitations" ana="#limitations[10]" resp="#tagger" cert="0.95">Reaction SMILES omits reaction-centre and condition metadata.</span>
      <span xml:id="t32" from="#a83" to="#a84" type="limitations" ana="#limitations[11]" resp="#tagger" cert="0.95">RInChI has no SMARTS/SMIRKS equivalent for substructure or generic transformations.</span>
      <span xml:id="t33" from="#a95" to="#a96" type="limitations" ana="#limitations[12]" resp="#tagger" cert="0.95">Macromolecular stochasticity and undefined chain length hinder representation.</span>
      <span xml:id="t34" from="#a127" to="#a128" type="limitations" ana="#limitations[13]" resp="#tagger" cert="0.95">OCR is hindered by resolution, abbreviations, and complex image context.</span>
      <span xml:id="t35" from="#a3" to="#a4" type="concepts" ana="#concepts[0]" resp="#paper" cert="0.95">chemical representation<term>chemical representation</term></span>
      <span xml:id="t36" from="#a3" to="#a4" type="concepts" ana="#concepts[1]" resp="#paper" cert="0.95">encoding of a chemical compound<term>encoding of a chemical compound</term></span>
      <span xml:id="t37" from="#a3" to="#a4" type="concepts" ana="#concepts[2]" resp="#paper" cert="0.95">linear representations<term>linear representations</term></span>
      <span xml:id="t38" from="#a3" to="#a4" type="concepts" ana="#concepts[3]" resp="#paper" cert="0.95">notations<term>notations</term></span>
      <span xml:id="t39" from="#a11" to="#a12" type="concepts" ana="#concepts[4]" resp="#paper" cert="0.95">molecular graph representation<term>molecular graph representation</term></span>
      <span xml:id="t40" from="#a13" to="#a14" type="concepts" ana="#concepts[5]" resp="#paper" cert="0.95">2D object<term>2D object</term></span>
      <span xml:id="t41" from="#a15" to="#a16" type="concepts" ana="#concepts[6]" resp="#paper" cert="0.95">graph<term>graph</term></span>
      <span xml:id="t42" from="#a15" to="#a16" type="concepts" ana="#concepts[7]" resp="#paper" cert="0.95">tuple<term>tuple</term></span>
      <span xml:id="t43" from="#a19" to="#a20" type="concepts" ana="#concepts[8]" resp="#paper" cert="0.95">adjacency matrix<term>adjacency matrix</term></span>
      <span xml:id="t44" from="#a19" to="#a20" type="concepts" ana="#concepts[9]" resp="#paper" cert="0.95">connectivity matrix<term>connectivity matrix</term></span>
      <span xml:id="t45" from="#a21" to="#a22" type="concepts" ana="#concepts[10]" resp="#paper" cert="0.95">node features matrix<term>node features matrix</term></span>
      <span xml:id="t46" from="#a23" to="#a24" type="concepts" ana="#concepts[11]" resp="#paper" cert="0.95">edge features matrix<term>edge features matrix</term></span>
      <span xml:id="t47" from="#a25" to="#a26" type="concepts" ana="#concepts[12]" resp="#paper" cert="0.95">graph traversal algorithm<term>graph traversal algorithm</term></span>
      <span xml:id="t48" from="#a25" to="#a26" type="concepts" ana="#concepts[13]" resp="#paper" cert="0.95">depth-first<term>depth-first</term></span>
      <span xml:id="t49" from="#a25" to="#a26" type="concepts" ana="#concepts[14]" resp="#paper" cert="0.95">breadth-first<term>breadth-first</term></span>
      <span xml:id="t50" from="#a25" to="#a26" type="concepts" ana="#concepts[15]" resp="#paper" cert="0.95">random search<term>random search</term></span>
      <span xml:id="t51" from="#a33" to="#a34" type="concepts" ana="#concepts[16]" resp="#paper" cert="0.95">hypergraphs<term>hypergraphs</term></span>
      <span xml:id="t52" from="#a39" to="#a40" type="concepts" ana="#concepts[17]" resp="#paper" cert="0.95">linear notations<term>linear notations</term></span>
      <span xml:id="t53" from="#a41" to="#a42" type="concepts" ana="#concepts[18]" resp="#paper" cert="0.95">connection table<term>connection table</term></span>
      <span xml:id="t54" from="#a43" to="#a44" type="concepts" ana="#concepts[19]" resp="#paper" cert="0.95">CTfiles<term>CTfiles</term></span>
      <span xml:id="t55" from="#a51" to="#a52" type="concepts" ana="#concepts[20]" resp="#paper" cert="0.95">SMILES<term>SMILES</term></span>
      <span xml:id="t56" from="#a53" to="#a54" type="concepts" ana="#concepts[21]" resp="#paper" cert="0.95">randomized SMILES<term>randomized SMILES</term></span>
      <span xml:id="t57" from="#a57" to="#a58" type="concepts" ana="#concepts[22]" resp="#paper" cert="0.95">OpenSMILES<term>OpenSMILES</term></span>
      <span xml:id="t58" from="#a59" to="#a60" type="concepts" ana="#concepts[23]" resp="#paper" cert="0.95">SMARTS<term>SMARTS</term></span>
      <span xml:id="t59" from="#a61" to="#a62" type="concepts" ana="#concepts[24]" resp="#paper" cert="0.95">InChI<term>InChI</term></span>
      <span xml:id="t60" from="#a63" to="#a64" type="concepts" ana="#concepts[25]" resp="#paper" cert="0.95">InChIKey<term>InChIKey</term></span>
      <span xml:id="t61" from="#a63" to="#a64" type="concepts" ana="#concepts[26]" resp="#paper" cert="0.95">InChIKey collision<term>InChIKey collision</term></span>
      <span xml:id="t62" from="#a65" to="#a66" type="concepts" ana="#concepts[27]" resp="#paper" cert="0.95">molecular descriptors<term>molecular descriptors</term></span>
      <span xml:id="t63" from="#a67" to="#a68" type="concepts" ana="#concepts[28]" resp="#paper" cert="0.95">structural keys<term>structural keys</term></span>
      <span xml:id="t64" from="#a67" to="#a68" type="concepts" ana="#concepts[29]" resp="#paper" cert="0.95">bit strings<term>bit strings</term></span>
      <span xml:id="t65" from="#a69" to="#a70" type="concepts" ana="#concepts[30]" resp="#paper" cert="0.95">MACCS<term>MACCS</term></span>
      <span xml:id="t66" from="#a71" to="#a72" type="concepts" ana="#concepts[31]" resp="#paper" cert="0.95">chemical fingerprints<term>chemical fingerprints</term></span>
      <span xml:id="t67" from="#a77" to="#a78" type="concepts" ana="#concepts[32]" resp="#paper" cert="0.95">Reaction SMILES<term>Reaction SMILES</term></span>
      <span xml:id="t68" from="#a79" to="#a80" type="concepts" ana="#concepts[33]" resp="#paper" cert="0.95">SMIRKS<term>SMIRKS</term></span>
      <span xml:id="t69" from="#a81" to="#a82" type="concepts" ana="#concepts[34]" resp="#paper" cert="0.95">RInChI<term>RInChI</term></span>
      <span xml:id="t70" from="#a85" to="#a86" type="concepts" ana="#concepts[35]" resp="#paper" cert="0.95">CGR<term>CGR</term></span>
      <span xml:id="t71" from="#a87" to="#a88" type="concepts" ana="#concepts[36]" resp="#paper" cert="0.95">BE-matrix<term>BE-matrix</term></span>
      <span xml:id="t72" from="#a89" to="#a90" type="concepts" ana="#concepts[37]" resp="#paper" cert="0.95">HORACE<term>HORACE</term></span>
      <span xml:id="t73" from="#a91" to="#a92" type="concepts" ana="#concepts[38]" resp="#paper" cert="0.95">reaction centre<term>reaction centre</term></span>
      <span xml:id="t74" from="#a93" to="#a94" type="concepts" ana="#concepts[39]" resp="#paper" cert="0.95">reaction fingerprints<term>reaction fingerprints</term></span>
      <span xml:id="t75" from="#a93" to="#a94" type="concepts" ana="#concepts[40]" resp="#paper" cert="0.95">vector representations of reactions<term>vector representations of reactions</term></span>
      <span xml:id="t76" from="#a95" to="#a96" type="concepts" ana="#concepts[41]" resp="#paper" cert="0.95">macromolecules<term>macromolecules</term></span>
      <span xml:id="t77" from="#a97" to="#a98" type="concepts" ana="#concepts[42]" resp="#paper" cert="0.95">amino acid sequences<term>amino acid sequences</term></span>
      <span xml:id="t78" from="#a99" to="#a100" type="concepts" ana="#concepts[43]" resp="#paper" cert="0.95">Peptides<term>Peptides</term></span>
      <span xml:id="t79" from="#a99" to="#a100" type="concepts" ana="#concepts[44]" resp="#paper" cert="0.95">chains of 2 to 50 AAs<term>chains of 2 to 50 AAs</term></span>
      <span xml:id="t80" from="#a101" to="#a102" type="concepts" ana="#concepts[45]" resp="#paper" cert="0.95">CHUCKLES<term>CHUCKLES</term></span>
      <span xml:id="t81" from="#a103" to="#a104" type="concepts" ana="#concepts[46]" resp="#paper" cert="0.95">HELM<term>HELM</term></span>
      <span xml:id="t82" from="#a103" to="#a104" type="concepts" ana="#concepts[47]" resp="#paper" cert="0.95">SMILES-like format<term>SMILES-like format</term></span>
      <span xml:id="t83" from="#a107" to="#a108" type="concepts" ana="#concepts[48]" resp="#paper" cert="0.95">Proteins<term>Proteins</term></span>
      <span xml:id="t84" from="#a107" to="#a108" type="concepts" ana="#concepts[49]" resp="#paper" cert="0.95">polypeptides<term>polypeptides</term></span>
      <span xml:id="t85" from="#a107" to="#a108" type="concepts" ana="#concepts[50]" resp="#paper" cert="0.95">Protein Data Bank<term>Protein Data Bank</term></span>
      <span xml:id="t86" from="#a109" to="#a110" type="concepts" ana="#concepts[51]" resp="#paper" cert="0.95">WURCS<term>WURCS</term></span>
      <span xml:id="t87" from="#a111" to="#a112" type="concepts" ana="#concepts[52]" resp="#paper" cert="0.95">BigSMILES<term>BigSMILES</term></span>
      <span xml:id="t88" from="#a113" to="#a114" type="concepts" ana="#concepts[53]" resp="#paper" cert="0.95">2D depictions<term>2D depictions</term></span>
      <span xml:id="t89" from="#a115" to="#a116" type="concepts" ana="#concepts[54]" resp="#paper" cert="0.95">3D depictions<term>3D depictions</term></span>
      <span xml:id="t90" from="#a117" to="#a118" type="concepts" ana="#concepts[55]" resp="#paper" cert="0.95">representation learning<term>representation learning</term></span>
      <span xml:id="t91" from="#a117" to="#a118" type="concepts" ana="#concepts[56]" resp="#paper" cert="0.95">internal representation<term>internal representation</term></span>
      <span xml:id="t92" from="#a119" to="#a120" type="concepts" ana="#concepts[57]" resp="#paper" cert="0.95">graph embedding<term>graph embedding</term></span>
      <span xml:id="t93" from="#a121" to="#a122" type="concepts" ana="#concepts[58]" resp="#paper" cert="0.95">learned fingerprints<term>learned fingerprints</term></span>
      <span xml:id="t94" from="#a123" to="#a124" type="concepts" ana="#concepts[59]" resp="#paper" cert="0.95">retrosynthesis<term>retrosynthesis</term></span>
      <span xml:id="t95" from="#a125" to="#a126" type="concepts" ana="#concepts[60]" resp="#paper" cert="0.95">protein structure prediction<term>protein structure prediction</term></span>
      <span xml:id="t96" from="#a127" to="#a128" type="concepts" ana="#concepts[61]" resp="#paper" cert="0.95">Optical Character Recognition<term>Optical Character Recognition</term></span>
      <span xml:id="t97" from="#a131" to="#a132" type="concepts" ana="#concepts[62]" resp="#paper" cert="0.95">human readable<term>human readable</term></span>
      <span xml:id="t98" from="#a3" to="#a4" type="unhoused_relations" ana="#unhoused_relations[0]" resp="#tagger" cert="0.95">chemical representation → encoding of a chemical compound<note>The review defines a chemical representation as any encoding of a chemical compound.</note></span>
      <span xml:id="t99" from="#a13" to="#a14" type="unhoused_relations" ana="#unhoused_relations[1]" resp="#tagger" cert="0.95">molecular graph representation → 2D object<note>A molecular graph representation is formally a 2D object.</note></span>
      <span xml:id="t100" from="#a15" to="#a16" type="unhoused_relations" ana="#unhoused_relations[2]" resp="#tagger" cert="0.95">graph → tuple<note>A graph is formally defined as a tuple of node and edge sets.</note></span>
      <span xml:id="t101" from="#a67" to="#a68" type="unhoused_relations" ana="#unhoused_relations[3]" resp="#tagger" cert="0.95">structural keys → bit strings<note>Structural keys are bit strings encoding group absence and presence.</note></span>
      <span xml:id="t102" from="#a99" to="#a100" type="unhoused_relations" ana="#unhoused_relations[4]" resp="#tagger" cert="0.95">Peptides → chains of 2 to 50 AAs<note>Peptides are chains of two to fifty amino acids.</note></span>
      <span xml:id="t103" from="#a107" to="#a108" type="unhoused_relations" ana="#unhoused_relations[5]" resp="#tagger" cert="0.95">Proteins → polypeptides<note>Proteins are polypeptides of fifty or more amino acids.</note></span>
      <span xml:id="t104" from="#a5" to="#a6" type="unhoused_relations" ana="#unhoused_relations[6]" resp="#tagger" cert="0.95">molecular formula → molecular connectivity and geometry<note>A molecular formula does not encode atom linkage or molecular geometry.</note></span>
      <span xml:id="t105" from="#a11" to="#a12" type="unhoused_relations" ana="#unhoused_relations[7]" resp="#tagger" cert="0.95">atoms and bonds → nodes and edges<note>Molecular graphs map atoms and bonds onto nodes and edges.</note></span>
      <span xml:id="t106" from="#a25" to="#a26" type="unhoused_relations" ana="#unhoused_relations[8]" resp="#tagger" cert="0.95">graph traversal algorithm → node order<note>Traversal selects the order used by matrix and string representations.</note></span>
      <span xml:id="t107" from="#a27" to="#a28" type="unhoused_relations" ana="#unhoused_relations[9]" resp="#tagger" cert="0.95">application task → molecular representation<note>The appropriate representation depends on the task.</note></span>
      <span xml:id="t108" from="#a31" to="#a32" type="unhoused_relations" ana="#unhoused_relations[10]" resp="#tagger" cert="0.95">pairwise molecular graph → delocalized and multivalent bonding<note>Ordinary molecular graphs cannot describe several non-pairwise bonding schemes.</note></span>
      <span xml:id="t109" from="#a35" to="#a36" type="unhoused_relations" ana="#unhoused_relations[11]" resp="#tagger" cert="0.95">dynamic molecular rearrangement → single static graph<note>A static graph may be inappropriate or detrimental for a rearranging molecule.</note></span>
      <span xml:id="t110" from="#a41" to="#a42" type="unhoused_relations" ana="#unhoused_relations[12]" resp="#tagger" cert="0.95">implicit hydrogens → connection-table size<note>Treating hydrogens as heavy-atom properties reduces atom and bond blocks.</note></span>
      <span xml:id="t111" from="#a53" to="#a54" type="unhoused_relations" ana="#unhoused_relations[13]" resp="#tagger" cert="0.95">randomized SMILES → data augmentation<note>Alternative starting nodes generate multiple valid strings for training.</note></span>
      <span xml:id="t112" from="#a57" to="#a58" type="unhoused_relations" ana="#unhoused_relations[14]" resp="#tagger" cert="0.95">proprietary SMILES canonicalization → toolkit variation<note>A proprietary algorithm leads implementations to vary.</note></span>
      <span xml:id="t113" from="#a59" to="#a60" type="unhoused_relations" ana="#unhoused_relations[15]" resp="#tagger" cert="0.95">SMARTS → SMILES<note>All SMILES can be SMARTS, but the reverse is false and decoding differs.</note></span>
      <span xml:id="t114" from="#a63" to="#a64" type="unhoused_relations" ana="#unhoused_relations[16]" resp="#tagger" cert="0.95">InChIKey → InChI<note>A key can occasionally map to more than one parent InChI.</note></span>
      <span xml:id="t115" from="#a71" to="#a72" type="unhoused_relations" ana="#unhoused_relations[17]" resp="#tagger" cert="0.95">hash function → fingerprint bits<note>Hashing assigns molecular patterns to non-unique fixed-length positions.</note></span>
      <span xml:id="t116" from="#a75" to="#a76" type="unhoused_relations" ana="#unhoused_relations[18]" resp="#tagger" cert="0.95">molecular-representation limitations → reaction representations<note>Reaction formats inherit limitations of their molecular components.</note></span>
      <span xml:id="t117" from="#a83" to="#a84" type="unhoused_relations" ana="#unhoused_relations[19]" resp="#tagger" cert="0.95">RInChI → generic transformation search<note>RInChI lacks a SMARTS or SMIRKS equivalent.</note></span>
      <span xml:id="t118" from="#a93" to="#a94" type="unhoused_relations" ana="#unhoused_relations[20]" resp="#tagger" cert="0.95">reaction fingerprint → reaction graph<note>A reaction fingerprint cannot be easily converted into a reaction graph.</note></span>
      <span xml:id="t119" from="#a101" to="#a102" type="unhoused_relations" ana="#unhoused_relations[21]" resp="#tagger" cert="0.95">CHUCKLES → polymer sequence and SMILES<note>CHUCKLES translates between monomer sequences and SMILES.</note></span>
      <span xml:id="t120" from="#a105" to="#a106" type="unhoused_relations" ana="#unhoused_relations[22]" resp="#tagger" cert="0.95">HELM polymer-level readability → modified peptide design<note>Polymer-level notation can make residue modifications more intuitive.</note></span>
      <span xml:id="t121" from="#a109" to="#a110" type="unhoused_relations" ana="#unhoused_relations[23]" resp="#tagger" cert="0.95">glycan sequence notation → docking<note>Sequence-based glycan representations do not support atom-based docking without conversion.</note></span>
      <span xml:id="t122" from="#a119" to="#a120" type="unhoused_relations" ana="#unhoused_relations[24]" resp="#tagger" cert="0.95">molecular graph → graph embedding<note>A graph network transforms the full graph into a predictive embedding.</note></span>
      <span xml:id="t123" from="#a127" to="#a128" type="unhoused_relations" ana="#unhoused_relations[25]" resp="#tagger" cert="0.95">image resolution and context → chemical OCR<note>Image quality, abbreviations, and layout hinder representation extraction.</note></span>
      <span xml:id="t124" from="#a3" to="#a4" type="senses" ana="#senses[0]" resp="#tagger" cert="0.95">chemical representation as any compound encoding, with notation reserved for linear forms</span>
      <span xml:id="t125" from="#a9" to="#a10" type="senses" ana="#senses[1]" resp="#tagger" cert="0.95">molecular graph as mathematical structure distinct from graph-derived file formats</span>
      <span xml:id="t126" from="#a13" to="#a14" type="senses" ana="#senses[2]" resp="#tagger" cert="0.95">3D graph information as attributes rather than intrinsic spatial positions</span>
      <span xml:id="t127" from="#a25" to="#a26" type="senses" ana="#senses[3]" resp="#tagger" cert="0.95">canonical consistency as deterministic node ordering and tie-breaking</span>
      <span xml:id="t128" from="#a27" to="#a28" type="senses" ana="#senses[4]" resp="#tagger" cert="0.95">representation quality as task dependent rather than absolute</span>
      <span xml:id="t129" from="#a39" to="#a40" type="senses" ana="#senses[5]" resp="#tagger" cert="0.95">linear notation as compact identity-search representation rather than direct matrix</span>
      <span xml:id="t130" from="#a53" to="#a54" type="senses" ana="#senses[6]" resp="#tagger" cert="0.95">randomized SMILES as random initial node with deterministic depth-first traversal</span>
      <span xml:id="t131" from="#a49" to="#a50" type="senses" ana="#senses[7]" resp="#tagger" cert="0.95">unique notation as one notation per compound and unambiguous notation as one decoded compound</span>
      <span xml:id="t132" from="#a65" to="#a66" type="senses" ana="#senses[8]" resp="#tagger" cert="0.95">descriptor as property encoding rather than reconstructable molecular structure</span>
      <span xml:id="t133" from="#a75" to="#a76" type="senses" ana="#senses[9]" resp="#tagger" cert="0.95">reaction representation as inheriting the limitations of its molecular components</span>
      <span xml:id="t134" from="#a91" to="#a92" type="senses" ana="#senses[10]" resp="#tagger" cert="0.95">reaction centre as changed atoms and bonds rather than the full reaction record</span>
      <span xml:id="t135" from="#a97" to="#a98" type="senses" ana="#senses[11]" resp="#tagger" cert="0.95">macromolecule representation as an interface between atomic chemistry and biological sequence</span>
      <span xml:id="t136" from="#a103" to="#a104" type="senses" ana="#senses[12]" resp="#tagger" cert="0.95">HELM granularity as complex polymer, simple polymer, monomer, and atom</span>
      <span xml:id="t137" from="#a117" to="#a118" type="senses" ana="#senses[13]" resp="#tagger" cert="0.95">representation learning as learned vectors rather than hand-calculated fingerprints</span>
      <span xml:id="t138" from="#a129" to="#a130" type="senses" ana="#senses[14]" resp="#tagger" cert="0.95">representation selection as a multi-stage workflow decision</span>
      <span xml:id="t139" from="#a9" to="#a10" type="claim_relations" ana="#claim_relations[0]" resp="#tagger" cert="0.95">builds-on → the molecular graph as the common base of many chemical formats<note>note: The review organizes many later formats around this shared abstraction.</note></span>
      <span xml:id="t140" from="#a7" to="#a8" type="claim_relations" ana="#claim_relations[1]" resp="#tagger" cert="0.95">contrasts-with → an exhaustive catalog of all chemical representations<note>note: The authors explicitly limit coverage to active AI and ML areas.</note></span>
      <span xml:id="t141" from="#a49" to="#a50" type="claim_relations" ana="#claim_relations[2]" resp="#tagger" cert="0.95">builds-on → IUPAC representation terminology and standards<note>note: The review applies IUPAC&#x27;s uniqueness and ambiguity distinctions.</note></span>
      <span xml:id="t142" from="#a133" to="#a134" type="claim_relations" ana="#claim_relations[3]" resp="#tagger" cert="0.95">builds-on → reported AI applications across graphs, strings, reactions, macromolecules, and images<note>note: The guide synthesizes established uses rather than introducing one new algorithm.</note></span>
      <span xml:id="t143" from="#a3" to="#a4" type="concept_edges" ana="#concept_edges[0]" resp="#tagger" cert="0.95">linear representations —same-as→ notations<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Direct naming equivalence. · the relation stated: Linear representations are referred to as notations.</note><term>linear representations</term><term>notations</term></span>
      <span xml:id="t144" from="#a19" to="#a20" type="concept_edges" ana="#concept_edges[1]" resp="#tagger" cert="0.95">adjacency matrix —same-as→ connectivity matrix<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Direct naming equivalence. · the relation stated: The adjacency matrix is also referred to as the connectivity matrix.</note><term>adjacency matrix</term><term>connectivity matrix</term></span>
      <span xml:id="t145" from="#a93" to="#a94" type="concept_edges" ana="#concept_edges[2]" resp="#tagger" cert="0.95">reaction fingerprints —is-a→ vector representations of reactions<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Direct categorical definition. · the relation stated: Reaction fingerprints are vector representations of reactions.</note><term>reaction fingerprints</term><term>vector representations of reactions</term></span>
      <span xml:id="t146" from="#a1" to="#a2" type="content_tags" ana="#content_tags.findings[0]" resp="#tagger" cert="0.95">Chemical representation design proliferated because computers advanced rapidly while molecules require many structural and chemical characteristics.</span>
      <span xml:id="t147" from="#a9" to="#a10" type="content_tags" ana="#content_tags.findings[1]" resp="#tagger" cert="0.95">Most representation families covered by the review build on molecular graphs.</span>
      <span xml:id="t148" from="#a11" to="#a12" type="content_tags" ana="#content_tags.findings[2]" resp="#tagger" cert="0.95">A molecular graph maps atoms and bonds to nodes and edges but stores spatial information only as attributes.</span>
      <span xml:id="t149" from="#a17" to="#a18" type="content_tags" ana="#content_tags.findings[3]" resp="#tagger" cert="0.95">Matrix encodings require artificial node order even though mathematical graph sets are unordered.</span>
      <span xml:id="t150" from="#a25" to="#a26" type="content_tags" ana="#content_tags.findings[4]" resp="#tagger" cert="0.95">Graph traversal and tie-breaking determine whether software regenerates a consistent representation.</span>
      <span xml:id="t151" from="#a27" to="#a28" type="content_tags" ana="#content_tags.findings[5]" resp="#tagger" cert="0.95">No single representation is correct for every molecular task.</span>
      <span xml:id="t152" from="#a29" to="#a30" type="content_tags" ana="#content_tags.findings[6]" resp="#tagger" cert="0.95">Graph substructures remain interpretable, unlike arbitrary substrings of SMILES.</span>
      <span xml:id="t153" from="#a31" to="#a32" type="content_tags" ana="#content_tags.findings[7]" resp="#tagger" cert="0.95">Pairwise molecular graphs cannot faithfully describe several delocalized, ionic, polycentric, or metal-bonded systems.</span>
      <span xml:id="t154" from="#a35" to="#a36" type="content_tags" ana="#content_tags.findings[8]" resp="#tagger" cert="0.95">A single static graph can be detrimental when molecular bonding rearranges on the problem timescale.</span>
      <span xml:id="t155" from="#a39" to="#a40" type="content_tags" ana="#content_tags.findings[9]" resp="#tagger" cert="0.95">Linear notations trade graph bulk for compact, searchable strings.</span>
      <span xml:id="t156" from="#a53" to="#a54" type="content_tags" ana="#content_tags.findings[10]" resp="#tagger" cert="0.95">SMILES is non-unique and unambiguous, while randomized SMILES supplies data augmentation through alternative atom orderings.</span>
      <span xml:id="t157" from="#a57" to="#a58" type="content_tags" ana="#content_tags.findings[11]" resp="#tagger" cert="0.95">Proprietary canonicalization causes different SMILES implementations to vary.</span>
      <span xml:id="t158" from="#a63" to="#a64" type="content_tags" ana="#content_tags.findings[12]" resp="#tagger" cert="0.95">InChI is layered and canonical, while InChIKey is compact but can collide and InChI is not always graph-decodable.</span>
      <span xml:id="t159" from="#a65" to="#a66" type="content_tags" ana="#content_tags.findings[13]" resp="#tagger" cert="0.95">Descriptors encode chemical properties rather than exact reconstructable structure.</span>
      <span xml:id="t160" from="#a71" to="#a72" type="content_tags" ana="#content_tags.findings[14]" resp="#tagger" cert="0.95">Hashed fingerprints map molecule-derived patterns into fixed-length, potentially non-unique bits.</span>
      <span xml:id="t161" from="#a75" to="#a76" type="content_tags" ana="#content_tags.findings[15]" resp="#tagger" cert="0.95">Reaction representations inherit limitations from their underlying molecular representations.</span>
      <span xml:id="t162" from="#a83" to="#a84" type="content_tags" ana="#content_tags.findings[16]" resp="#tagger" cert="0.95">RInChI is order invariant and supports duplicate-reaction identification but lacks a generic-transformation equivalent.</span>
      <span xml:id="t163" from="#a93" to="#a94" type="content_tags" ana="#content_tags.findings[17]" resp="#tagger" cert="0.95">Reaction fingerprints encode product-reactant structural change but do not readily convert back to reaction graphs.</span>
      <span xml:id="t164" from="#a95" to="#a96" type="content_tags" ana="#content_tags.findings[18]" resp="#tagger" cert="0.95">Macromolecule representation remains less studied and must bridge atomic and sequence descriptions.</span>
      <span xml:id="t165" from="#a103" to="#a104" type="content_tags" ana="#content_tags.findings[19]" resp="#tagger" cert="0.95">HELM combines SMILES-like monomers, simplified sequence forms, and graphs across a structure hierarchy.</span>
      <span xml:id="t166" from="#a117" to="#a118" type="content_tags" ana="#content_tags.findings[20]" resp="#tagger" cert="0.95">Representation learning creates internal vectors for prediction, making input information selection essential.</span>
      <span xml:id="t167" from="#a119" to="#a120" type="content_tags" ana="#content_tags.findings[21]" resp="#tagger" cert="0.95">Graph embeddings, SMILES language models, learned fingerprints, reaction formats, sequences, and images all support distinct AI tasks.</span>
      <span xml:id="t168" from="#a129" to="#a130" type="content_tags" ana="#content_tags.findings[22]" resp="#tagger" cert="0.95">Many drug-discovery workflows require several representations in sequence or simultaneously.</span>
      <span xml:id="t169" from="#a131" to="#a132" type="content_tags" ana="#content_tags.findings[23]" resp="#tagger" cert="0.95">Representation persistence reflects computation, readability, history, and continuity as well as chemical expressiveness.</span>
      <span xml:id="t170" from="#a3" to="#a4" type="content_tags" ana="#content_tags.definitions[0]" resp="#tagger" cert="0.95">any encoding of a chemical compound<term>chemical representation</term></span>
      <span xml:id="t171" from="#a3" to="#a4" type="content_tags" ana="#content_tags.definitions[1]" resp="#tagger" cert="0.95">a linear chemical representation<term>notation</term></span>
      <span xml:id="t172" from="#a11" to="#a12" type="content_tags" ana="#content_tags.definitions[2]" resp="#tagger" cert="0.95">a graph mapping atoms and bonds to nodes and edges<term>molecular graph</term></span>
      <span xml:id="t173" from="#a15" to="#a16" type="content_tags" ana="#content_tags.definitions[3]" resp="#tagger" cert="0.95">a tuple of node and edge sets<term>graph</term></span>
      <span xml:id="t174" from="#a19" to="#a20" type="content_tags" ana="#content_tags.definitions[4]" resp="#tagger" cert="0.95">a matrix recording pairwise node connectivity<term>adjacency matrix</term></span>
      <span xml:id="t175" from="#a51" to="#a52" type="content_tags" ana="#content_tags.definitions[5]" resp="#tagger" cert="0.95">a popular non-unique, unambiguous line notation generated by graph traversal<term>SMILES</term></span>
      <span xml:id="t176" from="#a59" to="#a60" type="content_tags" ana="#content_tags.definitions[6]" resp="#tagger" cert="0.95">a SMILES extension for generic substructure queries<term>SMARTS</term></span>
      <span xml:id="t177" from="#a61" to="#a62" type="content_tags" ana="#content_tags.definitions[7]" resp="#tagger" cert="0.95">an open layered canonical chemical notation<term>InChI</term></span>
      <span xml:id="t178" from="#a67" to="#a68" type="content_tags" ana="#content_tags.definitions[8]" resp="#tagger" cert="0.95">a bit string marking predefined chemical-group presence<term>structural key</term></span>
      <span xml:id="t179" from="#a71" to="#a72" type="content_tags" ana="#content_tags.definitions[9]" resp="#tagger" cert="0.95">a fixed-length vector hashing molecule-derived patterns to non-unique bits<term>hashed fingerprint</term></span>
      <span xml:id="t180" from="#a79" to="#a80" type="content_tags" ana="#content_tags.definitions[10]" resp="#tagger" cert="0.95">a SMILES-SMARTS hybrid specifying generic reaction transformations<term>SMIRKS</term></span>
      <span xml:id="t181" from="#a81" to="#a82" type="content_tags" ana="#content_tags.definitions[11]" resp="#tagger" cert="0.95">an order-invariant layered reaction identifier<term>RInChI</term></span>
      <span xml:id="t182" from="#a93" to="#a94" type="content_tags" ana="#content_tags.definitions[12]" resp="#tagger" cert="0.95">a vector of structural changes at a reaction centre<term>reaction fingerprint</term></span>
      <span xml:id="t183" from="#a117" to="#a118" type="content_tags" ana="#content_tags.definitions[13]" resp="#tagger" cert="0.95">learning an internal vector for an object and using it in prediction<term>representation learning</term></span>
      <span xml:id="t184" from="#a13" to="#a14" type="content_tags" ana="#content_tags.quantities[0]" resp="#tagger" cert="0.95">2D — formal dimensionality of a molecular graph</span>
      <span xml:id="t185" from="#a41" to="#a42" type="content_tags" ana="#content_tags.quantities[1]" resp="#tagger" cert="0.95">6 — parts of a connection table</span>
      <span xml:id="t186" from="#a45" to="#a46" type="content_tags" ana="#content_tags.quantities[2]" resp="#tagger" cert="0.95">612 bytes — example Molfile size for d-alanine</span>
      <span xml:id="t187" from="#a45" to="#a46" type="content_tags" ana="#content_tags.quantities[3]" resp="#tagger" cert="0.95">15 bytes — example SMILES size for d-alanine</span>
      <span xml:id="t188" from="#a45" to="#a46" type="content_tags" ana="#content_tags.quantities[4]" resp="#tagger" cert="0.95">59 bytes — example InChI size for d-alanine</span>
      <span xml:id="t189" from="#a47" to="#a48" type="content_tags" ana="#content_tags.quantities[5]" resp="#tagger" cert="0.95">11 — IUPAC desiderata for an electronic notation</span>
      <span xml:id="t190" from="#a49" to="#a50" type="content_tags" ana="#content_tags.quantities[6]" resp="#tagger" cert="0.95">4 — IUPAC notation categories: unique, non-unique, ambiguous, unambiguous</span>
      <span xml:id="t191" from="#a65" to="#a66" type="content_tags" ana="#content_tags.quantities[7]" resp="#tagger" cert="0.95">4885 — descriptors calculable by Dragon</span>
      <span xml:id="t192" from="#a69" to="#a70" type="content_tags" ana="#content_tags.quantities[8]" resp="#tagger" cert="0.95">166 and 960 — common MACCS key lengths</span>
      <span xml:id="t193" from="#a71" to="#a72" type="content_tags" ana="#content_tags.quantities[9]" resp="#tagger" cert="0.95">512, 1024, or 2048 — typical Daylight fingerprint lengths</span>
      <span xml:id="t194" from="#a73" to="#a74" type="content_tags" ana="#content_tags.quantities[10]" resp="#tagger" cert="0.95">approximately 127 million — CAS reaction records from 1840 onward</span>
      <span xml:id="t195" from="#a89" to="#a90" type="content_tags" ana="#content_tags.quantities[11]" resp="#tagger" cert="0.95">3 — HORACE abstraction levels</span>
      <span xml:id="t196" from="#a99" to="#a100" type="content_tags" ana="#content_tags.quantities[12]" resp="#tagger" cert="0.95">2 to 50 — amino-acid count defining peptides</span>
      <span xml:id="t197" from="#a107" to="#a108" type="content_tags" ana="#content_tags.quantities[13]" resp="#tagger" cert="0.95">50 or more — amino-acid count defining proteins</span>
      <span xml:id="t198" from="#a107" to="#a108" type="content_tags" ana="#content_tags.quantities[14]" resp="#tagger" cert="0.95">more than 150000 — protein and nucleic-acid structures in PDB</span>
      <span xml:id="t199" from="#a27" to="#a28" type="content_tags" ana="#content_tags.variables[0]" resp="#tagger" cert="0.95">task<term>task</term></span>
      <span xml:id="t200" from="#a25" to="#a26" type="content_tags" ana="#content_tags.variables[1]" resp="#tagger" cert="0.95">node order<term>node order</term></span>
      <span xml:id="t201" from="#a21" to="#a22" type="content_tags" ana="#content_tags.variables[2]" resp="#tagger" cert="0.95">node features<term>node features</term></span>
      <span xml:id="t202" from="#a23" to="#a24" type="content_tags" ana="#content_tags.variables[3]" resp="#tagger" cert="0.95">edge features<term>edge features</term></span>
      <span xml:id="t203" from="#a49" to="#a50" type="content_tags" ana="#content_tags.variables[4]" resp="#tagger" cert="0.95">uniqueness<term>uniqueness</term></span>
      <span xml:id="t204" from="#a91" to="#a92" type="content_tags" ana="#content_tags.variables[7]" resp="#tagger" cert="0.95">reaction centre<term>reaction centre</term></span>
    </spanGrp>
  </standOff>
  <text>
    <body>
        <p><anchor xml:id="a0"/> Molecular representations in AI-driven drug discovery: a review and practical guide</p>
        <p>Abstract</p>
        <p><anchor xml:id="a1"/>The technological advances of the past century, marked by the computer revolution and the advent of high-throughput screening technologies in drug discovery, opened the path to the computational analysis and visualization of bioactive molecules. For this purpose, it became necessary to represent molecules in a syntax that would be readable by computers and understandable by scientists of various fields. A large number of chemical representations have been developed over the years, their numerosity being due to the fast development of computers and the complexity of producing a representation that encompasses all structural and chemical characteristics. We present here some of the most popular electronic molecular and macromolecular representations used in drug discovery, many of which are based on graph representations. Furthermore, we describe applications of these representations in AI-driven drug discovery. Our aim is to provide a brief guide on structural representations that are essential to the practice of AI in drug discovery. This review serves as a guide for researchers who have little experience with the handling of chemical representations and plan to work on applications at the interface of these fields.<anchor xml:id="a2"/></p>
        <p>Keywords: Molecular representation, Cheminformatics, Drug discovery, Small molecules, Macromolecules, Linear notation, Molecular graphs, Reaction prediction, Artificial intelligence</p>
        <p>Introduction</p>
        <p><anchor xml:id="a3"/>The representation of molecules has been of interest to scientists since the nineteenth century [ 1 , 2 ]. Traditionally, molecules are represented as structure diagrams with bonds and atoms, and this is likely the representation most people think of when they think of molecules. However, other representations are required for the computational processing of chemical structures in cheminformatics. Here, we define a chemical representation as any encoding of a chemical compound; linear representations are referred to as notations.<anchor xml:id="a4"/></p>
        <p><anchor xml:id="a5"/>Over the years, scientists have developed many notations depicting various properties of a compound. A classic notation is the empirical formula, a non-standard form of Hill notation. Seemingly simple at first glance, the empirical formula of alanine, C 3 H 7 NO 2 , exemplifies the complexity of building a notation. Indeed, while information about the atoms is available, it is not possible to know how the atoms are linked from the molecular formula which, moreover, does not encode information related to the molecular geometry. As such, the molecular formula above can be associated to alanine as well as to sarcosine and lactamide. Variants of empirical formulas emphasizing any functional groups also exist but are loosely defined. In these group-centric representations, elements are grouped in the formula as they would be in the molecule so as to highlight any functional groups present e.g. CH 3 CH(NH 2 )COOH to represent alanine.<anchor xml:id="a6"/></p>
        <p>The advent of computers led to the development of a wide variety of machine-readable chemical representations. Computers allowed for the rapid digital storage and querying of compounds and their structures, swift modifications of digital information, and greater physical storage efficiency. Algorithms were implemented to visualize compounds as 2D depictions [ 3 , 4 ] and the computational visualization of compounds in 3D space was popularized with the development of specialized programs [ 5 – 7 ].</p>
        <p>Many precursors to computer-readable notations were introduced between 1947 and 1964 and were dedicated to small organic molecules [ 2 , 8 ]. At the time, memory efficiency was an important factor impacting the development of chemical notations. Popular representations used nowadays, however, were largely developed in and since the 70′s to represent small molecules [ 9 – 11 ], macromolecules [ 12 – 17 ] and chemical reactions [ 18 – 21 ].</p>
        <p><anchor xml:id="a7"/>In this review, we focus on chemical representations in cheminformatics and drug discovery. We first introduce the concept of a molecular graph, which is the most common machine-readable representation, and we give a brief overview of the main notations which paved the way for the current cheminformatics notations. We then focus on the representations that are used nowadays in the field of applying artificial intelligence (AI) to cheminformatics and drug discovery. Finally, we provide examples of AI-related applications using the chemical representations discussed in this review. This review is intended to provide an overview of basic cheminformatics knowledge to practising cheminformaticians, students in chemistry, cheminformatics, bioinformatics, and computer science, and anyone interested to learn more about molecular representations in drug discovery. While the coverage of representations introduced herein is not intended to be exhaustive, we emphasise that the representation used to solve a problem is always dependent on the task. Thus, the coverage is limited to areas where there is active research in applying machine learning (ML) and AI to cheminformatics and drug discovery. For readers interested in further reading on these topics we recommend references [ 22 – 29 ], in addition to the references cited in each section.<anchor xml:id="a8"/></p>
        <p>Graph representations for small molecules</p>
        <p>Introduction to the molecular graph representation</p>
        <p><anchor xml:id="a9"/>In order to understand the chemical representations presented in this review, it is important that the reader first has a solid understanding of molecular graphs, as most molecular representations discussed in this work are built on the molecular graph representation. However, there is a distinction between the notations and file formats built using molecular graphs (e.g. SMILES strings, Molfiles), and the abstract mathematical structure/data structure of a graph itself. The latter is introduced here.<anchor xml:id="a10"/></p>
        <p><anchor xml:id="a11"/>The idea behind the molecular graph representation lies in mapping the atoms and bonds that make up a molecule into sets of nodes and edges . Intuitively, one could imagine treating the atoms in a molecule as nodes and the bonds as edges , although there is no reason one could not consider other mappings. In typical graph representations, the nodes are represented using circles or spheres, and the edges using lines. In the case of molecular graphs, the nodes are instead often represented using letters indicating the atom type (as on the periodic table), or simply using points where the bonds meet (for carbon atoms).<anchor xml:id="a12"/></p>
        <p><anchor xml:id="a13"/>A molecular graph representation is formally a 2D object that can be used to represent 3D information (e.g. atomic coordinates, bond angles, chirality). However, any spatial relationships between the nodes must be encoded as node and/or edge attributes, as nodes in a graph (the mathematical object) do not formally have spatial positions, only pairwise relationships. There are of course limitations to this representation, which are discussed in a later section. The 2D and 3D representations of graphs can easily be visualized by many software packages, including ChemDraw [ 30 ], Mercury [ 31 ], Avogadro [ 32 ], VESTA [ 33 ], PyMOL [ 34 ], and VMD [ 35 ] (the latter 5 are suitable for small- and macro-molecules, and either free or open-source).<anchor xml:id="a14"/></p>
        <p>Mathematical definition of a graph</p>
        <p><anchor xml:id="a15"/>A graph 1 is formally defined as a tuple G = ( V , E ) of a set of nodes V and a set of edges E , where each edge e ∊ E connects pairs of nodes in V . In a molecular graph, V is intuitively the set of all atoms in a molecule, and E is the set of all bonds linking the atoms, although this does not have to be the case. Molecular graphs are generally undirected, meaning that the pairs in E are unordered. [ 36 ].<anchor xml:id="a16"/></p>
        <p><anchor xml:id="a17"/>To map a graph from an abstract mathematical concept to a concrete representation that can be handled on a computer, one needs to map the sets of nodes and edges to linear data structures; a common way to do this is using data structures such as matrices or arrays. Linear data structures are necessary in order to specify the connectivity of the nodes. To do so, an artificial node-ordering must first be calculated for encoding a molecule using arrays, even though V and E are formally sets and the order of elements in sets is irrelevant. The information to be mapped can include (1) how the atoms in the molecule are connected, (2) the identity of the atoms, and (3) the identity of the bonds.<anchor xml:id="a18"/></p>
        <p><anchor xml:id="a19"/>How the atoms are connected is commonly represented in the form of an adjacency matrix A ; given that a ij is an element of A , a ij = 1 means that there exists a bond between nodes v i and v j in molecular graph G , whereas a ij = 0 means that there exists no bond between them (Fig. 1 b). The adjacency matrix is also sometimes referred to as the connectivity matrix . Note that the adjacency matrix does not necessarily specify what type of bond is connecting each pair of nodes.<anchor xml:id="a20"/></p>
        <p>Example graph representation for acetic acid. a Graph representation of acetic acid with nodes numbered from one to four. b Example adjacency matrix, A , for an acetic acid graph with the corresponding node ordering on the left. c Example node features matrix, X , which one-hot encodes a few selected properties. d Example edge features matrix, E , where each edge feature vector is a one-hot encoding of single, double, or triple bonds. “Implicit Hs” stands for the number of implicit hydrogens on a given node</p>
        <p><anchor xml:id="a21"/>The identity of the atoms can be represented in the form of a node features matrix X (Fig. 1 c). Each row of X corresponds to a node v i (i.e. an atom in the molecule) in G ; this row is also referred to as the node feature vector x i for that atom. The length of x i corresponds to the number of atom features one has chosen to encode (e.g. a one-hot 2 encoding of atom type and formal charge).<anchor xml:id="a22"/></p>
        <p><anchor xml:id="a23"/>The identity of the bonds can be represented in the form of an edge features matrix E (Fig. 1 d). Each row of E corresponds to an edge e ij = ( v i , v j ) in G , and is referred to as the edge feature vector e ij for that edge. The length of e ij corresponds to the number of edge features one has chosen to encode (e.g. a one-hot encoding of possible bond types {single, double, triple, aromatic}).<anchor xml:id="a24"/></p>
        <p>Although common in AI applications, we would like to point out that it is not necessary to one-hot encode the various node and edge features. For example, the node features matrix shown in Fig. 1 c could instead have only 3 columns using integers to represent the same three properties (atom type, formal charge, and number of implicit Hs).</p>
        <p>Graph traversal algorithms</p>
        <p><anchor xml:id="a25"/>Although, formally, graphs are non-linear data structures made up of sets of nodes and edges, in practice, matrix representations of graphs are node order dependent. The node order used in a matrix representation is determined by a graph traversal algorithm (Fig. 2 ). Depending on the application, it can be desirable to consistently generate the exact same representation for the same molecule. Reliably generating the same representation for a molecule is dependent on getting the same node order every time. To this end, one can use methods such as a depth-first or breadth-first search to generate graph matrix representations. The graph traversal algorithm needs to include a consistent way to break ties when a node branches off and must therefore consistently select the same branch traversal order. In fact, the way in which different software packages break ties in traversing a graph is often what sets them apart. However, if consistency is not important (and, indeed, for some deep learning applications, one might want noisier data), a random search can be used.<anchor xml:id="a26"/></p>
        <p>Graph traversal algorithms. Three widespread graph traversal algorithms are illustrated above for an example branched graph. The numbers correspond to the order in which the nodes are explored, starting at node 1. a A depth-first search first explores each “branch” of a graph to the fullest extent, then goes back and explores branches at the last branched node, until all branches have been explored. b A breadth-first search first explores all nearest neighbours of a node, and then the nearest neighbours of the nearest neighbours, and so on, until the whole graph has been explored. c A random search explores nodes in the graph in an arbitrary order, regardless of how they are connected</p>
        <p>There are many ways to represent a graph</p>
        <p>The matrix representations discussed above are not the only way to represent graphs, as there are multiple ways to represent the same information. For example, as has been already mentioned, depending on what graph traversal algorithm is used, the order of the rows in the adjacency matrix (or atom/bond block) will be different.</p>
        <p><anchor xml:id="a27"/>Furthermore, when working with molecular graphs, there is not one correct way to represent any molecule, and the representation chosen must be appropriate for the task.<anchor xml:id="a28"/></p>
        <p>Advantages of molecular graph representations</p>
        <p>Graphs are formally 2D data structures with no spatial relationships between elements; nonetheless, 3D information (and information that is the “result” of a 3D structure e.g. stereochemistry) can be encoded into a graph representation. One natural place to put this data is in the node features matrix, X , for node information (such as if a chiral node is R or S), or in the edge features matrix, E , for edge information (such as the length of a bond).</p>
        <p><anchor xml:id="a29"/>The fact that one can naturally encode 3D information in a graph representation gives graphs many advantages over various linear notations, although some linear notations (such as SYBYL Line Notation) can also encode atomic 3D information. Additionally, the fact that all molecular subgraphs (i.e. subsets of G ) are interpretable can confer a particular advantage to graph notations over certain string notations, where, for example, substrings of a SMILES string (which we describe in the next section), do not necessarily correspond to a valid graph. In other words, all subgraphs are interpretable whereas all substrings are not. Nonetheless, there are also disadvantages to working directly with the molecular graph representation for many applications.<anchor xml:id="a30"/></p>
        <p>Limitations of molecular graph representations</p>
        <p>Breakdown of graph model</p>
        <p><anchor xml:id="a31"/>There are many types of molecules which cannot be described by the graph model. This is any structure containing any form of delocalized bonds, such as coordination compounds, as well as any molecule containing any of the following: polycentric bonds, ionic bonds, or metal–metal bonds. For example, organometallic compounds such as metallocenes or metal carbonyl complexes are difficult to describe using molecular graphs because their bonding scheme cannot be explained by valence bond theory. In other words, it would be difficult to describe the bonds using only pairwise relationships between atoms.<anchor xml:id="a32"/></p>
        <p><anchor xml:id="a33"/>Solutions to the handling of multi-valent bonds have been introduced via the use of hypergraphs ; in a hypergraph, edges are sets of at least two atoms ( hyperedges ) instead of tuples of atoms [ 37 ]. However, the use of hypergraphs is not further discussed here as they are not currently widespread in the field.<anchor xml:id="a34"/></p>
        <p><anchor xml:id="a35"/>For molecules where the arrangement of atoms is constantly changing in 3D space, the graph representation might not be meaningful, especially if pairwise bonds are breaking and forming or if the structure is frequently rearranging. That is, for applications where one is limited to using a single static representation for a molecule that is in fact rearranging on the timescale of the problem (e.g. tautomers), then a single molecular graph representation would not be appropriate and could even be detrimental to solving the problem.<anchor xml:id="a36"/></p>
        <p>Challenges of working directly with the graph representation</p>
        <p><anchor xml:id="a37"/>Another difficulty of working directly with graph representations is that they are not compact (both memory-wise and literally). To represent a molecular graph one would need, for example: an image, a tuple of matrices, lists, or tables; all these representations are generally more difficult to search through than a more compact linear representation (compare this to a string encoding a structure ID). They also become more and more cumbersome the bigger the graphs get, and their memory requirement would increase with the square of the number of nodes, at least.<anchor xml:id="a38"/></p>
        <p><anchor xml:id="a39"/>This is not a problem with linear notations, which build upon the graph framework to create more compact and memory-efficient representations for molecules [ 38 ]. Linear notations have the advantage that they can be, for example, entries in a table, as well as easily searchable (for identity search, not substructure search), when a matrix representation is not convenient.<anchor xml:id="a40"/></p>
        <p>Connection tables and the MDL file formats</p>
        <p>Below we discuss two formats closely related to the molecular graph representation: connection tables and the MDL (now BIOVIA) file format.</p>
        <p>Connection tables</p>
        <p><anchor xml:id="a41"/>Whilst graphs underlie the representation of molecules, the matrices by which they are described are not a compact representation, and scale as the square of the number of atoms. The connection table (Ctab) [ 39 ] is composed of six parts: (1) Counts line , (2) Atom block , (3) Bond block , (4) Atom list block , (5) Stext block , and (6) Properties block . Readers are referred to the referenced material for a detailed description of each component. The counts line is always the first line, and as such gives an overview of the structure by specifying the number of atoms, bonds, and atom lists, as well as the presence or absence of chirality. The version (V2000 or V3000) is also specified on this line. The atom block describes the identities of the atoms as a list with arbitrary index values, as well as the atomic symbols, mass differences, charge, stereochemistry, and associated hydrogens. Note that it is often practical to treat any hydrogens in a molecule as implicit —that is, not storing hydrogens as atom objects and instead implicitly defining the hydrogen count using a valence model. Treating hydrogens as properties of the heavy atoms rather than as explicit nodes significantly reduces the size of the atom and bond block, making the format more compact. These can be recalculated based on valence rules if required; in such cases, valency information must be given explicitly in the atom block. The bond block describes the connectivity of the atoms as well as the identity of the bonds connecting them. The atoms may be fully or partially connected by bonds, thereby supporting the description of fragments and unconnected atoms. The bond block is composed of the atom indices and bond types; the bond order is also provided as an additional column. There is no requirement for the bond block of the connection table to be ordered in a particular way. The two blocks are combined to form the core of the Ctab. Similarly to a matrix representation, the Ctab is extensible, meaning that lists describing supported properties may be added to the properties block. Notably, any entries associated with charges, radicals, or isotopes supersede those in the atom block, if present. As a result of backwards compatibility to previous versions and the prevalence programs utilising them, connection tables have become one of the standard formats for handling chemical structural information and underlie the widely used Molfile formats. It should be noted that connection tables are in themselves not a file format but are the core building block around which CT files are built.<anchor xml:id="a42"/></p>
        <p>The Molfile format</p>
        <p><anchor xml:id="a43"/>The Molfile format family developed by MDL are collectively known as CTfiles (chemical table files) as they use connection tables to describe molecular structures. In addition, CTfiles are highly extensible and as such have formed a series of file formats that have been widely used for chemical information transfer. The series is shown in Fig. 3 , which shows how the connection table is wrapped within the Molfile format, which can be subsequently wrapped into a structure/data (SD) file, containing both structural information and additional property data for any number of molecules.<anchor xml:id="a44"/></p>
        <p>The MDL family of file formats are collectively known as CTfiles (chemical table files) as they are built upon connection tables (Ctab), shown at the top of the figure. The connection table is split into an atom and bond block, describing the atoms and their corresponding connectivity. The Ctab is built upon to form the Molfile for the description of single molecules, RGfile for handling queries, SDfile for structure and associated data, RXNfile for the description of single reactions, RDfile for either a series of molecules/reactions and their associated data, and the XDfile for the transfer of structure or reaction data based on the XML format</p>
        <p>Similarly, the RXNfile contains the description of single reactions and the RDfile enables storage of reactions or molecules as well as their associated data. RGfiles on the other hand have been designed for handling queries and the XDfile is an XML based format for the transfer of structures or reactions along with their associated metadata. Further details about each of the files and their structure can be found in the MDL documentation and various textbooks introducing the field of cheminformatics [ 40 ].</p>
        <p>Linear notations for small molecules</p>
        <p><anchor xml:id="a45"/>Matrix representations require a large amount of disk space and are not well adapted for basic cheminformatic analysis (i.e. generation of list of compounds, online query of compounds). As a result, molecules nowadays are often represented as strings of characters encoding the Ctab and that can be interpreted by systematic sets of rules. For example, using implicit hydrogen, representing d -alanine using a Molfile takes 612 bytes, while using linear notations such as SMILES or InChI, which are described in this section, takes 15 and 59 bytes, respectively. As mentioned above, linear notations have the advantage of being compact and easy to manipulate (e.g. to use as command-line option or copy in an Excel spreadsheet). The main linear notations introduced in this section are exemplified in Table 1 .<anchor xml:id="a46"/></p>
        <p>Examples of chemical representations of alanine</p>
        <p>The IUPAC quest for a universal notation</p>
        <p>Over time, the way scientists name molecules has varied following the capabilities and needs of the scientific community. In the ages of alchemy, compounds and elements were named based on their properties; for example, aqua fortis and sweet oil of vitriol referred to nitric acid and diethyl ether, respectively. In the nineteenth century, the need for a systematic nomenclature of organic chemistry grew stronger, and a terminology was developed by the International Union of Pure and Applied Chemistry (IUPAC) [ 41 ]. This terminology is described at length in the IUPAC Color Books [ 42 ] and is universally used in the literature, patents, and government legislation. <anchor xml:id="a47"/>Nonetheless, this nomenclature is not ideal for cheminformatics applications and, in 1949, the IUPAC requested an international standard for electronic chemical notations requiring 11 desirable properties or “desiderata” [ 28 ]: simplicity of use, ease of printing and typewriting, conciseness, recognizability, ability to generate a unique chemical nomenclature, compatibility with the accepted practices of inorganic chemical nomenclature, uniqueness, generation of an unambiguous and useful enumeration pattern, ease of manipulation by machine methods, exhibition of associations, and ability to deal with partial indeterminates.<anchor xml:id="a48"/></p>
        <p><anchor xml:id="a49"/>According to the IUPAC formalism set in 1964 [ 28 ], notations can be classified as being unique (i.e. one notation for a given compound), non-unique (i.e. more than one notation for a given compound), ambiguous (i.e. the notation will regenerate more than one compound), or/and unambiguous (i.e. the notation will regenerate only the original compound). This formalism is used to describe notations in this section.<anchor xml:id="a50"/></p>
        <p>Although seven notations 3 were proposed to IUPAC as potential standards, only two retained the interest of the committee: the Dyson cyphering [ 43 ] and the Wiswesser Line Notation (WLN) [ 44 ]. Descriptions and related references for the remaining five notations can be found in two notable publications [ 2 , 45 ] which detail many chemical notations introduced until 1984, and in a report by Alan Gelberg [ 8 ]. After many revisions, Dyson’s notation, originally developed in 1947, was adopted in 1961 as an international notation by IUPAC. The Dyson cyphering was not very popular among the scientific community as it could not be handled on standard typewriters or ordinary punched-card machines and contained many arbitrary rules. The most used notation by the community was WLN, which was created in 1949 and did not present the drawbacks of the Dyson cyphering. For a detailed comparison between WLN and Dyson cyphering, we refer the readers to the Survey of Chemical Notations [ 28 ]. We do not provide further details on WLN and IUPAC-Dyson as the notations have fallen into desuetude; however, we feel that the competition between both notations illustrate the technological and technical aspects that were under consideration for the selection of a universal notation.</p>
        <p>The advent of contemporary notations</p>
        <p>Simplified Molecular Input Line Entry System</p>
        <p><anchor xml:id="a51"/>WLN requires an extensive knowledge and understanding of the notation’s rule. A more intuitive notation, the Simplified Molecular Input Line Entry System (SMILES), was developed in 1988 by Weininger et al. [ 9 ] and has been the most popular line notation ever since. SMILES notation system was then incorporated into the Daylight Chemical Information Systems [ 48 ] toolkit; the company is still currently maintaining it. The SMILES representation, non-unique and unambiguous, is obtained by assigning a number to each atom in the molecule and then traversing the molecular graph using that order; in the case of RDKit [ 49 ], the graph traversal algorithm used is depth-first search.<anchor xml:id="a52"/></p>
        <p><anchor xml:id="a53"/>There can be multiple atom numberings for a given molecule, leading to different SMILES. SMILES can thus be enumerated for data augmentation [ 50 ]. The ensemble of SMILES representing one molecule can be referred to as enumerated or randomized SMILES and are obtained by, for each molecule, randomly selecting an initial node for graph traversal while keeping the same graph traversal algorithm, thus leading to different atom orderings [ 51 ]. For clarity, we emphasize that randomized SMILES do not use a random search to generate representations, they rely on a depth-first search. To avoid conflicting SMILES representations for the same molecule, a unique SMILES can be designated, and several canonicalization methods exist to this end [ 38 , 52 , 53 ]. A schematic illustrating the difference between two SMILES variants is shown in Fig. 4 .<anchor xml:id="a54"/></p>
        <p>Canonical ( a ) and randomized ( b ) SMILES representations of aspirin. Randomized SMILES correspond to the various representations of a molecule obtained by randomly selecting the starting node in the graph traversal algorithm, thus changing the order of the nodes traversed in the molecular graph (still using depth-first search). Numbers represent the order of graph traversal, where 1 is the initial node (user defined). Considering a as being the canonical representation of aspirin, b shows a different ordering of the atoms of the molecule. The final SMILES is one possible SMILES among all the randomized SMILES which can be generated. Green arrows indicate how the molecular graph is traversed. Both SMILES strings shown represent the same molecule but, as the atom numberings are different, the generated SMILES strings are, too. The original figure can be found in [ 47 ]</p>
        <p><anchor xml:id="a55"/>Initially, SMILES did not encode for stereochemistry. A specification, referred to as isomeric SMILES, was introduced later on and is now the default SMILES in many software. SMILES can thus encode isomeric specifications, configurations around double bonds (Z or E), and configurations around tetrahedral centres as well as many other types of chiral centres which are rarely supported (e.g. allene-like, octahedral). Nonetheless, a problematic set of structures to describe using SMILES notation is those which cannot be easily described using molecular graphs (see “ Limitations of molecular graph representations ” section), such as organometallic compounds and ionic salts.<anchor xml:id="a56"/></p>
        <p>Generally, if the total sum of bond orders is not equal to one of the standard valences for a given atom in a molecule, this is addressed in the corresponding SMILES notation using square brackets. When the molecules involved in bonding are also aromatic, lowercase tokens may be used, though this becomes problematic with some cheminformatics software which do not allow “extra” bonds for aromatic atoms [ 54 ]. ChemAxon Extended SMILES (CXSMILES) can overcome some of these issues by storing special features [ 55 ]. These are stored after the SMILES string separated by a space or tab and can be ignored when parsing SMILES if necessary. In addition, several fields can be stored for any given SMILES string. One such feature is fragment grouping, which specifies which components are grouped together using a list of fragment indexes; this aids in the grouping of ions and salts. Additional specifications of ligand order and coordinate bonds aid in the description of organometallic compounds and are supported by CXSMILES. The atom-to-atom coordinate bonds are represented by single bonds in the SMILES but corrected by the additional information CXSMILES provides in the extension.</p>
        <p><anchor xml:id="a57"/>The OpenSMILES [ 56 ] specification was developed in 2007 to provide a SMILES standard form and to clarify some interpretations of corner cases present in the Daylight’s SMILES system. A major issue with Daylight’s SMILES is that its canonicalization algorithm is proprietary, and as such implementations vary between companies and research teams. A novel open source method to generate canonical SMILES was developed in 2012 [ 38 ]. Such SMILES are generated using the canonical label provided by the InChI representation [ 10 ], which is described later in this section. Using such “universal” SMILES seeks to facilitate the comparison between chemical models used by different toolkits.<anchor xml:id="a58"/></p>
        <p>SMILES Arbitrary Target Specification (SMARTS)</p>
        <p><anchor xml:id="a59"/>There exists an extension of SMILES developed for substructure searching, named SMILES Arbitrary Target Specification (SMARTS) [ 57 ]. In SMILES there exist two types of symbols to signify atoms and bonds which describe the underlying connectivity of a given molecular graph. However, in SMARTS, the available symbols allow for a more general specification of the molecular graph. This can be likened to the use of regular expressions in computer science. Classical SMARTS can describe an ensemble of molecules that differ at one atom or bond position. It is also possible to include logical operators such as “OR” and “NOT”. Contrary to SMILES, SMARTS can specify different isotopes or bonds types (aromatic or aliphatic). Detailed information about an atom environment can be given using Recursive SMARTS (e.g. ortho, meta, or para substitution patterns in arenes). All SMILES can be valid SMARTS, however the reverse is not true, and decoding a SMILES as a SMARTS will generally not yield the same decoded pattern.<anchor xml:id="a60"/></p>
        <p>International chemistry identifier</p>
        <p><anchor xml:id="a61"/>The best example of open-source canonical notation is the InChI (International Chemistry Identifier) representation [ 10 ], which was introduced in 2006 by NIST, under the auspices of the IUPAC, as a standard and freely available formula representation. InChI are composed of multiple layers, such as the Main , Charge , Stereochemical , and Isotopic layers, to name a few, which are themselves constituted of sublayers. For example, the Main layer is composed of the Chemical formula , Atom connections , and Hydrogen atoms sublayers (Fig. 5 ).<anchor xml:id="a62"/></p>
        <p>InChI notation of aspirin. Red letters are the standard beginning of the notation. The following 1 corresponds to the InChI version number, and S states that the notation is a standard InChI. Slashes (blue) are delimiters</p>
        <p><anchor xml:id="a63"/>A hashed version of the InChI, the InChIKey, is used for open-web searching and library searching [ 58 ]. The first block of an InChIKey represents the molecular skeleton, and the second block encodes for isomerism. InChIKeys are designed to be unique representations of their corresponding parent InChI representations. However, an InChIKey can sometimes map to more than one InChI, the situation being referred to as an InChIKey collision [ 59 ]. Unlike SMILES, InChIs are not guaranteed to be decodable back to the molecular graphs from which they originate, and SMILES have the advantage of being more human-readable. For a detailed overview of the applications of InChIs and the underlying algorithm, readers are referred to the works of Heller [ 10 ] and Warr [ 60 ].<anchor xml:id="a64"/></p>
        <p>Using chemical descriptors to represent molecules</p>
        <p><anchor xml:id="a65"/>The representations presented above are atom-based, meaning it is possible to rebuild the molecule based on the representation. There exist, however, other types of notations which, rather than encoding the exact structure of a compound, instead encode the physicochemical, structural, topological, and/or electronic properties of a compound. These are referred to as molecular descriptors [ 11 ] among which two main classes are structural keys and the hashed fingerprints. Descriptors are unique and ambiguous notations widely used in cheminformatics, and their complete descriptions would require a review of their own. A non-exhaustive list can be found in association with the Dragon software [ 61 ], which can calculate 4885 descriptors.<anchor xml:id="a66"/></p>
        <p>Structural keys</p>
        <p><anchor xml:id="a67"/>Structural keys are bit strings, encoding for the absence (using a 0) and the presence (using a 1) of a specific chemical group. To provide a general understanding of the structural keys concept, we present here a few widely used keys.<anchor xml:id="a68"/></p>
        <p><anchor xml:id="a69"/>MACCS Keys The first set of keys is referred to as MACCS (Molecular ACCess System) keys or MDL keyset [ 62 , 63 ] and is frequently used for similarity searching. In MACCS keys, each bit indicates the presence or absence of a particular structural fragment. Many variants of the MACCS keys exist [ 64 ], with the most commonly used being 166 and 960-bits long. thus encoding for the presence or absence of 166 and 960 structural fragments. It should be noted that there are many software implementations of the 166-bit MACCS keys, thus one should be cautious as one substructure will not be assigned to the same bit from one software to the other.<anchor xml:id="a70"/></p>
        <p>CATS For application in scaffold hopping, a topological pharmacophore descriptor, Chemically Advanced Template Search (CATS) [ 65 ], was developed. It can encode for six potential pharmacophore points: H-bond donor/acceptor, positively/negatively charged, aromaticity, and lipophilicity.</p>
        <p>Hashed fingerprints</p>
        <p><anchor xml:id="a71"/>Chemical fingerprints are vectors which contain indexed (ordered) elements encoding for physicochemical or structural properties. Hashed fingerprints differ from other descriptors by the fact that each feature is generated from the molecule itself, while in keys, patterns are pre-defined. Their lengths can be set prior to their generation and a hash function assigns molecular patterns to (non-unique) bits, hence the name. Topological or path-based fingerprints are represented by Daylight fingerprints, which usually consist of 512, 1024, or 2048 bits. The Daylight fingerprint encodes for every connectivity pathway within a molecule up to a given length. Circular fingerprints are representations of chemical structures by atom neighbourhoods and have been widely applied in Quantitative Structure–Activity Relationship (QSAR) analysis. A widely used class of circular fingerprints is ECFP (Extended Connectivity Fingerprints) [ 66 ], based on the Morgan algorithm. In ECFPs, heavy (i.e. non-hydrogen) atoms are encoded into multiple circular layers up to a given diameter.<anchor xml:id="a72"/></p>
        <p>Whether fingerprints can be called a chemical notation per say is debatable and comes down to a matter of opinion between experts. Regardless, chemical fingerprints are widely used in cheminformatics and drug discovery as they provide a quick and direct mapping from a graph to a vector representation that can be used as input to numerical models, such as QSAR models. It should be noted that fingerprints are flexible representations and can also encode physicochemical properties as integers (e.g. the hydrogen count) and floats (e.g. molecular weight).</p>
        <p>Representations for chemical reactions</p>
        <p>Harnessing reaction data for drug discovery</p>
        <p><anchor xml:id="a73"/>Chemical reactions represent the interconversion of one set of molecules into another related set, under a set of specified conditions. A vast body of reaction data has been amassed to date, with approximately 127 million reactions recorded from 1840 to the present day according to the Chemical Abstracts Service (CAS) [ 67 ].<anchor xml:id="a74"/></p>
        <p>In recent years, there has been a resurgence of interest in the development of models for the prediction of outcomes of chemical reactions, synthetic routes, and analysis of reaction networks, to name a few application areas. For a more comprehensive coverage of the representations of chemical reactions in databases and computer-aided synthesis design, we refer the reader to a review by Warr and the bibliography therein [ 68 ]. In addition, for a more comprehensive coverage of applications within autonomous discovery, we refer the reader to an extensive review by Jensen et al. [ 69 ].</p>
        <p><anchor xml:id="a75"/>Many of the representations described in the previous sections natively allow for, can be extended, or have analogous representations for describing chemical reactions. As the description of reactions is that of a set of molecules, limitations in each of the previously described representations are inherited in the description of chemical reactions. A reaction is often represented graphically with the reactants written to the left of a reaction arrow , and a set of resulting products written to the right of this arrow. The conditions under which the transformation occurs are written above or below the arrow, including information such as reagents, catalysts, solvents, temperature, and so forth. The graphical illustrations of reaction schemes often found in publications are, however, not easily machine-readable. Therefore, there exist a series of reaction data exchange formats that enable reactions to be represented in a machine-readable format. There is no inherent requirement for one format or another, as this is dependent on the application, toolkit, or software package used. Commonly used formats include the RXN and RD files described in an earlier section.<anchor xml:id="a76"/></p>
        <p>Reaction SMILES and SMIRKS</p>
        <p><anchor xml:id="a77"/>The SMILES format used for describing molecules has been extended to so-called Reaction SMILES by Daylight Chemical Information Systems. Each molecule in the reactants, agents, and products is represented by a SMILES string, and disconnected structures are separated by a period; this includes the individual molecules, ions and ligands, which are listed in an arbitrary manner. Reactants, agents, and products are separated by either the ‘&gt;’ or ‘≫’ symbol (the latter used when agents are not given). Atom-mappings (i.e. mappings of atoms in the reactants to their equivalent atoms in the products) can be stored in Reaction SMILES as a non-negative integer following the character ‘:’ within an atom expression. Atom mappings do not apply to agents. Furthermore, the storage of additional textual information such as the reaction centre (i.e. the atom and bonds that change during a transformation) or reaction conditions is not supported. Nonetheless, formats such as the RXN and RD file formats, especially the latter, can store this additional metadata, as can other file formats or databases.<anchor xml:id="a78"/></p>
        <p><anchor xml:id="a79"/>SMIRKS belong to the same family as SMILES and SMARTS. Where SMARTS describe molecular patterns or substructures generically, SMIRKS patterns can be used to define generic reaction transformations. They can be used to describe the reaction centre, to enumerate virtual libraries, and to form the knowledge base for reaction and retrosynthetic prediction systems. If one considers that a reaction is a set of atoms and bonds that change during a reaction and the reactant or substrate upon which that change occurs, then SMIRKS must encode the same set of atoms and bonds that change during the reaction, and the site at which that change occurs in the substrate as specified by a SMARTS pattern. The SMARTS pattern is used to specify both the site at which the atom and bond changes occur, and to capture any indirect effects that may influence the reaction. The atomic expressions must be defined such that (a) for any part of a molecule that is to be considered in a generic transformation for which the bonding does not change, SMARTS are to be used, and (b) in cases where bonds change, SMILES are to be used. In this sense, SMIRKS is a hybrid approach between SMILES and SMARTS. There are some rules that must be followed in order to ensure that SMIRKS patterns can be applied. The two sides of the transformation, the reactant(s) and product(s), must contain the same number of mapped atoms, and they must correspond on either side of the reaction. Additionally, any explicit hydrogens must appear explicitly on either side of the reaction and have corresponding atom mapping numbers. SMIRKS are converted into a reaction graph for their subsequent use. The reaction SMILES and corresponding SMIRKS are shown in Fig. 6 .<anchor xml:id="a80"/></p>
        <p>A selection of representations for a simple esterification reaction. The atom mapped reaction is shown in the top left as a structural diagram. The atom maps are consistent between reactant and product as shown. The atom maps in the SMIRKS do not correspond to the atom maps in the full reaction. Rather, they are used to keep track of the atoms within the SMIRKS. The condensed reaction graph and corresponding signature was generated using CGRtools [ 73 ]</p>
        <p>RInChI</p>
        <p><anchor xml:id="a81"/>An extension of the InChI, RInChI [ 18 , 70 ], was developed between 2008 and 2018 and introduced a unique, order invariant identifier for reactions. It was developed in response to the growing size of reaction data to aid reproducibility, to consider more information than just the participating molecules, and to provide enough information such that practically identical reactions would be represented the same way. RInChI grammar, however, is relatively more complicated than that of Reaction SMILES.<anchor xml:id="a82"/></p>
        <p>RInChIs use InChIs to describe each molecule. Where InChIs cannot be generated for a molecule, the RInChI tracks the number of “structureless” entities that are present in each of the reactants, agents, and products. In addition to specifying each molecule and reaction role, the RInChI must include information about equilibrium, unbalanced, or multi-step reactions. The RInChI employs a layering system, whereby each layer can describe a different aspect of the chemical reaction. Solvents and catalysts may be accounted for in a similar manner as in Reaction SMILES; however, RInChIs additionally allow for the direction of the reaction to be described. This is particularly useful, as different labs may conduct the same reaction under slightly different conditions, potentially reaching different conclusions about the direction of the reaction. The RInChI generated in this case would be the same, except for the direction flag. This aids in the identification of reactions that are in practical terms identical.</p>
        <p><anchor xml:id="a83"/>A proposed further extension to RInChI, ProcAuxInfo, enables the storage of metadata relating to yields, temperature, concentration, and other reaction conditions [ 71 ]. RInChI offers an alternative to Reaction SMILES that enables the identification of duplicate reactions, as the order in which molecules are listed in Reaction SMILES is arbitrary. Hashing the RInChI to yield the RInChI key provides a powerful tool for efficiently indexing and searching reaction data [ 18 , 71 ]. However, there is no SMARTS or SMIRKS equivalent for RInChI, limiting its use in substructure searching and in encoding generic chemical transformations. The RInChI and corresponding keys are shown in Fig. 6 .<anchor xml:id="a84"/></p>
        <p>Condensed graph of reaction (CGR)</p>
        <p><anchor xml:id="a85"/>Varnek and co-workers have developed the CGR approach [ 19 ], whereby molecular structures are encoded in a matrix containing the occurrence of fragments of a given type. The CGR is a superposition of the reactant and product molecules, and additionally defines what atoms and bonds have changed as well as their properties. This builds on the description of organic reactions using imaginary transition states as described by Fujita [ 72 ]. In analogy to SMIRKS, the CGR can be used to describe a reaction transformation. An example CGR is shown in Fig. 6 .<anchor xml:id="a86"/></p>
        <p>With the renewed interest in chemical reactions within cheminformatics in recent years, Varnek and co-workers have developed an open source toolkit enabling the wider use of CGR [ 73 ].</p>
        <p>Bond electron matrices (BE-matrix)</p>
        <p><anchor xml:id="a87"/>To exemplify the representation of reactions as matrices, the bond-electron matrix developed by Dugundji and Ugi was previously employed for reaction classification and has also been used as an inspiration for the representation used in programs such as the Elaboration of Reactions for Organic Synthesis (EROS) [ 74 ], and the Workbench for the Organisation of Data for Chemical Applications (WODCA). The BE-matrix is an N by N matrix, where N is the number of atoms in a molecule, and the diagonal entries specify the number of free valence electrons. The off-diagonals specify the bond orders between atoms as found in the bond matrix. The reaction is represented by an “R-matrix” which corresponds to bond changes or changes of non-bonded valence electrons. Positive values indicate bond formation, whereas negative values indicate bond breakage. Adding the “R-matrix” to the BE-matrix of a reactant gives the BE-matrix of a product. The “R-matrix” is therefore an alternate method for representation of the reaction centre [ 20 ]. The BE-matrix illustrates the concept of adding additional information into the matrix representation.<anchor xml:id="a88"/></p>
        <p>Hierarchical organization of reactions through attribute and education (HORACE)</p>
        <p><anchor xml:id="a89"/>HORACE [ 21 ] employs a machine learning algorithm for the classification of chemical reactions and is mentioned here because of the hierarchical description of chemical reactions that it uses. It was developed to describe specific reaction instances as well as abstractions of reaction types. Three levels of abstraction are employed. The lowest level describes the partial order of atom types, which gives an explicit hierarchy at the atom level by specifying the degree of similarity between atoms. Following the atom level description is the structural level description. This uses a list of functional groups as structural features by which to characterize individual molecules. The structural characterization is then used to specify which molecules correspond to atoms in the reaction centre. The highest level of abstraction specifies physiochemical properties, which describe the function of the corresponding structure. The hierarchy therefore enables a richer description of a chemical reaction than a purely structural one (as with SMILES).<anchor xml:id="a90"/></p>
        <p>InfoChem CLASSIFY</p>
        <p>The approaches used by Saller and co-workers to represent reactions underlies [ 75 ] and has inspired many of the approaches used for rule-based synthesis planning [ 76 , 77 ]. The first step is to identify and extract the reaction centre, defined as a set of atoms that have changed their number of implicit hydrogens, valency, number of π-electrons, atomic charges, or if at least one connecting bond belongs to the reaction centre. Bonds are defined as belonging to the reaction centre if they are made or broken. In order to identify such changing atoms and bonds, a mapping is used to identify equivalent atoms in the reactants and products.</p>
        <p><anchor xml:id="a91"/>Regardless of the representation used, a key problem in the representation of chemical reactions is the identification of the reaction centre. One approach to reaction centre detection and atom mapping is finding the maximum common substructure (MCS) between reactant and product molecules. The determination of the MCS is an NP-complete problem, meaning that the solution is non-deterministic in polynomial time. Several reviews discuss these approaches and have been referenced for the interested reader [ 78 – 80 ].<anchor xml:id="a92"/></p>
        <p>Having identified the reaction centre, atom hash codes are calculated for all atoms belonging to the reaction centre using a modified Morgan algorithm [ 53 ]. The hash codes include the following atom properties: atom type, valence state, total number of bonded hydrogen atoms (implicit and explicit), number of π-electrons, aromaticity, and formal charges as per the reaction centre definition. The hash codes generated for each atom in the reaction centre are summed for all reactants and one product of a reaction to provide a unique representation of the reaction centre.</p>
        <p>The description of the reaction centre can be extended to include the neighbouring chemical environment depending on the level of specificity required (Fig. 7 ). The reaction centre alone corresponds to a “broad” or more general description of the reaction, whereas inclusion of alpha atoms (atoms adjacent to those in the reaction centre) corresponds to a “medium” description of the reaction centre. Expanding the description to include the next set of adjacent atoms “narrows” the description of the reaction owing to increased specificity. The generated hash codes have been used in reaction classification and the approaches for reaction centre extraction utilized in a variety of synthetic planning tools.</p>
        <p>Atomic environments included in the description of the reaction centre. The reaction centre is used in calculations of atom hash codes for varying degrees of specificity</p>
        <p>Reaction fingerprints</p>
        <p><anchor xml:id="a93"/>Reaction fingerprints are vector representations of reactions. They specifically represent the structural changes taking place in the reaction centre. This information is captured by constructing fingerprints, such as the ECFP variant described previously, and taking the difference between the product and reactant vectors, optionally considering the agent. Schneider et al. [ 81 ] have used the difference fingerprint with the atom-pair variant to build a machine learning system for a 50-class reaction classification model. A similar approach to the computation of reaction vectors was described by Patel et al. [ 82 ] and has been used in de novo design and classification approaches [ 83 ]. The reaction fingerprint highlights an alternate approach to reaction centre detection and representation; however, it cannot be easily converted to a reaction graph. Lastly, the handling of stereochemistry has not been mentioned but is an active area of research [ 84 ].<anchor xml:id="a94"/></p>
        <p>Representations for macromolecules</p>
        <p><anchor xml:id="a95"/>While there have been many advances in the representation of small molecules, in comparison very few studies [ 85 ] have addressed the representation of macromolecules, which are polymeric structures. In this section, we present representations made for biopolymers and bio-oligomers, like proteins and oligosaccharides, and synthetic polymers. The process of representing macromolecules can be hindered by the fact that, while many polymers are monodisperse (i.e. constituting monomers have the same chain length), others can be polydisperse, such that their stochastic nature results in an undefined chain length. Examples of macromolecules and their notations are shown on Fig. 8 .<anchor xml:id="a96"/></p>
        <p>Example of linear notations for different types of macromolecules. Cyclosporin is an immunosuppressant medication and natural product. Lactose is a disaccharide used in the food industry. Insulin is a peptide hormone which regulates the metabolism of carbohydrates, fats, and protein. pHEMA or poly(2-hydroxyethyl methacrylate) is a polymer that forms hydrogel in water. Copolymers of pHEMA are used to make contact lenses</p>
        <p><anchor xml:id="a97"/>This section places itself at the interface between bioinformatics and cheminformatics. While in cheminformatics small molecules are described on the atomic-level, in bioinformatics, polymers, such as a proteins or polynucleotide molecules, are more commonly defined using their nucleotide and amino acid sequences. Representations which combine atomic and sequence information are presented here.<anchor xml:id="a98"/></p>
        <p>Amino acid-based structures</p>
        <p>The building blocks of peptides and proteins are amino acids (AAs), which are each made up of an amine group, a carboxyl group, and a side chain specific to each AA. AAs are commonly represented by a one-letter symbol, which commonly imply the L configuration for chiral AAs, or a three-letter abbreviation [ 86 ]. A limitation of the one-letter symbol is that while the Latin alphabet is large enough to describe the 20 AAs which appear in known genetic code, there are far more naturally occurring AAs.</p>
        <p>Peptides</p>
        <p><anchor xml:id="a99"/>Peptides are chains of 2 to 50 AAs linked by peptide bonds. They can be antibiotics, immunosuppressants, or antitumor agents. This broad range of biological activity sparked the interest of the community.<anchor xml:id="a100"/></p>
        <p><anchor xml:id="a101"/>A method named CHUCKLES [ 12 ] was developed in 1994 to infer SMILES of polymers from their sequences and vice versa. In cheminformatics, this method is particularly useful in inferring the SMILES from the peptide sequence, which is referred to as Forward Translation (FT). In FT, monomers sequences and SMILES are stored in a lookup table, with the SMILES excluding any atoms which would be involved in monomer bonding. For linear structures, SMILES corresponding to each residue are concatenated. In branched and cyclized structures, monomer indices are mapped to the SMILES, thus encoding for structures such as disulfide bridges. CHUCKLES is applicable to oligomeric structures and is used in BIOPEP-UWM [ 87 ]. An extension of CHUCKLES, CHORTLES, was designed to handle oligomeric mixtures. Two notations are well known for their ability to describe a broad range of macromolecules: the Hierarchical Editing Language for macromolecules (HELM) [ 14 , 88 ] and the Self-Contained Sequence Representation (SCSR) [ 89 ]. Both representations were developed concurrently, the first one relying on SMILES and the second one on the v3000 Molfile format. SCSR was developed by BIOVIA which provides automated interconversion between HELM and SCSR.<anchor xml:id="a102"/></p>
        <p><anchor xml:id="a103"/>In the following lines, we provide further details on HELM, which was developed by Pfizer under the auspices of the Pistoia Alliance. The objective of the project was to design a system representing combinations of component structure types (e.g. peptides, antibodies, chemical modifiers). An example of HELM notation is shown in Fig. 9 . Initially, HELM was limited to well-defined structures; however, HELM2 overcame this limitation and can describe polymer mixtures and free-form annotations. HELM represents monomers in a SMILES-like format, simple polymers using a simplified version of CHUCKLES and complex polymers using graphs. Its structure hierarchy follows the granularity of the structures: Complex Polymer, Simple Polymer, Monomer, and Atom. HELM is implemented in many pharmaceutical companies [ 90 ], in public databases (in 2016, ChEMBL21 contained 20,000 peptides annotated with HELM [ 91 ]), as well as in various packages and software such as RDKit (limited to peptides), ChemDraw, the Biomolecule Toolkit, ChemAxon, and Sugar&amp;Splice, which can all encode for peptides, DNA, and RNA.<anchor xml:id="a104"/></p>
        <p>Graph and HELM representation of a biphalin analog. Amino acids are coloured coded as followed: blue, green, red, and pink for tyrosine (Y), alanine (A), glycine (G), and phenylalanine (F), respectively)</p>
        <p><anchor xml:id="a105"/>In comparison with purely atomic-based notations such as SMILES, biocheminformatics representations can facilitate the development of modified drug peptides. For example, the substitution of natural L-AA with D-AA can improve the oral bioavailability of a peptide [ 92 ]. Such modifications would be intuitive with HELM, which provides readability at the polymer level, whereas SMILES provides descriptions on the atomic level. While these methods constitute a step forward to a better understanding and unification of cheminformatics and bioinformatics, errors in the translation of peptide notation from biological into chemical language have been detected and practical solutions proposed [ 93 ].<anchor xml:id="a106"/></p>
        <p>Proteins</p>
        <p><anchor xml:id="a107"/>Proteins are polypeptides made up of 50 or more amino acids. They are generally biological targets; however, therapeutic protein drugs have been engineered [ 94 ]. The largest repository of 3D structures of proteins and nucleic acids is the Protein Data Bank (PDB) [ 17 ], which contains more than 150,000 structures. PDB entries contain the atomic coordinates of every atom in a protein structure as well as solvent molecules (if applicable). Each atom is identified by a sequential number, a specific atom name, the name and number of its corresponding residue, a one-letter code specifying the chain, its spatial coordinates ( x , y , and z ), and an occupancy and temperature factor. Furthermore, any notations mentioned in the Peptide section can be used for protein representations. In 2008, the Protein Line Notation (PLN) [ 16 ] was created by Biochemfusion and is implemented in PubChem. Pseudo-atoms were used to represent a simplified version of a residue structure, which enabled a lossless conversion between chemistry and sequence formats.<anchor xml:id="a108"/></p>
        <p>Key macromolecules</p>
        <p>Most drugs are small organic molecules. However, drugs can also be macromolecular in nature, such as glycans (also referred to as carbohydrates) [ 95 ] or synthetic polymers [ 96 ].</p>
        <p>Glycans</p>
        <p><anchor xml:id="a109"/>Oligosaccharides and polysaccharides are glycans containing more than 3 and 20 monosaccharides (the smallest sugar unit), respectively. In drug discovery, glycans are interesting as receptors, small molecule glycomimetics, therapeutic glycopeptides, and vaccines. Glycan databases are used by carbohydrate researchers and structures are generally recorded using monosaccharide-based notations [ 97 – 100 ]. These representations do not allow for the analysis of the interactions between glycans and proteins using docking techniques, which require atom-based representations. Converter tools have been developed [ 101 , 102 ] that translate these notations to atom-based representations. With the aim of creating a linear and unique notation for glycan data, compatible with the usage of the semantic web, the Web3 Unique Representation of Carbohydrate Structures (WURCS) [ 15 ] was developed and combined bioinformatics and cheminformatics features. The newest version of WURCS [ 103 ], used by the International Glycan Structure Repository GlyTouCan [ 104 ], encodes the following features: the main carbon backbone of a monosaccharide residue, the backbone modifications (i.e. atoms belonging to a monosaccharide which are not part of the backbone), and the linkage information between the backbone and a modification. The notation provides explicit anomeric information and can handle ambiguous monosaccharide structures (e.g. unknown ring closure or anomeric information). Currently, WURCS is implemented in many databases but unsupported by most cheminformatics software.<anchor xml:id="a110"/></p>
        <p>Independent representations have been developed to address specific challenges. Pillong and Schneider [ 105 ] published a representation of monosaccharides based on pharmacophoric properties. Bojar et al. [ 106 ] developed a language model based on natural language processing (NLP) providing information on glycans connectivity and composition.</p>
        <p>Polymeric drugs</p>
        <p><anchor xml:id="a111"/>In the context of drug discovery, polymers are primarily used as drug deliverers. Nonetheless, some polymers have been used as active ingredients. Recently, the BigSMILES [ 107 ] syntax was introduced to encode for homopolymers, random- and block co-polymers, and molecules with different degrees of complexity in connectivity, such as linear polymers, ring polymers, and branched polymers. The stochastic unit of these polymers is identified by a pair of curly brackets. Repeated units are delimited by a comma and listed inside these brackets. Although BigSMILES are currently not canonical, a canonicalization scheme is under development. No application of this notation is available to this date; however, the development of polymeric drugs is expected to flourish [ 96 ], and ML models could be applied to aid in related studies.<anchor xml:id="a112"/></p>
        <p>Graphical representations for molecules and macromolecules</p>
        <p>The representations presented in the previous sections are designed for the storage and the cheminformatics analysis of compounds. In this section, representations which are made for direct visualization of compounds or/and their physicochemical properties are introduced.</p>
        <p>2D depictions</p>
        <p><anchor xml:id="a113"/>Molecules as raster or vector images are very often represented by their skeletal structures, which are referred to as 2D depictions (Fig. 10 a). Many difficulties can be encountered when generating 2D depictions related to the layout (e.g. orientation, overlap) and rendering (e.g. font, abbreviations, atom labels alignment) of the image. In 2008, the IUPAC issued recommendations for the standard display (typography, orientation of structure, etc.) of 2D depictions [ 108 ]. Such obstacles are overcome by a range of algorithms; however, as of now, none of them can perfectly display every chemical structure. This was exemplified in 2008 in a comparative study of 2 proprietary toolkits (Cactvs [ 109 ], used by PubChem, and Molinspiration [ 110 ]), and 3 open-source toolkits: RDKit, OASA [ 111 ], and CDK [ 112 ]. In 2017, improvements were done in CDK to depict stereochemistry more accurately and to solve atomic overlap [ 112 ]; on the latter point, the algorithm went from a heuristic approach to a refinement process. For more up-to-date details and examples of 2D depiction algorithms and their limitations, we refer the readers to a 2016 presentation by John Mayfield [ 113 ].<anchor xml:id="a114"/></p>
        <p>Examples of various molecules drawn using different display types. b – d Generated with Avogadro [ 32 ]. a Skeletal structure of the Fe-porphyrin subunit of haem B. b Ribbon diagram of haemoglobin. c Space-filling model of the Fe-porphyrin subunit of haem B. d Ball-and-stick model of the Fe-porphyrin subunit of haem B. Note the different orientations. e 2D visualization of protein–ligand interactions (PDB code: 2HPS). Reprinted with permission from [ 115 ]. Copyright 2020 American Chemical Society. f 3D visualization of protein–ligand interactions (PDB code: 6KYA)</p>
        <p>Apart from the 2D depictions of the structures themselves, molecules can be depicted in various ways for reactions and interaction studies (Fig. 10 e). In the latter, the aim is to investigate the environment or the behaviour of a molecule rather than its structure. A specific 2D depiction worth mentioning is the Markush structure, especially useful in patents, which depicts a specific series of compounds. A Markush structure possesses a fixed core with one or several variable parts which can be described by -R groups, bonds, atoms, etc. For macromolecules, different types of depictions are needed as the visualization often focuses on the polymer or peptide structures rather than the atomic structure. Associated to HELM, the Pfizer Macromolecule Editor (PME) was developed to visualize polymer structures and calculate molecular properties. A notable nomenclature for the depiction of glycans is provided by the Consortium for Functional Glycomics [ 114 ].</p>
        <p>3D depictions</p>
        <p><anchor xml:id="a115"/>Before the advent of computers, various molecular models were developed to visualize and manipulate molecules in 3D and were built by assembling balls and sticks made of materials such as plastics or metals. Nowadays, while physical molecular modelling kits are still used in educational environment to represent basic structures, visualization software has become a tool of choice for 3D graphical displays of molecules (examples of visualization software have been provided in the subsection Introduction to the molecular graph representation ). The software Avogadro, PyMOL, and VMD all offer the popular representations ball - and - stick , cartoon , and van der Waals (vdW), as well as many independent representations. Each representation is useful for the visualization of specific properties, be it the structure coloured by atom types (Fig. 10 d), the secondary biological structure (Fig. 10 b), or the space-filling vdW spheres (Fig. 10 c). The vdW spheres help visualize the surface on which the molecule can build interactions; using this depiction, interactions between proteins and ligands can be visualized in 3D (Fig. 10 f). 3D depictions are especially useful in docking and mechanistic studies, while 2D depictions are standard in structure–activity investigations.<anchor xml:id="a116"/></p>
        <p>AI applications within drug discovery using molecular representations</p>
        <p>Most of the representations we have discussed above have seen widespread use within the fields of drug discovery and artificial intelligence. If there are any molecular representations which the reader feels were not discussed, it is because we, the authors, were not aware of the widespread use of that representation within our specialized fields of research. The omission of some representations may have been intentional, or it may have been due to the fast rate of change and developments in this field as the availability of useful datasets for drug discovery applications grows. Lastly, several concepts that were historically used may see a resurgence as they are adapted to suit current methods.</p>
        <p>Graph representations for small molecules</p>
        <p><anchor xml:id="a117"/>Despite this being a review of molecular representations, many of these representations are themselves used in representation learning applications within deep learning. Representation learning is the idea of learning an internal representation (e.g. a vector) for a given object (e.g. a molecule) and then using that internal representation for a predictive task. These internal representations are learned, meaning models can be trained to create them using classic techniques such as backpropagation in neural networks. With representation learning tasks, it is key to first identify a suitable input representation of a molecule that contains as much of the desired/necessary information to solve a problem as possible. Of the applications described below, any using deep neural network (DNN) architectures are essentially carrying out representation learning tasks, whereas classical ML methods such as random forests (RFs) and support vector machines do not operate by learning internal representations.<anchor xml:id="a118"/></p>
        <p><anchor xml:id="a119"/>With the development of graph neural networks, a wave of recent work in drug discovery has focused on using the molecular graph representation directly for both property prediction and de novo design. As such, the molecular graph representation can be used for various applications within AI, and there is a large body of work discussing its use for molecular property prediction [ 26 , 116 – 119 ], and, more recently, molecular graph generation [ 120 – 125 ] and synthesis prediction [ 126 ]. In most cases this is done through graph representation learning, by which a graph embedding is obtained from the full graph representation using a graph network [ 127 , 128 ]; the learned graph embedding can be used as input to a property prediction model, such as a RF or DNN, in the same way a classic molecular fingerprint [ 66 , 129 , 130 ] is used. Until recently, more compact linear notations such as SMILES strings were favoured for many ML applications involving molecules, in part due to the larger memory requirement of molecular graph representations; this is, however, slowly changing. For two excellent reviews of deep learning applications in chemistry and drug discovery, we recommend [ 26 ] and [ 131 ]. For a good review on molecular generative models using AI, we recommend [ 132 ].<anchor xml:id="a120"/></p>
        <p>Another popular use of molecular graphs both within and outside drug discovery lies in part outside AI, where graphs are used as input for atomistic simulations (e.g. molecular dynamics) where atomic coordinates and periodic boundary conditions are used as the starting point for program-specific file formats which contain not only all atom coordinates, but also detailed bond information (e.g. bond length, dihedral angles, torsional angles) necessary to calculate the energy of a given molecular configuration using force fields. As such, the molecular graph representation has widespread use in molecular dynamics applications within drug discovery, such as docking, protein folding, and free energy perturbation calculations. These applications have been assisted by recent developments in AI [ 133 , 134 ].</p>
        <p>Linear notations for small molecules</p>
        <p><anchor xml:id="a121"/>Popular applications of linear notations such as SMILES and molecular fingerprints are in molecular property prediction and QSAR. SMARTS patterns have been used to define substructures with the aim of selecting or eliminating associated compounds [ 135 – 137 ]. Additionally, the use of string representations such as SMILES has seen a lot of unexpected success in the field of de novo molecular design using tools from NLP. Data augmentation can be done for many applications using randomized SMILES [ 51 , 138 ]. String representations have also seen success in property prediction using the learned latent space representations obtained using autoencoder frameworks [ 139 ]. As mentioned above, many of the aforementioned neural network models work by learning a vector representation for molecules in the training set, and using that learned representation to predict properties [ 116 , 118 , 140 ]; this is analogous to the older use of hashed fingerprint representations for molecular property prediction using traditional ML approaches, hence the term learned fingerprints .<anchor xml:id="a122"/></p>
        <p>Representations for chemical reactions</p>
        <p><anchor xml:id="a123"/>Common applications of the reaction representations are in retrosynthesis and reaction prediction. This is an important field of research, as the synthesizability of proposed compounds is key to computational drug design and having suitable retrosynthesis tools would allow scientists to “close the loop” of AI-driven drug discovery. Many of these applications are also discussed in [ 26 , 69 ].<anchor xml:id="a124"/></p>
        <p>Representations for macromolecules</p>
        <p><anchor xml:id="a125"/>Popular applications of the macromolecular representations introduced in this work are in protein structure prediction, as having an accurate picture of a protein and the role it plays in a given disease can help scientists to develop molecules for the right target. Pillong and Schneider [ 141 ] successfully applied their pseudo-receptor model in a virtual screening study aiming to identify aminoglycoside scaffolds with antibacterial potential. The interactions between glycans and proteins have been investigated [ 142 , 143 ] using ML. An important field of investigation linked to glycans is the prediction of glycosylation sites. Many tools were developed to infer such predictions and have been applied recently in the pipeline for the prediction of oncology drug targets [ 144 ] and the characterisation of the novel coronavirus (2019-nCoV) [ 145 ].<anchor xml:id="a126"/></p>
        <p>Graphical representations for molecules and macromolecules</p>
        <p><anchor xml:id="a127"/>We previously showed how the process of visualizing molecules has become faster, more practical, and more enjoyable thanks to better computational tools. This process is still an important field of research for which virtual reality and 3D printing techniques have been developed. Moreover, as the need for harvesting the large amounts of published data grows, the demand for methods for easily mining structures from papers and patent data is also growing. Optical Character Recognition (OCR) systems, relying on a variety of ML and probabilistic pattern recognition techniques, were created to translate 2D depictions of chemical structures to standard chemical representations [ 146 – 148 ]. Nonetheless, the development of OCR systems can be hindered by the images’ resolutions, the computational interpretations of chemical abbreviations, and the nature of the image representation, which can be embedded in text, in figures containing multiple structures, or in reaction pathways, and can be represented as either a skeletal formula or a Markush structure.<anchor xml:id="a128"/></p>
        <p>Discussion</p>
        <p><anchor xml:id="a129"/>At this point, it might become clear to the reader that many applications within drug discovery require multiple representations to be used simultaneously to solve a problem. For example, in protein structure prediction, one might start with the protein sequence, create a rudimentary 3D model of the structure, and then use advanced molecular dynamics methods to understand how the protein folds and what the final configuration/structure for the protein might be. The coordinates of the optimized protein structure (e.g. a PDB file) might then go on to be used in docking calculation, etc. Technical aspects may factor into the choice of representation(s) a researcher might make, such as the complexity of the method(s) for generating the representation(s), and if they are openly accessible.<anchor xml:id="a130"/></p>
        <p><anchor xml:id="a131"/>It is interesting to note that some representations have held the test of time better than others. This can be partly explained by the evolution of computer technologies, which have improved in terms of storage capabilities, processor qualities, and parallel programming capabilities. Standard representations such as IUPAC-Dyson and WLN were sensible during their times and were made to be manipulated by humans, but difficult to work with on a computer. Computationally simpler representations are now frequently used. Furthermore, detailed representations which require greater computational time to compute (compared to molecular string representations) can nowadays be used; this is the case for hashed fingerprints. Another possible explanation for the endurance of certain molecular representation is that they are more human readable than others, and thus have been better received by the cheminformatics community. Lastly, another reason why some notations persist and others do not is that within different fields and subfields (e.g. cheminformatics, bioinformatics, or AI), different notations are often preferred for either historical or continuity reasons within groups.<anchor xml:id="a132"/></p>
        <p>Conclusions</p>
        <p><anchor xml:id="a133"/>Molecules are complex structures and their representations must account not only for a wide variety of properties, such as stereochemistry and valence, but also for the different nature of these small molecules and macromolecules. The rise of cheminformatics and bioinformatics has led to a faster and more efficient drug discovery process as well as to a better understanding of molecular behaviour. In this review, we presented various popular notations and representations for small molecules, polymers, and proteins and their most common uses related to AI within computational drug discovery. We hope that this review will benefit practising cheminformaticians, students, and anyone else interested to learn more about the underlying molecular representations in cheminformatics that can be used in AI-driven drug discovery applications.<anchor xml:id="a134"/></p>
        <p>Acknowledgements</p>
        <p>L.D. and A.T. would like to thank the European Union’s Horizon 2020 research and innovation program. R.M. would like to thank the AstraZeneca Postdoc Program. Third-party materials used in figures [ 149 – 157 ] are licensed under CC BY [ 158 ]. The authors would like to thank the editor and the reviewers, two anonymous and Dr. Noel O’Boyle, for their extensive comments, suggestions, and patience throughout the many rounds of review.</p>
        <p>Abbreviations</p>
        <p>2-dimensional</p>
        <p>3-dimensional</p>
        <p>Amino acids</p>
        <p>Artificial intelligence</p>
        <p>Chemically Advanced Template Search</p>
        <p>Connection tables</p>
        <p>ChemAxon Extended SMILES</p>
        <p>Extended Connectivity Fingerprints</p>
        <p>Forward Translation</p>
        <p>Hierarchical Editing Language for Macromolecules</p>
        <p>International Chemistry Identifier</p>
        <p>International Union of Pure and Applied Chemistry</p>
        <p>Molecular Design Limited, Inc</p>
        <p>Machine-learning</p>
        <p>Natural Language Processing</p>
        <p>Optical character recognition</p>
        <p>Protein Line Notation</p>
        <p>Quantitative structure activity relationship</p>
        <p>Reaction-Data Files</p>
        <p>Reaction InChI</p>
        <p>Reaction</p>
        <p>SMILES Arbitrary Target Specification</p>
        <p>Simplified Molecular Input Line Entry System</p>
        <p>SMILES ReaKtion Specification</p>
        <p>Wiswesser Line Notation</p>
        <p>Web Unique Representation of Carbohydrate Structures</p>
        <p>Authors’ contributions</p>
        <p>RM and AT wrote the section entitled “ Graph representations for small molecules ”. All the authors contributed to the sections “ Notations for small molecules ” and “ AI applications within drug - discovery using molecular representations ”. The section “ Representations for chemical reactions ” was written by AT; LD wrote the sections “ Notations for macromolecules ” and “ Graphical representations for molecules and macromolecules ”. All authors read and approved the final manuscript.</p>
        <p>Funding</p>
        <p>L.D. and A.T. have received funding from the European Union’s Horizon 2020 research and innovation program under the Marie Sklodowska Curie grant agreement No 676434, “Big Data in Chemistry” (“BIGCHEM”, http://bigchem.eu ). The article reflects only the authors view and neither the European Commission nor the Research Executive Agency (REA) are responsible for any use that may be made of the information it contains.</p>
        <p>Availability of data and materials</p>
        <p>Not applicable.</p>
        <p>Competing interests</p>
        <p>All the authors were employed by AstraZeneca and declare no competing interests.</p>
        <p>Footnotes</p>
        <p>References</p>
        <p>Associated Data</p>
        <p>Data Availability Statement</p>
        <p>Not applicable.<anchor xml:id="a135"/></p>
    </body>
  </text>
</TEI>
