Collections Management Natural History Museums Common Development A Natural History Example using Darwin Core Much talk of common development Concern over level of agreement required Necessary differences between implementations “We’re all individuals” Does this necessarily mean “lowest common denominator”?

Collections Management Natural History Museums Natural History Catalogues KE: “Just another catalogue” Museum: “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 What more can we do?

Collections Management Natural History Museums “Standard” Structure KE EMu is object-oriented Commonality at several levels Base module Multimedia, Admin Base catalogue Location tracking, Deaccession, Condition checks, … Most natural history functionality built per site Simple specimen counts, measurements etc. Identifications Type status

Collections Management Natural History Museums “Standard” Catalogue Object Structure Base Module Base Catalogue CMCCFMNHMVNMNHWAG

Collections Management Natural History Museums 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

Collections Management Natural History Museums Natural History Catalogue Object Structure Base Module Base Catalogue NH Catalogue FMNHMVNMNH CMCCWAG

Collections Management Natural History Museums 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

Collections Management Natural History Museums Example – Darwin Core Darwin Core columns and tabs available in Natural History Catalogue layer Population of columns implemented for each specific client Mapping of client specific columns to standard DwC columns DwC columns automatically populated when record saved (similar to Summary Data) Significantly simplifies provision of DwC data (e.g. DiGIR provider) Once mapping done then all DwC immediately available for your collection Currently implemented for NMNH and MV Success depends on mapping

Collections Management Natural History Museums 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?

Collections Management Natural History Museums 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 Approach equally applicable to other catalogues and other modules