opentox api: lessons learnt, limitations and challenges

OpenTox APILessons Learnt, Limitations & Challenges.

P. Sopasakis1 and H. Sarimveis2

1. IMT Institute for Advanced Studies Lucca,2. National Technical University of Athens, School of Chemical Engineering.

October 29, 2013

OpenTox – USA 2013 OpenTox API 1/15

OpenTox APILessons learnt and perspectives for the OpenTox API.


Need for Exemplification

Further testing of APIswith additional algorithmimplementation, modeltraining and validation.

This procedure will revealthe shortcomings of thecurrent OpenToxframework,


Let’s make a Standard out of OpenTox...

According to RFC 6410:

A “Proposed Standard” is expected to be stable (no knownbugs), while it has received significant community re-view & enjoys enough community interest. Two seper-ate interoperable implementations from different code basesneed to be fully documented,

A “Standard” requires additionally widespread deploy-ment and use.


Portability of Models

Export the actual QSAR orQSPR model,

Take into account existingformats, e.g., PMML,

In-house formats such asRDF/XML, XML and JSON canserve the purpose of export-ing the actual model.


Metadata for datasets and their features

Datasets to be accompanied by statistics for their features(min, max, average, std and more)

Datasets to be linked to other resources (if applicable), e.g.,it should be clear when a dataset was created as a transfor-mation of some other dataset.


Prediction for Mixtures

It should be possible todefine datasets for mixturesputting together mixture-descriptors and mixtureproperties,

Demonstrate this function-ality with relevant exam-ples.


Stochastic DoA

A stochastic/probabilisticdomain of applicability(DoA) outputs a probabil-ity distribution function(histogram) for a givencompound

An extension of the APImay be necessary (or if not,an example of how to do sowill do)


Extensions for Nano-materials


Extensions for Nano-materials

It should be possible to map nanomaterials to their mi-croscopy images,

Images (list of URIs) can be made available using the AcceptHTTP header - This needs to be specified in the API,

Feature calculation based on microscopy images (geometricand chemical characteristics),

New ontological definitions (classes and properties) need tobe introduced to cater for nanostructures.


Optimal Experimental Design

Provide guidance to experimenters as what to measure (andunder what conditions) so as to improve the predictive abil-ity and/or the applicability of existing models

Consider unsupervised and supervised approaches

From the API point of view an OED can be an Algorithmthat maps datasets and/or models to datasets (i.e., com-pounds along with experimental conditions and a featureannotated as “prediction feature”).


Laboratory Comparisons

Question: Which laboratory offers more reliable measure-ments [There exist loads of relevant statistical tests]

The OpenTox ontology needs to be extended to this direction

API: An Algorithm can take up the comparison between twosets of measurements and export a Dataset where one canfind various statistics and the decision.


Additional MIMEs

In OpenTox we standardised the format of the RDF files,

The same can be done with other well-established formatssuch as JSON (particularly useful for integration with appli-cations that use Javascript), YAML or TOML.

What about binary formats such as Protobuf of BSON?


Some shortcuts

Make certain shortcuts part of the API:

How to create a copy of an existing dataset?

The method PUT /dataset/{id} is vaguely defined in theAPI – Explicitly state how the client can update a dataset(add/remove compounds, etc); Standardise such shortcuts.


Thank you for your attention.


opentox api: lessons learnt, limitations and challenges

Education