On Fri, Jul 22, 2016 at 8:42 AM, Jennifer L. Muzyka <
jennifer.muz...@centre.edu> wrote:

> InChI is very messy because there’s more than one version of the program
> that generates it.  So depending on what version you use, you get a
> different InChI.  That information about which version of the InChI rules
> you are using is an early part of the string.  The other problem with InChI
> is that the strings can be REALLY LONG, as in so long that it’s not
> possible to use them when you search Google.  That was another take-away
> from the course.
>

You do have to define the rules so that you get the sections right. Beyond
that, I suppose it may be true, but not for simple molecules. Any changes
by version would be for esoteric species (I am guessing.) What you are
saying violates the whole premise of InChI. Do you have examples, Jennifer?

2. Quick Facts 2.1. What is an InChI?

InChI is an acronym for IUPAC International Chemical Identifier. It is a
string of characters capable of uniquely representing a chemical substance
and serving as its unique digital ‘signature’. It is derived solely from a
structural representation of that substance in a way designed to be
independent of the way that the structure was drawn. A single compound will
always produce the same identifier.

[http://www.inchi-trust.org/technical-faq/]


You are using AJAX every time you use JSmol. All files are transmitted
using AJAX, and within JSmol you can do AJAX as simply as


x = load("http://......";)


I don't see why you would need any server-side piece these days. It is
certainly not "elegant" in my opinion. Elegant is

if ("my SMILES string".find("your SMILES string", "SMILES")) prompt "You're
good to go!"


without any concern for where the strings come from. That's what JSmol
does. No server required. Just make sure you are using  the right  options
in JSME. See http://chemapps.stolaf.edu/jmol/jsmol/jsmetest2.htm


}var JMEInfo = {        use: "HTML5"  ,visible: true  ,divId: "jmediv"
,options : "autoez;nocanonize"

}


Here's a note I have on that from an earlier jmol-users post:

JSME and 2D/3D -  It turns out that JSME has two modes of delivery of
SMILES -- "canonize" and "nocanonize"...The problem is that "canonize"
delivers aromatic symbols for rings that  are not huekel-aromatic -- all
six carbons, for example, in benzoquinone. Jmol does this, too, but Jmol
adds double bond indications as well, so ...c=cc=c.... The difference is
significant -- Jmol's SMILES representations are interpretable by the NCI
Resolver; JSME's "canonize" versions are not. So I  have to have JSME in
nocanonize mode in order to convert 2D to 3D using the NCI Resolver.

Bob
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to