So what is this digital divide? The term has enjoyed popularity in the mainstream press and has been used to describe a variety of gaps introduced by the rapid acceptance of computer technologies.
Often the digital divide, like XML, is oversold. Despite the frenzied hype that is associated with XML, and the digital divide, there are substantive issues that need to be addressed. In the world of librarianship, the digital divide to which I'm referring has several characteristics.
The first is the growing division between the types of resources to which libraries provide access.
As I said a minute ago, Lane's usage statistics suggest that our patrons prefer to search a single source for information. More and more we are finding that this source needs to be an integrated online resource. As familiarity with the World Wide Web spreads this will, in my opinion, only become more true.
The division between the types of library resources can also be seen in the way that libraries are adopting XML technologies. Many are cataloging their digital resources in METS, the Metadata Encoding and Transmission Standard, but keeping their traditional resources in MARC.
Whether these libraries intend these two sets of resources to be searched concurrently is unclear.
The second gap doesn't affect library patrons as much as it does librarians. Watch the online bulletin boards and you will probably see positions for "metadata specialists". These are essentially jobs for catalogers who have learned how to apply Dublin Core, a simple subset of elements, and attributes, used to describe and provide access to online resources.
Ironically, the pay for these positions is often higher than that for library catalogers. This is true despite the fact that library catalogers use a more complex data format, MARC, to catalog traditional library resources.
The fact that these professionals make more than catalogers indicates, to me, that cataloging has a problem with the way it is perceived. Forget about the outside world, the "black art" of MARC is rarely understood by anyone within the library, with the exception of catalogers.
Unfortunately, a result of being misunderstood is that you are sometimes devalued.
An example of this is the outsourcing trend that swept through libraries a few years ago. Though this may not be a popular observation, departments that get outsourced are often valued less than than those that don't; departments that are not outsourced are often kept "in-house" because they are perceived as being critical to the success of the organization's mission.
How can the foundation for all the library's services not be critical to its success? This is a case, I believe, of being too specialized. Ask any cataloger... a good understanding of MARC requires years of actual cataloging experience. Courses in library school will only scratch the surface.
A good grasp of MARC, though, is only that... it is not applicable to other endeavors because it is so specialized. One way catalogers might bridge the gap to better pay and more respectability is to expand their skill set to include cataloging using a universal data markup language, like XML.
How many of you have heard the term "dark data"? It is generally used to describe information that is stored in a database, and is only accessible through that database's interface.
Today, most library data is dark data. To find it, one must specifically search that library's catalog. The fact that your local library has a copy of Hamlet is not something you will discover by searching Google, or any other Internet search engine.
This is not the fault of integrated library system vendors. We have given them a standard that is designed for computers to process, not for human consumption. They have no standard way to provide access to library data because we haven't given them one. What we have given them is an efficient transmission format. "Do with it what you will."
Imagine, for a moment, the alternative. Suppose the library community created a standard XML format for library data. System vendors could then compete on the services they provide rather than the functionality of their system.
They could do this because they would not need to spend as much time independently developing tools to maintain a format that is only used by the library community. By utilizing tool sets that large corporations like Oracle and IBM create, our library system vendors could spend more time on customer support.
Though MARC implements an international standard, the standard is really only used by the library community. HTML and its younger sibling, XML, on the other hand, are ubiquitous.
They succeed, in part because they are simple. This doesn't mean that the creation of an XML library information standard will be trivial. The data structures required to adequately describe library resources are complex.
But just because something is complex and well established doesn't mean there isn't room for improvement. For many years, members of the library community have been suggesting alternatives to the current structure of library information. Two well-known examples include Barbara Tillet's "entity-relationship" and Michael Heaney's "object-oriented" cataloging models.
While these innovators have suggested changes to the structure of library data, the medium to implement these changes has not really existed prior to this time. XML's emergence provides us with the opportunity to rethink the structure of bibliographic information.
Moving to a non-MARC based XML format does not mean we throw out years and years of cataloging experience, but that we have the opportunity to try and implement changes that many in the cataloging community have been advocating for years.
I would doubt that many of you, other than the systems librarians here, have actually ever seen a real MARC record.
Still, MARC has probably influenced the way you do your job. The most obvious example, of course, is cataloging. Catalogers create bibliographic records using templates that bear a strong resemblance to MARC. Ask any cataloger what the 'a' subfield in the 246 field is and he or she will be able to tell you.
Many reference librarians have also had to, at one time or another, look at the "display MARC" version of a catalog record. When I worked as a paraprofessional at the University of North Carolina, I remember some hesitation among the reference librarians to use the library's new graphical interface client.
It seems they were accustomed to being able to quickly view the "display MARC" version of a record and did not want to give that convenience up.
Despite the fact that MARC was only intended as a transmission format. It pervades the library environment. Why not create a library transmission standard that can also be used as a display standard and template standard?
This doesn't mean that graphical editors shouldn't be created, but that being able to read the raw data format also has its advantages.