# 3.5. Interfaces, APIs and client modules (TECHNOLOGY)

**URL:** <https://discourse.gbif.org/t/3-5-interfaces-apis-and-client-modules-technology/1973>\
**Category:** Collections Catalogue\
**Created:** [March 27, 2020, 10:45am UTC](https://discourse.gbif.org/t/3-5-interfaces-apis-and-client-modules-technology/1973 "2020-03-27T10:45:02Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![cweiland](https://avatars.discourse-cdn.com/v4/letter/c/b38774/32.png) [@cweiland](https://discourse.gbif.org/u/cweiland)\
**Post date:** [April 28, 2020, 2:50pm UTC](https://discourse.gbif.org/t/3-5-interfaces-apis-and-client-modules-technology/1973/11 "2020-04-28T14:50:22Z")

</div>

> [@trobertson](#):
>
> 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.

That’s clear that one has to find the right balance between sth understandable, usable by humans but at the same time parsable, checkable by machines … Just thinking a bit towards enabling more rigid validation (=raising the threshold): More rigid requirements/validation helps users to understand the semantics of the data structures used. At least for me validation is much easier implemented and maintained using a web ui (or bulk upload via api) converging into a yaml, json-ld and finally rdf pipeline… I think the maintenance of the “low threshold interface” is a pain with sth like Excel, if there are significant changes in the data model upstream the validation pipeline … but maybe that’s a question of available capacities/human resources to support these entry points.

---

_[View the full topic](https://discourse.gbif.org/t/3-5-interfaces-apis-and-client-modules-technology/1973)._
