Hello All,

On Mon, 2009-12-07 at 09:10 +0200, Nina Jeliazkova wrote: 
> Hello Martin, All,
> 
> 
> Martin Guetlein wrote:
> > Hello All,
> >
> > On Fri, Dec 4, 2009 at 3:09 PM, Christoph Helma <helma at in-silico.de> wrote:
> >   
> >> Excerpts from Nina Jeliazkova's message of Fri Dec 04 12:39:56 +0100 2009:
> >>     
> >>>> I use the following workflow:
> >>>>
> >>>> POST /descriptor_calculation training_dataset                                    # creates feature_dataset
> >>>> POST /algorithm              training_dataset feature_dataset # creates model
> >>>> POST /model                  compound_uri                     # creates prediction
> >>>> or
> >>>> POST /model                  prediction_dataset               # creates dataset with predictions
> >>>>
> >>>> This is fairly straightforward and allows you to reuse/exchange descriptors.
> >>>>
> >>>>         
> >>> Yes, but straightforward implementation duplicates information
> >>> (training/feature datasets are not very much different).
> >>>       
> >> No, training and feature datasets are disjunct in my case. This allows
> >> me e.g. to quickly create lazar models with different types of
> >> descriptors and compare the results with other algorithms.
> >>     
> >
> >
> > To determine the parameters for building a prediction model (what to
> > predict?, which features to use?) is needed for the validation as
> > well.
> > I made a proposal how the curl call for validating an algorithm could
> > look like (see http://www.opentox.org/data/documents/development/validation/validation-and-reporting-overview-and-data-flow).
> > An excerpt:
> >
> >   
> Could you tell, why one would validate an "algorithm", and not a "model"
> ? (sorry if already discussed, I am a bit confused).
> 
> Otherwise, it seems the current API for algorithms
> http://opentox.org/dev/apis/api-1.1/Algorithm is a bit underspecified  :
> 
>     "parameters are algorithm dependent, specified by service provider
>     in the algorithm representation".
> 
> 
> Perhaps it make sense to introduce similar parameter/parameter names for
> the algorithm service itself, then the validation service could use the
> algorithm service calls?

This indeed makes sense. The validation service can only use the
standard Algorithm API. That's the only guaranteed interface that is
exposed. 
> 
> Best regards,
> Nina
> >   curl -X POST -d algorithm_uri="<algorithm_service>/algorithm/<algorithm_id>" \
> >                -d
> > training_dataset_uri="<dataset_service>/dataset/<train_dataset_id>" \
> >                -d
> > test_dataset_uri="<dataset_service>/dataset/<test_dataset_id>" \
> >                -d prediction_feature="<prediction_feature>" \
> >                -d
> > algorithm_params="<alg_param_key_1>=<alg_param_val1>;<alg_param_key_2>=<alg_param_val2>"
> > [OPTIONAL]\
> >                <validation_service>/validation
> >
> > -> validation-internal api call to build model:
> >
> >   curl -X POST -d dataset_uri="<dataset_service>/dataset/<train_dataset_id>" \
> >                -d prediction_feature="<prediction_feature>" \

Those two parameters could be introduced into the Algorithm API. Single
compounds would be a special case of datasets. 

> >                -d <alg_param_key1>="<alg_param_val1>" \
> >                -d <alg_param_key2>="<alg_param_val2>" \
Those two would have to be looked up in the RDF. There will always be
algorithm instance specific parameters. 

> >                 <algorithm_service>/algorithm/<algorithm_id>

this is already in the Algorithm API.

Christoph?

Best Regards,
Tobias 
> >
> > What do yout think?
> >
> > Best regards,
> > Martin
> >
> >
> >
> >   
> 
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development


-- 
Dipl.-Bioinf. Tobias Girschick

Technische Universität München
Institut für Informatik
Lehrstuhl I12 - Bioinformatik
Bolzmannstr. 3
85748 Garching b. München, Germany

Room: MI 01.09.042
Phone: +49 (89) 289-18002
Email: tobias.girschick at in.tum.de
Web: http://wwwkramer.in.tum.de/girschick