Outgoing

AJAX and Web interfaces

Thanks to Google, there has been a lot of interest lately in slick ways of doing interfaces on the Web.  Jesse James Garrett at Adaptive Path has given the technique a name, AJAX which stands for 'Asynchronous JavaScript and XML'.  It's always nice to have a name to make it easier to talk about something, and AJAX is a pretty good one.

Since we saw Google Suggest, Google Maps and GMail we've done some experiments too.  One of the things was to take all the controlled headings from WorldCat and do a suggest-like service.  Works pretty well, and it might be something we'll pursue later.

Lately, though, I've been applying AJAX to a Dewey browser.  This was inspired by the OCLC Research Software Contest.  Two of the things we have available are all the records with 'Ohio' in them from WorldCat and the DDC Summaries.  So I tried my hand at YADB (yet-another-DDC-browser).  There are a lot of them out on the web, but I had the idea of using the Rocks/Ganglia visualization   approach to help guide browsing.  For various reasons we ended up moving away from the 10x10 display to successive rows of 10, and in the process have gone through a half-dozen different approaches.  We think we've got one now that's going to work, though.

If you try to go through any of Google's interface code (in some ways this is easy in that since most of it runs in your browser and you have access to all the JavaScript that's doing the magic) you'll quickly realize that much of what they are doing isn't all that straight-forward, especially in the details.  Google tends to use XMLHTTPRequest which allows JavaScript to get data (not necessarily XML) from an HTTP server.  Google either downloads JavaScript structures which are turned into HTML by more JavaScript, or XML on which XSLT stylesheets are applied.  Making all this work across browsers gets complicated.

Another technique you'll see used is to load data into HTML iframes.  The nice thing about doing this is that the browser's history gets updated (so the back button works), and if you're loading XML with an associated XSLT file, that XSLT transformation happens automatically.

So what we are doing for the DDC Browser interface is to do all the HTML generation in the browser using XSLT on XML returned by the server.  The main page has four iframes, three for three levels of the DDC and a fourth for record display.  There is less than a page of JavaScript that keeps track of things and pokes the 'location' attribute of those iframes to display data.

This technique has gotten rid of virtually all the fancy JavaScript while still updating sections of the screen without reloading the whole page.  For a graphical browser (e.g Google Maps or the DDC Browser) not flashing the whole screen seems critical in making the system enjoyable to use.

The real trick to the system, though, is what happens in the server.  We've gone through several iterations there before we found a simple scalable solution.  Overall, the lines of code involved in the system is probably a third of where we started.  More on what I think of as our 3-level server side architecture in another post.

Thanks to Diane Vizine-Goetz (our DDC expert here in OR) for all her help with the browser.  In addition to browsing a collection of records, Diane thought of loading the DDC schedules themselves and using it for classification.  A sample of the Abridged DDC is show in the screen shot above.  Another aspect of interface design is making the whole thing pretty, simple, and functional, all at the same time.  Lance Osborne did most of the design work.

--Th

SRW: Compatibility vs. Compliance

The OpenSearch protocol developed as part of Amazon’s A9 has been pretty much dismissed by the SRW community as just being too limited to be of interest.  The idea of SRW was to make the functionality of Z39.50 available in a web-friendly manner.  Evidently A9 didn’t think it was quite friendly enough, and has come out with a simpler protocol, quite cleverly built on top of RSS, for easy access via news readers.

To me, however, OpenSearch looks like it might be very appealing to something like the NISO Metasearch Initiative, which just had a meeting in Chapel Hill.  OpenSearch has the feeling of the sort of thing where 'simple wins' and those with more complex technologies ignore it at their peril.

Is there a middle ground here?  Something that is compatible with SRU, but closer to A9?  Our Metasearch representative, Ralph LeVan thinks so and has offered to develop guidelines to make this happen.  The catch is that what is being proposed, while compatible with SRU, is not SRU compliant.  According to Ralph, there is some reluctance on the part of those developing SRW to embrace anything less than full compliance, but we argue that not only would the proposed simplification of SRU be a step forward from the screen-scraping that Metasearchers engage in, it is a step in the right direction, in that extending the services to full SRW compliance wouldn’t break anything.

Here are two from the A9 search query page:

>http://www.koders.com/?s={searchTerms}&p={startPage}&output=rss

>http://beta.indeed.com/opensearch?q={searchTerms}&start={startIndex}&limit={count}

