Bibliographic Wilderness

Think again.

http://listserv.nd.edu/cgi-bin/wa?A2=ind0803&L=ngc4lib&T=0&O=D&X=77132057060E3A8667&P=6033

Jesse Haro of the Phoenix Public Library writes:

Following the release of the Customer Service Agreement from Amazon this past

December, we requested clarification from Amazon regarding the use of AWS for library catalogs and received the following response:

“Thank you for contacting Amazon Web Services. Unfortunately your application does not comply with section 5.1.3 of the AWS Customer Agreement. We do not allow Amazon Associates Web Service to be used for library catalogs. Driving traffic back to Amazon must be the primary purpose for all applications using Amazon Associates Web
Service.”

There are actually a bunch of reasons library software might be interested in AWS. But the hot topic is cover images. If libraries could get cover images for free from AWS, why pay for the expensive (and more technically cumbersome!) Bowker Syndetics service to do the same? One wonders what went on behind the scenes to make Amazon change their license terms in 2007 to result in the above. I am very curious as to where Amazon gets their cover images and under what, if any, licensing terms. I am curious as to where Bowker Syndetics gets their cover images and on what licensing terms–I am curious as to whether Bowker has an exclusive license/contract with publishers to sell cover images to libraries (or to anyone else other than libraries? I’m curious what contracts Bowker has with whom). All of this I will probably never know unless I go work for one of these companies.

I am also curious about the copyright status of cover images and cover image thumbnails in general. Who owns copyright on covers? The publisher, I guess? Is using a thumbnail of a cover image in a library catalog (or online store) possibly fair use that would not need copyright holder permission? What do copyright holders think about this? This we may all learn more about soon. There is buzz afoot about other cover image services various entities are trying to create with an open access model, without any license agreements with publishers whatsoever.

I havent’ actually read it yet, but just the abstract alone of this Dlib article makes me think of a reoccurent problem I think about. If showing the user all the subjects that matched their query along with hits is useful (we often describe this as ‘facetted’ display, which I think is actually a misnomer), that might work well when you only have LCSH, but what the heck do you do when you have a corpus involving disparate controlled vocabularies?

Just listing all the controlled terms raw can easily give users misleading ideas in several ways, or just be plain confusing.

And what if some items in the corpus don’t have controlled subject/genre vocab at all?

So on reading that abstract I think, hmm, assuming LCSH is still the most common controlled vocab in your corpus could you use automated clustering algorithms to map other items to LCSH, to actually provide a meaningful list of subjects across your corpus?

Maybe.

The ONIX For Serials Coverage standard is out.

While it was mainly designed to be used within the ONIX SOH and SPS formats, they wisely decided to publish it as a free-standing schema too: “The Coverage Statement may also be used to express holdings or coverage in XML structures other than those specified in ONIX for Serials.”

I think this is a great idea, along the lines of the ‘mix and match’ incipient semantic web we find ourselves in. If you look at the standard, it is really a very nice way way to describe serial holdings coverage, in ways very amenable to machine calculation. For instance, to answer the question: “Is this particular issue X within the holdings?” Or, to combine various holdings statements into a contiguous human-displayable statement. Etc. This is something our current systems have trouble doing, because we don’t store the neccesary data in machine-actionable ways.

While the standard says it’s “designed to convey information about online serial resources from suppliers – such as hosting services, publication access management services, agents or publishers – to end customers in subscribing libraries.”, there’s really nothing about it that’s limited to that context.

If anyone is writing software where they need to store or exchange serials coverage data, I’d encourage them to check out ONIX For Serials Coverage. It’s very elegant, seems to me to be just the right level of complexity and flexibility to do what it needs to do, without being overly abstract/complex/flexible. Should be quite easy to work with. Hats off to the standards writers here.

I was at the ELUNA conference this past week.

Among other things, Oren Beit-Arie from Ex-Libris gave a presentation on their “Unified Resource Management” strategy for their products. I’m afraid I can’t find even any good marketting materials from EL on this online, let alone Oren’s slideshow, which would be great. But here’s what I took away from it (anyone else feel free to correct me).

A) Get Ex Libris products working together in an integrated way, working with one common data model, as ’services’ layered on top of a common database. Buy what services you want, all the services work well together in an integrated fashion. (There was a nifty boxes-and-lines diagram here about the idea for architecture).

B) An openness to… openness. The individual services should be mix-and-matchable with services from other providers (vendors or open source).

Now, I have no doubt that ‘A’, even by itself, is the right strategy for architecting library software. The current divisions between products and ‘modules’ we have are not always rational, leading to both user interface problems (lack of integration, have to look in different places for things that should be together), and workflow problems (again, staff has to enter things multiple times, and work with multiple products/modules/screens to accomplish what is one task to their workflow).

The architecture Oren was talking about is right from a technical perspective, and it’s indubitably right from a business perspective to give customers what they need/want. In fact, this strategy is no doubt in part a response to competitor Serials Solutions, whose products more-or-less already work like this. SerSol recently rebranded their products as the ‘360 suite’ to emphasize this level of integration. With the important caveat that SerSol’s suite does NOT include a traditional ILS or most of the functions/interfaces traditionally housed there. Which is the most complicated/difficult part, of course.

