Library Metasearching and Digital Collections
July 13, 2005 | Leave a Comment
Last week I attended two vendor demos in response to a University System of NH RFP. The two vendors were exLibris and Endeavor. In short, USNH is looking for two things: a solution for managing digital collections at the various schools in the university system and a utility for doing metasearching to give one-stop access to the various resources in the library’s many digital collections. Now I am not a librarian, nor all that familiar with library technology or processes. I was participating here purely from a technology standpoint, so in turn, anything I state here is from that angle.
One of our biggest needs is the ability to integrate the products with our existing university portal, SunGardSCT Luminis. By integration we really have three distinct pieces to this: Single Sign On (SSO), look and feel customization, and data exchange. From my perspective, those are listed in order of descending importance. I also care about APIs so the product can be extended and reused in ways the original company did not imagine. Last but not least, I care about usability. If untrained users cannot pick up the product and feel successful using it, they won’t.
Endeavor
The first vendor was Endeavor. Their two products are ENCompass and LinkFinderPlus.
LinkFinderPlus has great ability to allow for interface customization due to its use of XSLT. Basically you change the XSLT and you can make the interface look and act however you want. There is currently no built-in way to support SSO, but they believe it would not be difficult to build an extension. Additionally, they intend on supporting Shibboleth within the year. Depending on how they implement Shib, it could be good or bad… LinkFinderPlus doesn’t have any data per se, so data exchange is not necessary.
They do have APIs, sort of. Basically, if you don’t apply an XSLT, then you have straight XML and can interpret it like you would REST. As far as I’m concerned this is a great solution, even if it does seem like a “happy coincidence” feature.
ENCompass does have data, but no clear way to exchange it cleanly, not that I can imagine a need for this. The web interface again is XSLT customizable. The “archivers” interface is client side, which seems to work out quite nicely. I thought I’d be opposed to this, but recently my use of utilities like ecto and the Gallery plugins has me thinking differently. It does not yet support JPEG 2000, which is really important for archiving things like maps or murals which need to exist in extremely high resolutions to be able to see any of the useful details. It is also passing of the responsibility of all role and user identification to a directory or your ILS. This is a great step in the realm of identity management.
As a final note on Endeavor, all their products claim to be usability tested in their entirety. The interfaces are simple, could use a bit of work, but are adequate.
Final Grades:
Portal Integration: D
APIs: B
Usability: B
exLibris
My main impression of exLibris is that there are more bells and whistles. They seem to be a technology centered company and like most, suffer a bit from feature creep. Many of their interfaces have a lot of options that could leave users wondering what they are doing and feeling lost. Their two products are called MetaLib (with SFX) and DigiTool.
MetaLib (with SFX) is where the bells and whistles are really obvious. There are varying degrees of increased complexity in the interface depending on how deep you go. This is great for the librarians, but unlikely that students would use it. In fact Casey at MaisonBisson, also in attendance with me, states that “only 0.0067% (YES, less than a hundredth of a percent!) of the searches on our OPAC get “limitedâ€? to specific languages, locations, dates, or material types” in his article The High Cost Of Metasearch For Libraries. The interface seems to be minimally customizable, limited to headers, footers, and CSSS. However, there are “real” APIs for MetaLib, a separate product they call XServer. It is well documented and seems to be just the right amount of useful, but more cumbersome than a mere REST-like interface.
As for SSO, they currently support Shib, but it is unclear if that is as a destination or origin. On a much more degrading note, they had never heard of SunGardSCT Luminis or UPortal, so their knowledge of the portal space, specifically in higher-ed is limited at best.
DigiTool is purely web based and looks and functions adequately. Once again customization is limited. They do have JPEG 2000 support though, so thats a big plus. They claim to authenticate against an LDAP, but other than that, the identity management opportunities are limited at best. Usability seems low all around on these applications.
Final Grades:
Portal Integration: C
APIs: B
Usability: D
From the grades I gave, none of these are ideal. Read Casey’s assessment for more detail about where the metasearching falls down. I just wish the could make it more like Google Scholar or A9. My major question is how do these digital archives provide a solution better than DSpace? Check out the many existing, live, DSpace instances. DSpace is free and in turn has not got an equal seat at the table. It is scary how money often corrupts decisions like this.
Tags: a9, api, digital archive, endeavor, exlibris, google scholar, identity management, integration, jpeg2000, libraries, library, library systems, metasearch, metasearching, portal, REST, search technology, shibboleth, shibbolith, usability
JPEG 2000, first attempt
July 11, 2005 | 7 Comments
I recently learned a bit about a “new” technology called JPEG 2000 (.JP2 or .J2C). I’m a little unsure how this missed me for so long, but oh well.
In a nutshell, JPEG 2000 is a way to store multi-resolution images which can be delivered in a streaming fashion at the desired resolution. It also sports greater compression rates than JPEG, with far less quality loss. It does this using what is called “wavelet technology.” Strange buzzword, I kinda hope it doesn’t catch on…
Anyway, from a practical standpoint, I poked my head into Adobe PhotoShop CS and JPEG 2000 is not listed as a file type I can save as. However, poking around a bit, I found a product by LuraTech called LuraWave which provides a PhotoShop plugin, but alas it only runs in OS9, which I don’t have. I then found Lead Technologies offering a free plugin, but it is PC only… I then decided to step away from PhotoShop and try out Graphic Converter. It’s supposed to convert everything, right? Well, it does, all built-in and functional in the demo.
So now I have one created. The next step is figuring out how to get it embedded in a web page. Luckily a google search turned up this how-to guide. Which implies that all you need to do is use an embed tag. This proves to be an oversimplification, and most likely only compatible with IE.
This is an immature technology, which currently only appears to have support in the PC/IE area. I’m going to try some more tests with this at work on my PC and I’ll post again if I have luck in that area. As a side note, JPEG has been around for 15 years, so I guess it is time for something new here…
More Info:
http://www.jpeg2000info.com
LuraTech: LuraWave - JPEG 2000 implementation
Pegasus Imaging: Compression
Aware: Compression Software
Whitestone CommunitY: JPEG 2000
Tags: adobe, browsers, compression, graphics, image, imaging, jpeg, jpeg 2000, jpeg2000, photoshop, plugins, technology