Daniel,
Thanks for taking the time to jump in here!
As long as we have your attention, I’ll ask a question about InChI string
comparison:
Is a simple string comparison of two **standard** InChI’s, perhaps from
different sources, an acceptable method for determining compound identity? By
identity, I mean the same kind of connective identity that could be established
with a stereo SMILES comparison.
If there is uncertainty in the above InChI comparison, would pulling the
**standard** InChI from a single source like Resolver improve the comparison?
Otis
--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org
> On May 10, 2016, at 12:20 PM, Daniel Lowe <dan...@nextmovesoftware.com> wrote:
>
> Dear Pierluigi and Otis,
>
> OPSIN as a Java library and via its JSON api (e.g.
> <http://opsin.ch.cam.ac.uk/opsin/benzene.json>http://opsin.ch.cam.ac.uk/opsin/benzene.json
> <http://opsin.ch.cam.ac.uk/opsin/benzene.json>) can return standard or
> non-standard InChI.
>
> The non-standard InChI OPSIN produces differs from StdInChI by including the
> fixed hydrogen layer (i.e. tautomer information). The reasoning for this is
> that IUPAC names are typically tautomer specific so at the time I initially
> added InChI support (quite a few years ago now) I thought it would be useful
> to retain this information. As InChI is hierarchical one can get an InChI
> with identical layers as StdInChI by stripping the fixed hydrogen layer
> (using the InChI toolkit or otherwise). Obviously the same is not true in
> reverse as StdInChI (intentionally) lacks tautomer information.
>
> In practice utilisation of the layered nature of InChI is rare and virtually
> all sites with InChI now use StdInChI...so perhaps I should change
> opsin.ch.cam.ac.uk to display StdInChI in the GUI.
>
> Standard InChIKey is used as this is the format of InChI key used in various
> internet databases hence allowing one to Google for a specific structure.
>
> As pointed out earlier the NCI's chemical identifier resolver uses a copy of
> OPSIN internally....albeit I think the version is quite may now be quite out
> of date.
>
> My main goal while developing OPSIN was to use it in automated text-mining.
> As a result while I aim to keep to an absolute minimum cases where the
> resultant structure is not in agreement with the name, I do tolerate minor
> errors in the input e.g. missing/extra spaces. As names like "5-chlorohexane"
> only have one plausible interpretation trying to flag these as "incorrect"
> was a low priority. I'm not actually aware of any existing name to structure
> algorithm that would reject that name. I think to solve the general case
> (e.g. 2-propylbutane ["incorrect"] vs 3-methylhexane [correct]) you'd have to
> written a fair chunk of a chemical structure to name algorithm to know that
> it was incorrect!
>
> Daniel
>
> "For reasons that I do not fully understand, OPSIN returns InChI - not
> standard InChI. It does, however, return standard InChIKey! In general, I’d
> be very nervous about comparing InChI strings created by different resources."
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
