Sorry, I did not notice that the first post of this note had Markus' slides
attached! Here's the note without the huge attachment.
This is still a bit long, but it might be useful to the list and David's recent
questions re Resolver. It's a brief email interview with Markus Sitzmann that I
did for our local ACS section back in 2011.
Markus' answers to my questions 2 and 3 below are relevant to David Brown's
recent questions. With regard to his answer to question 2, one important change
has been made to Resolver. I believe by default OPSIN IUPAC resolver sits at
the front end of NIH/NCI Resolver, many IUPAC name2SDF are now calculated:
http://opsin.ch.cam.ac.uk
Otis
> --
> Otis Rothenberger
> o...@chemagic.com
> http://chemagic.com
>
>
> Begin forwarded message:
>
>>
>> Hi Otis,
>>
>> sorry for the late reply.
>>
>>
>> Three questions - quick ones, I think:
>>
>> I'm putting together a presentation for our local ACS Section including
>> Jmol's ability to communicate with Resolver.
>>
>> 1. Historical Question: It looks like Resolver was (is) an avocation for
>> you. What prompted you to put this thing together?
>>
>> Well, because of the services on cactus.nci.nih.gov (besides the
>> Resolver) our lab got many requests, like "can you convert this
>> file/CAS number list/SMILES strings" into another format? Or, "do
>> you have structures from a specific database". Such requests usually ended
>> on my desk.
>>
>> When I started working on the Resolver I was busy with building our
>> big chemical structure database here - my work was focuses to create
>> techniques normalizing chemical structures (e.g. linking together different
>> tautomeric forms that may occur in different databases for
>> the same compound - see http://cactus.nci.nih.gov/blog/?p=705).
>>
>> And the final building block was that I was playing around with one
>> of these new and fancy web frameworks like python/django - and from
>> there I built a prototype very quickly (and somebody from EPA fell in love
>> with it right after the prototype worked as it allowed him the
>> batch-wise lookup of CAS numbers very quickly - that was Nov. 2008; the
>> official release was July 2009).
>>
>>
>> 2. It appears that most SMILES to SDF are computed. Is there some simple
>> deciding factor that determines computation vs database look-up?
>>
>> SMILES to SDF is always computed, there are no exceptions from this.
>> Database look-up is only used in case of structure identifiers which
>> can not be converted into a full structure representation by some
>> algorithm (e.g. CAS numbers, InChIKey or CACTVS hashcodes). A special
>> case are chemical names - although there are algorithms/programs for
>> converting systematic names (and with some restriction trivial names)
>> into full structure representations the Resolver (currently) doesn't
>> use any of them - names are resolved also by a database lookup using a
>> ~70 million chemcial name index (which we "stole" from our colleges
>> form PubChem).
>>
>>
>> 3. When computed, what mechanics approach is used?
>>
>> For that, CACTVS (http://www.xemistry.com) is used. CACTVS parses
>> the original SMILES string, creates an internal structure representation
>> (called "ens" for 'ensemble'). From this representation a lot of
>> properties can be calculated including a long list of file format
>> representation including SDF.
>>
>>
>> I hope these are simple answer questions! Oh yeah, one other thing would
>> be helpful. Can you write three or four lines about yourself? I'd like
>> to tell our section something about you.
>>
>
> Professional Bio Deleted
>
>>
>> Regards,
>> Markus
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
