Computers in Libraries
Vol. 22, No. 8 • September 2002

Table of Contents Subscribe Now! Previous Issues ITI Home
• COMING FULL CIRCLE • 
'Standard' Issue: Defining Standards and Protocols
by Andrew K. Pace

I seem to recall a time when protocols and standards were two different things. In the past couple of years, the craze over new protocols has seemingly breathed new life into library information technology, replacing the doldrums of standards with the hope of new, universally accepted protocols. I must admit to being too young to have been there, but I wonder if things felt like this when MARC and Z39.50 were poised to change the world of library automation. MARC and Z39.50? Ugh ... so 5 minutes ago; where have you been? It's XML and OpenURL, and the Open Archives Initiative. Not only that, we'll do it all in Open Source! This profession is a sucker for the word "open." Where did all this openness come from, and what happened to standards?

Libraries' Lower Standards

Maybe it was the fear surrounding another 20-year adoption cycle, à la Z39.50,or the fact that only a librarian could really appreciate the intricacy and art form that is the MARC record. Whatever the cause, many librarians have dropped their stalwart allegiance to old standards in favor of new protocols. Of course, we placate ourselves with rounds of back-patting, reminding each other ad nauseam that XML is just dumbed-down MARC, or laughing at stories of the latest dot-com customer service desks as they discover what we have always known as the reference interview. (Actually, what's remarkable is that we make these comments within our own circles, but still invite outside experts to our conferences in hopes of learning something from them when they often have more to learn from us. But I digress.)

I mentioned that protocols and standards used to be two different things, albeit related. They also used to mean different things and have different purposes than they do now. For example, a protocol used to simply be the technical or analog rules used to complete a transaction. We can see how a protocol (whose traditional definition is a rough draft or an unratified convention) was something just short of a standard. Now, protocols, especially technical protocols, are ways around standards. Anyone with a little HTML knowledge and a book on Perl coding can create a Web protocol.

Standards are another story. The term "standard" itself has become so confused that we now have to call most of them "open standards." I think we can thank Microsoft and Apple for introducing two of the very first so-called "proprietary standards," one of IT's greatest oxymorons; that is, a protocol or file system that is so widely adopted as to be standard, but without the open specifications that make it a truly open standard. You often hear Adobe's PDF described as a proprietary standard. So a proprietary standard is essentially a closed standard, which is no standard at all. Make sense? No wonder protocol sounds better. And hence the profession's first embrace of open-ness—we like open books, open meetings, and open library doors. Who has time for closed standards? And yet libraries continually embrace proprietary standards every time they sign a new service contract with an online publisher, a database vendor, or an integrated library system company.

Higher Expectations

The struggle over standards and protocols is easily seen in the paradoxical relationship between library vendors and their customers. Libraries want vendor adherence to standards to be so strict, so open, and so well-documented as to make the distinctions between one vendor and another nearly invisible. Vendors, on the other hand, want to distinguish themselves from one another and capture market share among a relatively fixed customer base. Vendors have traditionally mollified libraries by embracing standards like MARC, HTML, and Z39.50, usually with their own proprietary twists. Or (in the case of some ILS vendors), they keep libraries coming back for more enhancements with half-baked versions of EDI (Electronic Data Interchange), ILL (Interlibrary Loan), and SIP/NCIP (Standard Interchange Protocol/NISO Circulation Interchange Protocol) standards.

But if one library system uses MARC and the http protocol, why can't two library management systems talk to each other without a third party, such as OCLC? Even systems that use the same standards and the same protocols look like foreign systems to each other. This is essentially what troubles me about library pursuit of some of the standards and protocols that are discussed in this issue.

Dream or Boondoggle?

Take, for example, the OpenURL. Simply put, libraries want to be able to create deep-link URLs that will take users directly to the full text of the articles that they seek. Furthermore, internal citations could conceivably link to other full-text articles either within or outside the specified database. Like the Digital Object Identifier standard that preceded it, the technical specifications are quite simple—create a standard format for the URL that will contain all the appropriate data for the user to obtain the appropriate copy of the article he is seeking. This summarizes some of the basic theory behind context-sensitive linking products like ExLibris' SFX, the fascination with which still puzzles me since it merely passes simple title and ISSN "metadata" from one database to another, based on defined "protocols," and makes little to no use of valuable metadata like author and subject.

I call OpenURL a "theory" because across the market it is still essentially that. Even those vendors that have embraced OpenURL have done so in different ways. Some use author last-name/first-name, others use first-name/last-name; some are struggling with the fact that they might not even have data like "author first name." Like MARC and Z39.50 before it, vendors and publishers are creating their own proprietary deep-linking methods around what is supposedly (and ideally) an open standard.

But more troubling than the technical difficulties is the expectation among libraries that vendors will have no problem linking from one system to another. In an era where companies are suing each other for URLs that link to sites deeper than a home page, the expectation that Springer will have nothing to say about linking directly to EBSCO full text is somewhat unrealistic. Not to mention the fact that OpenURL puts full-text databases themselves in jeopardy. Why go to all the trouble of dumping full-text articles into an abstract-and-index database when an OpenURL will find that full text for you? At worst, vendors will continue to pursue their own closed proprietary solutions. At best, they will all catch on to how badly libraries want this to work, and they will make us pay dearly for their own adherence to any emerging standard.

Protocol Harmonization

Various third-party vendors have come up with their own solutions to the OpenURL, deep linking, and cross-database (or meta) searching. In an effort to make up for the shortcomings of Z39.50 (which is usually just trepidation and lack of know-how on the part of content vendors to create Z39.50 servers), they have come up with something called "protocol harmonization." In essence, the harmony comes in the ability to search resources with a single interface (whether or not the interface has a standard protocol for searching) or in the server that stands waiting to resolve a URL into an OpenURL. But what's the point of harmony among a group that cannot get the melody right?

In the case of cross-database searching and deep linking, protocol harmonization is still a pipe dream, usually delivering proprietary standards, watered-down versions of Z39.50, and products that do not scale to those most anxious to use them. Furthermore, the harmony I am most anxious to see is one of these protocols that takes into account proxy and remote access, almost always an afterthought among vendors, but the underlying current in all libraries struggling with presentation of electronic resources to diverse users. Until there is cooperation behind these efforts, a real understanding of the problem among vendors, and a reasonable expectation among libraries, many new protocol efforts will remain well-specified solutions looking for the right problem.

Shut Up, Cassandra!

Cassandra, for those of you who don't remember from high school, was the doomsayer from Greek mythology, cursed with delivering prophecies that no one would believe. I hardly call my little opinions prophecy, and a column is a perfect vehicle for crying "It'll never work!" from the wings, as others try so very hard to make it work. I am not all doom and gloom, just recklessly pessimistic.

I will admit, however, that the work behind the Open Archives Initiative (OAI) turns me from recklessly pessimistic to cynically optimistic. In its most idyllic iteration, OAI would reduce library dependence on proprietary access to scholarly resources, creating new and efficient ways to expose scholarly publishing to an audience beyond the customer bases of online publishers. Simply put, the standardized exposure of metadata makes this possible; in combination with OpenURL, it makes it easier to implement. OAI turns protocol harmonization into interoperability standards, with the aim of more efficient content distribution. The bigger challenge here is cooperation and patience—cooperation among institutions that want to jump on the scholarly communication bandwagon, and patience among the leading institutions that want to be first on that wagon.

Perhaps the resulting paradox is that in an open choir, harmony is an idealistic fantasy. Our hearts are certainly in the right place, and our heads (some of the brightest in our profession are working very hard on these problems) are only half-a-step behind and catching up fast. I am cautiously optimistic that we will learn from the mistakes of MARC, Z39.50, and ILL when we implement XML, OAI, and NCIP in our libraries. I, for one, will keep an open mind.
 


Andrew K. Pace is head of the systems department at North Carolina State University in Raleigh. He acts as the primary liaison between the Systems Department and the Department for Digital Library Initiatives. His e-mail address is andrew_pace@ncsu.edu.
Table of Contents Subscribe Now! Previous Issues ITI Home
© 2002