Natural History Systems “Just another catalogue” “We’re different” Some degree of commonality in non-catalogue modules e. g. taxonomy Cross-fertilisation approach to catalogue design Ad-hoc evolution of natural history support Critical mass of natural history sites Can we do more?

Current Structure KE EMu is object-oriented Commonality at several levels Base module Multimedia Admin Base catalogue Location tracking Deaccession Condition checks, …

Current Structure (continued) Most natural history functionality built per site Simple specimen counts, measurements etc. Identifications Type status

Catalogue Object Structure

Creating a Natural History layer Extends base functionality Common across all NH sites Not “one size fits all” Add common columns Identifications Darwin Core Add common functionality Re-identification Specimens & Preparations

Proposed Catalogue Object Structure

Benefits Raise level of commonality amongst sites Facilitate data interchange Better utilise natural history based development by KE Easier adherence to standards Darwin Core ABCD Simpler implementations of protocols DiGIR Can grow incrementally

Issues Agreeing common goals Conflicting requirements Ultimately depends on NH user base Utilise EMuUsers forums Setting priorities Funding Backwards compatibility Don’t want to change existing column names! Changes to existing workflows? Integration with non-NH parts of catalogue?

Summary Critical mass of natural history sites using KE EMu Scope for common natural history level of module development Particularly suited to emerging standards Success dependent on degree of agreement