Talis Developer Network - Internet Explorer to replace the OPAC - Comments

Bridge the Chasm

RobStyles — Fri, 17 Mar 2006 10:33:39 +0000

You're right to feel frustrated at the lack of access to your library's data. It's been a problem for a long time and there has been a lot of behaviour that could be construed as protectionist - some by libraries themselves and much by systems vendors. Talis has been guilty of this in the past, but none of us here today are interested in closing stuff off like that.

In fact, we're actively trying to change the industry - we have open forums for all of our products, we have partnership programmes to facilitate cross-vendor working. More importantly, we're an active member of the W3C, working hard on trying to make this stuff work.

We started formalising much of our approach to open-ness some time ago now, we started with a set of values:

Sharing and community over duplication and isolation
Reuse over reinvention
Openness and interoperability over exclusivity
Experimentation over certainty

We've focussed very little on these in our marketing, but I hope they give you a string indication of where we're heading.

Rob Styles
Technical Lead, (some aspects of) Platform

Two Worlds, A Chasm Apart?

Tony Hirst — Tue, 14 Mar 2006 21:38:54 +0000

Rob-
I hear what you say - and agree with much of it - yes SRU/SRW would be nice (so where's a Z39.50 2 SRU/SRW relay for me to try stuff out?), yes OpenURL can do some useful things (I tried hacking my library's URLs and knocked up one or two URL redirects to simplify playing (I think you'd agree that http://ouseful.open.ac.uk/library/xml is simpler to remember as a keyword search on xml than http://voyager.open.ac.uk/cgi-bin/Pwebrecon.cgi?Search_Arg=xml&Search_Code=FT*&CNT=22? Yes, I know it can't cope with complex queries, but playing starts with the simple stuff...)) but I still haven't had half as much fun as I think I could have had!

As someone outside the library (though perhaps a thorn in their side) I'm not sure what info I want, but I know I do want it in an accessible form and I know I do want to play with it. Tinkering with the Google and Yahoo APIs can be lots of fun (what a sad life I lead!) but I can't have that fun with my library catalogue... so I can't easily mash results from library catalogue calls into online teaching material (or even subscribe to searches in my feed reader), and I can't mash library results with Amazon results etc.

It wasn't too long ago that only the librarians were allowed to access online commercial/subscription databases, and researchers would have to go and ask the library guardians to make searches for them. That's changed now - the OU library gives access to staff and students to a wealth of online databases, all under a common authentication scheme. But can I get easy to play with data out of the library catalogue system? What is it with the vendor that they (you?!) feel you have to lock up the information in sometimes quite horrible, often unvalidating, interfaces, rather than providing the info even in impoverished form, and via an imnpoverished keyword only search interface?

Out of interest, how often do average and below average library catalogue users use anything other than a single keyword search?

Tony Hirst
Dept. of ICT, Open University
http://ouseful.open.ac.uk/blog

Two Worlds

RobStyles — Tue, 14 Mar 2006 16:51:38 +0000

I was astonished when I joined Talis 15 months ago at the power of Z39.50. What a fantastic protocol. But you're right, it ain't easy and a million miles away from being mash-up friendly.

There are a good handful of initiatives ongoing to make Z39.50 more accessible. There's SRW/SRU, of which SRU could meet your need for a RESTful service; combined with CQL as the query syntax searching becomes much easier.

There's also OpenUrl which many OPACs support.

The main problem is that there is no clear winner, as my colleague Richard Wallis says:

"Some like OpenSearch are a bit too simplistic, some like SRW/SRU a bit too librariany, and some like OpenURL a bit too specialized"

This problem is at the heart of us straddling two worlds; the structured world of Z39.50, ISO2709 and AACR2 and the less structured folksonomies and standardisation-by-use of the internet.

We're not avoiding the problem though, we're developing some great platform services to help in this area; we've been discussing some of these at our Research Days and others underpin some of our demonstrators (like Whisper) which are designed to show what you'll be able to do for yourself with our platform services in the future.

Watch this space. :-)

Rob Styles
Technical Lead, (some aspects of) Platform

Making Z39.50 friendly

Tony Hirst — Tue, 14 Mar 2006 14:13:05 +0000

One of the things that has stopped me - to date - playing with library catalogues is that it's comparatively hard to get information out of them using everyday web technologies (feeds, http/xml based APIs etc).

I'd certainly start playing more with mashing library systems if there were a few Z39.50 to XML relays around. For example, where's the RSS feeding equivalent of this LoC Z39.50 search over my library catalogue (ideally with a RESTful way of calling the service too)?

This could provide a stop gap until more library systems offer eg opensearch natively.

Also note that the relay need not in the first instance be up to production strength, if the main aim was just to provide people who play with something to experiment with - (just call it beta!)

Or perhaps the catalogue vendors just want to keep hold of the information and the way it's presented?

Tony
Dept. of ICT, Open University
http://ouseful.open.ac.uk/blog

Internet Explorer to replace the OPAC

Paul Miller — Tue, 14 Mar 2006 13:19:37 +0000

When it arrives later this year, the next version of Microsoft's web browser will support A9's OpenSearch protocol by default. With libraries moving to embrace the same protocol, do we need a web interface to our catalogues any more? Read more about Microsoft's next browser, OpenSearch, and ways in which your library can benefit, then share your thoughts.