Author: Ross

The inimitable Art Rhyno and I are working on another project together (W-G?), which consists of several parts:

• Refine Art’s mind-bending idea of providing a WebDav interface to the OPAC
• Provide an OAI provider for Voyager ILSes (Hello? Endeavor?!)
• Try to put a real and legitimate Z39.50 (and SRW/U) server (that supports exact searches, relations, etc.) on the catalog
• Create a new, useful and user-friendly natural language query interface to the catalog.

Art (Mr. Cocoon) is doing the heavy lifting. He’s created a webapp that exports the bib database from Voyager to MODS (and downloads it with wget to a mirror). It is apparently easy (for him, not me) to then transform this output to WebDav.

I only really need the first part (although the second part is very “wow-cool”). We’ll take the exported MODS records, put OCLC’s OAICat upon it for OAI. Then I’ll start building a new interface for the OPAC. The databases stay in synch by wget traversing the cocoon output and checking the timestamps of when a record was modified. Very very neat.

We’re running into few problems, though.

Sometimes there are typos/data entry errors on records.

This raises an interesting conundrum. There is often the notion that the catalog is the “authority” for the library. Indeed, this is usually true, however it is impossible to completely eliminate human error.

When I was developing course/control, I sometimes had a problem with marcxml records not being valid. Almost every single time something was wrong with the MARC record. Of course, cataloging was always happy to fix it, but this shows chinks in our armor. If our metadata is wrong, who will get it right?

That being said, bad data (in this case) isn’t the end of the world. I can live with a margin of error if the interface is even moderately better.

The gcs-pcs list (no idea what it stands for) has been buzzing with activity since Eric Hellman released his “Latent OpenURLs in HTML” page to the world. It’s not that Eric’s idea is bad or wrong (the opposite, actually). It’s just different.

Dan, Jeremy, Richard, Raymond and I have a paper coming out next month in Ariadne and it mainly comes from ideas that were hashed out on the gcs-pcs list. They are not perfect, and we make that point in the paper. In fact, I had mentioned to Dan that we hadn’t brought up the issue of “OpenURL version” at all and that this could be problematic in the future.

Eric’s format, although obviously informed by the ideas on the list, seemed to come largely out of the blue and without external input in the design process. Again, this isn’t necessarily wrong either… I certainly have been known to run with something without asking others for input and then came back with something that may or may not be what the group as a whole expected.

The big difference is that I’m nobody and Eric’s not. If he has people interested in this project, that’s great. That’s what somebodys are good for. And I also like the fact that he’s not willing to wait around for a year to get a spec out (he is shooting for May 1st). I certainly don’t want a NISO or ALA schedule.

Here’s my problem:
OpenURL 1.0 is too freaking complicated to expect people to use.

It’s not that I feel that something must be simplistic in order to be implemented or for people to “get it”, it’s just that there should be varying levels of entry into our collections. For SRW, there’s SRU (still nothing I’m going to teach my mom in a day, but progress from Z39.50, certainly) and that should make it easier to link into our catalogs. If OpenURL seems too difficult for your average web hacker to use, they won’t. And we’ll be left on the sidelines with our little niche technology. Again.

My proposal is to have both formats supported (with the default being version 0.1) much like RSS currently does. State your version in your link and let the resolver work it out. This way, the people who use it can determine the easier way to implement OpenURLs on their site. Let the “market decide”, as it were.

I do not know the membership of gcs-pcs, but Eric is the only link resolver developer that has weighed in. I’m curious how others feel about the 1.0 vs. 0.1 debate.

We’re planning to (soft) launch WAG the Dog next week on the unsuspecting public. I am a little nervous about this. The WAGger is basically a proof-of-concept and a fun staging ground for developing new ideas. While Tech’s user base may be able to roll with the punches of a less-than-stable system, I also don’t want to put a bad taste in their mouths before the really useful features are introduced.

The WAG the Dog is basically two parts: the WAGger which parses the page you are looking at to see if there are things on there that could be localized (links that can be proxied, ISSNs, DOIs, etc.) and the (hopefully) soon-to-be-introduced “WAGnet” which takes what you’re looking at and tries to find other useful and relevant items in the collection and present them to you. Currently, it takes the LCSH of whatever you’re looking at (assuming there’s anything to work with) and finds other electronic resources in the same subject heading, presents them, checks to see if they appear in a database, present it, etc.

Next week I hope to also have some sort of folksonomic linkage, as well, so if any of the resources appear, say, in del.icio.us or unalog, get the tags from there, and use those tags on sites like Connotea or CiteULike. The only problem here is that I have no idea if people are socially bookmarking homepages of scholarly content. I guess I’ll find out.

Still, it will be interesting to see if the public finds WAG the Dog useful.

Well, let’s get this thing up. You’ve got to start somewhere, and just because I don’t really have anything to say… well, that’s never stopped me from speaking up before.