3.5. Interfaces, APIs and client modules (TECHNOLOGY)

Thanks, @waddink. I can provide some background on the evolution of the visuals-

The approach evolved from over a series of discussions starting with a very basic sketch. Initially, GBIF was exploring what could be done to improve the representation of information feeds available and enhance GRSciColl. Since many contributors are non-technical, we found it useful as a mechanism to validate if people understood what each other were saying. It was/is an exercise in seeing if this is would be useful to design and build, rather than a technical design for how it should be built.

An example of an improvement GBIF desperately need to progress relates to “duplicate” occurrence records. For example this museum record has a sequence record and was cited in this treatment. The clustering algorithms we’re exploring allow us to detect these and better represent data e.g. the specimen illustration.

When it comes to the technical aspects in addition to the aspects you raise, I’d comment that:

  • Similar to GBIF.org, I assume the information would be available through open APIs in addition to user interfaces
  • Many well-established infrastructures are in place and we should look to connect, partner, and build on those initiatives wherever possible. 100’s millions specimens and collections from ~90 countries are already sharing data through connected infrastructures, there are now well-functioning identifier mechanisms in place to partner with etc. I favor a step-wise approach to integrate and bolster these efforts.
  • We’ve learned that a one-size-fits-all solution rarely works. Collection metadata, citations, and specimen related data will be curated in a variety of systems and we should design for that flexibility and be agile.
  • The technical threshold for participation needs to be low and open to all. At the simplest, we need entry points that support those using Excel and a web form.
1 Like