Jerome McDonough of the Graduate School of Library & Information Science at the University of Illinois at Urbana-Champaign presented a paper this summer at the Balisage conference with the title Structural Metadata and the Social Limitation of Interoperability: A Sociotechnical View of XML and Digital Library Standards Development.¹ The title is very hard to penetrate, but the contents of the paper lay bare a theory for why we don’t have large, swirling pools of shared digital objects that cross institutional silo boundaries.

Jerome lays the issue out right away. Paraphrasing from several papers, he says:

Despite its success, however, XML has not lived up to many librarians’ expectations within one area, that of interoperability…. Digital library developers have expected that shared use of an XML standard for structuring of content and metadata (what is commonly called “structural metadata” within the digital library community) would ensure content interoperability and provide a clean division between content and higher level tools and services designed to work with standardized encodings of that content. In practice, this goal has proved extraordinarily elusive. Experiments conducted by participants in the Library of Congress National Digital Infrastructure for Preservation Program (NDIIPP) to test the exchange of digital objects between repositories failed even when participants were using the same XML-based encoding format and producing valid XML instances to exchange.

What Jerome is referring to is the ability to readily move objects from one repository to another. This would seem inherently doable on the surface — the offering repository and the receiving repository are both using XML and perhaps even the same “structural metadata standard” (METS, MPEG-21, etc.). These standards provide “a structural grammar for the encoding of complex digital objects” — the kind of thing needed to move these complex digital objects around various repositories. Jerome lays out two reasons why this doesn’t occur. First, there is a tremendous amount of flexibility in the metadata standards as a result of efforts to make each of the standards abstract enough to encode every conceivable structure. Document authors have choices in the depth of levels of description, labeling of object components, and arrangement of the object structure relative to creation of one or more interrelated descriptive metadata files. The second issue he identifies is the problem of “standards independence”, or the desire by the document standard author to have his/her metadata schema stand alone. Relying on other schemas may decrease the usefulness of the new standard to other organizations and environments.

The paper is a rich history of structural markup standards that have lead the profession to where it is today. He concludes with suggestions for the digital library community to move past this problem. One solution is to declare that our community is more concerned with using the flexibility inherent in the metadata standards for local needs than we are with sharing digital objects across silos. Counter to this is to refine standards to reduce the flexibility so as to increase the chances that the standards will promote interoperability. Jerome also offers the idea of promoting the activity of converting between various metadata formats to a more recognized and valued level. (He notes, for instance that the XSL stylesheets created by the Library of Congress that convert MODS into MARC/XML and back are omitted from the ‘Standards of the Library of Congress’ web page.)

Via Lorcan Dempsey.

Footnotes

1. McDonough, J. (2008). Structural Metadata and the Social Limitation of Interoperability: A Sociotechnical View of XML and Digital Library Standards Development. InBalisage: The Markup Conference Proceedings 2008. Montréal, Canada. Retrieved October 2, 2008, from http://balisage.net/Proceedings/html/2008/McDonough01/Balisage2008-McDonough01.html.

Michael J. Giarlo wrote a very nice summary of my FEDORA trilogy (only three parts so far — I think there are more good things to say about FEDORA; and besides, I like Douglas Adams’ concept of what a trilogy should be), and added a piece that I hadn’t considered:

3. Having one’s objects stored as XML on the filesystem also opens up opportunities to see how tools which act thereupon might be glued into the repository infrastructure. One such example might be for an XML-aware search engine (such as amberfish, Lucene, or Zebra). Since you’ve got low-level access to these files, it would be fairly simple to tack on a search & indexing system that is independent of your choice of repository.

Wow. Now that is a powerful concept. Not only do we not need FEDORA in the future to read our digital objects, we don’t need FEDORA now to read our digital objects. This would take a little digging to see if it is true, but if Fedora really does serialize the XML back to the FOXML file on disk for every change made to it, then one really could use the FOXML files on disk as a surrogate for the FEDORA application itself. After having conversations with Dan Davis about what it means to live in a Service-Oriented Architecture, I yearn for a time when FEDORA and other OhioLINK applications can send messages to each other. But for now, simply having another application that looks at the file modification timestamps on files to see if they have changed and should be processed in some way is a very interesting idea. It make sense, for instance, as a way to feed new/modified objects into an indexing application or a notification application. Or to ‘rsync’ a backup hot-spare server with content from the live server.

You hit all of points exactly right in your summary, Michael, and thanks for triggering a new line of thinking about how to exploit FEDORA to its fullest potential.

The text was modified to update a link from http://staff.washington.edu/leftwing/wordpress/2006/05/02/the-jesters-case-for-fedora/ to http://lackoftalent.org/michael/blog/2006/05/02/the-jesters-case-for-fedora/.