Pierluigi,
I am also verbose! I just don’t know how to discuss Resolver any other way. Re
Resolver...
I want to take a minute to detail what Resolver is doing with input because
this will help determine the best route to solve your problem. First, I think
you’re interested in testing student ability to write correct IUPAC’s from
drawn structures. Am I correct on this point?
Resolver can take a connectivity identifier (e.g. IUPAC, InChI, SMILES, SDF,
JMEfile) and convert one to the other by algorithm (e.g. SMILES to SDF). IUPAC
is the weak link here. Resolver cannot create IUPAC by algorithm. So it must do
data base look-up. With names in general (trivial and IUPAC), Resolver does a
look-up.
Since Resolver takes a wide range of input, it needs to recognize identifier
types. For example, you don’t have to tell Resolver that you are giving it a
SMILES - it knows! In the case of IUPAC entry, Resolver uses OPSIN as a
screening aid AND as an IUPAC parser. Resolver takes both trivial and IUPAC
names. OPSIN helps Resolver differentiate trivial (common) from IUPAC. Note
that neither OPSIN nor Resolver can create an IUPAC. They parse IUPAC. Resolver
does this via OPSIN. Once parsed, the goal of resolving to other identifiers by
algorithm can be achieved. In the case of 2-chlorooctane and 7-chlorooctane,
both can be parsed! Important point here re your objective: Resolver (via
OPSIN) can read and parse many IUPAC's correctly - neither Resolver nor OPSIN
can create IUPAC by algorithm.
OK, back to your objective, providing I’m correct on your goal:
1) Structure (2d or 3d) to IUPAC is going to be limited to look-up. My little
demo proves just that. My feeling is that PubChem is a better IUPAC look-up
(Oops, that slipped out!)
2) If, however, you want students to draw a structure, enter an IUPAC, and
click a button to see if they are correct, you can do this despite the OPSIN
and Resolver IUPAC calculation limitation. In my view, this is best handled my
JSME and JSMOL together:
A) Get the student IUPAC from a field input.
B) Get the student drawing SMILES from JSME. Bob is correct, the correct JSME
SMILES option must be set. Alternatively, transfer the drawing to Jmol and use
the Jmol SMILES.
C) Send the student IUPAC to Resolver to get a SMILES. Resolver should be able
to do this for many IUPAC names. After parsing, SMILES generation is an
algorithm. Alternatively, use OPSIN directly.
D) Use Jmol’s SMILES compare to check student right or wrong.
E) Throughout this, you are going to be plagued by the 2-chlorooctane and
7-chlorooctane backward numbering dilemma - no way around that. To OPSIN and
Resolver, if it’s parseable, it’s correct.
Again, I think the SMILES comparison is your best bet, but maybe **standard**
InChI comparison is worth a try.
Finally, I should probably report this approach to forcing Resolver to use or
not use OPSIN:
https://cactus.nci.nih.gov/chemical/structure/1-butanol/stdInChI?resolver=name_by_opsin
https://cactus.nci.nih.gov/chemical/structure/1-butanol/stdInChI?resolver=name_by_database
Otis
--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org
> On May 10, 2016, at 6:08 AM, Pierluigi Quagliotto
> <pierluigi.quaglio...@unito.it> wrote:
>
> 1) 7-ethyl-3,5-dimethyl-4-propyldodecane
>
> 2) 3-chloro-3-ethyl-4-methylpentanoic acid
------------------------------------------------------------------------------
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
