You are here: Home » Development » API » API 1.1 - archived version » Algorithm


Provides access to OpenTox algorithms

REST operations

Description Method URI Parameters Result Status codes
Get URIs of all available algorithms
GET /algorithm (optional)
List of all algorithm URIs or RDF representation, or algorithms of specific types, if query parameter exists

Returns all algorithms, for which owl:sameAs is given by the query
Get the ontology representation of an algorithm GET /algorithm/{id} - Algorithm representation in one of the supported MIME types
Apply the algorithm POST /algorithm/{id} dataset_uri
parameter (specified by the algorithm provider)
model URI
dataset URI

Redirect to task URI for time consuming computations




  • dataset_service=datasetservice_uri, pointing to a dataset service. Relevant, if the output of the algotithm is a dataset (e.g. with calculated descriptors).  If dataset_service parameter is not specified, the model service uses a pre-configured dataset service.

Algorithm representation



Input parameters:

  • dataset_uri is mandatory for all kind of prediction algorithms (machine learning or otherwise), as well for data processing algorithms.
  • prediction_feature is mandatory for prediction (classification/regression) and other supervised learning algorithms. The URI of the feature with the endpoint to predict is expected as value.
  • parameter contains all the algorithm specific parameters
  • TODO: Update AlgorithmTypes ontology to include information of input and output parameters

Algorithm types

Algorithm types are defined in algorithm types ontology

Data cleanup algorithms. Algorithm, which is a subclass of

  • input parameters: dataset_uri , parameter
  • output parameters: dataset_uri

Feature selection algorithms  , subclass of

  • input parameters: dataset_uri , parameter
  • output parameters:  feature_uri


Sample curl calls for descriptor selection:

Select the 40 most informative descriptors (according to Information Gain) from dataset

curl -X POST -d "dataset_uri=" -d "prediction_feature=" \
 -d 'numToSelect=40'


Supervised learning algorithms , subclass of

  • input parameter:  dataset_uri , parameter,  prediction_feature
  • output parameters:  dataset_uri


Sample curl calls for learning models:

Learn a dicision tree model:

curl -X POST -d 'dataset_uri=' -d 'prediction_feature=' \
-d 'dataset_service='

Available options of J48 can be found at:

Learn a model with the k nearest neighbor algorithm (k=5):

curl -X POST -d 'dataset_uri=' -d 'prediction_feature=' \
 -d 'dataset_service=' -d 'KNN=5' \



Descriptor calculation algorithms   subclass of

  • input parameters: dataset_uri , parameter
  • output parameters:  dataset_uri


Sample curl calls for calculating descriptors:

Calculate all CDK feature:

curl -X POST -d 'dataset_uri=[]=' \
-d 'dataset_service='

Calculate WienerNumbers using CDK:

curl -X POST -d 'dataset_uri=[]=' \
-d 'WienerNumbersDescriptor=true' -d 'ALL=false' -d 'dataset_service=' \

Available descriptors can be found here:

Calculate structural descriptors with FreeTreeMiner with a minimum support of 80%:

curl -X POST -d 'dataset_uri=[]=' \
-d 'dataset_service=' -d 'minSup=0.8'


