Hi Surajit,

Yes, via dataset service POST / PUT operations , as defined in OpenTox API
.  Any of SDF, MOL, CSV (with smiles) , SMI, RDF, CML and other formats
defined as supported in the API.
http://opentox.org/dev/apis/api-1.1/dataset

TUM and NTUA are using these services on daily basis for uploading data,
descriptors and prediction results.

Examples can be found in any of the partners' code as well as
https://ambit.svn.sourceforge.net/svnroot/ambit/branches/opentox/opentox-client
(look at tests)

Once a dataset is created, it is accessible in any other format via
Accept:media-type  HTTP header.

Hope this helps.
Nina

On Tue, Jul 13, 2010 at 12:54 PM, surajit ray <mr.surajit.ray at gmail.com>wrote:

> 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
> >
>
>
>
> --
> Surajit Ray
> Partner
> www.rareindianart.com
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>