[OTDev] TUM API proporsals for new developed algorithms

Nina Jeliazkova nina at acad.bg
Wed Jun 30 14:09:42 CEST 2010


Dear  Tobias, All,

Tobias Girschick wrote:
> Dear All,
>
> Our first suggestion is to drop the "[]" in the compound_uris[], ...
> parameter names for version 1.2 as they complicate things with URIs.
>   
Agree, same for feature_uris[], where relevant. 

- There is nothing in the URL parsers to prevent having multiple values
of the same parameter, so [] is purely informational.
- For some reason '[]' confuse Restlet's Reference class, especially
when constructing URLs with such parameters.
> Second, to include our newly developed algorithms as webservices in
> OpenTox, it will be necessary to extend the current API 1.1 a little
> bit. For Jörg's multi-label algorithm we would need to change the
> prediction_feature parameter in the Algorithm API to
> prediction_features[] (or prediction_features, if we drop the brackets).
> as there will be more than one feature predicted at the same time. The
> model API and model RDF representation can be left unchanged in our
> opinion. For validating the multi-label classification there will be new
> validation measures. 
>   
The current opentox.owl doesn't impose restrictions on single prediction
feature - you could have as many as needed. (Toxtree models normally has
more than one prediction feature) .

I agree the name might be misleading and changing to plural might be better.
> Multi Label measures are calculated similar to normal classification
> measures. Some are just adapted and micro or macro averaged over the
> predictions (Micro or Macro AUC, Precision, Recall, F1...). Others are
> introduced for the ranking output of some classifiers (One-error,
> coverage, Ranking Loss,...). In the results, we could still use a
> similar format as for classification and use the micro and macro
> averaged values and the new measures. 
>
>   
Seems validation statistics need an upgrade.
> The second algorithm that will need changes (CDE - conditional density
> estimation) generates not single prediction values, but prediction
> intervals. We propose to just update the dataset with 2 columns
> (interval start and end) instead of 1 (predicted value). Here, too, for
> validation there will be three additional measures that evaluate the
> quality of the predicted intervals. 
>   
There are 'tuples' construct in opentox.owl (I think Christoph is using
them for lazar predictions),  if you provide some examples I will try to
figure out if existing constructs can be used.

Best regards,
Nina
> Any comments, or suggestions?
>
> Regards,
> TUM OpenTox Team
>
>   




More information about the Development mailing list