Archive for the ‘Jerome blog’ Category

In the background at Discovery event

Posted on May 26th, 2011 by Paul Stainthorp

Notice: Undefined index: ga_export_settings in /var/www/html/wp-content/plugins/google-analytics-async/google-analytics-async.php on line 403

A few of the Jerome project team are at the JISC/RLUK event in London: ‘Discovery – building a UK metadata ecology‘. Our slides are running on a screen in the foyer; I’ll be hanging around to talk about them.

How commercial next-generation library discovery tools have *nearly* got it right

Posted on May 17th, 2011 by Paul Stainthorp

Notice: Undefined index: ga_export_settings in /var/www/html/wp-content/plugins/google-analytics-async/google-analytics-async.php on line 403

In Huddersfield (again – I’m barely away from the place!), yesterday, at a CILIP UC&R (University, College and Research Group) Yorkshire & Humberside [catchy name] training event on ‘Discovering Discovery Tools‘. Librarians from four different UK universities gave practical, pros-and-cons descriptions of how they implemented and are now running four different commercial next-gen resource-discovery tools:

Five (count ‘em!) people from Lincoln were in the audience. I was wearing two hats: one for project Jerome for thinking about design concepts in resource discovery tools; the other for my day job – Lincoln is in the middle of a strategic review of Library ICT systems, which may well end up recommending that we buy one of these products.

It was all good stuff. First off, libraries need to hear the honest, warts and all counterpoint to the glowing terms in which each discovery product is described by its vendor. Secondly, it’s useful to subject all four* resource discovery platforms to the same amount of daylight, and see where the common problems lie, as well as where one tool outperforms another. Thirdly—and even though there’s a lot of resource discovery hyperbole to be heard—this is still a big shift for academic libraries, and I think we should discuss implications that are wider than the costs/benefits for an individual institution.

(*Yes, I know there are a few other tools. But they weren’t in the room yesterday.)

Lockside
What’s stopping us? (Canal lock gate at the University of Huddersfield.)

Things that jumped out at me:

Commercial resource discovery has reached a level of maturity that was absent a couple of years ago. That’s not to say that all next-gen resource discovery tools are perfect (because they aren’t), or that there aren’t any problems (because there are; see below), but academic libraries do now have a genuine choice between several different, viable commercial products.

Here’s a heresy: the differences between these four products are not that significant. I think that anyone who went away from yesterday’s event thinking that out of the four discovery tools on display there are some ‘good’ and some ‘bad’ …is probably wrong. It’s not really about the product, it’s about the willingness of the vendor to overcome problems, and about their attitude to their customers. Do you buy a slightly-less slick product, but from a company you feel you can have a more productive relationship with?

In fact, most of the real problems with resource discovery seem to be common to all four of the products on show yesterday. De-duping via FRBR reckons to be a bit of an Achilles’ heel. (A shame. FRBRisation is one of those things you either need to get right, or not do at all. A half-arsed attempt is worse than not bothering.)

Also broken: known-item search. This ought to be trivial to fix, and it needs to be sorted now now now.  I find it particularly sinister that some commercial resource-discovery tools rank their search results according to secret, proprietary algorithms that can’t be inspected or challenged by their users, let alone altered/improved. This is a problem. What’s the point of a library that can’t justify how its resource discovery system actually works? Are we just here to sign the cheques?

Libraries still have a tendency to overcomplicate things for their users. Sometimes they do this because they have no choice (perhaps their shiny new discovery tool doesn’t quite work they way it should); but often they seem just too ready to accept a situation where users are inconvenienced sooner than address an underlying problem. Lincoln included in this sweeping generalisation.

There’s no point pretending that a library can make two independent decisions to purchase [a] a next-gen resource discovery platform, and [b] a journals knowledgebase/link resolver. The two things are all tied up together. To pick a random example: you want Summon, you’d better want 360.

Why can’t we just buy access to a search index? If I want to pay to provide my users with the benefits of a lovely big central index of content, why do I have to buy into your discovery algorithm and web front-end as well? (Whither JISC collections?)

Related, and finally – we really shouldn’t have to replace our search and discovery interfaces every time we want/need to use a different content provider, and we shouldn’t be placed in the situation of having to make collection/subscription decisions in order to ‘feed’ our discovery tool. It may be temptingly easy, cost aside, to pick up and put down different next-gen discovery products (“…it’s just a subscription!”) but there’s too much at stake for our users.

Three quarks for Muster MARC!

Posted on April 21st, 2011 by Paul Stainthorp

Notice: Undefined index: ga_export_settings in /var/www/html/wp-content/plugins/google-analytics-async/google-analytics-async.php on line 403

My esteemed, gracious and talented colleague Mr. Jackson is not happy.

He’s not happy because I’ve asked him to do something which he thinks is an awful, depressing, retrograde step. I’ve asked him to add a MARC export function to Jerome.

Nick’s argument in a nutshell (he won’t mind me paraphrasing):

  • MARC is awful: truly awful. It’s holding back humanity’s (and libraries’) progress. We shouldn’t be doing anything to prolong its life. #marcmustdie

My argument in a nutshell:

  • For better or worse, libraries still use MARC, and this will be a useful facility for libraries who want to consume our open data straight into their existing Library Management Systems.

What does the studio audience think? Should Jerome serve up MARC (actually, MARCXML. I’m not a monster.) because someone, somewhere might want to consume it, or should we take a stand and insist on providing only decent, sane data formats from now on?

For anyone who’s blissfully unaware of MARC (MAchine-Readable Cataloging) formats, read this. Then read this, this, and this. Then go and have a lie down in a darkened room.

I don’t love MARC. More than anything, I don’t really understand it (I have a cataloguer to do that for me). But it still has currency in libraries. #shouldmarcdie?

The Jerome mind map

Posted on April 20th, 2011 by Paul Stainthorp

Notice: Undefined index: ga_export_settings in /var/www/html/wp-content/plugins/google-analytics-async/google-analytics-async.php on line 403

We’re using a free, preview version of a web-based mind mapping tool called MindMeister to plan and make notes for Jerome. Each week, the notes are copied across to our project tracking app (Pivotal Tracker) to form the development iteration for the week.

It’s very rough and ready, but you’re more than welcome to take a look at the Jerome mind map at: http://www.mindmeister.com/92308610/jerome