scholarly journals General introduction to DINA

2018 ◽  
Vol 2 ◽  
pp. e25646
Author(s):  
James Macklin ◽  
Markus Englund ◽  
Falko Glöckler ◽  
Mikko Heikkinen ◽  
Jana Hoffmann ◽  
...  

The DINA Consortium (“DIgital information system for NAtural history data”, https://dina-project.net, Fig. 1) was formed in order to provide a framework for like-minded large natural history collection-holding institutions to collaborate through a distributed Open Source development model to produce a flexible and sustainable collection management system. Target collections include zoological, botanical, mycological, geological and paleontological collections, living collections, biodiversity inventories, observation records, and molecular data. The DINA system is architected as a loosely-coupled set of several web-based modules. The conceptual basis for this modular ecosystem is a compilation of comprehensive guidelines for Web application programming interfaces (APIs) to guarantee the interoperability of its components. Thus, all DINA components can be modified or even replaced by other components without crashing the rest of the system as long as they are DINA compliant. Furthermore, the modularity enables the institutions to host only the components they need. DINA focuses on an Open Source software philosophy and on community-driven open development, so the contributors share their development resources and expertise outside of their own institutions. One of the overarching reasons to develop a new collection management system is the need to better model complex relationships between collection objects (typically specimens) involving their derivatives, preparations and storage. We will discuss enhancements made in the DINA data model to better represent these relationships and the influence it has on the management of these objects, and on the sharing of information. Technical detail of various components of the DINA system will be shown in other talks in this symposium followed by a discussion session.

Author(s):  
Falko Glöckler ◽  
James Macklin ◽  
Fredrik Ronquist ◽  
Jana Hoffmann

The DINA Consortium (“DIgital information system for NAtural history data”, https://dina-project.net ) was formed in order to provide a framework for like-minded large natural history collection-holding institutions to collaborate through a distributed Open Source development model to produce a flexible and sustainable collection management system. Target collections include zoological, botanical, mycological, geological and paleontological collections, living collections, biodiversity inventories, observation records, and molecular data. DINA is funded by the participating member institutions. DINA Core Members are organizations or individuals who commit at least one half-time equivalent of resources to the development of the consortium goals, at least half of which should be available for code development. The DINA system is architected as a loosely-coupled set of several web-based modules. The conceptual basis for this modular ecosystem is a compilation of comprehensive guidelines for Web application programming interfaces (APIs) to guarantee the interoperability of its components. Thus, all DINA components can be modified or even replaced by other components without crashing the rest of the system as long as they are DINA compliant. Furthermore, the modularity enables the institutions to host only the components they need. DINA focuses on an Open Source software philosophy and on community-driven open development, so the contributors share their development resources and expertise outside of their own institutions. One of the overarching reasons to develop a new collection management system is the need to better model complex relationships between collection objects (typically specimens), research data and associated workflows. We will present the enhancements provided by the approach of the DINA system focussing on the flexibility to plug in compliant components and accommodate additional (meta-)data and specimen related research data with the help of a generic data module. Furthermore, we will discuss challenges in the governance of the development activities such as organizing the distributed code development of the core modules, the code review process and the choice of the software stack. These organizational challenges will be overcome with the help of a revised Memorandum of Understanding.


Author(s):  
Falko Glöckler ◽  
James Macklin ◽  
David Shorthouse ◽  
Christian Bölling ◽  
Satpal Bilkhu ◽  
...  

The DINA Consortium (DINA = “DIgital information system for NAtural history data”, https://dina-project.net) is a framework for like-minded practitioners of natural history collections to collaborate on the development of distributed, open source software that empowers and sustains collections management. Target collections include zoology, botany, mycology, geology, paleontology, and living collections. The DINA software will also permit the compilation of biodiversity inventories and will robustly support both observation and molecular data. The DINA Consortium focuses on an open source software philosophy and on community-driven open development. Contributors share their development resources and expertise for the benefit of all participants. The DINA System is explicitly designed as a loosely coupled set of web-enabled modules. At its core, this modular ecosystem includes strict guidelines for the structure of Web application programming interfaces (APIs), which guarantees the interoperability of all components (https://github.com/DINA-Web). Important to the DINA philosophy is that users (e.g., collection managers, curators) be actively engaged in an agile development process. This ensures that the product is pleasing for everyday use, includes efficient yet flexible workflows, and implements best practices in specimen data capture and management. There are three options for developing a DINA module: create a new module compliant with the specifications (Fig. 1), modify an existing code-base to attain compliance (Fig. 2), or wrap a compliant API around existing code that cannot be or may not be modified (e.g., infeasible, dependencies on other systems, closed code) (Fig. 3). create a new module compliant with the specifications (Fig. 1), modify an existing code-base to attain compliance (Fig. 2), or wrap a compliant API around existing code that cannot be or may not be modified (e.g., infeasible, dependencies on other systems, closed code) (Fig. 3). All three of these scenarios have been applied in the modules recently developed: a module for molecular data (SeqDB), modules for multimedia, documents and agents data and a service module for printing labels and reports: The SeqDB collection management and molecular tracking system (Bilkhu et al. 2017) has evolved through two of these scenarios. Originally, the required architectural changes were going to be added into the codebase, but after some time, the development team recognised that the technical debt inherent in the project wasn’t worth the effort of modification and refactoring. Instead a new codebase was created bringing forward the best parts of the system oriented around the molecular data model for Sanger Sequencing and Next Generation Sequencing (NGS) workflows. In the case of the Multimedia and Document Store module and the Agents module, a brand new codebase was established whose technology choices were aligned with the DINA vision. These two modules have been created from fundamental use cases for collection management and digitization workflows and will continue to evolve as more modules come online and broaden their scope. The DINA Labels & Reporting module is a generic service for transforming data in arbitrary printable layouts based on customizable templates. In order to use the module in combination with data managed in collection management software Specify (http://specifysoftware.org) for printing labels of collection objects, we wrapped the Specify 7 API with a DINA-compliant API layer called the “DINA Specify Broker”. This allows for using the easy-to-use web-based template engine within the DINA Labels & Reports module without changing Specify’s codebase. In our presentation we will explain the DINA development philosophy and will outline benefits for different stakeholders who directly or indirectly use collections data and related research data in their daily workflows. We will also highlight opportunities for joining the DINA Consortium and how to best engage with members of DINA who share their expertise in natural science, biodiversity informatics and geoinformatics.


Author(s):  
Brecht Declercq ◽  
Loes Nijsmans

Both traditional and more recent audiovisual carriers degrade. Even CD-ROMs have typically only a ten-year expected life span. In addition, playback equipment for both analogue and digital carriers will ultimately grow scarcer and more expensive to repair or replace. Archives and museums are inevitably faced with the decision of whether to preserve audiovisual carriers after their content has been digitized. This paper o ers a draft decision- making framework developed by the Flemish Institute of Archiving (VIAA). Assuming that an institution already has a digital collection management system in place, the proposed framework addresses the concepts of favourability, possibility, value, preservation conditions and the risk for other carriers through a series of questions. The paper also addresses the disposal of carriers, should an organization decide that disposal is in the best interests of its collections.


2018 ◽  
Vol 2 ◽  
pp. e26479
Author(s):  
Sharon Grant ◽  
Janeen Jones ◽  
Kate Webbink ◽  
Rob Zschernitz

On the 9th of April 2010 the Field Museum received a momentous email from the ORNIS (ORnithology Network Information System) team informing them that they could now access the products of a nationwide georeferencing project; its bird collection could be, quite literally, put on the map. On the 7th of August 2017 those data (along with the sister datasets from FISHNet (FISH NETwork) and MaNIS (Mammal Network Information System) finally made their way into the Museum’s collection management system. It's easy to get data out, why is it so hard to get it back? To make it easier, what do we need to do in terms of coordination, staffing, and/or technological resources? How can tools like data quality flags better accommodate the needs of data-providers as well as data-users elsewhere along the collections data pipeline? We present a real life case studyof repatriating an enhanced dataset to its institute of origin, including details on timelines, estimates of effort, and lessons learned. The best laid repatriation protocols might not prepare us for everything, but following them more closely might save us some sanity.


2018 ◽  
Vol 2 ◽  
pp. e26083
Author(s):  
Teresa Mayfield

At an institution without a permanent collections manager or curators, who has time to publish data or research issues on that data? Collections with little or no institutional support often benefit from passionate volunteers who continually seek ways to keep them relevant. The University of Texas at El Paso Biodiversity Collections (UTEP-BC) has been cared for in this manner by a small group of dedicated faculty and emeritus curators who have managed with no budget to care for the specimens, perform and publish research about them, and publish a good portion of the collections data. An IMLS grant allowed these dedicated volunteers to hire a Collections Manager who would migrate the already published data from the collections and add unpublished specimen records from the in-house developed FileMaker Pro database to a new collection management system (Arctos) that would allow for better records management and ease of publication. Arctos is a publicly searchable web-based system, but most collections also see the benefit of participation with biodiversity data aggregators such as the Global Biodiversity Information Facility (GBIF), iDigBio, and a multitude of discipline-specific aggregators. Publication of biodiversity data to aggregators is loaded with hidden pathways, acronyms, and tech-speak with which a curator, registrar, or collections manager may not be familiar. After navigating the process to publish the data the reward is feedback! Now data can be improved, and everyone wins, right? In the case of UTEP-BC data, the feedback sits idle as the requirements of the grant under which the Collection Manager was hired take precedence. It will likely remain buried until long after the grant has run its course. Fortunately, the selection of Arctos as a collection management system allowed the UTEP-BC Collection Manager to confer with others publishing biodiversity data to the data aggregators. Members of the Arctos Community have carried on multiple conversations about publishing to aggregators and how to handle the resulting data quality flags. These conversations provide a synthesis of the challenges experienced by collections in over 20 institutions when publishing biodiversity data to aggregators and responding (or not) to their data quality flags. This presentation will cover the experiences and concerns of one Collection Manager as well as those of the Arctos Community related to publishing data to aggregators, deciphering their data quality flags, and development of appropriate responses to those flags.


Sign in / Sign up

Export Citation Format

Share Document