InChI Facilities and Applications

InChI Discussion Group,

Recently, there appeared a number of requests to define "standard" InChI =
generation options.

The reason is that InChI string as well as the 2nd block of InChIKey for =
the same structure produced with different options may be different.
To overcome this issue, some standard generation options should be =
recommended.

After a discussion, InChI development team would like to suggest the =
following tentative standard to your consideration and comments.

The main idea is that everybody who is not sure which InChI generation =
options to use would use the same "standard" set of options. However, =
individuals who believe the "nonstandard" options they have selected =
reflect some kind of reality may use whatever they believe is right. The =
burden of InChI option selection would be=20
replaced with the selection of InChI layers to compare; in most common =
cases this may be done without much thinking by using InChIKey.

1) It is recommended to generate InChI with all possible layers included =
and all software fixes turned "ON".
This means the following related to InChI generation command-line =
parameters for cInChI-1:

/FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud

/FixedH - Turn off Mobile H perception
/RecMet - Include bonds to metal
/SPXYZ - Include Phosphines Stereochemistry
/SAsXYZ - Include Arsines Stereochemistry
/Newps - Narrow end of wedge points to stereocenter
/Fb - Fix bug leading to missing or undefined sp3 parity
/Fnud - Fix non-uniform drawing issues

Note on /Fnud option. This is the last fix introduced after 1.02-beta =
release to appear in the final 1.02 release.
It is intended to fix minor issues related to halogen oxoanions (e.g., =
ClO4- with 4 double bonds and "minus" on Cl) and amidinium cations =
(-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N.=20
The impact of this fix is rather small: as tested with ChemSpider =
database (courtesy of Antony Williams), it changed 209 InChI out of =
~17M.


2) It is suggested that, for convenience, we introduce a new =
command-line option for the software which serves as a short-cut to =
above command-line parameters, tentatively called /STDINCHI or /STDGEN.
It is assumed that while interpreting command-line,
'/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ /Newps =
/Fb /Fnud'


3) It is recommended that InChI users, when they would like to check if =
the two InChI/InChIKeys represent the same structure, do the following:

(a) compare the two InChIKeys first blocks (or respective layers of =
InChI).
If they are different, the structures are different.
Otherwise,
(b) compare the two InChIKeys second blocks (or the rest of InChI).
If they are the same, the structures are the same.
Otherwise,
(c) there are still chances that these two different InChIs are of the =
same structure because they were created with different options.
If it is definitely not the case (the user knows that both InChIs are =
produced with, say, standard options), the structures are different.
Otherwise, user is advised to compare the 2 InChIs layer by layer, as =
described in InChI Technical Manual, appendix 4.

Note: it is assumed that the word "different" above means "different by =
full InChI string".
It may not always mean that a particular chemist would consider the two =
structures as being different.

For example, a pair of "different structures" as found by comparing the =
2nd block of InChIKey may:
- differ by a degree of protonation
- be different tautomeric forms of the same compound
- have different stereochemistry
- be really different in case of metal atoms present.
To find out the user needs to compare InChI strings as described at the =
end of (c).


4) The suggestion to have "standard" options like above has both =
positives and negatives.
Namely:
Pros
=3D=3D=3D=3D=3D=3D=3D
(P1) the number of command-line generation parameters will be reduced =
making software usage simpler;
(P2) anybody (even those not familiar with InChI layout) will be able to =
produce the identifiers/keys in an unambiguous manner;
(P3) the comparison of InChI/InChIKeys will be, in general, more =
reliable.
Cons
=3D=3D=3D=3D=3D=3D=3D
(C1) InChI strings will be longer (as a suggested "standard" requires =
including of all possible layers);
(C2) InChI/InChIKeys for many existing compilations should be =
re-calculated;
(C3) the "standard" form may not match chemical understanding of some =
users (e.g., those who consider different tautomers as the same =
molecule).

In our opinion, (P2) is the most important issue.


We appreciate and encourage your continued interest and input.

-Steve Stein, NIST
-Steve Heller, NIST
-Alan McNaught, RSC
-Dmitrii Tchekhovskoi, NIST
-Igor Pletnev, NIST

