Dilettante's Ball

Moving this party elsewhere

2006-01-17T14:15:00.000-05:00

Although I've never actually had too much of a problem with Blogger (except for a hideous spam invasion during Access 2005), I've decided to move this soapbox over to WordPress on the Code4lib server.

So, from now on, I'll be at http://dilettantes.code4lib.org/.

All (none) of you that read this, take note.

Time to start polishing off my helmet for the playoff run

2005-12-25T13:48:00.000-05:00

No, that's not a euphemism for anything.

Pittsburgh's dominance in the first quarter was so complete that it produced some almost unbelievable stats. In the opening period, the Steelers outgained the Browns 196-1; had 162 passing yards to minus-2 for Cleveland; and led in first downs 9-0.

(from espn.com)

Bring it on, y'all.

To Free or not to Free?

2005-12-24T15:35:00.000-05:00

Last week I was reading Dorothea Salo's posting about OCLC's report on library branding, and it got me to thinking about this a bit.

In particular, I thought about her comment:

I would want to trial-balloon a Deep Web play in my next survey, if I were OCLC. I would want to know how many people have heard of the Deep Web, what they think is in it, whether they think information useful to them is in it, whether they would access it through their libraries if they could. This moves away from free-vs.-paid and toward exclusive-vs.-nonexclusive. People like the idea of being privileged. If the library is a place that privileges them, I think theyÂll go for it. Special-collections and archives get a boost in this campaign, too; access to rare or unique information is the ultimate in privilege.

I see a tension here. While many push for an "information wants to be free" model, this would, inherently, devalue the role of the organization that makes it free. In fact, to take her quote even farther, this is especially true of special collections and archives.

Allow me to explain.

Users aren't particularly discriminatory as to where they get their information. Our students or faculty don't really care if the article or research they are looking at comes to them courtesy of Georgia Tech or if it was found in Citeseer. They are more likely to say they found something in "Google Scholar" vs. the actual institutional repository for the school they are actually getting it from. The more open the information is, the less exclusive our collection becomes and the less leverage and value we hold (at least conforming to our traditional model).

With special collections, this is especially true. Special collections are "special" because they are "unique". Libraries spend a lot of money curating these collections. Historically, this has enjoyed a fairly good ROI because it distinguishes the library (and therefore, larger institution) as something "special" itself. These materials are exclusive to that particular institution and give value to the collection.

However, there is pressure to digitize and publish these collections. If all of these collections are digitized and published, we have a bunch of silos strewn about the internet requiring the user know about find them to use them. Since it is a lot of work to digitize and mark up these collections, there's not a terribly good return for the effort.

In an effort to improve findability, the collections need to be aggregated with other similar collections to increase their exposure. However, the result of this is improved awareness and accessibility, but at the same time it dilutes exclusiveness and branding. Whoever provides the aggregation/discovery service gets the benefit of the content, so some of the content providers (inherently) must lose.

So, what does this mean? It should not prevent us from making our collections more open and accessible. That runs counter to our mission. However, we need to start thinking of ways to generate value when our information is free. There are plenty of ways of doing that, such as tailoring services that aggregates the "free" information for our communities, or building systems that can use the information in unique and specialized ways.

There is a large cultural shift that needs to take place to realize this future, however. We still place a lot of emphasis (way too much, really) on the size and uniqueness of our collections. With a world of information available (or a lot of it, at any rate), it's not so much an issue of how many books you have in your building, but how you are able harness all the good data and present it in useful and meaningful ways. There aren't easy metrics to this. ARL just can't count book spines and annual budget. Serious consideration needs to be paid to what and how a library is utilizing the collection outside their walls.

Rails Resolver Router: on Rails!

2005-12-21T17:56:00.000-05:00

Since my foray into python a couple of months ago, I've been enjoying branching out into new languages.

I had pitched the concept of a link resolver router for the state universal catalog to a committee I sit on (this group talks about SFX links in the 856 tag and whatnot). The problem with making links for a publicly available resource point to your institutional resolver is just that. It's pointing your your institutional resolver, despite the fact that your audience could be coming from anywhere. This plays out even greater in a venue such as a universal catalog, since there's not really a "home institution" to point a resolver link, anyway. OCLC and UKOLN both have resolver routers, and OCLC's certainly is an option, but I don't feel comfortable with the possibility that all of our member institutions might have to pay for the service (in the future). My other problem with OCLC's service is that you can only belong to one institution and I have never liked that (especially as more and more institutions have link resolvers).

So, in this committee I mentioned that it would be pretty simple to make a router, and since I was having trouble getting people to understand what exactly I was talking about, I decided to make a proof-of-concept. And, since I was making a proof-of-concept, I thought it'd be fun to try it in Ruby on Rails.

Now, a resolver router is about the simplest concept possible. It doesn't really do anything but take requests and pass them off to the appropriate resolver. It's a resolver abstraction layer, if you will. I thought this was a nice, small project to try to cut my Ruby teeth on. There's a little bit a database, a little bit of AJAX. It's also useful, unlike making a cookbook from a tutorial or something.

It took about three days to make this. After you pick your resolver (Choose a couple! Add your own!), you'll be taken to a page to choose between your various communities for appropriate copy.

I chose this particular citation because it shows the very huge limitation of link resolvers (if you choose Georgia Tech's resolver and Emory's resolver, for instance); despite the fact that this is freely available, it does not appear in my resolver. That's not really the use case I envision, though. I am thinking more of a case like my co-worker, Heather, who should have access to Georgia Tech's collection, Florida State's resources (she's in grad school there), Richland County Public Library (she lives in Columbia, SC), and the University of South Carolina (where her husband is a librarian). The resolver router alleviates the need to search for a given citation in the various communities (indeed to even have to think of or know where to look within those communities).

Sometime later this winter, I'll have an even better use case. I'll keep that under wraps for now.

Now, my impression of Ruby on Rails... For a project like this, it is absolutely amazing. I cannot believe I was able to learn the language from scratch and implement something that works (with this amount of functionality) in such a short amount of time. By bypassing the need to create the "framework" for the application, you can just dive into implementation.

In fact, I think my time to implementation would have been even faster if the number of resources/tutorials out there didn't suck out loud. Most references point to these tutorials to get you started, but they really aren't terribly helpful. They explain nothing about why they are doing what they are doing in them. I found this blog posting to be infinitely more useful. Her blog in general is going in my aggregator, I think.

When it comes to learning Ruby, this is a masterful work of art... but... not terribly useful if you just want to look things up. I recommend this for that.

Anyway, I am so impressed with Ruby on Rails that I am planning on using it (currently) for "alternative opac project", which is now being code named "Communicat". More on this shortly (although I did actually develop the database schema today).

Back to the whiteboard for inspiration

2005-12-01T09:19:00.000-05:00

Paul Miller (of Talis) was kind enough point out that Talis already has a product named Alto.

In fact, it's their ILS.

D'oh.

Given that Talis' corporate name is "composer-based" (and, I don't know, that they came up with the name waaaaaaaaaaaaaaaaaaaay before I did) I suppose I can relinquish the name "Alto" :)

So, uh, any suggestions for an appropriate name... send 'em to me!

Envisioning Alto

2005-11-30T12:09:00.000-05:00

I have mentioned here several times the "alternative to the catalog" project I am trying to implement at Tech. One of the problems that I've had is naming the project something that lets people realize what I'm talking about, without the political hairiness of saying "catalog replacement" (since that's technically not true, anyway).

In a meeting two weeks ago (about subject guides), I was drawing the concept of this project on the whiteboard of our conference room. It's been up ever since and in the middle, I had written "ALTOpac" because that was an easy way to loosely describe it in a way that the uninitiated in the room could envision where I was starting from. Sitting in another meeting today, the capitalized letters jumped out at me: ALTO. It means nothing.

And I like that. Of course it still doesn't explain what it's about. That's what subtitles are for.

Now, let me explain what the hell Alto is and what it is supposed to do.

Alto is a "community-based collection builder and search engine".

Come to think of it, that might not actually clear anything up.

Let's back up a bit, shall we?

To say searching the catalog is "searching our collection" is quite arbitrary and false. Metasearch doesn't really solve this problem, since you'd still only point the metasearch engine at certain assets and it's non-trivial to make relationships between assets. Metasearch is part of the solution, but hardly the panacea.

Again, our "collection" is an ambiguous term and shouldn't be solely determined by our collection development policies/budget. It is our opinion that if something is important enough to be added to a reserves list (even a web page), it should technically be part of our collection. I would not, however, say it should be cataloged (and that's why this isn't a catalog replacement project, see?). If an item is even bookmarked (via a local social bookmarking service, such as unalog or connotea) it should then become part of our collection. A 1927 engineering textbook from Purdue's catalog? Index it! If a member of our community finds it important enough to want to come back to and share with a group, it's important enough for us to aggregate into our "collection". Relevance comes later (keep reading, if you're interested).

