I wrote yesterday of Nicole Engard’s comment that the ILS was about as open and flexible as a brick wall. Today I learned that the vendor of that ILS had tried to squash her public criticism.

Not cool.

It’s pure speculation on my part, but what comes next? Surely no vendor would send Vinny over to bust an uppity biblioblogger’s knee-caps, but might they offer a customer a better deal if they could just help quiet down a critic within the customer’s organization?

Not speculation: how do we feel about vendors that will spend lavish sums of money to court potential customers, but do little to improve the product and regularly refuse suggestions that they open a round-table with technology leaders among their existing client-base?

John Blyberg’s ILS Customer Bill-of-Rights is especially relevant here, but also, let’s think about our side of the relationship.

update: I keep forgetting to link to this public example of how bad our OPACs/ILSs are. Thanks go to David Walker for making me ROTFL.

III, ILS, ILS Customer Bill-of-Rights, Innovative Interfaces, John Blyberg, Nicole Engard, criticism, libraries, library, squashing criticism, squelched

Nicole Engard last month posted about The State of our ILS, describing the systems as:

I’d say it’s a like the crazy cousin you have to deal with because he’s family! It doesn’t fit, we are a very open IT environment, we have applications all over that need to talk to each other nicely and the [ILS] is a brick wall preventing us from getting the information we need and sending the information we’d like.

Nicole’s point about interoperability is well put, and the post is part of her preparation for conversation and discussion she hopes will go on at the American Association of Law Libraries annual meeting in July.

Coincidentally, I’ll be at AALL next month. My presentation will focus on the things we can do once we overcome the problems Nicole describes, but my concordance with her point should be clear (see previous posts one, two, three).

Extra: When will people who want to improve things not feel as though the ILS is against them, as in this post by Steve Lawson?

update: I keep forgetting to link to this public example of how bad our OPACs/ILSs are. Thanks go to David Walker for making me ROTFL.

AALL, American Association of Law Libraries, future libraries, ILS, interoperability, lib20, libraries, library 2.0, Nicole Engard, standards, Steve Lawson

I feel a little misrepresented by a post from Talis’ Richard Wallis claiming you don’t need technology for Library 2.0 – but it helps, but the company blog doesn’t allow embedded URLs, so I’m posting my comment here:

Richard, please don’t misunderstand me. Technology is the essential infrastructure for Library 2.0. My point was that technology alone doesn’t make a library. It would be better to read my post in the context of Meredith Farkas‘ and Jenny Levine’s recent posts crying out for more programmers in libraries.

Meredith and Jenny are right, libraries need more technology help, but people like John Blyberg and me (and there are quite a few of us) need their help to demand better products from vendors. I say that because I think we can agree on this point: programmers at the customer end of the equation can’t win in the long-run against vendors who continue to deliver poorly designed products.

So while I advocate for change within our libraries, my challenge to vendors is clear: deliver flexible, extensible products that leverage working standards, not just “library standards.” There are many examples outside the library space showing the success of such efforts, use those examples, build on them. And the true lesson of Web 2.0 for you is that the vendor who opens up their product wins against others who impose barriers to remixing.

library, libraries, ils, vendor, talis, web 2.0, web20, lib20, library 2.0, library20, future, vision, open systems

Ryan beat me to reporting on the interesting new services at the Ockham Network (noted in this Web4lib post). The easiest one to grok is this spelling service, but there are others that are cooler.

He also alerted me to a Perl script to proxy Z39.50 to RSS. Though for those more into PHP (like me), I’d like to point out the YAZ extension from the folks at Index Data.

This extension offers a PHP interface to the YAZ toolkit that implements the Z39.50 Protocol for Information Retrieval. With this extension you can easily implement a Z39.50 origin (client) that searches or scans Z39.50 targets (servers) in parallel.

The module hides most of the complexity of Z39.50 so it should be fairly easy to use. It supports persistent stateless connections very similar to those offered by the various RDB APIs that are available for PHP. This means that sessions are stateless but shared among users, thus saving the connect and initialize phase steps in most cases.

Clearly, if I wasn’t so lazy, I’d get around to compiling YAZ into my PHP and actually build something with it. Though without Z39.50 on my own ILS, the incentive is understandably diminished.

Finally, I’ve gotten an answer about indexing cat dates in III so they can be used in searches or sorts. The answer is mostly “no,” but I go into a little more detail at LibDev.

tags: cat date, ils, index data, information retrieval, libaries, library, library catalog, library systems, ockham, opac, perl script, php, rss, search by cat date, sort by cat date, xml, yaz, z39.50, z39.50 proxy

There’s an interesting discussion going at LibDev about what our ILSs are. It all started with a discussion of what role XML and webservices could/should play with ILS/catalogs, but a comment reminded us that Vendor’s decisions about adding new features to products that have been around for 20 or 30 years sometimes edge towards lock-in. I replied offering Flickr as an example of a vendor that’s been successful in part because of their open APIs.

Then David Walker made the point that most ILS were built as inventory systems in the days long before Google showed us that search and retrieval was a separate issue.

The problem is that we have long mistaken these systems for a search and retrieval tool. That is really only a secondary (at best) feature of any ILS, and so it should come as no surprise to us that [they leave] much, much to be desired in that area.

David’s point is almost inarguable. Entirely inarguable, except that electronic sources represent a growing region of our information landscape while the relative number of non-electronic resources inventoried in the ILS shrinks. Unless the ILS evolves, the only items we’ll need to inventory are our preserved resources and archives, and ILSs aren’t very good at that either.

tags: david walker, electronic resources, electronic sources, flickr, google, ils, integrated library system, inventory system, libdev, library system, search and retrieval, search help