'f' enable fullscreen mode
'w' toggle widescreen mode
'o' enable overview mode
'h' enable code highlight mode
'p' show presenter notes

This presentation is joint work with the Biodiversity Informatics group at the Swedish Museum of Natural History, including: Stefan Daume, Ingimar Erlingsson, Kevin Holston, Ida Li, Karin Karlsson, Fredrik Ronquist.

Thanks go also to Christopher Lewis with team and to Paul Morris with team for valuable feedback.

The DINA project (DINA from DIgital NAtural history collections) is an international effort to develop a web-based collection management system to be hosted at a national or regional scale, replacing independent databases and helping to make datasets broadly accessible for research and public use.

We are using an open source oriented development methodology, cooperating internationally in a decentralized fashion, aiming to:

• pool developer resources
• improve software quality and transparency.
• provide a complete and relevant feature set

Through open discussions of DINA objectives and activities, the project has benefited from a broad diversity of perspectives and technical contributions beyond its resource limitations.

Technical development of DINA system components is the cohesive theme underlying open-source software development among members of the DINA consortium. New member are welcome to contribute to the work.

Some important architectural objectives are:

• Web-oriented, public accessibility, using open source technology stacks
• Service oriented architecture favoring RESTful web services
• Using international standards, like Darwin Core and Audubon

A diverse set of teams, with different…

• Countries
• Spoken and written languages
• Cultures
• Locations
• Working hours / time zones
• Technology choices / programming languages
• IT-infrastructures and existing systems / applications

How do we find a common ground?

• Not “One to rule them all”
• Decentralized model with teams working on separate modules
• Lingua franca – communicate in English
• Web meetings when needed, mailing list, IRC channel
• Agreement upon using standards to exchange data
• Implementations are up to respective team
• Peer reviewed DINA compliance through DINA Technical Committee

A mechanism for exchanging latest changes (deltas) for occurrence data

Java EE implementation

• Reference implementation JAX-RS Jersey for RESTFUL, JPA
• JAXB – Apache Abdera for Atom Feed and Entry
• Database server: MySQL 5.1
• App server: Glassfish 3.1.2

Java SE implementation

• Database server: MSSQLServer
• App server: Tomcat

Python/django implementation

• Python using django framework
• Database server: postgres
• Web server: Apache2

PHP implementation

• PHP
• Used at gbif.se, now refactored into Java Play framework

Rule One / One Rule

Web UIs should get their data through Web services through versioned and documented web APIs.

Licenses

Open understandable licenses both for code and content

• Code - open source licensed such as GPLv3 (or BSD, MIT)
• Content - open content using Creative Commons licensing

Web UIs - will comply with a graphical profile

• DINA UI Theme using Twitter Bootstrap stylesheets like the MIT-licensed BootsWatch UI themes
• Logos (see footer) and other reusable images for branding
• Web and print (open) fonts - Source Sans Pro, Source Serif Pro, Source Code Pro
• The DINA Web poster is an example of using the DINA graphical profile

Web data services - will comply with the DINA REST API style

• Versioned
• Documented

The DINA REST API standard provides guidelines for the implementation of DINA-compliant RESTful APIs for modules and systems developed by DINA partners or any contributor of modules and systems that are intended for integration into DINA system assemblies.

Objective

• provide a realiable contract between DINA modules
• enable a simple assembly of modules and systems developed by partners in the DINA consortium
• enable the integration of external modules and systems into DINA assemblies

• The DINA consortium wants to encourage a fast-growing and diverse ecosystem of DINA-compliant contributions, thus the standard should ensure a reliable contract for integration of a broad range of modules, but should not be overly restrictive.

• While examples or recommendations for tools, frameworks or technologies may be given in the standard, it must not impose any implementation technologies on contributors.

• If open normative standards exist that cover specific requirements of the DINA REST API standard, it should build on and incorporate these standards instead of defining custom solutions.

Condensed

• Data components implemented as RESTful web services with properly styled JSON and/or XML responses
• API endpoints available through Cool URI patterns
• Comply with emerging conventions for mapping CRUD operations to HTTP verbs (GET, POST, PUT, HEAD etc)
• API responses with metadata and multiple language support
• Documented and versioned, use curl examples to show usage for data migration

All details are in the draft DINA Web API standards document

Some resources you can tap into:

• http://www.dina-project.net/wiki/DINA_API_Standard_Discussion_Notes
• https://DINA-Collections.github.io
• https://github.com/DINA-Collections

Contact us if you want to collaborate, and get access to our mailing list, wiki, meetings and workshops.

• A DINA compliant media server module will be presented next
• The DINA Technical Committee will publish the first version of the DINA Web API standardization document after it has been presented to the DINA steering group
• More DINA compliant modules are in the works and will be peer reviewed and then released

• Provide collaboration platform and suggest tools and methods and invite to meetings
• Collate and share overview, providing DINA architectural road map and directions, unified "branding" assets (logos, stylesheets etc)
• Conflict resolution / voting capacity for controversial architectural topics
• Capacity to "certify" or validate and whitelist versions of DINA components / packages
• Determine which packages are stable and collate the reference DINA Web "distro" as a VM?
• Organize focus group and testing efforts of packages / modules?