OpenTox API: Lessons learnt, limitations and challenges
1. OpenTox API
Lessons 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
3. Need for Exemplification
Further testing of APIs
with additional algorithm
implementation, model
training and validation.
This procedure will reveal
the shortcomings of the
current OpenTox
framework,
OpenTox – USA 2013
OpenTox API
3/15
4. Let’s make a Standard out of OpenTox...
According to RFC 6410:
A “Proposed Standard” is expected to be stable (no known
bugs), while it has received significant community review & enjoys enough community interest. Two seperate interoperable implementations from different code bases
need to be fully documented,
A “Standard” requires additionally widespread deployment and use.
OpenTox – USA 2013
OpenTox API
4/15
5. Portability of Models
Export the actual QSAR or
QSPR model,
Take into account existing
formats, e.g., PMML,
In-house formats such as
RDF/XML, XML and JSON can
serve the purpose of exporting the actual model.
OpenTox – USA 2013
OpenTox API
5/15
6. 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 transformation of some other dataset.
OpenTox – USA 2013
OpenTox API
6/15
7. Prediction for Mixtures
It should be possible to
define datasets for mixtures
putting together mixturedescriptors and mixture
properties,
Demonstrate this functionality with relevant examples.
OpenTox – USA 2013
OpenTox API
7/15
8. Stochastic DoA
A stochastic/probabilistic
domain of applicability
(DoA) outputs a probability distribution function
(histogram) for a given
compound
An extension of the API
may be necessary (or if not,
an example of how to do so
will do)
OpenTox – USA 2013
OpenTox API
8/15
10. Extensions for Nano-materials
It should be possible to map nanomaterials to their microscopy images,
Images (list of URIs) can be made available using the Accept
HTTP header - This needs to be specified in the API,
Feature calculation based on microscopy images (geometric
and chemical characteristics),
New ontological definitions (classes and properties) need to
be introduced to cater for nanostructures.
OpenTox – USA 2013
OpenTox API
10/15
11. Optimal Experimental Design
Provide guidance to experimenters as what to measure (and
under what conditions) so as to improve the predictive ability and/or the applicability of existing models
Consider unsupervised and supervised approaches
From the API point of view an OED can be an Algorithm
that maps datasets and/or models to datasets (i.e., compounds along with experimental conditions and a feature
annotated as “prediction feature”).
OpenTox – USA 2013
OpenTox API
11/15
12. Laboratory Comparisons
Question: Which laboratory offers more reliable measurements [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 two
sets of measurements and export a Dataset where one can
find various statistics and the decision.
OpenTox – USA 2013
OpenTox API
12/15
13. Additional MIMEs
In OpenTox we standardised the format of the RDF files,
The same can be done with other well-established formats
such as JSON (particularly useful for integration with applications that use Javascript), YAML or TOML.
What about binary formats such as Protobuf of BSON?
OpenTox – USA 2013
OpenTox API
13/15
14. 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 the
API – Explicitly state how the client can update a dataset
(add/remove compounds, etc); Standardise such shortcuts.
OpenTox – USA 2013
OpenTox API
14/15
15. Thank you for your attention.
OpenTox – USA 2013
OpenTox API
15/15