Dear all,

During our last meeting I promised to post an example of our SuperAlgorithm/Model implementations:

SuperAlgorithm (incorporates feature mining): 

  - (text/uri-list) POST '/algorithm/lazar/?'

  Create a lazar prediction model

  Parameters:
  (String) dataset_uri — Training dataset URI
  (optional, String) prediction_feature — URI of the feature to be predicted
  (optional, String) feature_generation_uri — URI of the feature generation algorithm
  (optional, String) - — further parameters for the feature generation service
  Returns:
  (text/uri-list) — Task URI

Right now all additional parameters are passed to the feature_generation service - for a generic API we would need a mechanism to split parameters among sub-algorithms (e.g. feature calculation, feature selection, model learning).

The completed task returns a lazar model, which I would consider a SuperModel (integrates feature generation for the query compound(s)):

  - (text/uri-list) POST '/model/:id/?'

  Make a lazar prediction. Predicts either a single compound or all compounds from a dataset

  Parameters:
  (optional, String) dataset_uri — URI of the dataset to be predicted
  (optional, String) compound_uri — URI of the compound to be predicted
  (optional, Header) Accept — Content-type of prediction, can be either `application/rdf+xml or application/x-yaml`
  Returns:
  (text/uri-list) — URI of prediction task (dataset prediction) or prediction dataset (compound prediction)

IMHO SuperModels should wrap everything that is needed to predict chemical structures (application of feature generation algorithms, sub-models and consensus algorithms for consensus predictions, ...) into a single object. They should accept (and need) only chemical structures as input parameters.

Best wishes for the new year!

Christoph