There are also relationships that our community (for the sake of argument, let's start with "Georgia Tech") builds that are highly relevant for finding connections between disparate "things". So, the items put on reserve for a particular course have an umbrella of commonality between them that should be utilized for anyone that runs across any of these items. The relevance ranking should be even greater for a user that happens to be a member of the group in question (for instance, is enrolled in the class).

If Alto has a citation management-esque feature in it, users can very specifically group relevant resources together based on a project. Resources can be anything: books, websites, articles, searches, chat transcripts, trails, you name it.

And all of this should feed the "relevance beast", as it were.

So that's some background. Given that we'll have some formal subject classifications for these objects (from the OPAC or from metasearch or whatever), we should be able to bridge the formal to folksonomy to make sense of how people have classified their saved things.

We can then begin to cluster search results. Format, subject, concept, group, policies... All of these can be browsed after the search begins. The search results will be a combination of metadata objects and library content. If some of the results appear in a given "subject guide", the guide will a suggested resource (and will, in turn, push some resources into the result set).

The goal is to open the silos we have created around our resources/services. It would break down the ambiguity between "collections", "services" and "policies" since they're all interrelated.

How do we plan to do this? Glad you asked (you're still reading, right?)!

We've exported all of the bib records from our catalog. The plan is to use METS as our wrapper around MODS. We'll then harvest our institutional repository and index our website. That's a pretty good base to start with. All of this is stored in a dbXML database and indexed with Lucene.

If users want to harvest a collection from citeseer or OAIster, that will be available and will become part of our collection. Annotations, links to reviews, links to content to index will all be made available.

I'm leaving a lot out and glossing some of this over... but it starts to put the idea on "paper" for me to come back later.

I sound my barbaric YAWP over the walls of my cubicle.

2005-11-30T09:44:00.000-05:00

I woke up at 4:30 this morning.

One could easily write this off to a variety of stresses: an article I have no business writing; a conference I have no business helping organize; a huge project that I am having problems getting started on; a house that I apparently haven't sunk enough money in to move into yet; a house that I can't drag far enough away from the railroad tracks to sell; the usual burden that is "the holidays"... sure one could try to pin it on any of those.

But I woke up thinking about (meaning that I was dreaming about) something I read recently from Richard Wallis on Panlibus, Talis' 'blog:

Well yes, the current generation of ILS systems were not built with Web Services everywhere. To put it bluntly, who will pay the salaries of the developers who are going to develop these services for you to consume?

Strange thing to dream about, I know. However, when I think about this one quote, it pisses me off to no end. The University System of Georgia pays Endeavor over $500,000 a year for the privilege of running an ILS that they haven't invested any innovation in years. Granted, we are 35 libraries, so it's not like we're all paying that ransom, but, on the flip side, we're probably also getting a discount for the very fact that we are so large.

Then, to think we are but a percentage of Endeavor's total customer base...

WHERE IS THAT MONEY GOING, RICHARD?

Of course, I realize that Talis is in no way related to Endeavor, but I cannot imagine their pricing is so radically different that their coffers have no shillings to pay for developers.

Besides, they must already have developers, right? Maybe you need hire developers with vision.

So, to this argument, I call bullshit.

The other thing that struck me (again, apparently in my dream) is the apologetic tone I see quite frequently (recent example here, lots of others floating about) that shifts the blame of our stagnant, crappy Integrated Library Systems to us, the customers instead to our vendors. The argument goes that we, the libraries, have asked for the wrong things for the ILS and the poor vendors (poor, poor vendors) had their hands tied, literally tied, trying to keep up with our demands to be able to incorporate any sort of innovation in the last 15-20 years. Besides, they'd say, if they came up with something different, libraries might not want the change.

What (successful) technology company has ever relied on RFPs for their innovation? Are Google's hands tied until some customer says, "Hey, can you make a web based 'maps' site? You know what we need? A new way to do threaded email."? How about Intel? Microsoft?

No. These companies realize that they need to innovate to survive. To stagnate or half-ass is the kiss of death. See Novell. For a more dramatic example, see Apple.

No, it's time we stop taking it like abused spouses from our vendors. You know, maybe we did overcook the porkchop and maybe we do open our mouths too much, but that's no reason to have a black eye. If a handful of the better funded libraries were to help found something like the Apache Foundation for library software, our abusive husbands might find treat as partners rather than punching bags. I think I might know a good place to look for talent.

(In truth, our rottweiler woke me up, but the dream still stands).

Library 1.7.02-4 pre 6

2005-11-20T11:08:00.000-05:00

I really, really hate this Library 2.0 meme for a couple of reasons.

1) All of our problems will not, in fact, be solved with AJAX and web interfaces

2) In fact many of our problems cannot be solved by technology at all (try doing interesting and meaningful and different work with the current body of MARC records out there and see what I mean)

3) This quest for 2.0 would be better served if "2.0" was a milestone on the journey to "Library 4.5" -- I mean, come on folks, let's get back into innovating.

4) I think it trivializes some actually exciting and useful work that I fear will continue to fly under the radar because it's not "Web 2.0" enough.

Maybe hype is necessary to rally the troops, but I really wish vision would get more attention.

echo(strtolower(COinS));

2005-10-27T21:17:00.000-04:00

Er, anybody object to making COinS all lowercase?

Because I'm starting to think its case structure is awkward and silly.

As much as I liked gravy on my french fries...

2005-10-21T12:15:00.000-04:00

Current weather conditions: 76 degrees and sunny.

Reactions from Access 2005

2005-10-19T19:43:00.000-04:00

I'll have to keep this rather short, since the hotel wireless network is being flaky (as usual) (in fact I am having to write this while standing in the bathroom -- oddly the best wireless reception in my room).

Again, the conference organizers have proven why this is the only professional event I schedule in my year. I'll comment on the earlier days a little later, but while day 3 is still rather fresh in my mind (as fresh as my poor, oversaturated mind can be), I'd like to touch on a few things.

1) Listen to every word Lorcan says, always. It blows my mind what an amazing asset he is to our community and how there are people (in my library) who have no idea who he is. His presentation this morning has completely energized me to kick it up a notch in getting our library more into our (and other) user's "LifeFlow".

2) Art and Peter proved that WAG needs no "G". I've been working with Art on this WebDav/OPAC project for months (thanks to SUDOC, as he pointed out), and I never, ever would have dreamed of the things these two are coming up with. Cocoon is, evidentally, a very magical beast and the potential of storing these "trails" could have huge implications on the collaborative research environment that we are trying to create at Georgia Tech. Being able to chart the path of scholarship would make it easier to get to the giant to stand upon his shoulders.

3) Internet communication is lousy when trying to develop a new spec. Despite being there at the beginning (and being a very loud proponent of COinS), I could not wrap my head around the use cases for COinS-PMH. Oh, Dan tried to "learn me", but it really took his presentation today to "get it". I definitely "get it" now, and expect to see COinS-PMH all over Tech.

4) Hackfest is the greatest invention ever. And I honestly couldn't imagine it working properly at any other conference (sorry, LITA).

5) This is why I'm applying to enroll in the Master's program for Human-Computer Interaction at Tech. This, coupled with the previous two presentations (Art/Peter's, Dan's)... Holy crap. The world would be so different.

6) The U.S. is screwed. We have sold our souls, culture and future to corporate interests and I'm not sure how we can fix it. As Peter remarked to me, hopefully Cliff Lynch's vision of a world where everything is digitized except the intellectual output after 1920 will light a fire under us. I fear at that point it may be too late, however. It looks like Canada's future might be a bit brighter. Even if it isn't, I'll get fired up by the revolutionary rhetoric, any day.

Wow, I love this place.

But, you see, my wheel is nothing like all of those other seemingly identical wheels

2005-10-05T20:39:00.000-04:00

I am still feeling my way around Python. I have yet to grasp the zen of being Pythonic, but I am at least coming to grips with real object orientation (as opposed to the named hashes of PHP) and am actually taking the leap into error handling, which, if you have dealt with any of the myriad bugs in any of my other projects, you'd know has been a bit of a foreign concept to me.

Python project #2 is known as RepoMan (thanks to Ed Summers for the name). It attempts to solve a problem that not one but two other opensource projects already have solved admirably (I'll go into more about this in a bit). RepoMan is an OAI Repository indexer that makes said repository available via SRU. I created it in an attempt to make our DSpace implementation searchable from remote applications (namely, the site search and the upcoming alternative opac). It's an extremely simple two script project that has only taken a week to get running largely due to the existence of two similar and available python scripts that I could modify for my own use. It's also due to the help of Ed Summers and Aaron Lav.

The harvester is, basically, Thom Hickey's one page OAI harvester with some minor modification. I have added error handling (the two lines I added to compensate for malformed xml must have been over the "one page limit") and instead of outputting to a text file, it shoves the records in a Lucene index (thanks to PyLucene). This part still needs some work (I'm not sure what it would do with an "updated" record, for example), but it makes a nice index of the Dublin Core fields, plus a field for the whole record, for "default" searches. This was a good exercise for me to work with xml, Python and Lucene, because I was having some trouble when trying to index the MODS records for the alternative opac.

The SRU server is, basically, Dan Chudnov's SRU implementation for unalog. It needed to be de-Quixotefied and is, in fact, much more robust than Dan's original (of course, unalog's implementation doesn't need to be as "robust", since the metadata is much more uniform), but certainly having a working model to modify made this go much, much faster. The nice part is that there might be some stuff in there that Dan might want to put back into unalog.

So, here is the result. The operations currently supported are explain and searchRetrieve and majority of CQL relations are unsupported, but it does most of the queries I need it to do and, most importantly, it's less than a week old.

So the burning question here is: why on earth would I waste time developing this when OCKHAM's Harvest-to-Query is out there, and, even more specifically, OCLC's SRW/U implementation for DSpace is available? Further, I knew full well that these projects existed before I started.

Lemme tell ya.

Harvest-to-Query looked very promising. I began down this road, but stopped about halfway down the installation document. Granted, anything that uses Perl, TCL and PHP has to be, well, something... After all, those were the first three languages I learned (and in the same order!). Adding in IndexData's Zebra seemed logical as well since it has a built-in Z39.50 server. Still, this didn't exactly solve my problem. I'd have to install yazproxy, as well, in order to achieve my SRU requirement. Requiring Perl, TCL, PHP, Zebra and yazproxy is a bit much to maintain for this project. Too many dependencies and I am too easily distracted.

OCLC's SRW/U seemed so obvious. It seemed easy. It seemed perfect. Except our DSpace admin couldn't get it to work. Oh, I inquired. I nagged. I pestered. That still didn't make it work. I have very limited permissions on the machine that DSpace runs on (and no permissions for Tomcat), so there was little I could do to help. This also solved a specific purpose, but didn't necessarily address any other OAI providers that we might have.

So, enter RepoMan. Another wheel that closely resembles all the other wheels out there, but possibly with minor cosmetic changes. Let a thousand wheels be invented.

Happy Birthday, you anemic ghoul!

2005-09-22T17:47:00.000-04:00

I heard on NPR this morning that today is Nick Cave's birthday.

You can tell from my listening habits that I listen to a lot of Nick Cave, but I had never really thought about him having things like birthdays and whatnot.

He's 48. He doesn't look a day over 375, though.

So, have a smoke, drink some red wine and lament your wretched existence to your unforgiving maker in celebration.

The NISO Riots of Ought-Five

2005-09-20T16:39:00.000-04:00

