Notes and documentation to implement the SmartDots API
Many otolith exchanges that use SmartDots are done under the auspice of ICES. In these cases, SmartDots uses the ICES system where events are created and managed by otolith coordinators from member countries. Access to these systems require login privileges to the ICES system.
Creating a server that supports the SmartDots Application Programming Interface (API) allows users to manage the storage of the necessary information about samples and associated images to be able to annotate them.
Doing so enables independent use of the SmartDots client application without a dependence on the ICES server as well as promoting compatibilities between other groups that support the API. A representational State Transfer (REST-API) is instantiated by a web framework which includes a development stack (Python, C#, PHP, RDMS)
Motivation to create such a server includes desire to have autonomy over server performance, account management, etc.
The technical details of the SmartDots Application Programming Interface can be found in the ICES library. Link to SmartDots Web API – Technical documentation
For other usage of SmartDots, an underlying system can be made usable by the application by providing the appropriate Application Programming Interface.
The SmartDots application expects that the information about specimens and their associated otoliths be defined and provided following a given data dictionary. It also expects that users who are doing annotations be defined, and can be authenticated through the API, and that images of otoliths be available in bitmap format.
The basic system that could support the SmartDots API can be summarised in the following diagram.
Examples of systems that support the SmartDots API include the ICES system, DFO Dots, DTU Dots, ...