In Dublin’s fair city, where the metadata are so pretty… John Roberts Archives New Zealand

OVERVIEW Dublin Core NZGLS Lessons learned Relevance to recordkeeping metadata

DUBLIN CORE In the beginning (i.e. 1995: before ISO 23081, before ISO 15489, before SPIRT, before AS4390) … Dublin Core Element Set “DCMES” (ISO 15836) Application profile thinking Dublin Core Abstract Model (drafts 2004, latest version June 2007)

DUBLIN CORE.

DUBLIN CORE ABSTRACT MODEL to specify the components and constructs used in Dublin Core metadata. defines the nature of the components used and describes how those components are combined to create information structures. provides an information model which is independent of any particular encoding syntax. facilitates the development of better mappings and cross-syntax translations

ABSTRACT MODELS

NZGLS Based on DCMES Additional elements – Function – Availability – Audience – Mandate Ambition to describe off-line resources and non-document resources for e-Government Note the influence, via AGLS, of recordkeeping metadata

NZGLS REVIEW 5 years on from development … Changes: – In technology – In Government strategy – NZ affiliation to DCMI – In the world of metadata standards

ATTITUDES PREVENTING UPTAKE search engine technologies “make metadata irrelevant”. organisations have “lost the metadata battle” – that they have too much information and therefore have to rely on technology to manage and locate it. residual misunderstanding that NZGLS is a competitor to Dublin Core international standards are sufficient strategy of waiting for Dublin Core to produce a relevant COI standard, e.g. DC-Gov, DC-ED, DC-Lib historic belief that NZGLS was specifically designed for the Government Portal.

SHIFT IN FOCUS broadening of focus from discovery to service delivery consequentially from metadata for support of discovery to metadata for support of service delivery and Information Management Alignment with other standards, e.g. geospatial standard, name and address standard Selection or development of encoding schemes for key metadata elements

DUBLIN CORE AND RECORDKEEPING DCMI commitment to persistence “[DCMI] pledges that as far as they are able, formal documents … will continue to be available throughout the life of the DCMI. Where a persistent resource is modified, a change history will be archived. ”

DUBLIN CORE AND RECORDKEEPING DC often critiqued as unsuited for recordkeeping “analysis of Dublin Core reveals significant limitations as to its applicability for recordkeeping metadata” (Evans and Lindberg, Describing and analyzing the recordkeeping capabilities of metadata sets, 2004) What is meant in this statement by “Dublin Core”? – Is it actually the DCMES? But remember not to judge it by suitability for something it doesn’t aim to deliver

DC AND ISO DC initially to describe web resources (“document- like-objects”) But abstract model is for describing a generalised resource Can be used to describe agents, or other entities Collection Description Application Profile Note that abstract model includes aggregation of related descriptions

DUBLIN CORE AND RECORDKEEPING DC metadata useful as an aggregation layer “Because the Dublin Core standard has not been designed for other uses, it does have limitations and should not be applied in every situation. For example, it is not easy to store collection management information, detailed rights management data, or technical metadata for preservation purposes within the Dublin Core elements.”

SO ITS NOT OUR STUFF? Why do recordkeepers care about Dublin Core? Or, do we care? If not, we should!

FOUR GOOD REASONS 1. DC has done a lot of good thinking about metadata in a networked world 2. Discovery is a purpose of recordkeeping metadata 3. There is a lot of DC instance metadata out there 4. Sharing our metadata is a strong expectation among funders and records’ users

INTEROPERABILITY Why do we want a metadata standard? – Reduce implementation costs? – Interoperability? Why do we care about interoperability? What are we going to share? With whom? And why? Interoperability of what? – Instance metadata? – Term declarations?

REDUCE, REUSE, RECYCLE Metadata sustainability Avoid multiple similar, but slightly different, terms Reuse terms where possible To enable recycling of instance metadata

LESSONS LEARNED There is much more to a metadata standard than just a set of elements Need to be “implementation ready” … But not technology dependent In general, cross-framework interoperability is hard, unless intentionally designed

INTEROPERABILITY FRAMEWORKS Abstract framework Metadata vocabularies – Elements (set of metadata properties and their semantics) – Values (controlled sets of value terms) Metadata formats (“bindings”, “encodings”) Application profiles (Nilsson et al., Towards an Interoperability Framework for Metadata Standards, 2006)

MACHINE-PROCESSABLE INTEROPERABILITY Requires these components to be online in standardised forms RDF vision But there are other approaches e.g. microformats

APPLICATION PROFILES No “silver bullet, one size fits all” metadata standard Even a “core” like DC is in practice implemented in a wide range of flavours The Lego model of metadata components

“METADATA STANDARD” What do we mean by “metadata standard”? The term is used variously to describe: – Element sets – Abstract models – Application profiles Need to be more precise With NZGLS, we thought we wanted a “metadata standard” We developed an application profile

REFERENCES Dublin Core Abstract Model MetaMap metamap.html Evans and Lindberg, Describing and analyzing the recordkeeping capabilities of metadata sets, MADRAS Registry Dublin Core Collections Application Profile Nilsson et al., Towards an Interoperability Framework for Metadata Standards,