I am at the NISO OpenURL/Metasearch Workshop, and in almost every way it's going well. I don't have a whole lot to say about the workshop content itself. It's very informative and helpful, but I've really got nothing of value to add or comment upon.

Except one thing.

Today was "Metasearch" day and just after lunch was a panel presentation of David Lindahl and Jeff Suszczynski of the University of Rochester Libraries and David Walker of Cal State San Marcos Library on "Innovative uses of Metasearch". And these are two inspirations in the field of metasearch development. Anyone with a metasearch engine (and, sadly, I am not one), please look at these schools' work in regards to how they are leveraging their metasearch implementations.

Both of them spoke at some length about what sorts of incredible engineering feats that they had to accomplish to overcome the shit environment that we have found ourselves electronically. During the Q&A session, Peter Noerr, of MuseGlobal (a vendor), basically admonished these three visionaries because vendors are creating tools to do all of the work that they are doing.

Are you kidding me? They are doing the things that they are doing despite the fact that vendors make it damn near impossible for us to easily provide these services.

There was a very thick tension that set upon the room at this point. You could almost sense that the librarians, finally driven to the edge by their corporate masters, were ready to rise up, break the chains and slay the dragon that torments them so.

Almost.

But then, we're librarians.

And the tension passed.

And then we had a nice break. No chairs were thrown. No blood was let.

Oh well, maybe next time.

Metasearch Metadata Metaphor

2005-09-15T21:09:00.000-04:00

SRW/U is to Yngwie J. Malmsteen as OpenSearch is to Keith Richards.

Yngwie Malmsteen is technically superior, however aesthetically unlistenable (unimplementable, in the case of SRW/U).

Keith Richards is sloppy, unsophisticated and writes timeless melodies that resonate with the masses (OpenSearch is sloppy, unsophisticated -- while time will tell if OpenSearch becomes "timeless" [seems doubtful, honestly], but there are certainly a lot of OpenSearch targets).

Mike Taylor wrote a very insightful reaction to Dan's worklog posting (and incredibly objective, given his investment and relationship to SRW/U). And he's right.

And I'm right. Unless SRW/U can capture some of the mojo that OpenSearch has, it might as well be Yngwie J. Malmsteen.

Implementing COinS in the SFX Menu

2005-09-07T15:59:00.000-04:00

Since Andrew asked:

This should go in your banner.tmpl file. I am not bothering with BANNER_TYPE_3, since I am not really sure how I would represent that in a COinS format, anyway.

Thanks to David Walker for showing me how this would work.


<TMPL_IF BANNER_TYPE_1>
    <TMPL_IF ATITLE>
        <TR valign="top">
            <TD class="LabelBold">Title:</TD>
            <TD class="Label"><TMPL_VAR NAME="ATITLE" ESCAPE='HTML'>            
            </TD>
        </TR>
    </TMPL_IF>
    <TR valign="top">
        <TD class="LabelBold">Source:</TD>
        <TD class="Label">
            <TMPL_IF BTITLE>
                <TMPL_VAR NAME="BTITLE" ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF ISBN>
                [<TMPL_VAR NAME="ISBN" ESCAPE='HTML'>]
            </TMPL_IF>
            <TMPL_IF AULAST>
                <TMPL_VAR NAME="AULAST" ESCAPE='HTML'>
            </TMPL_IF>
            <span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:book<TMPL_IF ATITLE>&rft.atitle=<TMPL_VAR NAME="ATITLE" ESCAPE='URL'></TMPL_IF><TMPL_IF BTITLE>&rft.title=<TMPL_VAR NAME="BTITLE" ESCAPE='URL'></TMPL_IF><TMPL_IF ISBN>&rft.isbn=<TMPL_VAR NAME="ISBN" ESCAPE='URL'></TMPL_IF><TMPL_IF AULAST>&rft.aulast=<TMPL_VAR NAME="AULAST" ESCAPE='URL'></TMPL_IF><TMPL_IF INST>&rft.inst=<TMPL_VAR NAME='INST' ESCAPE='URL'></TMPL_IF><TMPL_IF YEAR>&rft.date=<TMPL_VAR NAME='YEAR' ESCAPE='URL'></TMPL_IF><TMPL_IF SPAGE>&rft.spage=<TMPL_VAR NAME='SPAGE' ESCAPE='URL'></TMPL_IF><TMPL_IF EPAGE>&rft.epage=<TMPL_VAR NAME='EPAGE' ESCAPE='URL'></TMPL_IF>"></span>            
        </TD>
    </TR>
    <TR>
        <TD>
            <TMPL_IF INST>
                <TMPL_VAR NAME='INST' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF YEAR>
                yr:<TMPL_VAR NAME='YEAR' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF SPAGE>
                pg:<TMPL_VAR NAME='SPAGE' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF EPAGE>
                -<TMPL_VAR NAME='EPAGE' ESCAPE='HTML'>
            </TMPL_IF>
        </TD>
    </TR>
</TMPL_IF>



<TMPL_IF BANNER_TYPE_2>
    <TMPL_IF ATITLE>
        <TR valign="top">
            <TD class="LabelBold">Title:</TD>
            <TD class="Label"><TMPL_VAR NAME="ATITLE" ESCAPE='HTML'></TD>
        </TR>
    </TMPL_IF>
    <TR valign="top">
        <TD class="LabelBold">Source:</TD>
        <TD class="Label">
            <TMPL_IF JTITLE>
                <TMPL_VAR NAME="JTITLE" ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF ISSN>
                [<TMPL_VAR NAME="ISSN" ESCAPE='HTML'>]
            </TMPL_IF>
            <TMPL_IF AULAST>
                <TMPL_VAR NAME="AULAST" ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF YEAR >
                yr:<TMPL_VAR NAME='YEAR' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF VOLUME >
                vol:<TMPL_VAR NAME='VOLUME' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF ISSUE >
                iss:<TMPL_VAR NAME='ISSUE' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF SPAGE>
                pg:<TMPL_VAR NAME='SPAGE' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF EPAGE >
                -<TMPL_VAR NAME='EPAGE' ESCAPE='HTML'>
            </TMPL_IF>
            <span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal<TMPL_IF ATITLE>&rft.atitle=<TMPL_VAR NAME="ATITLE" ESCAPE='URL'></TMPL_IF><TMPL_IF JTITLE>&rft.jtitle=<TMPL_VAR NAME="JTITLE" ESCAPE='URL'></TMPL_IF><TMPL_IF ISSN>&rft.issn=<TMPL_VAR NAME="ISSN" ESCAPE='URL'></TMPL_IF><TMPL_IF AULAST>&rft.aulast=<TMPL_VAR NAME="AULAST" ESCAPE='URL'></TMPL_IF><TMPL_IF INST>&rft.inst=<TMPL_VAR NAME='INST' ESCAPE='URL'></TMPL_IF><TMPL_IF YEAR>&rft.date=<TMPL_VAR NAME='YEAR' ESCAPE='URL'></TMPL_IF><TMPL_IF SPAGE>&rft.spage=<TMPL_VAR NAME='SPAGE' ESCAPE='URL'></TMPL_IF><TMPL_IF EPAGE>&rft.epage=<TMPL_VAR NAME='EPAGE' ESCAPE='URL'></TMPL_IF><TMPL_IF VOLUME >&rft.volume=<TMPL_VAR NAME='VOLUME' ESCAPE='URL'></TMPL_IF><TMPL_IF ISSUE >&rft.issue=<TMPL_VAR NAME='ISSUE' ESCAPE='URL'></TMPL_IF>"></span>            
        </TD>
    </TR>
</TMPL_IF>


<TMPL_IF BANNER_TYPE_3>
    <TR valign="top">
        <TD class="LabelBold">Source:</TD>
        <TD class="Label">
            <TMPL_IF TITLE>
                <TMPL_VAR NAME="TITLE" ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF NUMBER>
                [<TMPL_VAR NAME="NUMBER" ESCAPE='HTML'>]
            </TMPL_IF>
            <TMPL_IF INVLAST >
                <TMPL_VAR NAME='INVLAST' ESCAPE='HTML'>
            </TMPL_IF>
            <TMPL_IF YEAR >
                yr:<TMPL_VAR NAME='YEAR' ESCAPE='HTML'>
            </TMPL_IF>            
         </TD>
    </TR>
</TMPL_IF>

All the cool kids are implementing COinS

2005-09-01T23:04:00.000-04:00

A little while ago, I added COinS (ContextObjects in Spans) to our SFX menu pages. I have been asked by several people about the motivation of this, since it would seem that the user would know if fulltext was available to them at this stage.

Dan Chudnov posted to his worklog one of the advantages to putting COinS in the SFX menu.

So, imagine one of our users is at an SFX menu for another institution. Normally, they'd be, well, screwed. If COinS are enabled in the menu, however (and now we've proven this is pretty darn simple), they could use WAG the Dog or Dan's bookmarklet or Greasemonkey extension (he has them for GT) and get to our fulltext subscription.

Another use case is GT Library's web designer. Heather is a GT employee (of course), so she access to all of our resources. Being an FSU student, she also has access to their collection. Imagine Heather getting a GT SFX menu for an article that we don't have available in fulltext. By using her bookmarklet, she could then see if that article is available from FSU, without having to manually look for it herself. If FSU implemented COinS in their menus, then it would work both ways. With GALILEO opening up SFX for the entire state, one has to assume that all of our users could potentially belong to more than one library community (GT and ATL/Fulton Public Library, for example), each with their own subscriptions.

Anyway, it's quite cool to see (quasi-)real world examples of how COinS would work.

Geek Chic

2005-08-27T00:06:00.000-04:00

I just caught the end of Dark City. I love this movie, despite its cheesiness, and I think it speak volumes of you, as a nerd, as to where you stand on this flick.

In general, I see the computer geek community as comprised of two camps: the slashdot community, made up of the engineering (and engineering aspirant) type; efficiency, economy, practicality rule above aesthetics. Things that kick ass are valued more than objects of elegance. Principle carries more weight than pragmatism.

Then there is the other group. This is a nerd set that values form, as well as function. Perfection gives way to pragmatism. Strong coding skills aren't necessary (they help, of course), because "rules" are an "impediment to creativity". "Innovation" is the watchword above "propriety". Thankfully, I would place a vast majority of #code4lib in this arena.

