.. |date| date::

=========================
OpenTox API Working Group
=========================

.. :Date:    30 September 2015

.. University College Dublin, Dublin, Ireland

.. https://docs.google.com/document/d/153ip9ll_pzqMphoJ4d608ujd5GuYysZcTDAODsrXsrc/edit

Workshop Objectives
===================

Capture 
  - service provider (developer) experiences
  - service consumer (client) experiences

Identify open issues

Resolve open issues

Unify and update API documentation

OpenTox
=======

http://opentox.org/dev/apis/api-1.2

Focus on predictive toxicology 

REST interfaces for: Compound, Feature, Dataset, Algorithm, Model, Validation, Report, Ontology, Task, Authentication and Authorisation

RDF representation

ToxBank
=======

http://api.toxbank.net

Extensions for capturing bioassay data 

Additional objects: Alert, Data, Index, Investigation, Organisation, Project, Protocol, Search, Session, Template, User.

RDF representation, ISA-Tab (http://isatab.sourceforge.net/format.html)

eNanoMapper
===========

IDEA: http://enanomapper.github.io/API

NTUA: http://app.jaqpot.org:8080/jaqpot/swagger

IST: https://enm.in-silico.ch/api/dist

Extensions for capturing nanomaterial data

Additional objects: Bundle, Myaccount, Property, Query, Substance, Substanceowner, Pmml, Bibtex

JSON representation


Developer experiences
=====================

(De)Serialisation of large datasets/investigations
==================================================

  - system/infrastructure limitations (time, memory, database/webserver size limits, ...)
  - impossible for RDF (performance of RDF parsers/serializers, markup size)
  - even JSON markup can cause problems
  - we propose CSV/TSV as data exchange format for datasets
    
Complexity of the one webservice/class model
============================================

  - code separation, maintenance
  - performance penalties caused by suboptimal data structures
  - performance penalties of webservices (data (de)serialisation)
  - complicated server infrastructure

Communication with external services
====================================

  - ad hoc requests for features that deviate from official API
  - reliablity/availability of external services
  - undocumented API details
  - undocumented/silent API/data format changes 
  - no common strategy for conflict resolution, API or data representation updates

Local service deployment (e.g. for in house services)
=====================================================

  - installation far from straightforward
  - management of additional server instances
  - duplication of functionality, bloat
  - update strategy

Documentation
=============

  - scattered/outdated documentation
  - maintenance
    - too many places to consider (error prone)
    - ideally autogenerated from code
  - ideally combined with tests (availability, API coverage, API compliance)

Client experiences
==================

Open issues
===========

Workflow for
  - API unification and updates
  - issue and conflict reporting/resolution

Documentation
  - location
  - format (Swagger, Wiki, ...)
  - maintenance
  - link to inventories, tests 

...

OpenTox APIs
============

http://opentox.org/dev/apis/api-1.2

http://api.toxbank.net

http://enanomapper.github.io/API

http://app.jaqpot.org:8080/jaqpot/swagger

https://enm.in-silico.ch/api/dist


Next steps
==========