In Dublin’s fair city, where the metadata are so pretty…

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

2. OVERVIEW • Dublin Core • NZGLS • Lessons learned • Relevance to recordkeeping metadata

3. 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)

4. DUBLIN CORE .

5. 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

6. ABSTRACT MODELS

7. ABSTRACT MODELS

8. 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

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

10. 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.

11. 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

12. 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.”

13. 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

14. DC AND ISO 23081 • 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

15. DUBLIN CORE AND RECORDKEEPING • DC metadata useful as an aggregation layer • www.matapihi.org.nz • “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.”

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

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

18. 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?

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

20. 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

21. 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)

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

23. 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

24. “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

25. REFERENCES • Dublin Core Abstract Modelhttp://dublincore.org/documents/abstract-model/ • MetaMaphttp://mapageweb.umontreal.ca/turner/meta/english/metamap.html • Evans and Lindberg, Describing and analyzing the recordkeeping capabilities of metadata sets, 2004 http://www.nl.go.kr/dcpapers/pdf/2004/Paper_27.pdf • MADRAS Registryhttp://www.gseis.ucla.edu/us-interpares/madras/ • Dublin Core Collections Application Profilehttp://www.dublincore.org/groups/collections/collection-application-profile/ • Nilsson et al., Towards an Interoperability Framework for Metadata Standards, 2006http://kmr.nada.kth.se/~mini/papers/TowardsAFramework.pdf