"Thankfully", for two reasons:

It shows hope for the library development community

I hang out there all day, and I tend to dislike the former group

Another way to look at this schism is "The Matrix" vs. "Dark City". Both movies are based on the same premise: Cartesian logic. They both center around thinking things that cannot be certain that anything exists besides themselves. The difference is that one is a kick ass blockbuster smash and the other is a low budget cult classic.

You can enjoy both movies (I certainly do), but if you laugh more at "I know kung-fu" than seeing the wires attached to Rupert Sewell as he fights with the bad guy who looks like Reducto from "Harvey Birdman: Attorney at Law", you squarely fall in the innovator more than engineer camp. What is your Keanu tolerance? It says a lot.

Although I'm not sure why, the world does need both "The Matrix" and "Dark City" fans. They serve different purposes.

But when you're recruiting a geek, it's good to know what you're getting. Try "The Matrix" vs. "Dark City" question and evaluate from there.

Abstract Artunit

2005-08-15T17:27:00.000-04:00

I've mentioned several times in this space the OPAC redesign project that Art and I are working on. There hasn't really been anything to show, to date, because it's taken a very long time to get actually get the data out of Voyager. There are easier and faster ways we could have done this, probably, but we've been a little bogged down trying to get this to work in Art's webdav environment. This has required sucking the data out of Oracle according to LCC and that's been no easy task. GovDocs are in a different hierarchy, based on SUDOC (CODOC, for Art).

In the meantime, I get emails from Art at 12:30 at night, 7:30 in the morning that say things like:

I am woefully weak on python but I know you have been working with python lately and I wondered if the approach I am using makes sense. I am persisting date modified information with a python shelve. So it looks like:

shelf[url] = last_modified

This seems to work wonderfully, but I needed to add:

import dumbdbm

for the shelf to have somewhere to put the info. What I think is supposed to happen is that the shelf command looks for some sort of database option and cycles through them all looking for storage. The "import dumbdbm" seems to be a way to add an option if no other is found. Have you ever tried anything like this? I wanted to use pickle/cpickle but a million links would probably throttle it.

... I, of course, have no idea what he's talking about, but it's flattering nonetheless that he thinks I might.

Anyway, last week I started actually working with PyLucene and our metadata mirror files (Art, meanwhile, is doing similar work with Cocoon/Lucene) and I came across what is possibly the most useful byproduct of this project. While I was preparing the logic to frbrize the mirror data, it struck me that it doesn't have to be perfect, at first.