But it’s Part B that is really exciting. SerSol doesn’t do that.

Now, achieving part A alone will be a technical challenge. But on top of that, making all the pieces mix-and-matchable with other vendors products? It’s an even bigger technical challenge (does that mean that common data schema needs to be some kind of standard common accross vendors?). It’s also a political challenge and a business challenge for Ex Libris.

Will they be able to get other vendors to cooperate? (The incipient emergence of real-world stable open source library software makes this more likely, and provides some projects that are likely to cooperate regardless of what the traditional ones do).

Will they be able to actually make this work for themselves, actually commit to it, not be scared of what it could mean to their own bottom line? Now, Ex Libris has always been one of the vendors that is most comfortable with open-ness, and really trying to provide software that works with their competitors, instead of relying on lock-in. Not to detract from ‘ideological’ motivations in the company which are probably present, this is also due in part to their business position. (There are always ‘material conditions’ helping to determine things, sez this Marxist). Their strongest product was SFX–NOT an ILS–and their ILS product always had a relatively weak market share in North America anyway. So they had no choice but to promote interoperability.

It’s clear that they want Primo, their new ‘front end’ unit, to inter-operate with everyone else’s stuff, so other vendor’s customers can still buy Primo.

But do they really want all their other products–including back-ends–to inter-operate with OTHER vendors front-ends and back-ends too? So I could even–gasp–choose to use a Primo competitor with their back-end products? Are they really going to be willing/able to pull this off? It’s going to take serious technical resources, and in the long term, they’re not going to be able to justify such resources to themselves if it results in lowering their own ‘lock in’–or are they?

What Ex Libris says they want to sell me, is indeed what I want to buy. Will they be able to make it happen? Will they be able to do it in time for it to matter? The URM ’strategy’ [Oren was clear that it's not a 'product', it's a 'strategy'] is just being born, and the timeline was “next 5 years or more”.

Time will tell. But I am encouraged that they seem to have a strategy which makes sense from a technical perspective, not just a business perspective, something we are not used to expecting from our vendors, and which we all desperately need. [Of course a vendor with a great technical idea that goes out of business helps nobody either--I'm not saying the business can be sacrificed to the technical.]

Specifically with the stuff that generates the coverage strings missing from the SFX API. In some cases of SFX including services from ‘related’ SFX objects, my current code will generate empty or incorrect coverage strings that do not match what the SFX menu itself provides.

I am trying to come up with a very hacky workaround to this. If you want the new version, contact me in a couple days (I should REALLY put this stuff in a publically available SVN). But a VERY hacky workaround is what it will have to be, and will probably still have some edge cases it can not deal correctly with. To explain what the deal is… it’s confusing to explain, but I’ll just give you my Ex Libris enhancement request:

(more…)

A way I’ve been verbalizing something we all think about lately:

Our ILSs were originally intended to support our work flow. The old-fashioned-sounding phrase we still use–”automation”–points at this. We were providing ‘automation’ to make individual jobs easier. Whether the ILSs we have do this well or not is another question, but some still assume that the evaluation of an ILS stop and ends here.

But in fact, in the current environment there is another factor to evaluate. Not just work flow support, but ILS serving as a data store for the ‘business’ of the library. The work that the ILS is supporting produces all sorts of data—the most obvious ones being bib records and holdings information, but it doesn’t stop there. The ILS needs to provide this data, not just to support current identified work flow and user tasks, but to be a data store in and of itself for other software, existing and yet to be invented, supporting tasks existing and yet to be discovered. The ILS needs to function as a data store for the ’single business’ of our library. Not neccesarily the only one (although there’s something to be said for a single data store for our ’single business’), but the data that IS in there needs to be accesible.

Thanks to Lorcan Dempsey for pointing out the concept of ’single business systems environment’ in the National Library of Australia’s IT Architecture report, which got me articulating in this way. I think it’s on the way to a useful way to articulate things which are often understood by ‘us’ but not articulated well to ‘them’ (adminstrators, vendors, our less technically minded colleagues).

So I feel like I just won a wrestling match with the Horizon Information Portal (our OPAC), and wanted to gloat and share what I’ve done. The rules of the match were ‘XSLT’, because HIP has a point of intervention where you can change display using XSLT (not always very easily). My stuff isn’t entirely deployed yet, but I’ll show you on our test server.

(more…)

So, no more Corinthian.

New product apparently expected towards the end of 2008.

1) New product will be based on Unicorn. Will moving from Horizon to Unicorn be no easier than moving from Horizon to another vendor’s ILS…. will it be harder than moving to Evergreen?

2) Prior to the end of 2008, will we have a few more more succesful implementations of open source ILSs, in libraries comparable to our own, to give our own timid libraries enough confidence to make that move? Fall 2008 instead of Summer 2007, the previous (well, the latest previous) Corinthian release date—gives us more time.

The biggest winner of this announcement is Evergreen and Koha.

Oh, and all the rest of us too. Sometimes the only way to get off the sinking ship is to be pushed.