From Client to App: Extending Diversity Workbench with REST and graphical web interfaces

What this was about

Björn Quast described work in progress to connect Diversity Workbench more directly with users. Currently the Windows-only client is organised by data concept and feels complex, and publishing pipelines transform data several times with no way back. LIB's online catalogue offers adjustable filters, suggestions, Boolean queries, table downloads and specimen pages with stable identifiers. A redesign aims at mobile-friendly visual exploration using an Elasticsearch index that respects DWB's multi-level access rights. A REST API with concept-based endpoints, sharing JSON structures with the index, supports variable user interfaces and constraint-based insert/update ingest rules. It is already used to ingest ASV registry data (OTU tables, occurrences, identifications).

Why it matters. It shows a path for legacy desktop CMSs to open up through APIs and web front ends, including data ingest from other systems.

In the room

• The DWB client is Windows-only and structured by data concept, which confuses users.
• Publication pipelines filter by access rights, project and collection through multiple format transformations, with no way back.
• The online catalogue offers adjustable filters, suggestions, Boolean sub-queries, CSV download and specimen pages with stable identifiers.
• Redesign goals: mobile-friendly, chart-based visual exploration backed by Elasticsearch with DWB's access rights.
• The REST API uses concept-level endpoints (e.g. four collection-event tables in one schema) sharing JSON with the index.
• Ingest rules (insert, update, insert-if-not-exists, attach) are decided via database-style constraints.
• The API is used to ingest ASV registry data into DWB.

Notable moments