By separating the data from the ILS, we can create any kind of interface we want, indeed several, should we choose, without worrying about affecting the backend system at all. We can combine records, add metadata as necessary, remove it if it doesn't work properly, tweak our search algorithms, and incorporate it into any sort of system we want, because it would have absolutely no effect on the ILS itself. We'll still have the original "authority" should we mess anything up too badly and we'll have all kinds of value that couldn't (and probably shouldn't) go in a "conventional opac".

This sort of abstraction from the "inventory control system" is such a basic programming principle that I have to wonder why no vendors implement it (even I, as an untrained hacker understand the importance of this). It also abstracts the user interface from the catalogers a bit -- added bonus. Catalogers are great for many things, but designing user interfaces generally isn't one of them.

Civics lesson

2005-08-14T16:07:00.000-04:00

Representative "Democracy" at work. Read it and weep.

Via Metafilter.

Librarians are arrogant asses

2005-08-11T23:43:00.000-04:00

Despite our waning patronage (both physically and virtually), librarians never cease their criticism of the barbarism of the unwashed masses for not adopting their love of rich metadata.

"Dumbing down the catalog"
"I don't think it's too much to ask a student to learn what the library catalog is"
"Thousands of hits"
"Did A9 even bother to look at SRW/U?"

Let's take the first (widely used) statement. A system that is able to take a natural language query and present to the user a list that contains many of the things they are looking for early in the result set is not dumb. Hemingway, Ernest is dumb. Not understanding what I, the user, mean when I type "Ernest Hemingway" is dumb. This standard is applied to librarians, why not the catalog? A librarian doesn't explicitly require the patron to know they're looking for before they will help them with a reference question, but we expect them to form a perfect boolean query to isolate that rare manuscript (acquired in 1963 and widely unheard of) that would be the "perfect compliment to their term paper".

Number two: I don't expect a student to learn how to use a sliderule, either. It's not necessary for them to know what double clutching is. It wouldn't be the end of the world if they never have seen a typewriter's correction ribbon. Technology makes awkward systems obsolete.

In regards to the "thousands of hits" meme (which Alane Wilson argued against quite convincingly), how many hits would a user get if all of our databases were searched simultaneously? What if they are getting a sufficiently smaller set of results, but it's because they're looking in the wrong place? I am seldomly unhappy with my Google results as a starting place.

Should A9 have? Does SRW/U really make any sense whatsoever to 95% of the world outside of libraries? Why doesn't the SRW/U crowd try to work with the OpenSearch community? Why? Because we say ours is better, so the other shouldn't be trifled with. To be clear, it's possible to layer OpenSearch on top of SRU; Georgia Tech does it. Is one superior to the other? SRW/U is certainly more sophisticated. Despite what you will read to the contrary, however, OpenSearch is much, much easier to implement. If you know the metadata schema of the SRW/U server, simple SRU clients are possible, but, like Z39.50 before it, there are no constraints on what you might get from an SRW/U server. OpenSearch, while limited and limiting (for certain), has a somewhat different purpose than SRW/U. SRW/U is a protocol for searching for and retrieving metadata. OpenSearch is a spec for searching for and retrieving search results. This may sound redundant, but there is a nuanced difference. No matter the OpenSearch source, the results will always look the same, so it is very simple to integrate into a display (yet not so simple to actually do anything else with the result). While SRW/U is definitely more versatile, transforming your results to OpenSearch has its advantages. But this is a hard sell to the library world, because the "metadata isn't rich enough".

It's time we stopped scorning and ignoring the outside world, because they are doing fine without us. Aaron Krowne notes that a huge amount of scholarly content is freely available, further making our position in society weaker, making it all the more important that we co-opt popular culture, rather than ridicule it. Our standards are great... now let's see how they can interface with the real world.

Understanding the problem

2005-08-04T15:38:00.000-04:00

Fairly recently on the Web4Lib mailing list, a thread started by Jim Campbell (of UVA) and David Walker (of Cal State San Marcos) (and others) prompted me to ask what the role of OPAC is in the modern library.

Outside of "Inventory Control System", I don't feel like I got a very good or meaningful response.

I have been thinking a lot about something that Karen Schneider had written a while ago about the need for search interfaces to be search/browse. By this, I mean you begin your session by typing some words in a box and your interface adapts itself contextually to the results and what you should be looking at, so your "browse" options would be logical based on the context of your results.

If your terms were to bring back government documents, say, you would also have the ability to browse our GovDocs research guide or email our GovDocs librarian. If your search brought back a database (for example, ABI/Inform), then the page should also link to the subject guide that includes ABI/Inform (in this case, the Business guide).

This, of course, requires that the "library website" be in a format that makes it potentially servable in this manner. For our site, I have proposed that our content be broken down into small sections (rather than pages) that can be classified and served as necessary.

If you are an undergrad and one of your results happens to be one of your reserves items (which I'll get to in a minute), there's not much need to see the faculty policies for placing something on reserve. There is a use, however, in seeing the circulation policies regarding said reserve as appropriate to an undergrad.

If your search results in a journal that we get through an aggregator that sucks (meaning Lexis-Nexis or Factiva or their ilk), present tutorials on getting to the journal through that aggregator (or just a tutorial, in general).

Searches should be weighted contextually, as well. Objects that appear in your reserves lists or subject disciplines should have more relevance than other things. Circulation/clickthroughs should boost relevance (although I realize that non-circulating items present a problem here).

The important thing I want to see is the relationship between objects and content. My search brings back a journal. Besides the obvious information I want to know about thing (esp. things not included, like, what is it about?), tell me what databases index this thing; what other journals are similar; what is the current ToC (if available via RSS); are there preprints from this journal in our institutional repository/ETDs; etc. If there is any library created content related to a particular object, I want that, too.

I want to break down the silos between our resources and content and different collections.

And, yes, I think articles and other database content should be included in that as well (if you have the credentials to view them - if not, an indication of what you'd see if you were logged in).

If we don't include the entirety of our collections, I am not entirely sure what the purpose of the catalog is.

Dead air

2005-08-04T15:31:00.000-04:00

I notice a lot of the 'blogs I read regularly have recently had a similar posting to this one:

Wow, it's been so long since I last posted. Well, it's time to catch up.

I suspect for many, summer is the busy time of year. This is when you have to pack in all of the important projects before fall semester begins. It's also conference season and, hopefully, you might be able to sneak in a vacation (oh well, two out of three for me).

Anyway, here's to getting this blog beast out of hibernation.

Behold the awesome power of craigslist

2005-07-11T09:26:00.000-04:00

Yesterday I posted my truck, and it sold in 20 minutes. 20 minutes.

No wonder the print media is losing classified ad revenue left and right to craigslist.

ed. Never mind about clicking the link... I just had to remove the posting, because despite the fact that the ad said "SOLD" all over it, people were still contacting me about it.

My baby's done grown up

2005-06-21T17:30:00.000-04:00

Emory University Libraries has released Reserves Direct(2). I left for Georgia Tech during the redesign process and it far exceeds anything I could have imagined. It shares little to nothing from 0.9 (I was always too self-concious to label it a 1.x release).

One of the bigger changes is that it's now in PHP5/MySQL. PostgreSQL, for several reasons, was a rather large barrier to adoption for many libraries. The database has been completely redesigned (that was really the only part I participated in), since the old version was built upon a very awkward legacy data model (see the history for more on this). They also consolidated the three interfaces (staff, faculty and student) into one which should clear up much of the confusion faculty members would have when they couldn't edit their class from the student interface (see the demo). Actually, the new interface is so much more user-friendly, it's obvious that Maurice York (who did most of the actual interface design) put quite a bit of work into it. Jason White did the bulk of the actual coding, which I'm sure will be an improvement over the mess of code that passed for a reserves system previously. I'll know more about that soon, since I'm supposed to add the Voyager integration module (it currently only works with SirsiDynix Unicorn). My take is that this job should be a whole hell of a lot easier, thanks to Jason et. al.

One thing I find pretty slick about their site is the promotional video. That's Andy Ditzler doing the voiceover (and I'm assuming he directed it). It's seldom you see an OpenSource project with a marketing video, and even less by one sponsored by a library. I mean, who cares if the documentation is spotty if there's a slick promotional campaign, right?

I don't mean to sound so much like a shill for Reserves Direct, but it's really amazing to see something that started by being disappointed at an Eres demo turn into this.

Gussying up OpenSearch

2005-06-15T13:36:00.000-04:00

So, last week, before I left for SMUG, Mike Rylander (of Evergreen-ILS), Joshua Ferraro (of Liblime/Koha) and I began talking about OpenSearch interfaces for our respective catalogs. The only reason I was able to really contribute to the conversation was the fact that I had my little python CGI, but I hadn't thought much about it since I wrote it.

I had largely given up on targeted searching within OpenSearch due to the fact that targeted searching would be wasted on A9. A9 is basically only keyword and phrase searching, so more sophisticated queries would really only produce results in the catalog column. You would remove any advantage of A9's cross searching plus you'd remove any advantage of the catalog's native interface. Since I hadn't seen anyone else implementing OpenSearch, there was no point in pursuing this.

Well, until last week. Mike was talking about implementing OpenSearch in Evergreen and was interested in including results from Koha catalogs. Since I had already created my OpenSearch widget, it also seemed like a natural target. More natural, in fact, since the advantages of including the Georgia academic libraries in a search of Georgia public libraries (and vice versa) seemed so obvious.

This meant that targeted searching needed to work, though. I made the suggestion that queries should assume keyword and respond to CQL if it is supplied. CQL is just so intuitive that it seems silly not to use it, plus the added bonus of not having to manipulate it in any way before I send requests to yazproxy. Always looking for ways to get out of doing work, you see. So with that statement, I packed up and headed to SMUG and its lack of internet access for the rest of the week.

When I got back, not only had Mike created a proof-of-concept search interface, he had also created an extension to OpenSearch to account for relevancy and merged sets. He proposes adding the namespace xmlns:openIll="http://open-ils.org/xml/openIll/1.0" and using an <openill:relevance> tag to display relevance. With this, result sets can be merged and sorted by relevance, and any search targets that don't include this will appear as columns like normal.

There are some issues with this method, the most obvious being "what is relevance?" For example, I have no abilities to sort or get relevancy rankings from Voyager's Z39.50 server. In order to make Mike's proof-of-concept work, I had to "fake" a relevancy ranking based on order (which is always reverse chronological by creation date). I take the remainder of 100 minus ((the quotient of 100 divided by the number of results) and multiplied by the (result number minus 1)) (wow, refreshing my arithmetic vocabulary). My point here is, that's a crappy algorithm. For queries that produce thousands of results, you'll wind up with upwards of 50 hits with greater than 98% relevancy, despite the fact that the second result may not be relevant at all. Of course, I'd never put this in a production system, but it still goes to prove that relevancy is relative. The other problem is that in a merged search of two or more OpenSearch targets, the results on page three of a given target may be considerably more relevant than, say, the third result of the other target, yet you will still get all of the less relevant results in the pages in between. While, this is possibly a valid argument, it sort of misses the point of OpenSearch which I view merely as a resource exposure tool rather than a robust search protocol (at this stage, anyway).

The good news is that when Art and I have our OPAC mirror set up, we will actually be able to do relevance properly. The even better news is that we don't even have to have a concept of how the public interface is going to work to get this functionality. We'll have the data, we'll have the indexer, we just need to point Z39.50 queries to it and then direct them to the real OPAC (for now).

One thing I want to point out, though, is how cool the Evergreen and Koha results are. Not only are they deduping (we'll be able to do that later), but they display a sort of brief holdings (x copies available) and provide links on author and subject. I wasn't even thinking about providing subjects! I will have to see how easy it is to add this sort of functionality to our search results.

I hope to be able to point our OpenSearcher at our DSpace repository soon, too. We're currently trying to install the OCLC SRW web app and this could go a long way in providing exposure to DSpace from other resources like WAG the Dog or our catalog.

Mr. SMUG Man

2005-06-11T11:41:00.000-04:00

So I'm sitting in the Adele K. Stamp Student Union at the University of Maryland waiting for the shuttle to take me to the Metro and the airport (and out of this hell-furnace they call D.C.) logged into their campus wireless with some username and password that got passed around at the SMUG (SFX/Metalib User's Group) conference.

All in all, this was a really useful conference (and I don't throw those words around lightly). One major problem, however, was that there was really no internet access for the people here (to be fair, there was a lab in the library that we could use -- but our schedule didn't allow us to get there much). Even worse, I was staying in the dorm. The dorm rooms have nothing but a bed, really... so it was imperative to avoid the dorm at all costs until I wanted to fall asleep.

But back to the conference: this was my first SMUG, and I really didn't know what to expect. The morning started off (early!) with the typical rah-rah fest of the vendor announcements (this time through the Ex Libris filter, rather than Endeavor). The last of these, though, was a bit inspirational.

Ex Libris has named Oren Beit-Arie their Chief Strategy Officer and he spoke about upcoming development and goals for the company. The amazing part here is he talked about how Ex Libris was going to focus on interoperability. He added that Ex Libris wants to create products that are modular and can be used with other technologies, whether Ex Libris is the backend or something else is and Ex Libris is used as the front end (or vice versa). Wow! This is exactly what I asked Endeavor to do (they won't).

Dear University System of Georgia: can we please move to Ex Libris as our primary vendor?
If not, Dear Ex Libris: are you hiring?

Helping put the smug into SMUG, oddly my name was mentioned by two of the speakers before 10AM on the first day (Oren and Roy Tennant). The last time my name called out before 10 AM in a room full of my peers, I had to do 3-5 (thank you folks, I'm here until 3PM!). To be completely honest, though, it was always addressed as "Peter Binkley and Ross Singer". This is actually the way it should be done, Peter should always come before me. Still... flattering that Oren had any idea who I was. Roy, of course, is on the beer (scotch, wine) list.

Roy was next to talk about the pros and cons of Google Scholar. This was very informative, made even more so by the fact that Anarug Acharya (principal engineer, Google Scholar) arrived in the middle of Roy's presentation.

Then Carla Lillvik of Harvard spoke of their Metalib installation. I'm sorry, but it flat out sucks. Worse, it has taken 2 years to get to this level of suckery. Metalib--

Next up was a panel on Metalib usability testing. If anyone needs to read Polishing the Turd, it's these folks. It seems the problems with Metalib's user interface are so deep (and customization so difficult) that they resort to things like "changing colors of tabs" to help the users. Metalib--

Anurag spoke after lunch and talked about the mechanics and direction of Google Scholar. I feel a little better about the holdings issue now, but I still am a bit uncomfortable about the advantage that gives Google Scholar over other database search engines. Anurag is an interesting fellow. He's very confident (some may take it as arrogant), intelligent, and while he wants to work with libraries, he doesn't really want to deal with our b.s., either.

At this point the program changed dramatically and my presentation with Selden was moved up to be next. I hadn't actually gotten a chance to get to a computer to see if my presentation was working (it's, of course, a live presentation). After a scary moment without any network connectivity, we were up and running. Frank Cervone introduced us and mentioned my heavy metal hair from high school. As usual, I forgot half of the things I wanted to say while onstage.

It was quite cool that Anurag stayed as long as he could through my presentation.

Afterwards, I spoke to Oren and he got me on the notion of "Context Objects" vs. "Latent OpenURL Autodiscovery". I will definitely investigate this more, but Oren (and Herbert van de Sompel) are probably right. This is probably a much better approach.

I need to start wrapping this up so I can catch the shuttle... but I have quite a bit more that I want to say... mainly how by day two (thanks to Roy, Mike McKenna and David Walker, not to mention Karen Groves) I am very high on Metalib again, but only through the X-Server. I got to spend a lot of time with David Walker (in fact, he was inducted into the beer list) and I'm really glad I did. He's doing some amazing stuff at Cal State San Marcos and we can all learn a lot from him.

So, Metalib++?

I also have several orders for WAGgers. I am thinking of maybe moving it to being a hosted service.

Also, thanks to Katie Gohn for supplying the entertainment at our table at the Dinner/Reception Thursday night.

The Rock & Roll "Aesthetic"

2005-06-02T09:16:00.000-04:00

When people ask me why I "retired" from acting a couple of years ago, I always tell them, "Because I don't like other actors".

So why I decided to get back into playing music is a bit beyond me. While actors and theatre people have their constant drama and their singing songs from musicals at cast parties, in many ways it pales in comparison to the juvenile society and culture that exists around rock and/or roll.

This is my first real band since The Province of Avocado (Ashley Proffitt doesn't count) which was, like, back in 1999 (so last millenium...) so I hadn't bothered to maintain my equipment. After dealing with a shorted out instrument cable for a month (and a shorted speaker cable for even longer), I finally decided it was time for new cables.

I really hate guitar shops. They are crowded, expensive, staffed by former members of my high school heavy metal band, and one has to hear (repeatedly) some kid (badly) playing either:

Metallica's Seek and Destroy
Metallica's Master of Puppets

or, if they want to show how sensitive they are

Metallica's Welcome Home (Sanitarium)

It almost makes you nostalgic for the poorly played Stairway to Heaven you used to hear.

So, a couple of months ago, with the Benz overheating, I drove across Atlanta to Guitar Center to buy some cables. It was everything I feared and worse. To boot, their cables were really freaking expensive, and since Selena's reluctant about my spending $35/mo. on rent for our practice space, she would really freak out if I spent $100 on cables.

So I went home and bought all of my cables for somewhere around $30 from Musician's Friend. This, naturally, put me on their mailing list.

So when my first catalog arrived, I was transported back to high school. Oh sure, some of the companies are different (although not that many) and some of the gadgets are high-techier (although not much), but the vibe is still the same. And for a 32 year old, it is a vibe of shame.

Let me get some things clear before I continue:

I went to high school in Chattanooga, TN.
I graduated in 1990.
When I graduated, I had hair halfway down my back.
My ensemble routinely consisted of tight jeans, converse all-stars (or wrestling shoes) and either a Metallica t-shirt or a Queensryche t-shirt.
My first bass (a Peavey Foundation) was purple.
In my senior year, my band performed for the entire school some Tesla song and Ozzy Osbourne's Crazy Train.

What I'm trying to say is that I've been in the belly of the beast of bad taste and it's nothing to be proud of and it should not be perpetuated.

So imagine my horror, 15 years later, when I see this. And this. And this (Dave Mustaine?!). How about this one? Even moving over to basses, where I belong, and had hoped (erroneously) was more "dignified", revealed this. At least there aren't as many cheesy graphics.

The struggle for the average musician is navigating between the heavy metal death schwag and the jam band "kind" look. My current bass strap would make the unsuspecting bystander think I play in the "Dave Matthews Cover Band", due to my frustration at trying to find a comfortable, padded bass strap a couple of years ago. I hate it, but I hate skulls and flames and snakes even more.

Dear "rock & roll industry": Zakk Wylde, Joe Satriani and George Lynch weren't that all that cool or interesting 15 years ago, please stop trying to sell me their crap now.

Also, I still have my Peavey, but it's no longer purple and it sits in pieces in my shed.

The view from the moral high ground reveals that I've fallen behind

2005-06-01T11:27:00.000-04:00

I drove to work today. Normally, I take the train, but for several stupid reasons, I decided to drive.

Atlanta drivers have a disdain for "rules" and "traffic laws" that make me want to scream. They will pass you in an exit-only lane only to hold up that lane when they try to merge back into traffic 3 cars ahead. Four or five cars will plow through the intersection after the light has changed. The turn signal is apparently a sign of weakness.

So, because some fathead wants to get 6 car lengths ahead, we all sit and suffer in some of the worst traffic in the country. By actually following the rules, you:

Are forced to sit in the traffic being caused by those that break the rules
Are probably more of a liability on the road because if everyone is doing "wrong" things, you are the unpredictable one by being different.

Which brings me to metasearch (and a jarring segue). I am currently not sitting in a meeting in Macon to decide which metasearch product the state is going to go with. And, really, it doesn't matter that much.

Although I won't name any names, the candidates were down to two choices:

A "traditional" metasearch that uses standards like Z39.50, SRW/U, etc. to search
A metasearch that is based on screen scraping

While the research libraries in the state were leaning towards #1, there was something gnawing at us that was hard to deny.

#2 really mopped the floor with #1 as a federated search engine. Not only was it exponentially faster, but it is capable of searching over 95% of our databases (as opposed to #1 which is in the 30-40% range... and does that slowly).

Still, there is other functionality in #1 that still makes it desirable (mostly revolving around workflow and integration into an academic environment, integration with our link resolvers). As a cross database searcher, however, #2 is clearly the winner.

What this brings me to is... How did we get to this point? Why is it actually so much easier and brings better results when we "break the rules"? We have invested a lot of time, thought and energy into creating our standards... how can it possibly be easier to screen scrape results pages rather than use the tools we have created?

I blame libraries first. Securing access via Z39.50, XML gateway, API, etc. has never been a particularly high priority. Metasearch is not only a "systems" issue. It also needs to be looked upon as a collection development issue. If two vendors have "Compendex" and only one of them makes it available through means outside the native web interface, unless that vendor's native web interface is "the suck" (technical term), they really should be considered the more desirable option. Along with a whole host of other factors, of course. Still, I think non-native access is a very low priority among collection development decisions.

I blame the vendors next. First of all, so many of them don't even offer some sort of alternative access. Secondly, if they do, it's an afterthought.

I have been toying with robcaSSon's federated search project, unhelpfully supplying suggestions when he asks #code4lib for help on particular problems. What Rob has written so far is very cool (but unfinished and therefore not publically available) but it struck me how slowly it searched Academic Search Premier and Business Source Premier (that's Rob's "canned" query -- those two dbs with the keyword search "hamid karzai and heroin").

In the native interface, searching across those two dbs is nearly instantaneous... it's basically just waiting for the browser to render the tables that takes any time. In Rob's interface, it takes about 5+ seconds to do the same search (and this is with no load on Rob's end, since it's not in production... so real world performance would probably be lower). Now, as we learned from Metasearch product #1, this is sadly respectable in the metasearch arena. It's still bad, though, and I wanted to figure out why it took so much longer.

Using indexdata's handy yaz-client, I fired up a Z39.50 session to EBSCO's Z39.50 server to investigate. Searching "hamid karzai and heroin" took a little over 4 seconds. Hmm. 4 seconds?! So I did a search for "female genital mutilation". 0.2 seconds. Hmm. I did the original search again. 0.05 seconds. Wow. I exited out of yaz-client and then reopened the connection and did it all again. Basically the same thing.

So, apparently it's the first search in a session that's a problem. And that sucks. Inherently, every search in a metasearch is the first search in the session. Certainly some connections can be cached, but this definitely raises the complexity of the application and, no matter what, not everything can be cached all the time.

Now, yazproxy would be perfect for dealing with this. It could maintain the session information and at the same time transform the output to xml. Everybody wins! Well, except I can't get it to work. I guess that's a bit of a hindrance...

So, again, by trying to do right and follow the standards our community has set, we are left behind the sloppy, inexact searching of a screen scraping method. Ultimately, we all lose, though, because screen scraping can only go so far. The richness of services we can layer upon a screen scaper has far less depth than that of a structured search.

And laying on the horn doesn't really help...

WAG the Monkey

2005-05-31T17:03:00.000-04:00

I've finally managed to rewrite quite a bit of the WAGger to run in Greasemonkey, a sort of crazy swiss-army knife for Firefox. My only experience with Greasemonkey up until now was modifying Peter Binkley's Firefox extension to work with GM (which required... nothing on my part, really). My hesitation mainly revolved around my historical frustrations surrounding JavaScript and the amount of work I'd potentially have to put into something that works in a browser that nobody uses.

Now I'm pretty happy I invested some time.

First of all, I have the WAGger persistence that I really could never get from the PHP Localizer. Instead of requiring the user to know when to use the bookmarklet, WAG the Monkey knows when to wag for the user. Of course, this assumes it's always on, which is less than ideal.

Another advantage is that it's fast. Real fast. Like so much faster. Like really.

The best part is that I think I can use most of it for a better and faster bookmarklet style WAGger, as well.

Thank you, Greasemonkey, for making me get off my ass and learn JavaScript in ways that I should have a long time ago.

If you want to try it (for a Georgia Tech experience), install Greasemonkey, then this user script.

Now that I've overcome my fear of JavaScript, maybe I'll take a look at Piggy Bank. RDF has always given me the willies...

Vendors are people too... ...or so we're told

2005-05-19T19:19:00.000-04:00

Today, I attended GUGM 2005. GUGM stands for "GIL User's Group Meeting", and, unless you happen to be from the State of Georgia, you probably have no idea what that means. "GIL" stands for "GALILEO Interconnected Libraries" which is fancy name for the consortial deal the University System of Georgia has with Endeavor's Voyager. All 34 USG schools use Voyager and we have a big, happy union catalog and universal borrowing and the whole works.

So once a year USG and Endeavor throw GUGM, which is a hodge-podge of Voyager semi-related sessions intermingled with Endeavor rah-rah propaganda.

I was in attendance because I was asked to do a presentation on WAG the Dog. I probably wouldn't have gone otherwise. There were very few automation type sessions and learning about the problems with ILL and cataloging aren't the best way I can spend my days.

Still, I actually had a pretty good time. I carpooled down (to Macon) with Crit Stuart and we had pretty good conversation - amazing since we left GT at 7:30AM. The keynote speaker was Kris Biesinger on GACollege411. This is a really pretty incredible service for high school students in Georgia to help track their path to college. Bravo! I certainly wish something like that had existed when I was in high school (and I wouldn't have wasted a year and a half at UTC).

This is not the point of this posting, however.

The first session I attended (by process of elimination) was one of the aforementioned Endeavor rah-rahs given by Dave Richter, VP of Global Sales. It was a mostly dry overview of the "state of the company" and whatnot, but what stuck with me was an air of humility that permeated from his PowerPoint.

We have gained of reputation of being less responsive to our users.

We need to act more like partners with our customers.

We need to become technological innovators again.

Granted, this was coming from the VP of Global Sales, so if anyone should be able to cry crocodile tears it was he, but still, there was something to these admissions of culpitude that one rarely sees from a vendor, especially one associated with Reed-Elsevier.

He went to describe the dilemma of being a library vendor in that one may have to go the "novel" approach of working with another vendor to deliver a particular product. That this sort of "radical" thinking was what you sometimes "had" to do, but what to do if this particular deal would possibly favor a competitor's product over another you or your parent company offers?

Here is where I had to interject. I tried to hold my tongue as long as I could and I kept telling myself, "Don't sound confrontational... Don't sound confrontational..."... but I think I sounded confrontational.

I said something along the lines of:

I understand that you have a business to run and you have to think of the bottom line across all your divisions... but ultimately that hurts us. We can't expect any one vendor to supply all of our information needs, so therefore we need you to play nice with each other. Further, we need to be able to do anything we want with our data and the data we're paying for. When we license Voyager from you, we don't want proprietary features that make WebVoyage do things that we can't do in any other way. We have ideas of what we can do with our database, and the limitations you set on what we're able to do with it forces us into little silos of data. And that's good for no one.

I went on to say some more about "speaking for the library developer community at large" (sorry library developer community at large) that we need vendors to relax a bit and open up their products more to us.

I talk a lot, I realize, but the crux of this is: We have to treat each other as "partners". We (the libraries) are reliant on the ILS and database vendors to accomplish our tasks as libraries. Vendors are reliant on libraries to even have their freakin' business. We both need to address the reliance we have on each other and actually work with each other as symbiotic entities.

Also, Memo to library vendors: Don't worry so much about losing our business to a competitor. There is no reason to be overprotective. An ILS migration is probably the biggest nightmare that faces a library organization, so it would take an incredible act of negligence or bankruptcy to drive us away.

One last note. If you want to regain your place as a technological innovator, perhaps you should start fostering and endorsing a development community among your customer base. It could only serve to make your product and company stronger.

Exposing ourselves - what libraries can learn from the flasher community

2005-05-17T11:14:00.000-04:00

Last Thursday/Friday I decided to put my development time where my mouth is and actually try to fiddle around with A9's Opensearch. Earlier in the week, I had told my boss that I wanted to do this and that I didn't think it would take much time or energy.

Her reaction was:

What is Opensearch?
Ok, now that I know what Opensearch is, why on earth would anybody choose to search Georgia Tech's catalog in their web search?

At the time, my argument centered around the fact that I was only using our catalog because it would be a fairly simple exercise to get working with Opensearch. If it seemed viable and simple to do, the real project would be to get our DSpace repository searchable this way. Since my proposal wasn't really gaining much momentum with her, I tried to sweeten the pot by noting that our environment was set up exactly like the Library of Congress's (SRW/U via Yazproxy to a Voyager database), and if they found it useful... well, wouldn't it make Tech look good to have the LoC using something we developed?

Ok, I realize this definitely makes me seem like sort of Iago whispering weasely ideas into Othello's head but there is some truth to it and if the end-product is a success (or even if the LoC is passingly interested in it), I think there's some "good to be gotten". Having an agenda isn't necessarily wrong. Using other people's desire to increase our profile in the community to further that agenda probably is, though. Oh well... enough of my cravenness.

So, in an effort to expand my horizons a bit and to try to make this a little more portable (you know, just in case the Library of Congress is interested...), I decided to try to develop this Opensearch to SRU thingy in python. Dan and Ed have been advocating python for a while now (as has my friend Tom... apparently python is heavily used in XBox hacks). The #code4lib sprint at ALA will probably be python-based, so I thought I better start getting familiar with the language a bit. I had dived into python a couple of months ago to try my hand at unalog development, but reality stepped in and dragged me back to PHP. I always do better if I have an actual objective, anyway.

By the time I left for a mini-vacation (ah, so therapeutic!) on Friday, I had a mostly working prototype (thanks to Dan for some python pointers). In fact, it was a completely working prototype except for the fact that it wasn't encoding xml entities (so, keep it in lower ASCII, folks!), which is, of course, less than ideal. I should be able to fix that today.

Right now the query requires either "keyword anywhere" or minimal knowledge of CQL. The nice thing about CQL is that it actually makes quite a bit of sense.

author=Hemingway
subject=biology and title="Introduction to biology"

This syntax either needs to be made apparent in the Opensearch column description (less than ideal) or it needs to be translated from however A9 would define this sort of thing.

On my train ride in this morning, I began to think about the conversation with my boss about this project again. Even if our potential user base is relatively small, isn't this exactly the sort of thing we want them to be able to do? From a search engine or any search of any sort, wouldn't we want to also be able to show relevant resources from our own collection? Yes, the user would need to add the column (strike one!) to their A9 search results (strike two! They're at Google!), but if it's easy enough to implement, why wouldn't we offer this? A metasearch would certainly be more ideal to expose our collections, but I don't have access to that right now and I haven't figured out how A9 deals with access controlled content, anyway.

One of the goals of the redesigned OPAC project is to create human parseable, crawler-friendly urls so these avenues of discovery can be opened. There is no good technical reason that web opacs place the session information in the url (my guess it is for backwards compatibility with cookieless browsers).

Wouldn't these urls make a lot more sense:

http://gil.gatech.edu/isbn/0632044160
http://gil.gatech.edu/author/Wilson, David L./title/Introduction to biology
http://gil.gatech.edu/issn/1465-7392
http://gil.gatech.edu/title/Nature cell biology

urlencoded, of course.

Things like this seem so simple for providing a little better access to our collections from the outside world.

Polishing the turd: the dangers of redesigning the OPAC

2005-05-09T10:06:00.000-04:00

So as Art and I continue to try to export the data from our respective Voyager catalogs to create an alternative web opac, I have been trying to formulate what such a beast should look like. We have the opportunity to make the web interface look and behave in any way we want, so there are a lot of things to think about. The goal is to make the opac behave in the way non-information professionals would expect a searching interface to work, so we're not just talking about a cosmetic makeover to the current design.

We just had a professional usability study done on our web site and services. The results were rather sobering. While not every aspect of our web presence is bad, a great deal of it is, and, worse, the bad parts are generally the most important. Making the situation even more complicated is the fact that a lot of these awkward interfaces are not under our control (the databases, ejournals and opac). Well, not currently under our control.

I'll skip over the part about our website (we're able to fix that pretty easily) and write about what they recommended for the catalog. The first screen they gave us was a redesigned search form. An interesting dialogue came out of that:

Usability Expert: Ok, so this is the search form...
Librarian(s): So... is this the simple search form or the advanced search?
Usability Expert: This is the search form.

And it really is as simple as that. It is a text input field that, by default, would do a keyword natural language query on the catalog, or you could add limits and filters (title, author, subject, etc.) or make a more sophisticated boolean search using the exact same form.

The other screen they showed was a full record page for a journal. It was extremely well laid out, but I noticed that it had a lot of visual clues in the page that item you were looking at was a journal. This is another incredibly simple feature. Different types of resources can have their own layout based on what is logical for that type of resource. Also, we could conceivably display electronic holdings from SFX in our opac interface, so the user doesn't have to click on the SFX button (or generic 856 link) and open the SFX window to see if an issue is available electronically. We could also, at this point, give recommendations of other resources that might be valuable (such as A&I databases that this particular journal appears in).

The usability study was extremely useful for looking at the opac through non-library eyes, but with a view focused on making things more useful.

Last week I began trying to visualize how to lay out search results. The initial design, I think, will look something like:
Your search for "Ernest Hemingway" resulted in:
167 Total Items :: 102 Books :: 50 Videos :: 2 Journals :: 13 Audiobooks :: 1,072 Items from GIL Express

With each of those being tabs to view different types of resources (plus a link to our state union catalog at the end). The goal is to be somewhat A9-ish, but I can't say I'm a huge fan of the column layout.

I am, however, a huge fan of the folksonomy. I definitely plan on implementing user-supplied subject headings. We want to implement a del.icio.us style social bookmarking/citation management system here anyway (probably using unalog), and it seems like this would fit in quite well with that. I wouldn't actually expect users to just add "tags" to things without some sort of personal gain, so if it was incorporated into a "bookbag" system, it might actually get used. Although the idea of just leaving breadcrumbs around the opac (and databases) might be useful if they don't want to clutter up their bookmark pages with a ton of items. This is something that we can play around with. Mark Leggott talks about adding folksonomic support in the University of Winnipeg's alternative opac project, as well. Interestingly, I had no idea Mark was working on something like this (rob caSSon, at the University of Miami, Ohio, is also working on a similar project. Miami and Winnipeg are both III sites; perhaps they should get in touch with each other).

Over the weekend (yes, I get a touch obsessed about my job), I began thinking about the utility of displaying dust jackets in the opac. When I was designing a new books list application at Emory, it seemed "obvious" to include dust-jackets in the results. I mean, that's what Amazon does and it's user-friendly, right? Well, while I was thinking about it this weekend, I started wondering how useful this really was. What is the purpose of showing the dust jacket? It certainly won't help the user much if they go into the stacks to find the book... we rebind everything in those boring red/green/gray/"khaki" bindings, with no indication of what the original dust jacket looked like. If anything, this seems like it might be more confusing to the user.

Something that seemed so "obviously necessary" in a modern opac 12 months ago now seems pretty frivolous and would just add unneeded clutter to what will probably already be a fairly cluttery interface.

I'm sure this design will continue evolving, but it's got to start somewhere.

Reflections on the Shins at the Variety Playhouse and ruminations on some other recent shows

2005-05-04T09:31:00.000-04:00

I am a total sucker for a well crafted pop song.

This might come as a bit of a surprise to anyone that is familiar with my standard listening fare, but this secret obsession is nothing new. Let me clarify: when I say "pop", I am not talking about the bubblegum pablum and effluvium that the industry tries to pass as music, but genuinely original, thoughtful and well-created songcraft that appeals to me as both a musician and a human being.

Enter the Shins. There is arguably no other act right now that is producing such catchy and hook-laden music. It's not all necessarily upbeat, but it's all pop. It also has the unique attribute of being something that Selena and I both really like.

Selena bought us tickets to their show last night at the Variety Playhouse. The Variety is definitely one of the better venues in town and I had been looking forward to the show.

I need to go on a sidebar here before I continue: I am a misanthrope. In general, I abhor other people (at least in groups) and find myself dreading to go to events with large numbers of people because I feel those people cannot be trusted to behave. Since I realize I am in the minority here, I generally just opt to avoid situations where I'll get agitated by the behavior of others. For example, Selena and I have never been to a movie together. We both have had enough aggravating experiences in movie theaters that we feel it's just in our best interest to wait until the movie comes out on DVD.

This being said, I do like to go to shows. However, given my general musical tastes, majority of the shows I go to are populated by a fairly homogenous, docile, and, in many cases, stoned crowd. That's my "base" and we'll call "comfort zone".

Poppier music pushes me out of that safety net into the more dirty masses and I tend to get a little tweaked and annoyed by the behaviors of those around me.

So, back to the story. The opening act was the Brunettes and we can just say that the less I have to deal with them the better. They are a New Zealand band that reminds me of the Partridge Family and for their last song (or one of their last songs... I lost track) they all donned "Olsen twins" masks and played their instruments. It was like musical Carrot Top and I was happy when their set ended.

The crowd consisted of a lot of frat boys and their girlfriends/wives. There were quite a few visors worn. I am not much of a fan of those who wear visors. At one point, I leaned over to Selena and explained that by playing the music we do, my band would never attract a crowd and, as a pleasant side-effect, would therefore certainly never attract this crowd. Selena wasn't really buying it, though. She still just thinks my music sucks.

The Shins were quite good. They had a lot of energy, their songs were tight. My... complaint... if you can call it this... is that I felt like they acted like they were playing at a frat house (and it seemed obvious that they had experience doing so).

Maybe I should stop now... The Shins are a very good band and if you don't get hung up on the crowd, you'll probably enjoy them live.

In the last three weeks, I have seen Band of Horses (or, more commonly, just "Horses") twice. They opened for Iron & Wine at the Variety a couple of weeks ago, and I caught them again last week at the EARL opening for the Mountain Goats. It's not often that I am blown away by an opening act, but Horses was pretty amazing. There is a bias here, Ben Bridwell is the younger brother of Mike Bridwell, who is a close friend and, until last December, neighbor. I had seen and enjoyed Ben's previous band, Carissa's Wierd, but Horses is much better. Their sound definitely has some roots in Crazy Horse, but there's a Pac-NW sound in there, too. There's some old Modest Mouse and a lot of Black Heart Procession and it's just good.

Iron & Wine, of course, is great as well. Again, there's bias. I&W's drummer, Jonathan Bradley, also happens to be the drummer in my band. If you are familiar with Iron & Wine, your reaction might be "drummer?!?", but, indeed, Sam Beam tours with a full band. Jonathan also plays "shaker" and other various wussy percussion on the albums. Sam has begun to rearrange some of his older songs to take advantage of the extra instrumentation, but sometimes it goes a bit far. "Bird Eating Bread" sounded like a Jimmy Buffett song. I sort of hope this is just Sam getting used to all the toys at his disposal.

A quick note on the crowds of these two shows: Iron & Wine's was ok, but there was a bit too many of the "indie-rocker idolaters" of the variety that haunt "Low" and "Pedro the Lion" shows and stand in reverence and yell, "We love you" to the band.

Maybe because the headliners were the Mountain Goats, and it's hard to imagine anyone shouting "we love you" to John Darnielle, the crowd at the EARL was much better. Ah, sweet, sweet EARL...

As talented as Hemingway or Faulkner... If we're talking about the drinking

2005-04-30T00:22:00.000-04:00

Well, it's official. I am a published author. Granted, I didn't do much; Dan wrote this paper almost singlehandedly, really. I put in a little more work than I did on this paper (this helped), although not much. Any of you who read my rather awkward white paper should immediately recognize that Dan is a much more inspired writer than I.

Still, I'm happy it's out and I'm extremely thankful to have been given the opportunity to work with this group. I was way out of my league.

RSS & Libraries: Ahab's great white whale

2005-04-29T23:02:00.000-04:00

If the library blogosphere was your only source of current events within libraries, you would think that RSS was new MARC record and that podcasting will alleviate the need for circ rules.

This is ridiculous, of course, but that's not to say that there isn't merit to RSS (podcasting seems silly to me). RSS (in the right context) is perfect for libraries. Elsevier has just begun RSS feeds for current awareness searches (this has some problems, as well, but they are not insurmountable). RSS feeds for new acquisitions has potential, as well (although for larger libraries this needs to be filtered a bit... Emory, for example, gets 600 new items a week... put that in your Live Bookmarks, mofo). I know there are libraries that make RSS feeds of their news and announcements. This seems a little self-indulgent (how many people really subscribe to these?), but if they aren't much extra work, why not? I have no stone to throw here, really, I have come up with "Wag the 'Blog", after all.

RSS's real potential lies in computer-to-computer communication, though. All this talk of setting up feeds for our users is mostly noise to the primary goal which should be getting our services and collections visible in other sites and interfaces like A9's OpenSearch. What we need right now is marketing and mindshare. Feeds of new items that have gone into the anthropology subject guide are nice and all, but it'd help a lot more if that feed appeared contextually off of a Google search or something.

Lorcan Dempsey makes note of the University of Michigan exporting their reserves lists via RSS to Sakai, their portal/courseware application. This is the perfect application of RSS and, I note, something I put into Reserves Direct almost 2 years ago. Granted, I didn't think this was anything revolutionary or even noteworthy at the time, I just needed a way to get the reserves lists into Blackboard and this was a technology my feeble brain could wrap itself around. Actually, the RSS feed was never even advertised. Blackboard 5 has no native RSS capability (neither does Bb 6, for that matter... at least not in the course interface), I used a Perl CGI (now ported to PHP) to write the RSS feed as JavaScript in the page. This was a hack-y solution, but it worked, and that was what was necessary.

I guess what I'm drawn to here is the fact that the electronic reserves software that my employer has chosen to use doesn't support RSS. In fact, there is no alternative to its own interface. At Emory, I was present at a demo for said program and I left thinking, "huh... we can do that...". Two and a half to three years later, the commercial product still boasts the same feature set (which was indeed impressive -- three years ago) but has not evolved a bit. In the same time (and primarily because Jason White took over the main programming duties when I left) Reserves Direct has become an extremely powerful and extraordinarily flexible tool for getting the collection and services to where the user would want it. Namely, contextually among their other course items.

How could our vendors be so out of touch to something so simple and obvious?

I was meant for the stage... or Amazon or Google or something

2005-04-26T00:28:00.000-04:00

Maybe it's the bachelor's degree in a joke major from a football factory school talking here... but why must libraries constantly overthink themselves into obsolescence?

Why must the only search that brings back relevant data be an "exact search"? And, even then, why can't that search include the leading article?

I realize metasearch isn't the solution to every problem. But it would solve a vast majority of them. And then I look at A9's OpenSearch and I think, "Jesus Christ, what are these momos in the NISO committee doing?"

That's, of course, not fair. OpenSearch will be nowhere near as sophisticated or as robust as NISO Metasearch. And that is, of course, exactly why it will exist everywhere but libraries and NISO Metasearch will exist nowhere but libraries.

Don't get me wrong. I love and embrace the rigidity of the MARC record. That being said, I want both authorities and friendly, loose and sloppy interfaces. I want Voyager and Amazon. I want Web of Knowledge and Google Scholar. And I want to be able to move around between simple and complex interfaces at will.

And as a developer, I want RSS and SRU, not OpenURL 1.0 and Z39.50. I like MODS. Hell, I like Dublin Core. I also like knowing that a good MARC record is living behind it.

Why can't libraries cater to the information semi-literate once and a while?

Librarians and Lager: a bonding agent

2005-04-16T02:50:00.000-04:00

Art Rhyno, Eric Lease Morgan and Jeremy Frumkin and I.

Dan Chudnov, Roy Tennant and I.

Todd Holbrook, Calvin Mah, John Durno and Mark Jordan put up with the 'Murrican Ass that I am.

William Wueppelman put up with that, too.

Jason White, Aaron Krowne, Will Young and I used to go for "free beer" at the Dogwood Brewery (R.I.P).

Bernardo Gomez.

Nathan & Michelle Robertson were good enough to let my drunk ass into their home.

Emily Patrick was, as well.

David Atkins (Pasquale), Cat Cochrane (Honda Civic Wagon thingy), Teresa Braden (apartment, among other places)... Anne Langley (Petron, wedding).

Megan Adams, you and your LSU ilk put up with the worst of my liver in New Orleans. Chicago, as well. No ilk there, though.

Ah, sweet beer. You, friend, are a uniter, not a divider. Maybe W should learn a thing or two from you.

Maybe it's the beer talking.

Oh the irony

2005-04-16T01:46:00.000-04:00

So, we launched the WAGger on Wednesday afternoon... sort of. We created a couple of pages for it, and linked to it from a couple of places. A "soft launch", as they say. Still, it was a launch, nevertheless, so we needed to tell our public services librarians about it. We held a brownbag on Thursday at lunch to explain the fact that it was launched (soft launched) to help public services with the implementation.

Here's where the irony comes in. jake was down. But since jake runs on tomcat, it was still "alive", it just wasn't returning connections. So, despite my praise from the other day, jake wasn't allowing the WAGger to continue to SFX to display holdings.

Thankfully, the audience seemed to blow this off.

In the near future, expect to see a jake mirror at Georgia Tech.

"Evolution favours the pathetic"

2005-04-13T09:41:00.000-04:00

--Art Rhyno

jake & CUFTS: studies in social frustration

2005-04-12T23:52:00.000-04:00

Dan says jake could no longer be updated because of the heavy costs of maintenance.

Todd (or, rather, Mark) says CUFTS can no longer be free because of the heavy costs of maintenance.

They are both (all three of them) right, and it's incredibly sad. Knowledgebases are expensive to maintain.

I use both of these programs in WAG the Dog, despite the fact that I have access to SFX and make heavy use of the SFX API. jake is used in multiple places, and, regardless of the fact that the data has not been updated in years, is invaluable to the project. Before I bog down the SFX API with requests about an object that I know little about, I query jake to see if it is even a journal of some sort. Granted, exact title searches (especially on abbreviated titles) doesn't really exist in jake, and no journal that has been created in the last couple of years would be included (something I definitely need to address), but it filters out a lot of noise... especially from Google Scholar. Today I realized the value of jake for WAGnet, the resource advisement piece of WAG the Dog. jake is able to find a lot of things (albeit fuzzily) that SFX just isn't able to.

CUFTS is a really nice link resolver. Since SFU (or COPPUL, I'm not sure of the dynamics) has decided to charge for the knowledgebase (something I completely sympathize with), I have exported our live target data from SFX and imported it into CUFTS. Since I'm more interested in using CUFTS for an electronic holdings database rather than a link resolver, all of the links are OpenURLS pointing back to SFX. The nice part of CUFTS, is that it gives me a link to the database level as well as the journal and article level. When it comes to resource advisement, this is great. I can query CUFTS for a particular ISSN, find the database it resides in, and present a link saying, "hey, this journal you found appears in XYZ Academic. You might find more related things by searching there".

The sad part about CUFTS moving to a subscription model is that I don't have access to the A&I holdings information of a particular database. Yes, this data is in the SFX kb, but our e-resources team isn't going to activate the "getAbstract" service in SFX. Without that, I am not sure I can export it. This would be a great boon for WAGnet, but at the moment I have no clue how to tap this potential.

So, instead, I have to work with old data from jake and figure out ways to link jake's database names to our own.

Watch the maintenance costs increase.

Who will police the police?

2005-04-11T22:55:00.000-04:00

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.

Thoughts on OpenURL Autodiscovery

2005-04-08T17:50:00.000-04:00

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.

Countdown to WAGging

2005-04-08T16:53:00.000-04:00

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.

Hello World

2005-02-08T20:59:00.000-05:00

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.