A bunch of my colleagues are dressed up today. I considered donning my khaki-colored dockers, denim shirt, and brown loafers, but was afraid that no one would recognize me as being a vendor. I needed too many props to pull off the costume, like some PowerPoint slides that look like a real website. I have mastered the ability to smile, rock back and forth on my feet while swinging my arms, and exuding that look of "Boy, do I have a solution for you!"

It's getting harder these days to determine whether what libraries are getting is a trick or a treat. We tend not to take "trick or treat" too seriously . . . as in give me a treat or I will play a trick.

Sometimes the trick is figuring out just what the heck is going on, like when two competing vendors join forces to offer products and services. We've seen this ad nauseam in the ILS vendor world in the last couple of years. It's even present in the open source community where openness is the shared structure despite the fact that the products themselves compete. This week, we see it in the self-check and security arena.

3M and Checkpoint have apparently joined forces. It's not quite a merger and I am still trying to figure out the techno-political ramifications of the partnership: 3M will be an exclusive reseller of Checkpoint technology, and Checkpoint will continue to sell directly to libraries. The partnership is described in this press release (pdf).

Reading between the lines a little, it seems like 3M is enamored of Checkpoint's technology, and Checkpoint likes 3M's support and customer service infrastructure. How they will reconcile their products might be akin to how the entire self-check and security market reconciles its standards, something that has been contentious for the last few years. 3M and Checkpoint are both on the NISO RFID for Library Applications Working Group, chaired by VTLS's Vinod Chachra. TAGSYS, an RFID maker, is also on the group. The extent to which competing vendors have input into the standard is unclear.

In my opinion, the discussion around RFID has been too philosophical (privacy, data leaks, etc.) and not technical enough (interoperability, technological lifespan, etc.). Establishing a relationship with a self-check and security vendor has too often been a life-long relationship for technological reasons. Interoperability is the only hope in being able to choose the right vendor with whom to establish a relationship.

It was about eight years ago this fall that I sat down to make my very first attempt at professional writing. I submitted my very first column for "Coming Full Circle" in Computers in Libraries. I probably shouldn't admit this, but I think I worked harder on that column than on any one since, with the possible exception of my very first column for American Libraries. I'm happy to say that the CIL article on digital preservation still has legs. I'm a little sad for digital preservation that the article still has legs.

I was pretty good in those days at making outlandish predictions about library technology, some of which were right on the mark, but I thought for sure that the digital preservation topic would be such a moving target as to render its content obsolete in a matter of a year or two. The problem, of course, as with many good things in this world, is that preservation is expensive and the return on the investment is quite distant.

I don't mean to suggest that nothing has changed in nearly a decade. I'm merely pointing out that the long-term benefit requires a long-term plan. We also need to keep in mind that the vendors that will involve themselves in this area will require short-to-medium-term returns on their prospects.

Most vendors cannot even think in the terms dictated by preservation needs. I recall talking to a representative from Adobe back around the time I wrote that first column. He told the story of asking the National Archives how long the files had to last. The NARA employee answered flatly, "Until the end of the Republic." Of course what seemed like a joke at the time was an important precursor to PDF for Long-term Preservation.

How sustainable is long-term preservation? And who does one turn to when trying to find expensive solutions to problems that the average person would barely acknowledge? Or, in this case, to answer the question of just how expensive the endeavor is? Grant funders. And thanks to the generous support of the National Science Foundation and the Andrew W. Mellon Foundation, we can look forward to an answer from the Blue Ribbon Task Force on Digital Preservation and Access. The task force—co-chaired by Fran Berman, cyberinfrastructure expert and director of the San Diego Supercomputer Center at the University of California–San Diego, and Brian Lavoie, an economist, preservation expert, and research scientist with OCLC—will convene an international panel of experts to develop actionable recommendations on economic sustainability of digital information for the science and engineering, cultural heritage, academic, public, and private sectors.

Like good librarians, we have already done a fair amount of work on digital preservation standards, such as PREMIS. The addition of this work could go a long way toward determining the long-term sustainability of libraries' and archives' substantial investments in and careful planning for the future.