Re: [InChI-discuss] InChI standard generation options (request forcomments) From: Wolf-D. Ihlenfeldt <wdi@xe...> - 2008-01-11 15:17 Attachments: Message as HTML      No comments, except that I agree with your choice of options, and these have been picked up by the latest CACTVS toolkit source and are now the default. W. D. Ihlenfeldt Xemistry GmbH wdi@... _____ From: inchi-discuss-bounces@... [mailto:inchi-discuss-bounces@...] On Behalf Of Igor Pletnev Sent: Thursday, January 10, 2008 9:24 PM To: inchi-discuss@... Subject: [InChI-discuss] InChI standard generation options (request forcomments) InChI Discussion Group, Recently, there appeared a number of requests to define "standard" InChI generation options. The reason is that InChI string as well as the 2nd block of InChIKey for the same structure produced with different options may be different. To overcome this issue, some standard generation options should be recommended. After a discussion, InChI development team would like to suggest the following tentative standard to your consideration and comments. The main idea is that everybody who is not sure which InChI generation options to use would use the same "standard" set of options. However, individuals who believe the "nonstandard" options they have selected reflect some kind of reality may use whatever they believe is right. The burden of InChI option selection would be replaced with the selection of InChI layers to compare; in most common cases this may be done without much thinking by using InChIKey. 1) It is recommended to generate InChI with all possible layers included and all software fixes turned "ON". This means the following related to InChI generation command-line parameters for cInChI-1: /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud /FixedH - Turn off Mobile H perception /RecMet - Include bonds to metal /SPXYZ - Include Phosphines Stereochemistry /SAsXYZ - Include Arsines Stereochemistry /Newps - Narrow end of wedge points to stereocenter /Fb - Fix bug leading to missing or undefined sp3 parity /Fnud - Fix non-uniform drawing issues Note on /Fnud option. This is the last fix introduced after 1.02-beta release to appear in the final 1.02 release. It is intended to fix minor issues related to halogen oxoanions (e.g., ClO4- with 4 double bonds and "minus" on Cl) and amidinium cations (-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N. The impact of this fix is rather small: as tested with ChemSpider database (courtesy of Antony Williams), it changed 209 InChI out of ~17M. 2) It is suggested that, for convenience, we introduce a new command-line option for the software which serves as a short-cut to above command-line parameters, tentatively called /STDINCHI or /STDGEN. It is assumed that while interpreting command-line, '/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud' 3) It is recommended that InChI users, when they would like to check if the two InChI/InChIKeys represent the same structure, do the following: (a) compare the two InChIKeys first blocks (or respective layers of InChI). If they are different, the structures are different. Otherwise, (b) compare the two InChIKeys second blocks (or the rest of InChI). If they are the same, the structures are the same. Otherwise, (c) there are still chances that these two different InChIs are of the same structure because they were created with different options. If it is definitely not the case (the user knows that both InChIs are produced with, say, standard options), the structures are different. Otherwise, user is advised to compare the 2 InChIs layer by layer, as described in InChI Technical Manual, appendix 4. Note: it is assumed that the word "different" above means "different by full InChI string". It may not always mean that a particular chemist would consider the two structures as being different. For example, a pair of "different structures" as found by comparing the 2nd block of InChIKey may: - differ by a degree of protonation - be different tautomeric forms of the same compound - have different stereochemistry - be really different in case of metal atoms present. To find out the user needs to compare InChI strings as described at the end of (c). 4) The suggestion to have "standard" options like above has both positives and negatives. Namely: Pros ======= (P1) the number of command-line generation parameters will be reduced making software usage simpler; (P2) anybody (even those not familiar with InChI layout) will be able to produce the identifiers/keys in an unambiguous manner; (P3) the comparison of InChI/InChIKeys will be, in general, more reliable. Cons ======= (C1) InChI strings will be longer (as a suggested "standard" requires including of all possible layers); (C2) InChI/InChIKeys for many existing compilations should be re-calculated; (C3) the "standard" form may not match chemical understanding of some users (e.g., those who consider different tautomers as the same molecule). In our opinion, (P2) is the most important issue. We appreciate and encourage your continued interest and input. -Steve Stein, NIST -Steve Heller, NIST -Alan McNaught, RSC -Dmitrii Tchekhovskoi, NIST -Igor Pletnev, NIST

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Beda Kosata <Bedrich.Kosata@vs...> - 2008-01-22 11:34 Attachments: smime.p7s      It is certainly a good decision to have standard set of options for InChI generation. I would also appreciate if such as set of options was reflected in the default settings of the program, so that it would produce a "standard" InChI *without* any specific options given. I believe that this is also what an unsuspecting user would expect. Best regards Beda Kosata Igor Pletnev wrote: > InChI Discussion Group, > > Recently, there appeared a number of requests to define "standard" InChI > generation options. > > The reason is that InChI string as well as the 2nd block of InChIKey for > the same structure produced with different options may be different. > To overcome this issue, some standard generation options should be > recommended. > After a discussion, InChI development team would like to suggest the > following tentative standard to your consideration and comments. > > The main idea is that everybody who is not sure which InChI generation > options to use would use the same "standard" set of options. However, > individuals who believe the "nonstandard" options they have selected > reflect some kind of reality may use whatever they believe is right. The > burden of InChI option selection would be > replaced with the selection of InChI layers to compare; in most common > cases this may be done without much thinking by using InChIKey. > > 1) It is recommended to generate InChI with all possible layers included > and all software fixes turned "ON". > This means the following related to InChI generation command-line > parameters for cInChI-1: > > /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud > > /FixedH - Turn off Mobile H perception > /RecMet - Include bonds to metal > /SPXYZ - Include Phosphines Stereochemistry > /SAsXYZ - Include Arsines Stereochemistry > /Newps - Narrow end of wedge points to stereocenter > /Fb - Fix bug leading to missing or undefined sp3 parity > /Fnud - Fix non-uniform drawing issues > > Note on /Fnud option. This is the last fix introduced after 1.02-beta > release to appear in the final 1.02 release. > It is intended to fix minor issues related to halogen oxoanions (e.g., > ClO4- with 4 double bonds and "minus" on Cl) and amidinium cations > (-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N. > The impact of this fix is rather small: as tested with ChemSpider > database (courtesy of Antony Williams), it changed 209 InChI out of ~17M. > > > 2) It is suggested that, for convenience, we introduce a new > command-line option for the software which serves as a short-cut to > above command-line parameters, tentatively called /STDINCHI or /STDGEN. > It is assumed that while interpreting command-line, > '/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ /Newps > /Fb /Fnud' > > > 3) It is recommended that InChI users, when they would like to check if > the two InChI/InChIKeys represent the same structure, do the following: > > (a) compare the two InChIKeys first blocks (or respective layers of InChI). > If they are different, the structures are different. > Otherwise, > (b) compare the two InChIKeys second blocks (or the rest of InChI). > If they are the same, the structures are the same. > Otherwise, > (c) there are still chances that these two different InChIs are of the > same structure because they were created with different options. > If it is definitely not the case (the user knows that both InChIs are > produced with, say, standard options), the structures are different. > Otherwise, user is advised to compare the 2 InChIs layer by layer, as > described in InChI Technical Manual, appendix 4. > > Note: it is assumed that the word "different" above means "different by > full InChI string". > It may not always mean that a particular chemist would consider the two > structures as being different. > > For example, a pair of "different structures" as found by comparing the > 2nd block of InChIKey may: > - differ by a degree of protonation > - be different tautomeric forms of the same compound > - have different stereochemistry > - be really different in case of metal atoms present. > To find out the user needs to compare InChI strings as described at the > end of (c). > > > 4) The suggestion to have "standard" options like above has both > positives and negatives. > Namely: > Pros > ======= > (P1) the number of command-line generation parameters will be reduced > making software usage simpler; > (P2) anybody (even those not familiar with InChI layout) will be able to > produce the identifiers/keys in an unambiguous manner; > (P3) the comparison of InChI/InChIKeys will be, in general, more reliable. > Cons > ======= > (C1) InChI strings will be longer (as a suggested "standard" requires > including of all possible layers); > (C2) InChI/InChIKeys for many existing compilations should be re-calculated; > (C3) the "standard" form may not match chemical understanding of some > users (e.g., those who consider different tautomers as the same molecule). > > In our opinion, (P2) is the most important issue. > > > We appreciate and encourage your continued interest and input. > > -Steve Stein, NIST > -Steve Heller, NIST > -Alan McNaught, RSC > -Dmitrii Tchekhovskoi, NIST > -Igor Pletnev, NIST > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > _______________________________________________ > InChI-discuss mailing list > InChI-discuss@... > https://lists.sourceforge.net/lists/listinfo/inchi-discuss

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Dmitrii Tchekhovskoi <Dmitrii.Tchekhovskoi@ni...> - 2008-01-22 18:01 Changing the InChI program(s) behavior so that a "standard" InChI is produced *without* any specific options would require either (a) introducing new options that would turn off each of the "standard" options, or (b) introducing a new option to cancel all "standard" options at once. In my opinion, each of the possibilities may confuse both users (who already have some InChI experience) and existing software (that uses or incorporates InChI code; please keep in mind that InChI software library, libinchi.dll/.so, also needs proper command line options.) Regards Dmitrii At 06:34 AM 1/22/2008, Beda Kosata wrote: >It is certainly a good decision to have standard set of options for >InChI generation. I would also appreciate if such as set of options was >reflected in the default settings of the program, so that it would >produce a "standard" InChI *without* any specific options given. I >believe that this is also what an unsuspecting user would expect. > > Best regards > > Beda Kosata > >Igor Pletnev wrote: > > InChI Discussion Group, > > > > Recently, there appeared a number of requests to define "standard" InChI > > generation options. > > > > The reason is that InChI string as well as the 2nd block of InChIKey for > > the same structure produced with different options may be different. > > To overcome this issue, some standard generation options should be > > recommended. > > After a discussion, InChI development team would like to suggest the > > following tentative standard to your consideration and comments. > > > > The main idea is that everybody who is not sure which InChI generation > > options to use would use the same "standard" set of options. However, > > individuals who believe the "nonstandard" options they have selected > > reflect some kind of reality may use whatever they believe is right. The > > burden of InChI option selection would be > > replaced with the selection of InChI layers to compare; in most common > > cases this may be done without much thinking by using InChIKey. > > > > 1) It is recommended to generate InChI with all possible layers included > > and all software fixes turned "ON". > > This means the following related to InChI generation command-line > > parameters for cInChI-1: > > > > /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud > > > > /FixedH - Turn off Mobile H perception > > /RecMet - Include bonds to metal > > /SPXYZ - Include Phosphines Stereochemistry > > /SAsXYZ - Include Arsines Stereochemistry > > /Newps - Narrow end of wedge points to stereocenter > > /Fb - Fix bug leading to missing or undefined sp3 parity > > /Fnud - Fix non-uniform drawing issues > > > > Note on /Fnud option. This is the last fix introduced after 1.02-beta > > release to appear in the final 1.02 release. > > It is intended to fix minor issues related to halogen oxoanions (e.g., > > ClO4- with 4 double bonds and "minus" on Cl) and amidinium cations > > (-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N. > > The impact of this fix is rather small: as tested with ChemSpider > > database (courtesy of Antony Williams), it changed 209 InChI out of ~17M. > > > > > > 2) It is suggested that, for convenience, we introduce a new > > command-line option for the software which serves as a short-cut to > > above command-line parameters, tentatively called /STDINCHI or /STDGEN. > > It is assumed that while interpreting command-line, > > '/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ /Newps > > /Fb /Fnud' > > > > > > 3) It is recommended that InChI users, when they would like to check if > > the two InChI/InChIKeys represent the same structure, do the following: > > > > (a) compare the two InChIKeys first blocks (or respective layers of InChI). > > If they are different, the structures are different. > > Otherwise, > > (b) compare the two InChIKeys second blocks (or the rest of InChI). > > If they are the same, the structures are the same. > > Otherwise, > > (c) there are still chances that these two different InChIs are of the > > same structure because they were created with different options. > > If it is definitely not the case (the user knows that both InChIs are > > produced with, say, standard options), the structures are different. > > Otherwise, user is advised to compare the 2 InChIs layer by layer, as > > described in InChI Technical Manual, appendix 4. > > > > Note: it is assumed that the word "different" above means "different by > > full InChI string". > > It may not always mean that a particular chemist would consider the two > > structures as being different. > > > > For example, a pair of "different structures" as found by comparing the > > 2nd block of InChIKey may: > > - differ by a degree of protonation > > - be different tautomeric forms of the same compound > > - have different stereochemistry > > - be really different in case of metal atoms present. > > To find out the user needs to compare InChI strings as described at the > > end of (c). > > > > > > 4) The suggestion to have "standard" options like above has both > > positives and negatives. > > Namely: > > Pros > > ======= > > (P1) the number of command-line generation parameters will be reduced > > making software usage simpler; > > (P2) anybody (even those not familiar with InChI layout) will be able to > > produce the identifiers/keys in an unambiguous manner; > > (P3) the comparison of InChI/InChIKeys will be, in general, more reliable. > > Cons > > ======= > > (C1) InChI strings will be longer (as a suggested "standard" requires > > including of all possible layers); > > (C2) InChI/InChIKeys for many existing compilations should be > re-calculated; > > (C3) the "standard" form may not match chemical understanding of some > > users (e.g., those who consider different tautomers as the same molecule). > > > > In our opinion, (P2) is the most important issue. > > > > > > We appreciate and encourage your continued interest and input. > > > > -Steve Stein, NIST > > -Steve Heller, NIST > > -Alan McNaught, RSC > > -Dmitrii Tchekhovskoi, NIST > > -Igor Pletnev, NIST > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > InChI-discuss mailing list > > InChI-discuss@... > > https://lists.sourceforge.net/lists/listinfo/inchi-discuss > > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >InChI-discuss mailing list >InChI-discuss@... >https://lists.sourceforge.net/lists/listinfo/inchi-discuss

