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
>
>
|