Several early adopters and other careful readers generously provided us with feedback regarding the details of the specification. As a result, we were able to make a number of improvements. The most significant change to the schema is that it now includes a namespace, which provides OAI PMH compatibility.

The documentation changes may be less significant, but we hope they add clarity. A new column in the properties tables provides guidance as to whether the property being described is an attribute or a child of the corresponding property that has preceded it. In addition, in response to a request, we gave one of the allowed values lists (the relationType pairs) a thorough overhaul.

I’d like to add my personal thanks to the Metadata Working Group members who helped review these changes, to the technical experts from our member institutions who provided advice, and to our Metadata Coordinator, Frauke Ziedorn, for everything she does, including keeping track of the feedback we get from community members.

On another note, a small team from the Metadata Working Group will begin working in April on a second version of the schema that is interoperable with the Dublin Core. Please stay tuned for more information on this development as it unfolds.

The CDL is seeking a developer for the Unified Digital Format Registry (UDFR, http://www.udfr.org).

The UDFR project is developing a reliable, sustainable, and publicly available semantic knowledge base of file format representation information.

Stakeholders for this project are drawn from academic and national libraries and archives around the world, including the University of California, Harvard University, the Florida Center for Library Automation, the Library of Congress, Library and Archives Canada, the British Library, the UK and US National Archives, the Koniklijke Bibliotheek and Nationaal Archief of the Netherlands, and many others. The project is funded by the Library of Congress as part of its National Digital Information Infrastructure Preservation Program.

 If you or someone you know is interested in applying, please apply through this link:

 https://jobs.ucop.edu/applicants/Central?quickFind=53751

After many months and a lot of very early morning conference calls with my European colleagues, I am delighted to make this announcement. The core group that worked on this second iteration of the scheme came from:

• British Library
• California Digital Library
• CISTI (Canada Institute for Scientific and Technical Information)
• DTU Library (Technical Information Center of Denmark)
• ETH Zurich (Swiss Federal Institute of Technology Zurich)
• GESIS (Leibniz Institute for the Social Sciences, Germany)
• TIB (German National Library of Science and Technology)
• TU-Delft (Delft University of Technology)

Other members were involved in an advisory capacity as well. And, this iteration of the scheme also benefited greatly from the many helpful comments offered during the community review period we conducted in the late summer and early fall of 2010.

There are several key features to the metadata scheme, and my colleague Angela Gastl and I discuss these thoroughly in an article in the recent DLIB issue on research data. Briefly, these include a small mandatory set limited to those properties required for a data citation, as well as a carefully selected optional set that allows for the description of data and other resource relationships as desired.

The mandatory set is:

• Identifier
• Creator
• Title
• Publisher
• PublicationYear

It is also notable that the DataCite organization is committed to supporting the scheme in a way that makes both very useful to DataCite’s own members  and also available to the broader community.

On the “useful to DataCite’s own members” thread, I’ll say from California Digital Library’s perspective that we are very glad that the scheme is now finalized. As some readers know, our DataCite application is EZID. Now, we will be able to update our local application to the DataCite standard. Look for increasing functionality and services over time.

EZID (with DataCite inside) is one of the key tools you need to take control of the management and distribution of your research, share and get credit for it, and build your reputation through its collection and documentation. Read more about EZID here, or contact us.

Image courtesy of University of the Pacific Library Holt-Atherton Special Collections

For an identifier to persist, it has to continue to identify the object, to be linked to the object, in a way that will not change if the object is moved or renamed. Persistent IDs mean never having to show a nasty 404 error message again.

The way that EZID approaches this problem is twofold: a) by offering long-term identifiers, and b) by providing a mechanism for the owner of the identifier to update the metadata associated with it. In other words, if you move your stuff to a new storage location, and if you update its address, then the linkage you established persists.

The way I think about persistence, though, extends further than identifiers. This may be a little unorthodox, but it seems to me that the notion of persistence, of continuing steadily in some state or direction, extends to organizational work practices and to institutions.

We certainly ask and respond to questions these days about the health of organizations and institutions, given the poor state of this “recovery” in general and all the bad news about California’s economy, in particular. So how can you tell if a prospective collaboration partner or service provider is likely to be around this time next year, never mind five years down the road? How do you avoid getting a nasty “vendor not found” message?

The answer, of course, is that there are no absolute guarantees. But I think there are indicators. Organizations that follow good practices, such as business continuity planning and establishment of service level agreements inspire a level of some confidence. An additional level of protection can come from what the Data Portability Project folks call a “data portability policy.”  This is the idea (in part) of making transparent what data users bring in to a site (or application) and what they can get out.

Somehow, the admission that failure may occur, followed by the laying of groundwork for graceful exit, inspires the ability to continuing steadily in some state or direction, to persist. Do you agree?

I saw this for myself when I sat down at a table in Hannover, Germany, for the first summer meeting of DataCite. I was leading a discussion of the Working Group on Metadata. Included in the discussions with me were representatives from these organizations:

• ETH Zürich (Swiss Federal Institute of Technology)
• GESIS (German Social Science Infrastructure Services)
• DTU (Technical University of Denmark)
  
• British Library
• Purdue University Libraries
• TIB (German National Library of Science and Technology)/DataCite
• ANDS (Australian National Data Service)
• CISTI (Canada Institute for Science and Technical Information)
• SNDS (Swedish National Data Service)

Before I left home, I had received some advice from a veteran of metadata standards work, John Kunze. He wrote, “In my extensive experience with metadata standardization, the biggest threat to that process in our community (not the private sector) is non-convergent discussion.  One approach to use…is the “desert island” question: if you know you’d be stranded by yourself on an island for five years and you could only bring 7 books with you, which would you bring?”

Up to this point, the metadata group had met virtually a few times, which is a greater than usual challenge with members spread from Europe all the way to Australia. So our face-to-face time was especially valuable. I took John’s advice and proposed that we focus our attention and efforts on achieving consensus on a core set of required elements. My colleagues readily agreed to this strategy.

We worked for 3 hours and, in the end, settled on 6 required elements. We also achieved a greater understanding of the differences between our various organizations, and that became apparent as we made the case for one metadata element or another. This makes for a better end product, because a standard that can accommodate a wide range of use cases and users is more successful than one that is more narrowly defined. When our discussions bumped into the edges of disagreement, we were able to uncover assumptions, clearing up misconceptions.

The Working Group on Metadata has more work to do, of course. We still have the optional elements to discuss. We must coordinate our work with other standards groups. And, now, we are back to functioning on a virtual basis. But, I think that we head into these remaining tasks with new strength both from our modest successes, and also from the experience of overcoming differences to achieve them.