Re: [InChI-discuss] InChI standard generation options (request for comments) From: <zucker@re...> - 2008-01-25 09:57 Dear InChI developers, As yet another unsuspecting victim of the cInChI-1 default settings, I would like to point out that default settings should always follow the principle of least surprise. What on earth would possess you to introduce a non-default flag called "FixSp3Bug"? Do you really believe there exists a user who *wants* a buggy InChI? By default? This is the lunacy that results when you take the virtue of "backwards compatibility" too far. One last comment: it is unfriendly in the extreme to require users to troll the InChI-discuss mailing lists just so one can find out what the appropriate switches are to produce a standard InChI. This way lies madness... Jeremy > Changing the InChI program(s) behavior so that a "standard" InChI is > produced *without* any specific options would require either > > (a) introducing new options that would turn off each of the > "standard" options, or > (b) introducing a new option to cancel all "standard" options at once. > > In my opinion, each of the possibilities may confuse both users (who > already have some InChI experience) and existing software (that uses or > incorporates InChI code; please keep in mind that InChI software > library, libinchi.dll/.so, also needs proper command line options.) > > Regards > > Dmitrii > > > At 06:34 AM 1/22/2008, Beda Kosata wrote: >>It is certainly a good decision to have standard set of options for >> InChI generation. I would also appreciate if such as set of options was >> reflected in the default settings of the program, so that it would >> produce a "standard" InChI *without* any specific options given. I >> believe that this is also what an unsuspecting user would expect. >> >> Best regards >> >> Beda Kosata >> >>Igor Pletnev wrote: >> > InChI Discussion Group, >> > >> > Recently, there appeared a number of requests to define "standard" >> InChI generation options. >> > >> > The reason is that InChI string as well as the 2nd block of InChIKey >> for the same structure produced with different options may be >> different. To overcome this issue, some standard generation options >> should be recommended. >> > After a discussion, InChI development team would like to suggest the >> following tentative standard to your consideration and comments. >> > >> > The main idea is that everybody who is not sure which InChI >> generation options to use would use the same "standard" set of >> options. However, individuals who believe the "nonstandard" options >> they have selected reflect some kind of reality may use whatever >> they believe is right. The burden of InChI option selection would be >> > replaced with the selection of InChI layers to compare; in most >> common cases this may be done without much thinking by using >> InChIKey. >> > >> > 1) It is recommended to generate InChI with all possible layers >> included and all software fixes turned "ON". >> > This means the following related to InChI generation command-line >> parameters for cInChI-1: >> > >> > /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud >> > >> > /FixedH - Turn off Mobile H perception >> > /RecMet - Include bonds to metal >> > /SPXYZ - Include Phosphines Stereochemistry >> > /SAsXYZ - Include Arsines Stereochemistry >> > /Newps - Narrow end of wedge points to stereocenter >> > /Fb - Fix bug leading to missing or undefined sp3 parity >> > /Fnud - Fix non-uniform drawing issues >> > >> > Note on /Fnud option. This is the last fix introduced after >> 1.02-beta release to appear in the final 1.02 release. >> > It is intended to fix minor issues related to halogen oxoanions >> (e.g., ClO4- with 4 double bonds and "minus" on Cl) and amidinium >> cations (-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N. >> > The impact of this fix is rather small: as tested with ChemSpider >> database (courtesy of Antony Williams), it changed 209 InChI out of >> ~17M. >> > >> > >> > 2) It is suggested that, for convenience, we introduce a new >> > command-line option for the software which serves as a short-cut to >> above command-line parameters, tentatively called /STDINCHI or >> /STDGEN. It is assumed that while interpreting command-line, >> > '/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ >> /Newps /Fb /Fnud' >> > >> > >> > 3) It is recommended that InChI users, when they would like to check >> if the two InChI/InChIKeys represent the same structure, do the >> following: >> > >> > (a) compare the two InChIKeys first blocks (or respective layers of >> InChI). If they are different, the structures are different. >> > Otherwise, >> > (b) compare the two InChIKeys second blocks (or the rest of InChI). >> If they are the same, the structures are the same. >> > Otherwise, >> > (c) there are still chances that these two different InChIs are of >> the same structure because they were created with different options. >> If it is definitely not the case (the user knows that both InChIs >> are produced with, say, standard options), the structures are >> different. Otherwise, user is advised to compare the 2 InChIs layer >> by layer, as described in InChI Technical Manual, appendix 4. >> > >> > Note: it is assumed that the word "different" above means "different >> by full InChI string". >> > It may not always mean that a particular chemist would consider the >> two structures as being different. >> > >> > For example, a pair of "different structures" as found by comparing >> the 2nd block of InChIKey may: >> > - differ by a degree of protonation >> > - be different tautomeric forms of the same compound >> > - have different stereochemistry >> > - be really different in case of metal atoms present. >> > To find out the user needs to compare InChI strings as described at >> the end of (c). >> > >> > >> > 4) The suggestion to have "standard" options like above has both >> positives and negatives. >> > Namely: >> > Pros >> > ======= >> > (P1) the number of command-line generation parameters will be >> reduced making software usage simpler; >> > (P2) anybody (even those not familiar with InChI layout) will be >> able to produce the identifiers/keys in an unambiguous manner; >> > (P3) the comparison of InChI/InChIKeys will be, in general, more >> reliable. Cons >> > ======= >> > (C1) InChI strings will be longer (as a suggested "standard" >> requires including of all possible layers); >> > (C2) InChI/InChIKeys for many existing compilations should be >> re-calculated; >> > (C3) the "standard" form may not match chemical understanding of >> some users (e.g., those who consider different tautomers as the same >> molecule). >> > >> > In our opinion, (P2) is the most important issue. >> > >> > >> > We appreciate and encourage your continued interest and input. >> > >> > -Steve Stein, NIST >> > -Steve Heller, NIST >> > -Alan McNaught, RSC >> > -Dmitrii Tchekhovskoi, NIST >> > -Igor Pletnev, NIST >> > >> > >> > ------------------------------------------------------------------------ >> > >> > ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> > It's the best place to buy or sell services for >> > just about anything Open Source. >> > >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > InChI-discuss mailing list >> > InChI-discuss@... >> > https://lists.sourceforge.net/lists/listinfo/inchi-discuss >> >> >> >>------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >>Defy all challenges. Microsoft(R) Visual Studio 2008. >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>_______________________________________________ >>InChI-discuss mailing list >>InChI-discuss@... >>https://lists.sourceforge.net/lists/listinfo/inchi-discuss > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > InChI-discuss mailing list > InChI-discuss@... > https://lists.sourceforge.net/lists/listinfo/inchi-discuss

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Markus Krummenacker <kr@AI...> - 2008-01-26 21:58 Dear InChI developers, (I am not subscribed to inchi-discuss@... , so please excuse me for just dropping off my $0.02) I also think setting the options correctly for the cInChI-1 executable is exceedingly complicated and confusing. When I started using this, I had no idea what I was getting into... So, maybe now, you could consider making use of the "InChI=1/" preamble in the InChI strings, to accurately identify the variants, such that there will be less confusion regarding what kind of string one is looking at. Maybe it is too early to switch it to "InChI=2/". However, why not introduce a "InChI=1S/", where the "S" would stand for "standard" ? This would be the string generated when setting all the standard options and bug fixes as enumerated in your earlier announcement below. And then, given that the executable name also already has a bizarrely complicated name, (cInChI-1 looks like a password, containing upper and lower case letters, numbers, and other miscellaneous punctuation characters...), why not at the same time also provide a separate executable called cInChI-1S ? With this arrangement, calling cInChI-1S without any additional settings will produce a truly standardized "InChI=1S/" InChi string. Maybe you could even have cInChI-1S reject all additional arguments, such that the only legal way of running it always produces the standard string. This would presumably clarify things a bit, and make standard InChi generation easy for the average user. -- -- Regards Markus Krummenacker zucker@... writes: > Dear InChI developers, > > As yet another unsuspecting victim of the cInChI-1 default settings, I > would like to point out that default settings should always follow the > principle of least surprise. What on earth would possess you to introduce > a non-default flag called "FixSp3Bug"? Do you really believe there > exists a user who *wants* a buggy InChI? By default? This is the lunacy > that results when you take the virtue of "backwards compatibility" too > far. > > One last comment: it is unfriendly in the extreme to require users to > troll the InChI-discuss mailing lists just so one can find out what the > appropriate switches are to produce a standard InChI. This way lies > madness... > > > Jeremy > > > > Changing the InChI program(s) behavior so that a "standard" InChI is > > produced *without* any specific options would require either > > > > (a) introducing new options that would turn off each of the > > "standard" options, or > > (b) introducing a new option to cancel all "standard" options at once. > > > > In my opinion, each of the possibilities may confuse both users (who > > already have some InChI experience) and existing software (that uses or > > incorporates InChI code; please keep in mind that InChI software > > library, libinchi.dll/.so, also needs proper command line options.) > > > > Regards > > > > Dmitrii > > > > > > At 06:34 AM 1/22/2008, Beda Kosata wrote: > >>It is certainly a good decision to have standard set of options for > >> InChI generation. I would also appreciate if such as set of options was > >> reflected in the default settings of the program, so that it would > >> produce a "standard" InChI *without* any specific options given. I > >> believe that this is also what an unsuspecting user would expect. > >> > >> Best regards > >> > >> Beda Kosata > >> > >>Igor Pletnev wrote: > >> > InChI Discussion Group, > >> > > >> > Recently, there appeared a number of requests to define "standard" > >> InChI generation options. > >> > > >> > The reason is that InChI string as well as the 2nd block of InChIKey > >> for the same structure produced with different options may be > >> different. To overcome this issue, some standard generation options > >> should be recommended. > >> > After a discussion, InChI development team would like to suggest the > >> following tentative standard to your consideration and comments. > >> > > >> > The main idea is that everybody who is not sure which InChI > >> generation options to use would use the same "standard" set of > >> options. However, individuals who believe the "nonstandard" options > >> they have selected reflect some kind of reality may use whatever > >> they believe is right. The burden of InChI option selection would be > >> > replaced with the selection of InChI layers to compare; in most > >> common cases this may be done without much thinking by using > >> InChIKey. > >> > > >> > 1) It is recommended to generate InChI with all possible layers > >> included and all software fixes turned "ON". > >> > This means the following related to InChI generation command-line > >> parameters for cInChI-1: > >> > > >> > /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud > >> > > >> > /FixedH - Turn off Mobile H perception > >> > /RecMet - Include bonds to metal > >> > /SPXYZ - Include Phosphines Stereochemistry > >> > /SAsXYZ - Include Arsines Stereochemistry > >> > /Newps - Narrow end of wedge points to stereocenter > >> > /Fb - Fix bug leading to missing or undefined sp3 parity > >> > /Fnud - Fix non-uniform drawing issues > >> > > >> > Note on /Fnud option. This is the last fix introduced after > >> 1.02-beta release to appear in the final 1.02 release. > >> > It is intended to fix minor issues related to halogen oxoanions > >> (e.g., ClO4- with 4 double bonds and "minus" on Cl) and amidinium > >> cations (-C(-NHR)(-NR'R'') drawn with "plus" on C rather than on N. > >> > The impact of this fix is rather small: as tested with ChemSpider > >> database (courtesy of Antony Williams), it changed 209 InChI out of > >> ~17M. > >> > > >> > > >> > 2) It is suggested that, for convenience, we introduce a new > >> > command-line option for the software which serves as a short-cut to > >> above command-line parameters, tentatively called /STDINCHI or > >> /STDGEN. It is assumed that while interpreting command-line, > >> > '/STDINCHI' will be unfolded to '/FixedH /RecMet /SPXYZ /SAsXYZ > >> /Newps /Fb /Fnud' > >> > > >> > > >> > 3) It is recommended that InChI users, when they would like to check > >> if the two InChI/InChIKeys represent the same structure, do the > >> following: > >> > > >> > (a) compare the two InChIKeys first blocks (or respective layers of > >> InChI). If they are different, the structures are different. > >> > Otherwise, > >> > (b) compare the two InChIKeys second blocks (or the rest of InChI). > >> If they are the same, the structures are the same. > >> > Otherwise, > >> > (c) there are still chances that these two different InChIs are of > >> the same structure because they were created with different options. > >> If it is definitely not the case (the user knows that both InChIs > >> are produced with, say, standard options), the structures are > >> different. Otherwise, user is advised to compare the 2 InChIs layer > >> by layer, as described in InChI Technical Manual, appendix 4. > >> > > >> > Note: it is assumed that the word "different" above means "different > >> by full InChI string". > >> > It may not always mean that a particular chemist would consider the > >> two structures as being different. > >> > > >> > For example, a pair of "different structures" as found by comparing > >> the 2nd block of InChIKey may: > >> > - differ by a degree of protonation > >> > - be different tautomeric forms of the same compound > >> > - have different stereochemistry > >> > - be really different in case of metal atoms present. > >> > To find out the user needs to compare InChI strings as described at > >> the end of (c). > >> > > >> > > >> > 4) The suggestion to have "standard" options like above has both > >> positives and negatives. > >> > Namely: > >> > Pros > >> > ======= > >> > (P1) the number of command-line generation parameters will be > >> reduced making software usage simpler; > >> > (P2) anybody (even those not familiar with InChI layout) will be > >> able to produce the identifiers/keys in an unambiguous manner; > >> > (P3) the comparison of InChI/InChIKeys will be, in general, more > >> reliable. Cons > >> > ======= > >> > (C1) InChI strings will be longer (as a suggested "standard" > >> requires including of all possible layers); > >> > (C2) InChI/InChIKeys for many existing compilations should be > >> re-calculated; > >> > (C3) the "standard" form may not match chemical understanding of > >> some users (e.g., those who consider different tautomers as the same > >> molecule). > >> > > >> > In our opinion, (P2) is the most important issue. > >> > > >> > > >> > We appreciate and encourage your continued interest and input. > >> > > >> > -Steve Stein, NIST > >> > -Steve Heller, NIST > >> > -Alan McNaught, RSC > >> > -Dmitrii Tchekhovskoi, NIST > >> > -Igor Pletnev, NIST > >> > > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > ------------------------------------------------------------------------- > >> Check out the new SourceForge.net Marketplace. > >> > It's the best place to buy or sell services for > >> > just about anything Open Source. > >> > > >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >> > > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > InChI-discuss mailing list > >> > InChI-discuss@... > >> > https://lists.sourceforge.net/lists/listinfo/inchi-discuss > >> > >> > >> > >>------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >>Defy all challenges. Microsoft(R) Visual Studio 2008. > >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>_______________________________________________ > >>InChI-discuss mailing list > >>InChI-discuss@... > >>https://lists.sourceforge.net/lists/listinfo/inchi-discuss > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > InChI-discuss mailing list > > InChI-discuss@... > > https://lists.sourceforge.net/lists/listinfo/inchi-discuss > >

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Beda Kosata <Bedrich.Kosata@vs...> - 2008-01-27 08:08 I think that this suggestion is really worth consideration. As I see it, the whole discussion boils down to a central decision that should be made - what really is InChI - is it a format for storing chemical structures or is it a unique identifier for a structure. In the former case, there is not problem in having a thousand options for generation of InChI, but in the latter case there should be *no* options that would change how the resulting InChI looks. Just imagine an md5 (or sha1 or whaterver) hash algorithm having several options that would influence for instance how long the resulting hash is. I believe that nobody would use such an algorithm and the reasons are pretty obvious. The layered structure of InChI makes it possible to intelligently compare two InChIs and see if they represent the same structure with the difference only in position of movable hydrogens or some other minor feature. But the decision which information is important and which not should be done when the InChIs are compared, not when they are generated. Once we have a really standard InChI, it would be also much more useful to use InChIKeys. As for now, using or omitting fixed hydrogen layer obscures other important information about the structure that are stored in the second part of InChIKey. If generation of non-standard InChIs is permitted by the software, I strongly support the idea of having the "standard" InChI marked using something as the suggested "1S" version. I believe that with growing number of users, there will be more and more people who don't care about how the InChI is generated and if there are any options. They would just like to use it. Therefore the need for extra option would diminish. Also the reason why the software does not produce "standard" InChI without some special flags will become obscure and incomprehensible to all but the developers. I think that the change in the software "interface" is necessary and the sooner its done, the less painful it will be. Best regards Beda Markus Krummenacker wrote: > Dear InChI developers, > > (I am not subscribed to inchi-discuss@... , so > please excuse me for just dropping off my $0.02) > > I also think setting the options correctly for the cInChI-1 executable > is exceedingly complicated and confusing. When I started using this, > I had no idea what I was getting into... > > So, maybe now, you could consider making use of the "InChI=1/" > preamble in the InChI strings, to accurately identify the variants, > such that there will be less confusion regarding what kind of string > one is looking at. > > Maybe it is too early to switch it to "InChI=2/". > > However, why not introduce a "InChI=1S/", where the "S" would stand > for "standard" ? This would be the string generated when setting all > the standard options and bug fixes as enumerated in your earlier > announcement below. > > And then, given that the executable name also already has a bizarrely > complicated name, (cInChI-1 looks like a password, containing upper > and lower case letters, numbers, and other miscellaneous punctuation > characters...), why not at the same time also provide a separate > executable called cInChI-1S ? > > With this arrangement, calling cInChI-1S without any additional > settings will produce a truly standardized "InChI=1S/" InChi string. > > Maybe you could even have cInChI-1S reject all additional arguments, > such that the only legal way of running it always produces the standard > string. > > This would presumably clarify things a bit, and make standard InChi > generation easy for the average user. >

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Andrew Dalke <dalke@da...> - 2008-05-30 18:48 On Jan 10, 2008, at 9:24 PM, Igor Pletnev wrote: > Recently, there appeared a number of requests to define "standard" > InChI generation options. ... > 1) It is recommended to generate InChI with all possible layers > included and all software fixes turned "ON". > This means the following related to InChI generation command-line > parameters for cInChI-1: > > /FixedH /RecMet /SPXYZ /SAsXYZ /Newps /Fb /Fnud > > /FixedH - Turn off Mobile H perception > /RecMet - Include bonds to metal > /SPXYZ - Include Phosphines Stereochemistry > /SAsXYZ - Include Arsines Stereochemistry > /Newps - Narrow end of wedge points to stereocenter > /Fb - Fix bug leading to missing or undefined sp3 parity > /Fnud - Fix non-uniform drawing issues > Note on /Fnud option. This is the last fix introduced after 1.02- > beta release to appear in the final 1.02 release. This thread started last January but I had nothing to add until now. One of my clients added InChI support to an in-house system. The first version they wrote did not use any of the switches mentioned here. Their assumption, like Beda Kosata's, is that the program without any parameters should give the right answers. Especially there should be no reason to have to specify that I want the code to work correctly. If you don't want to change the existing program, make a new binary called "inchi", which is a lot easier to remember and type than "cInChI-1", and specify that this program always generates the right InChI and InChI keys, without needing any extra options. For those who use the system as a library, again, the default arguments should be correct, and the documentation and release notes say what needs to be done to get old behavior. Anyway, I pointed out Igor's message, quoted above, and we tried out the options mentioned. The "/FixedH" option causes some problems when using the InChiKey with ChemSpider. ChemSpider does not use the "/FixedH" option, so InChI=1/C8H7Cl2NO3/c9-4-1-5(10)7(2-6(4)11)14-3-8(12)13/h1-2H,3,1= not FixedH - InChIKey=VMNPETQUBQUXAP-UHFFFAOYAG FixedH - InChIKey=VMNPETQUBQUXAP-XWKXFZRBCY If you do the search at http://www.chemspider.com/Search.aspx then you'll find that the first option (which does not use /FixedH) gets a hit for ChemSpider ID: 71702, while the second option (with /FixedH) finds nothing. Because we want to support links to ChemSpider we decided to not use the recommended /FixedH option. This isn't necessarily a problem in InChIKeys per se. This is more a problem of knowing how to use the keys, and how to generate them, and how to search using them. This information about best practices isn't published anywhere that I know of, and what little there is, like the quoted email, seems to contract what others are doing. Is such a document available? I also note that the "/Fnud" is for 1.02 and the current version is only 1.02beta. Is there any timeline for when the bug fix will be available? While I'm here, I notice that the official InChI page is redirected to http://old.iupac.org/inchi/ Is this still the official web site or does "old" mean there's a new page somewhere? Andrew dalke@...

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Beda Kosata <Bedrich.Kosata@vs...> - 2008-06-01 18:26 Andrew Dalke wrote: > > While I'm here, I notice that the official InChI page is redirected to > http://old.iupac.org/inchi/ > Is this still the official web site or does "old" mean there's a new > page somewhere? > > Andrew > dalke@... > Work on new IUPAC site is still in progress and there remain some documents that are not yet converted to the new system. For these the redirection you mentioned is used. AFAIK http://old.iupac.org/inchi/ is the newest version of the document, regardless of the name of the site. Best regards Beda Kosata > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > InChI-discuss mailing list > InChI-discuss@... > https://lists.sourceforge.net/lists/listinfo/inchi-discuss >

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Igor Pletnev <igor.pletnev@gm...> - 2008-06-02 20:23 Attachments: Message as HTML      Andrew, thank you for the feedback. Though right now I am not in a position to answer all your questions definitely, let me comment on some issues. > If you don't want to change the existing program, make a new binary > called "inchi", which is a lot easier to remember and type than > "cInChI-1", and specify that this program always generates the right > InChI and InChI keys, without needing any extra options. Agree. Thanks to all you inchi-discuss members and your suggestions, it is [nearly] exactly what will appear in InChI software v. 1.02 final release. > the options mentioned. The "/FixedH" option causes some problems > when using the InChiKey with ChemSpider. ChemSpider does not use the > "/FixedH" option, so > InChI=1/C8H7Cl2NO3/c9-4-1-5(10)7(2-6(4)11)14-3-8(12)13/h1-2H,3,1 > > not FixedH - InChIKey=VMNPETQUBQUXAP-UHFFFAOYAG > FixedH - InChIKey=VMNPETQUBQUXAP-XWKXFZRBCY > > If you do the search at http://www.chemspider.com/Search.aspx then > you'll find that the first option (which does not use /FixedH) gets a > hit for ChemSpider ID: 71702, while the second option (with /FixedH) > finds nothing. Let me attract your attention to the fact that solution of the problem may be not only by omitting FixedH layer upon InChI/InChIKey generation. Another one is to use InChIKey created with FixedH but just search in ChemSpider for the 1st block of that key (note that ChemSpider understands this). For your example, search in the ChemSpider for the _1st_ block of InChIKey VMNPETQUBQUXAP returns the same hit, ChemSpider ID 71702, as one you mentioned. As an added bonus, you may also search in Google for that _1st_ block: http://www.google.com/search?q=VMNPETQUBQUXAP and find one more result which corresponds to InChIKey created (in contrast to ChemSpider) with FixedH layer, VMNPETQUBQUXAP-XWKXFZRBCY: http://sci-toys.com/scichem/jqp011/79383.html (Note that search in Google by a full key created without FixedH, VMNPETQUBQUXAP-UHFFFAOYAG, returns nothing - which is exactly opposite to ChemSpider's behavior). Best regards, Igor On Fri, May 30, 2008 at 10:48 PM, Andrew Dalke <dalke@...> wrote: > This thread started last January but I had nothing to add until now. > > One of my clients added InChI support to an in-house system. The > first version they wrote did not use any of the switches mentioned > here. Their assumption, like Beda Kosata's, is that the program > without any parameters should give the right answers. Especially > there should be no reason to have to specify that I want the code to > work correctly. > > If you don't want to change the existing program, make a new binary > called "inchi", which is a lot easier to remember and type than > "cInChI-1", and specify that this program always generates the right > InChI and InChI keys, without needing any extra options. > > For those who use the system as a library, again, the default > arguments should be correct, and the documentation and release notes > say what needs to be done to get old behavior. > > Anyway, I pointed out Igor's message, quoted above, and we tried out > the options mentioned. The "/FixedH" option causes some problems > when using the InChiKey with ChemSpider. ChemSpider does not use the > "/FixedH" option, so > > InChI=1/C8H7Cl2NO3/c9-4-1-5(10)7(2-6(4)11)14-3-8(12)13/h1-2H,3,1= > > not FixedH - InChIKey=VMNPETQUBQUXAP-UHFFFAOYAG > FixedH - InChIKey=VMNPETQUBQUXAP-XWKXFZRBCY > > If you do the search at http://www.chemspider.com/Search.aspx then > you'll find that the first option (which does not use /FixedH) gets a > hit for ChemSpider ID: 71702, while the second option (with /FixedH) > finds nothing. > > Because we want to support links to ChemSpider we decided to not use > the recommended /FixedH option. > > This isn't necessarily a problem in InChIKeys per se. This is more a > problem of knowing how to use the keys, and how to generate them, and > how to search using them. This information about best practices > isn't published anywhere that I know of, and what little there is, > like the quoted email, seems to contract what others are doing. > > Is such a document available? > > I also note that the "/Fnud" is for 1.02 and the current version is > only 1.02beta. Is there any timeline for when the bug fix will be > available? > > While I'm here, I notice that the official InChI page is redirected to > http://old.iupac.org/inchi/ > Is this still the official web site or does "old" mean there's a new > page somewhere? > > Andrew > dalke@... > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > InChI-discuss mailing list > InChI-discuss@... > https://lists.sourceforge.net/lists/listinfo/inchi-discuss >

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Andrew Dalke <dalke@da...> - 2008-06-03 09:52 On Jun 2, 2008, at 10:23 PM, Igor Pletnev wrote: > For your example, search in the ChemSpider for the _1st_ block of > InChIKey > VMNPETQUBQUXAP > returns the same hit, ChemSpider ID 71702, as one you mentioned. Yes, it does. My comment weren't that InChI or ChemSpider were wrong, it was that using InChIKeys require some subtlety. Most chemists I know, including the ones using the tool I'm helping to develop for my client, don't know about InChIKeys, much less its nuances. If I show a key and say they can search on Google or ChemSpider, they are likely to use the entire key, and fail. Instead, should I train them to only use the first half of the key? If yes, is it better than I only display \ that block, and/or only generate a hyperlink without the 2nd block? If I implement a search engine like ChemSpider, is it best practice that the default key search also includes a search for identical topology hash, ignoring the 2nd half of the key? Or should the back end generate and use as search keys both the /FixedH and non-/FixedH forms when doing the search? I'm looking for guidance on how to use InChiKeys in practice in order to achieve the goals for which InChI and its keys were created. Andrew dalke@...

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Geoffrey Hutchison <geoff@ge...> - 2008-06-03 21:32 On Jun 2, 2008, at 4:23 PM, Igor Pletnev wrote: > Agree. Thanks to all you inchi-discuss members and your suggestions, > it is [nearly] exactly what will appear in InChI software v. 1.02 > final release. Is there an estimate as to when that 1.02 final release will appear? I ask, because Open Babel is nearing a major release and we should obviously like to incorporate these changes and the "correct default" options. Cheers, -Geoff

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Dmitrii Tchekhovskoi <Dmitrii.Tchekhovskoi@ni...> - 2008-06-10 14:48 Andrew, You've got right to the point. In v.1.02 beta, one may create two almost identically looking InChIKeys, one with and another without /fixedH and/or /RecMet options, saying nothing about other options. Although one may, using the documentation on InChIKey, deduce from the InChIKey's "flag character" whether /fixedH was used or not, the result does not seem to be satisfactory for a variety of reasons (you brought up one of them), including the lack of recommended default settings and/or "best practices." The reason for the problem is in the flexibility of the InChI layered structure. The layered structure of InChI cannot be represented by a single 25-character hash or by a two-part 25-character hash: such a short hash does not have enough capacity to represent more than two pieces of the whole InChI. Here I would like to concentrate on two meaningful but different methods of generating the InChIKey: (1) Creating an InChIKey out of an InChI that contains all possible layers thus reflecting as much details of the underlying chemical drawing as possible. The resultant 2nd segment of InChIKeys would differ not only for different stereo and isotopic configurations, but also for different tautomeric forms and different degrees of protonation. (2) Creating an InChIKey out of an InChI that contains all possible layers except /fixedH and /p (protonation), and adding the degree of protonation as a separate 1-character 3rd segment to the InChIKey. The resultant 2nd segment would be identical for all tautomeric forms and degrees of protonation. If would depend on the stereochemistry and isotopic composition. The 3rd segment would be different for different degrees of protonation, for example, NH4(+) and NH3. In this approach a minor ambiguity concerning what to do about (de)protonation with D(+) or T(+) instead of H(+) still remains. [I would like to note that this 27-character hash cannot be created with the current 1.02 beta release code without changing it] The 1st InChIKey segments in (1) and (2) would be identical. (1) may be interpreted as an identifier of a chemical drawing. (2) may be interpreted as an identifier of a chemical compound in a bottle which is subject to tautomerization and protonation. (3) One may consider another 3-segment hash which would have the last 2 segments made out of the 2nd segments of (2) and (1), respectively. This would enlarge the InChIKey length, probably without adding proportionally to its value. Method (2) is very close to what you find on the ChemSpider web site. (1) and (2) are some of the options we are currently considering. Personally, I would prefer (2) as a substance search key to be published on the Internet. An opposite viewpoint is that a chemist knows better what she is drawing, therefore, (1) should be used. Another complication comes from a demand for a simple, standard solution that would fix all InChI creation options by standardizing them once and for all. Obviously, this demand cannot be fully satisfied. To prove this, a single counterexample is needed. Here it is. There are at least two interpretations of the stereochemistry in chemical drawings: (a) perspective and (b) when only the narrow end of the wedge points to a stereocenter. Well, if we consider (b) as the only right way and make other similar decisions, then the standard set of InChI options may be established. Most probably these options would include /fixedH and /recmet, that is, all drawing details are included. However, hashing of this "standard" InChI would produce (1), which is not invariant w.r.t. tautomerization and protonation. Therefore, in my opinion, such a "standard" InChI (which may be reduced to a InChI created with a smaller number of options by /inchi2inchi conversion) may not be directly suitable for a search-oriented hashing: it has too fine granularity due to being different for different tautomeric forms and degrees of protonation. Designing a search technique brings this all into one more dimension, although so far the search techniques are out of the scope of the InChI project. The search technique may depend on how relatively valuable are "near hits" vs. "false positives". One may want to manually examine the only, say, 5 found "near hits" (when only the 1st InChIKey segment was found) or reject right away 1000 hits that have different 2nd segment because there are 100 other exact 2-segment matches. The interpretation of the "flag character" in the found InChIKey may also be useful. So far we have not decided on the "best practice" of creating and using InChIKey you are asking about. Regards Dmitrii At 05:52 AM 6/3/2008, Andrew Dalke wrote: >On Jun 2, 2008, at 10:23 PM, Igor Pletnev wrote: > > For your example, search in the ChemSpider for the _1st_ block of > > InChIKey > > VMNPETQUBQUXAP > > returns the same hit, ChemSpider ID 71702, as one you mentioned. > >Yes, it does. My comment weren't that InChI or ChemSpider were >wrong, it was that using InChIKeys require some subtlety. Most >chemists I know, including the ones using the tool I'm helping to >develop for my client, don't know about InChIKeys, much less its >nuances. If I show a key and say they can search on Google or >ChemSpider, they are likely to use the entire key, and fail. > >Instead, should I train them to only use the first half of the key? >If yes, is it better than I only display \ that block, and/or only >generate a hyperlink without the 2nd block? > >If I implement a search engine like ChemSpider, is it best practice >that the default key search also includes a search for identical >topology hash, ignoring the 2nd half of the key? Or should the back >end generate and use as search keys both the /FixedH and non-/FixedH >forms when doing the search? > >I'm looking for guidance on how to use InChiKeys in practice in order >to achieve the goals for which InChI and its keys were created. > > > Andrew > dalke@... > > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >InChI-discuss mailing list >InChI-discuss@... >https://lists.sourceforge.net/lists/listinfo/inchi-discuss

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Markus Sitzmann <sitzmann@he...> - 2008-06-10 16:23 Dimitri, > The 1st InChIKey segments in (1) and (2) would be identical. > > (1) may be interpreted as an identifier of a chemical drawing. > (2) may be interpreted as an identifier of a chemical compound in a > bottle which is subject to tautomerization and protonation. > > (3) One may consider another 3-segment hash which would have the last > 2 segments made out of the 2nd segments of (2) and (1), respectively. > This would enlarge the InChIKey length, probably without adding > proportionally to its value. > > Method (2) is very close to what you find on the ChemSpider web site. > > (1) and (2) are some of the options we are currently considering. > Personally, I would prefer (2) as a substance search key to be > published on the Internet. An opposite viewpoint is that a chemist > knows better what she is drawing, therefore, (1) should be used. while variants (1) and (2) (and (3) maybe) make clearly sense to me, my major problem is that - if you just look at a InChIKey (maybe from a unknown source) - it is not possible to recognize anymore which of the two variants (1) or (2) has been used to calculate it. If you look at a InChI string it is possible in most cases because the layer gives a clear indication, however, in case of a InChIKey this information is not available from InchIKey itself. In my opinion, that adds kind of a ambiguity for searching by InChIKey (since you can not be sure what the original creator of the InChIKey meant exactly). -- Markus Sitzmann, Ph.D. Laboratory of Medicinal Chemistry Center for Cancer Research National Cancer Institute National Institutes of Health 376 Boyles St Frederick, MD 21702, USA 301-846-5974 (office) 301-846-6033 (fax) sitzmann@... http://www.linkedin.com/pub/1/7b8/342 http://www.xing.com/profile/Markus_Sitzmann

Re: [InChI-discuss] InChI standard generation options (request for comments) From: Dmitrii Tchekhovskoi <Dmitrii.Tchekhovskoi@ni...> - 2008-06-11 18:16 Markus, You may find answers to most of your concerns in Table 1 on page 3 of Software-1-02-beta.pdf included in InChI v.1.02 beta package available on IUPAC web site. Regards Dmitrii At 12:23 PM 6/10/2008, Markus Sitzmann wrote: >Dimitri, > > > The 1st InChIKey segments in (1) and (2) would be identical. > > > > (1) may be interpreted as an identifier of a chemical drawing. > > (2) may be interpreted as an identifier of a chemical compound in a > > bottle which is subject to tautomerization and protonation. > > > > (3) One may consider another 3-segment hash which would have the last > > 2 segments made out of the 2nd segments of (2) and (1), respectively. > > This would enlarge the InChIKey length, probably without adding > > proportionally to its value. > > > > Method (2) is very close to what you find on the ChemSpider web site. > > > > (1) and (2) are some of the options we are currently considering. > > Personally, I would prefer (2) as a substance search key to be > > published on the Internet. An opposite viewpoint is that a chemist > > knows better what she is drawing, therefore, (1) should be used. > >while variants (1) and (2) (and (3) maybe) make clearly sense to me, >my major problem is that - if you just look at a InChIKey (maybe from >a unknown source) - it is not possible to recognize anymore which of the >two variants (1) or (2) has been used to calculate it. If you look at >a InChI string it is possible in most cases because the layer gives >a clear indication, however, in case of a InChIKey this information >is not available from InchIKey itself. In my opinion, that adds kind of >a ambiguity for searching by InChIKey (since you can not be sure what >the original creator of the InChIKey meant exactly). > >-- > > Markus Sitzmann, Ph.D. > > Laboratory of Medicinal Chemistry > Center for Cancer Research > National Cancer Institute > National Institutes of Health > > 376 Boyles St > Frederick, MD 21702, USA > > 301-846-5974 (office) > 301-846-6033 (fax) > > sitzmann@... > > http://www.linkedin.com/pub/1/7b8/342 > http://www.xing.com/profile/Markus_Sitzmann > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >InChI-discuss mailing list >InChI-discuss@... >https://lists.sourceforge.net/lists/listinfo/inchi-discuss

1 message has been excluded from this view by a project administrator.