SETF meeting - 24. October 2014

Revision as of 15:57, 22 August 2016 by Karin Karlsson (Talk | contribs) (Minutes)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Time: 11:00 UCT (13:00 local)

Location: Museum of Natural History, Stockholm


  1. DINA REST API standard (DINA_API_Standard_Discussion_Notes)
  2. DINA UI Standard - example
  3. roadmap for official adoption
    • DINA module map – API blueprint for each of the components, to help define tasks for the different teams.
    • Thorough technological evaluation of the modules in Pluto-F, Canadian system, DINA, etc.
  4. presentation at TDWG
  5. Specify 7 updated beta version:, username: testuser1, password: testuser1
  6. Other items?


List of participants

DINA Licensing

  • this had already been discussed at the last face-to-face meeting; this is not yet resolved, requires further consultation and the DINA license policy needs to address both licensing of code and content
  • "code" license(s):
    • some members are still in the process of clarifying their institutional requirements/constraints with regard to new or existing modules contributed to DINA
    • it will be necessary to collect currently used licenses with a view on arriving at an (ideally) single or harmonised DINA license
    • we need to assemble a list of "best practices" with regard to licensing
  • "content" license(s):
    • this is also not yet resolved
    • the meeting participants expressed that it would be desirable if content would be shareable within the consortium
  • next steps: consultation of individual institutions to obtain licensing guidelines
  • the SETF aims to provide at a licensing recommendation for the Steering Committee

User management module

  • a shared user management module used by DINA modules was discussed as one possible collaborative development project
  • such a module requires a shared model regarding
    • DINA identities
    • user permissions
    • authentication
  • more research is necessary before partners can commit to details
  • an approach by which only parts of this model are used by each partner is imaginable, i.e. a central DINA user identity service could be used to issue identities for all local DINA assemblies, but permissions are managed by a custom module developed and used by individual partners
  • furthermore, it may not be desirable to enforce the full identity/authentication routines within local DINA module assemblies
    • this could be addressed by offering public and private endpoints for the provided DINA modules
    • this needs to be added to the DINA Web API standard

DINA graphical identity

  • It was discussed if a shared graphical identity and a set of UI templates could improve usability and overall adoption of DINA.
  • Concerns:
    • conflicts with existing corporate identity
    • potential conflicts with other developments and projects
  • However, similar to the agreement on providing UI reference implementations for modules, it was agreed that recommended graphical templates could be provided.

Core module strategy


  • The core module is the web-bases collection manager. Wrt to development efforts this can be split into a framework (module manager) and data capture and management component.
  • Starting point?
    • Focus should be on data capture or "collecting event".
    • In order to drive this forward a useful subset of functionality and related subset of the data model have to be defined; while inspired by experiences with the Specify data model it is independent of this and can incorporate already collected new requirements (details provided by James)
  • In order to plan for development the following packages of the core module, addressing specific functions and concepts with distinct boundaries, were identified:
    • Core collecting event (covering the key functions for data capture and editing associated with e.g. accession events)
    • Agents (covering managing, linking and reconciling agents; registry of agent services, etc)
    • Taxonomy (supporting both mechanisms to structure collections as well as capturing scientific work on classification)
    • Determination event
    • Geography
    • Transactions
    • Preparation and storage
    • Media

Implementation strategy

  • pending further discussions it was agreed that partners should start implementation on the core module collaboratively and package by package rather than in parallel
  • this requires a shared development infrastructure
  • Next steps:
    • define a module and core module package map, including separate APIs for the latter
    • decide on shared infrastructure (repo, issue tracker, planning strategy and tools, integration services)
    • decide on common implementation technology (?)
    • agree on specific contributions (resources and expertise) from each partner
    • setup agreed infrastructure


  • several comments are awaiting incorporation in the current API standard draft document
  • testing of compliance turned up as a major issue
    • a proposal for further investigation was to include a "module manager" in the development of the core module from the start; this module manager would implement at least large parts of compliance testing functionality
    • as the quickest workable approach it was suggested to identify compliance reviewers from other teams
    • finally, it would be possibel to simply let the community of users enforce compliance

Data migration problems

  • several data migration projects (to Specify) are underway; experiences with this will be valuable input for DINA migration efforts and should be collected on the Wiki

Action items


  • collect a list of currently used licenses (code & content) within member organisations
  • clarify pending policies on code and content licensing (some members where waiting for this)
  • make a licensing recommendation to the DINA Steering Committee; with view of planned collaborative development and public shared repos this is a fairly pressing issue to resolve

DINA API standard

  • continue consultation on this and ideally complete and adopt the standard by the end of 2014

Core module

  • see points outlined in the minutes above

Data migration problems

  • setup up wiki page and structure to collect information on migration experiences (Who?)

Next meeting

  • Tentatively: Wednesday, 19.11.2014 - 14:00 UCT (call)

This page was last modified on 16 August 2022, at 09:50. Content is available under Attribution-Share Alike Non-commercial 2.5 or later, Unported unless otherwise noted.