Design
======
General concepts
----------------
We understand **compound groups** to be sets of substances defined by their
shared molecular features, and which are useful to consider as a group because
they share other properties of interest.
The premise for grouping chemicals together is that many substances share
substantial similarities in toxicological characteristics. The notion that
these similarities are related to underlying similarities in molecular
structure is supported by toxicological research (Kazius et al., 2005; Singh et
al., 2016). Environmental fate and exposure potential are also known to be
related to molecular structure, making compound groups an important unit of
analysis in chemical hazard assessment and in the environmental health sciences
more broadly (Krowech et al., 2016).
Compounds groups of toxicological interest can be identified by a number of
research strategies, including computational and predictive toxicology
approaches (Faulkner et al., 2017).
Our focus, however, is on enumerating compounds that belong to groups *already
identified* through established methods. Over several decades of toxicological,
epidemiological, and regulatory science worldwide, several hundred compound
groups have been recognized and associated with known health hazards. For
example, `IARC `_ classifies "Nickel compounds" and
several other compound groups according to their carcinogenicity.
See below for :ref:`references `.
Methods for associating compounds with groups
---------------------------------------------
Computational tools already exist for analyzing and searching molecular
structures. Given a broad enough *set of relevant molecular structures*, and a
set of :ref:`defined ` *structural patterns* corresponding to
compound groups of interest, it should be possible to apply existing
computational methods to identify which compounds belong to which group(s). That
is the goal of Common Groups.
Thus, we sometimes describe our project as **"populating" groups** with relevant
examples of substances that belong to those groups. The immediate intended
application of this project is to give technical definitions and enable
computationally populating the set of compound groups named throughout all the
hazard identification sources of the `GreenScreen for Safer Chemicals`_ and the
`GreenScreen List Translator`_.
Design of this program
----------------------
The ``commongroups`` software automates the process of going from a compound
group definition to a list of substances that belong to the group. The program
reads technical definitions of compound groups from a Google Spreadsheet. In
the spreadsheet, the users of the program must define each group using the set
of :ref:`parameters ` described below. With these definitions, the
program searches a database of molecular structures looking for matches to the
patterns; hundreds of thousands of compounds can be evaluated automatically in
this way. Finally, the program generates lists of matching compounds, and
reports its results in the form of a web-browseable directory of groups.
To describe the "search" process in slightly more technical terms: For each
compound group, ``commongroups`` formulates a database query that expresses the
specified structural patterns and selection logic. It then runs this query
against a local database of chemical structures, and retrieves the resulting set
of compounds that match the group definition. Essential to this processs is the
`RDKit`_ open-source cheminformatics toolkit, which enables database querying
using molecular structure comparisons.
The actual compounds identified when a group is populated using ``commongroups``
will necessarily depend on what compounds are represented in the database that
is used. For information about how we construct a database for this purpose, see
:doc:`database`. For detailed technical documentation about how the
program works, see :doc:`usage` and the :doc:`developer`.
.. _definitions:
Defining groups
---------------
In this project we define groups by specifying one or more patterns in molecular
structure. We express these patterns in `SMARTS`_ notation (or, if very simple,
sometimes in `SMILES`_ notation). For some groups, we may need to specify
multiple patterns linked by logical conditions ("and", "or", "not", etc.). Here
are a few simple examples of molecular patterns that correpsond to compound
groups of toxicological interest.
======================== ============================
Compound group Structure pattern (SMARTS)
======================== ============================
Mercury compounds, alkyl ``[Hg]C``
Diazonium salts ``[C,c][N+]#[N]``
Methacrylates ``[CH3]C(=[CH2])C(=O)O-[*]``
======================== ============================
Since SMARTS expressions are not very intuitive or easily understood, it is
helpful to be able to visualise the meaning of a SMARTS expression. To that end,
we recommend a useful web app called `SMARTSviewer`_ developed at the University
of Hamburg.
We believe that the technical definitions of compound groups should be openly
discussed and peer-reviewed to ensure their accuracy and robustness. This aspect
of the Common Groups project will be documented and conducted elsewhere.
.. _parameters:
Parameters for defining a compound group
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following parameters define a compound group. However, note that this is
subject to change as the project and software develops.
- ``cmg_id``: A unique identifier for the group.
- ``name``: The name of the group, e.g., "Phthalates".
- ``method``: The search method for identifying compounds in the group. We
anticipate possibly having a range of computational methods available, but
in the current (early) version of this software, the only option is ``SQL``.
- ``structure_type``: How the structure is notated, i.e., SMILES or SMARTS.
- ``structure``: The structure or pattern used as input to the search method.
- ``code``: The criteria for how compounds should be evaluated to determine
whether or not they match the structural pattern. For the time being, these
definitions must be written in `SQL`_, a programming language used in
database operations.
- Specifically, this parameter corresponds to the ``where`` clause of a SQL
``select`` statement.
- The substrings ``:m`` and ``:s`` will be substituted with the name of the
database column containing molecular structures, and the value of the
``structure`` parameter, respectively.
Examples
^^^^^^^^
Here is an example of some group parameters in tabular form, as they would
appear in a spreadsheet:
====== ======================== ========= ============== ========= =============
cmg_id name method structure_type structure code
====== ======================== ========= ============== ========= =============
1001 Lead compouds SQL SMILES ``[Pb]`` ``:m @> :s``
2002 Mercury compounds, alkyl SQL SMARTS ``[Hg]C`` ``:m @> :s ::qmol``
====== ======================== ========= ============== ========= =============
In this example, note that lead compounds are defined with a very simple SMILES
string, which just specifies the element lead. The query code expresses a
substructure search: any molecule containing the lead atom as a substructure is
matched. In contrast, alkyl mercury compoounds requires a slightly more nuanced
definition, and we use SMARTS to specify the pattern of a mercury atom bound to
a *non-aromatic* carbon. We also include the ``::qmol`` term in the query code
to indicate that the structure is a query molecule.
In addition to these technical parameters, compound groups can be further
described by adding notes or plain-language descriptions. This information is
not used for computational purposes, but can be included for interpretation and
communication of results. In the ``commongroups`` spreadsheet format, any
columns *after* the parameters are read in as additional information.
In the next section, we describe the form of database that is necessary to
perform compound group population using these kinds of definitions.
.. _toxrefs:
References
----------
- Kazius, J., McGuire, R., & Bursi, R. (2005). Derivation and validation of
toxicophores for mutagenicity prediction. *Journal of Medicinal Chemistry*,
48(1), 312–320. https://doi.org/10.1021/jm040835a
- Singh, P. K., Negi, A., Gupta, P. K., Chauhan, M., & Kumar, R. (2016).
Toxicophore exploration as a screening technology for drug design and
discovery: Techniques, scope and limitations. *Archives of Toxicology*,
90(8), 1785–1802. https://doi.org/10.1007/s00204-015-1587-5
- Krowech, G., Hoover, S., Plummer, L., Sandy, M., Zeise, L., & Solomon, G.
(2016). Identifying chemical groups for biomonitoring. *Environmental Health
Perspectives,* 124(12), A219–A226. https://doi.org/10.1289/EHP537
- Faulkner, D., Rubin Shen, L. K., et al. (2017). Tools for green molecular
design to reduce toxicological risk. In R. J. Richardson & D. E. Johnson
(Eds.), *Computational systems pharmacology and toxicology* (pp. 36–59).
Cambridge: Royal Society of Chemistry.
https://doi.org/10.1039/9781782623731-00036
.. _GreenScreen for Safer Chemicals: https://www.greenscreenchemicals.org/
.. _GreenScreen List Translator:
https://www.greenscreenchemicals.org/learn/greenscreen-list-translator
.. _SMARTS: http://www.daylight.com/dayhtml/doc/theory/theory.smarts.html
.. _SMILES: http://www.daylight.com/dayhtml/doc/theory/theory.smiles.html
.. _SMARTSviewer: http://smartsview.zbh.uni-hamburg.de/smartsview/view
.. _RDKit: http://rdkit.org/
.. _SQL: https://en.wikipedia.org/wiki/SQL