Dear Surajit,

If you do not need permanent storage, you can use our compound service
at webservices.in-silico.ch/compound.  You can post various formats
(e.g. Smiles, SDF, ...) and it will return a valid OpenTox compound URI.
Similarly you can retreive various compound representations from a
compound URI.  Please have a look at the README at
github.com/helma/opentox-compound for documentation and examples. 

Please note that all name lookups (names, cas numbers, ...) use the
external Cactvs service, which was down yesterday. Format conversions
are done internally and should work.

Best regards,
Christoph


Excerpts from surajit ray's message of Tue Jul 13 11:54:18 +0200 2010:
> Hi Nina,
> 
> Is there a mechanism yet of entering a smiles/(other formats)  in a form
> field (or through RDF call) and putting it into a location on a server
> (ambit ?) - so that hence forward the compound service can be used to
> deliver the compound to other components/algorithms/models ?
> 
> Cheers
> Surajit
> 
> On 13 July 2010 15:00, Nina Jeliazkova <jeliazkova.nina at gmail.com> wrote:
> 
> > Hi Surajit,
> >
> > One approach is to consider using representations with lower inherent
> > ambiguity (InChI, MOL, CML, etc.) - needless to say all of these are
> > available via OpenTox dataset services.
> >
> > Best regards,
> > Nina
> >
> > On Tue, Jul 13, 2010 at 12:21 PM, surajit ray <mr.surajit.ray at gmail.com
> > >wrote:
> >
> > > Hi Egon,
> > >
> > > Our workflow uses the CDK Smilesparser object to read in the smiles. In
> > the
> > > light of these bugs - should we be wary of certain smiles OR look at some
> > > other means of reading in the smiles ?
> > >
> > > If so what would you advise as the best alternative to the smiles parser
> > ?
> > >
> > > Cheers
> > > Surajit
> > >
> > > On 13 July 2010 11:37, Egon Willighagen <egon.willighagen at gmail.com>
> > > wrote:
> > >
> > > > Dear Dmitry,
> > > >
> > > > On Mon, Jul 12, 2010 at 9:42 AM, Druzhilovsky
> > > > <dmitry.druzhilovsky at ibmc.msk.ru> wrote:
> > > > > In my opinion, CDK is the most correct for sensing. On the other
> > hand,
> > > > CDK
> > > > > has some bugs with SMILES periodically . So, I daresay CACTVS do for
> > > > SMILES
> > > > > in complex apps.
> > > >
> > > > I'd very much look forward to an OpenSMILES (re-)implementation. A lot
> > > > of bugs have been resolved, and most reside in the aromaticity concept
> > > > of SMILES, which is needlessly complex, partly because the whole
> > > > aromaticity concept is ill-defined...
> > > >
> > > > There are some unit tests indeed still failing for the SMILES parser,
> > > > but we welcome more bug reports on the SMILES parser if you find
> > > > them... this is a very easy way to contribute to the CDK project...
> > > >
> > > > Egon
> > > >
> > > >
> > > > --
> > > > Post-doc @ Uppsala University
> > > > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg
> > > > Homepage: http://egonw.github.com/
> > > > Blog: http://chem-bla-ics.blogspot.com/
> > > > PubList: http://www.citeulike.org/user/egonw/tag/papers
> > > > _______________________________________________
> > > > Development mailing list
> > > > Development at opentox.org
> > > > http://www.opentox.org/mailman/listinfo/development
> > > >
> > >
> > >
> > >
> > > --
> > > Surajit Ray
> > > Partner
> > > www.rareindianart.com
> > > _______________________________________________
> > > Development mailing list
> > > Development at opentox.org
> > > http://www.opentox.org/mailman/listinfo/development
> > >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> >
>