Since I've said it a few times, I thought I would get it down in print before it got taken out of context or worse. "Interoperability is the biggest lie in automation today." The word is thrown around as easily and meaninglessly as "friend." Interoperable is, at best, an adjective for standards-based systems, and at worst, a hack to cover up the fact that different systems are not at all meant to speak to one another. The former case is so rare as to make it the exception; the latter case is perpetual job security for systems people.

interoperability
Function: noun
: ability of a system (as a weapons system) to work with or use the parts or equipment of another system
—Webster's Online

I'm not sure why Webster's chose weapons when online systems would have made a good example; perhaps they wanted to emphasize the interoperability of pieces and parts, though computer hardware would have done okay for that. In fact, hardware interoperability is much less of a lie than software interoperability. Systems folk are much more used to after-market memory, cables, etc. We're spoiled now by the (nearly) Universal Serial Bus. But the time is not so distant that we should have forgotten that hardware used to be as proprietary as most software.

Why am I so worked up about this? Well, first of all, I care about standards, and interoperability without standards is more often than not an end-run around them. Second, unlike loose use of the word "friend," interoperability can cost time and money. It's the same reason I object to the oft-overused "automagically." In my experience, there's no magic in IT—just lots of hard work. The more we describe it as magic, the less respect there is for hard work.

So what? Well, I've been advocating breaking systems apart for some time now. The dis-integrated library system is reality—the classic ILS, link resolving, metasearch, ERM, patron self-service, digital asset management, CRM (e.g. PeopleSoft, Banner), "next-gen" catalog interfaces. Would you believe someone who told you they had a Shangri La where all these pieces interoperate? I'm generally skeptical in thinking that any two of them can. Sometimes a little skepticism can be healthy.

I am willing to admit that I remain skeptical about the "one big pile" approach to next generation catalogs that is sweeping the library automation world. While I don't agree that advanced relevance ranking techniques are ineffective on bibliographic records (go look, there is no literature that I can find on this topic...there's tons on full-text, but nothing on surrogate record relevance), I wonder what happens when the catalog becomes more than it used to be.

If a relevance algorithm is based on whether or not a library holds a title, what happens when an article is thrown in the mix? How does/will Google's relevance algorithm work when the body of content is 20M books and 20M articles?

One development I am encouraged by comes from our friends at Bowker Syndetics, the folks who have been enriching catalog records for several years now. Traditionally, catalog enrichment with things like book jackets, Tables of Contents (TOCs), reviews, etc., is done on the fly by tying content to something like an ISBN. Of course, the problem with enriching records on the fly is that the content of the enrichment is not part of the retrieval process.

Traditionally, the way around this has been to dump tons of data into the MARC record itself—the perfect example of tradition stunting progress. Our profession's obsession with "the record"—not MARC, but the record itself—has led to missed opportunities, both philosophical and technological.

Syndetics now has an interesting compromise, called ICE (Indexed Content Enrichment). What if you could have all the enrichment and index it with your MARC data? New catalogs—AquaBrowser, Endeca, Primo, and Encore—will certainly help this idea along. It may even be what led Bowker to see Medialab (creator of AquaBrowser) as a nice little acquisition opportunity.

Calling all researchers! Let's not make the mistake that some of the vendors and showroom floor demo wizards are. We need more research in this area. Indexing first chapters, reviews, tables of contents, flyleafs, and annotations—and turning media awards and fiction files into faceted navigation elements—does not necessarily improve relevance ranking. It can provide recall where there was none before, but relevance is something different. And how will any of this compare with full-text (especially book-length text) relevance ranking?

Is Bowker onto something? I got to thinking about all the hub-bub over BISAC codes in the public library space. Then I thought about Bowker owning Books in Print and all this enrichment content. They and others are also heavily involved in the ONIX standard for publishers. Then I recalled that AquaBrowser has a deal with LibraryThing for tagging and other content. Throw in a little ICE and you've got a pretty interesting cocktail, making this a more intriguing battle:

BIP + ONIX + BISAC + ICE + LibraryThing vs. MARC

Throw in all the full text that is coming at us and all bets could be off. Think about the fact that Bowker is part of the Cambridge Information Group which also owns CSA, ProQuest IL, and RefWorks; and now Bowker owns AquaBrowser. Boy, all Bowker needs is an ILS for a soup-to-nuts package. I reckon there's one or two for sale out there.