1 files changed, 143 insertions, 0 deletions
diff --git a/public/presentations/opentox-dublin/api.rst b/public/presentations/opentox-dublin/api.rst
new file mode 100644
index 0000000..2763b50
--- /dev/null
+++ b/public/presentations/opentox-dublin/api.rst
@@ -0,0 +1,143 @@
+.. |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
+==========
+