To me those two examples look incompatible, but maybe the '?s' in the first should have been '?q'.

Here's an SRU search:

>http://alcme.oclc.org/srw/search/ORPublications?query=”levan”&recordPosition=1&maximumRecords=10

The SRU example looks simple enough, although it won’t come back as RSS automatically.

So what’s not compliant about the proposal?  No explain record is required and neither is support for even simple CQL (the Common Query Language that SRW/SRU queries are expressed in).

I’ve argued in the past (with only moderate success) that if you are doing something that is similar to an OpenURL request you really should put it in the OpenURL syntax, even if you aren’t bringing up a full OpenURL server.  It gives you a natural path for future development, avoids incompatibilities and you don’t have to spend time developing yet-another funky syntax.

--Th

Mumbai

I recently attended a digital library conference in Mumbai (formerly Bombay) India (http://www.icim2005.org/).  I gave a tutorial, mostly about FRBR, that didn't elicit much response at the time, although a former IFLA Fellow emailed me later saying she was inspired to start some FRBR research because of the talk.  I also gave a plenary talk which seemed to resonate with the audience, although I shared the time with a man who actually controls some federal money (and has firm ideas on how it should be spent), which is always strong competition.

The main theme of the plenary talk was the progression of digitization from the data itself, to metadata, reference works, journals, and now books.  A librarian told me a story that put this in some perspective:  When she attended library school in 1990 they were taught about Medline and other online search services.  I assume with little or no actual use of the services themselves (it reminded me of being in library school in the US in 1970 trying to learn and program in COBOL with no access to a computer!).    At the time she thought how useless it was -- she was sure there was no way she would ever be able to afford such services.   Now, online searching is what she does all day as a librarian.  In fact, with projects such as the Million Book Project, it can be expected that a lot of the digitization of books will be in India.

The progressive digitization of materials has had a large impact on scholarly communication in the developed world as it becomes easier and faster to get information.  It must be having even more impact on the less developed world as, in only a decade, they go from only very limited access to information to access that approaches ours.

Of course what people really want to do is talk to each other.  One of the delegates told the story of seeing a manual laborer working outside his home pause from his landscaping job, reach into his pocket and pull out a cell phone.  Here is someone, probably working for $2/day, that finds it possible to have a cell phone!  In fact, cell phones (and their use) were in constant use during the conference.  In the past I've found it annoying when a cell phone rings during a talk, but once you've heard twenty of them ring during one talk, it just becomes accepted.

--Th

4

Four.  That's how many newspapers were outside my door this morning.

When I was growing up we used to have our milk delivered.  I'm sure there were several reasons for this: a hold-over from when refrigeration wasn't as good and a lack of second cars to lug the milk around being the main ones.  Over the years 'milkmen' have just about disappeared -- the last one delivering in our neighborhood retired a couple of years ago and no one replaced him.  I would have predicted that fewer people would be visiting houses each day not more, but that doesn't seem to be the case.

I only paid cash for one of those papers.  The others are either free, a 3-month trial, or from frequent-flyer miles (use them or lose them, and I never seem to accumulate enough to use them for free flights).  But yesterday was trash day:  three different trucks went by our house picking up the main trash, recycling, and lawn debris.  Not to mention the possibility of another one I didn't use for large items.  Over the course of a week I calculate:

• 6 mail deliveries
• 3+ trash pickups
• 23 different newspapers and flyers

That's just for our house.  I know there at least a couple of daily papers we don't get, not to mention all the dry-cleaner deliveries, solicitations, school buses, FedEx, UPS, etc.  There are literally hundreds of commercial cars and trucks in our neighborhood every week!

So, what does this mean to libraries?  I have to admit it wasn't as obvious to me as it was to Stu Weibel.  This is the last mile problem: getting physical objects to people.  Although libraries are more and more about digital objects, the local library business will continue to have a physical presence for a long time to come.  Lorcan Dempsey likes to talk about library logistics.  Academic libraries do pretty well at getting items to users via campus mail.  Publics have a ways to go.  And interlibrary loan should be easier for everyone.

--Th

Getting started

With apologies to Tim Bray, I've named this blog Outgoing.  For twenty years my bosses have suggested I publish more.  Maybe the more informal medium of a blog will be what I need to do that.

I expect to write about some of the projects we have going in OCLC Research, the techniques we use, and the occasional post about some trend that looks important to libraries.

--Th