An Algorithm service shall provide separate URLs for algorithms with default (or without) parameters and for algorithms with specific parameter values. The second type of algorithm URLs are created on the fly, when an algorithm with specific parameters or a dataset is invoked. For example, when calculating descriptors, depending on the and a set of parameters, the calculation service creates the following feature: 
<ot:NumericFeature rdf:about="">
<dc:creator>Name of creator</dc:creator>
<ot:hasSource rdf:resource=""/>
<owl:sameAs rdf:resource=""/>
<rdf:type rdf:resource=""/>
and internally the algorithm service creates a new algorithm entry:
with a representation like below: 
<ot:Algorithm rdf:about="">
        <dc:title rdf:datatype="">minSup</dc:title>
        <dc:description rdf:datatype=""> Specifies the min support for mining (fraction). Is to be between 0 and 1</dc:description>
        <ot:paramScope rdf:datatype="">optional</ot:paramScope>
        <ot:paramValue rdf:datatype="">0.8</ot:paramValue>
        <dc:title rdf:datatype="">dataset_service</dc:title>
        <dc:description rdf:datatype="">URI to the dataset service to be used</dc:description>
        <ot:paramScope rdf:datatype="">optional</ot:paramScope>
        <ot:paramValue rdf:datatype=""></ot:paramValue>
        <dc:title rdf:datatype="">dataset_uri</dc:title>
        <dc:description rdf:datatype="">URI to the dataset to be used</dc:description>
        <ot:paramScope rdf:datatype="">mandatory</ot:paramScope>
        <ot:paramValue rdf:datatype=""></ot:paramValue>
        <dc:title rdf:datatype="">hydrogen</dc:title>
        <dc:description rdf:datatype="">Include hydrogen atoms. </dc:description>
        <ot:paramScope rdf:datatype="">optional</ot:paramScope>
        <ot:paramValue rdf:datatype="">false</ot:paramValue>
    <dc:description rdf:datatype="">OpenTox REST interface to the FTM algorithm implementation of TUM.</dc:description>
    <dc:title rdf:datatype="">FreeTreeMiner </dc:title>
    <dc:identifier rdf:datatype=""></dc:identifier>
    <dc:date rdf:datatype="">Tue Jun 22 16:14:24 CEST 2010</dc:date>
  • If a client would like to use exactly same algorithm settings to calculate, it will use the, available via ot:hasSource, in an uniform way for all kind of algorithms, regardless of the existence of parameters;
  • All the complexity is hidden within the algorithm service;
  • If a calculation with the generic algorithm is initiated with specific set of parameters, the service might lookup internally whether such set already exist and eventually reuse, otherwise a new algorithm URL is created along the calculations;
  • A calculation with the algorithm is initiated without parameters , these are already known;
  • If a calculation with the algorithm is initiated with specific set of parameters, the service shall throw an error 400 "Bad request".


Return results:


  • Restrict results to URL
  • Agree on how the resulting URL is returned.  There are several options (not mutually exclusive)
- if no content is returned, the URL is within Location-ref HTTP header (this is mandatory for redirect responses, like returning task IDs), but can be in any other response. - if content is returned, depending on the content type, it can be text/uri-list or RDF representation, containing perhaps only a simple RDF node with the URL as the node identificator and the object type.


Supported MIME types


  • application/rdf+xml (default)


  • application/xml (PMML)
  • text/xml (PMML)
  • text/x-yaml
  • text/x-json
  • application/json
  • ...

HTTP status codes

Interpretation Nr Name
Success 200 OK
No algorithm in the respective category found, or specific algorithm not found 404 Not Found
Incorrect dataset URI, or incorrect parameters 400 Bad request
Model building error 500 Internal Server Error
Model building in progress (redirect to task URI)
303 Redirect
Service not available 503 Service unavailable


This is a generic interface for OpenTox algorithms. As algorithms can be used for a wide variety of purposes (e.g. model building, feature calculation, feature selection, similarity calculation, substructure matching), required and optional input parameters and algorithm results (e.g. model or dataset URIs, literal values) have to be specified in the algorithm representation together with a definition of the algorithm.


Document Actions

Feature Selection

Posted by Sopasakis Pantelis at Oct 02, 2009 02:27 PM
There is no POST for feature selection algorithms. I propose the following RESTful operation:

POST /algorithm/preprocessing/featureselection/{feat_sel_algorithm_id}
posted parameters: dataset_uri, feature_definition
supported mime types: text/uri-list
returns: URI list of (selected) feature definitions.

questions on proposal by CH

Posted by Tobias Girschick at Oct 08, 2009 02:29 PM
I am not totally clear how you envision the algorithm ontology. Here you propose that a
GET on /algorithm/{id} returns an algorithm_ontology_uri. Could you
specify what I do get back from something like that:

GET /algorithm_ontology/{id}

Would this return the XML (or whatever we choose) representation of the

But if this works out, I basically agree with a simplified API

Algorithm - Dataset compatibility

Posted by Jeliazkova Nina at Dec 17, 2009 09:54 AM
Algorithm Ontology to be extended to include information what kind of features/datasets are compatible with particular types of algorithms.

- algorithm requires compound structures
- algorithm requires numerical features only