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