Thanks Daniel, that’s good to know. Pierluigi, take note of this re your
suggested use of standard InChI. It looks like that’s a go for string
comparison.
On canonical SMILES, Bob made them irrelevant inside Jmol. I still don’t
understand how it works, but it works!
Otis
--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org
> On May 10, 2016, at 3:00 PM, Daniel Lowe <dan...@nextmovesoftware.com> wrote:
>
> Otis,
>
> Yes, StdInChI is a good way of determining if two molecules from different
> sources have the same connectivity/stereochemistry and indeed this part of
> the reason for InChI's creation.*
>
> The process of creating a standard InChI discards tautomer and resonance form
> information, so different sources with different representations should still
> give the same InChI.
> Representation can sometimes still be a problem for some inorganic
> compounds. InChI breaks all bonds to metals, but molecules like ferrocene
> still end up with two possible InChIs depending on if the Iron is considered
> neutral or +2 charged. InChI also doesn't handle some issues like ring-chain
> tautomerism.
>
> A comparison with canonical SMILES will have all these issues and be
> tautomer/resonance form specific (although of course one could apply
> "business rules" to normalize representation prior to creating the canonical
> SMILES)
>
> Daniel
> * You can also use the layered nature of InChI to check if two molecules are
> different whether that difference is due to different
> constitution/connectivity/hydrogen placement or stereochemistry
>
> On 10/05/2016 17:52, Otis Rothenberger wrote:
>> 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 <mailto:o...@chemagic.org>
>> http://chemagic.org <http://chemagic.org/>
>>> On May 10, 2016, at 12:20 PM, Daniel Lowe <
>>> <mailto:dan...@nextmovesoftware.com>dan...@nextmovesoftware.com
>>> <mailto: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 <http://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
>>> <https://ad.doubleclick.net/ddm/clk/304595813;131938128;j>
>>> _______________________________________________
>>> Jmol-users mailing list
>>> Jmol-users@lists.sourceforge.net <mailto:Jmol-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>> <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
>> <https://ad.doubleclick.net/ddm/clk/304595813;131938128;j>
>>
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net <mailto:Jmol-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>> <https://lists.sourceforge.net/lists/listinfo/jmol-users>
>
>
> --
> Daniel Lowe
> Senior Software Engineer
> NextMove Software Limited
> Registered in England No. 07588305
> Registered Office: Innovation Centre (Unit 23), Cambridge Science Park,
> Cambridge CB4 0EY
> ------------------------------------------------------------------------------
> 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
