I’ve made a little update to two of the PatREST Google gadgets (top and new items)–partly due to the insistance of a certain Superpatron, but mostly because I was planning on doing it anyway.

The new versions allow users to display cover images along with the records. A new option gives you the choice of text only, images only, or images and text. Not a major change, but noteworthy. Also, in case you missed the update in my previous post, the new items gadget can now match subject headings–useful if you want to be notified about new items on a particular topic.

For the purposes of the Talis mashup competition (for the judges), the original xml files are still available under a different name (tops-v1.xml and new-v1.xml). Everyone else, here are the new ones:

• tops.xml
• new.xml

(FYI, it’s the same URL as the previous version. If you’ve already added it to your Google page, the update will be automatic)

While working on this little project, I became painfully aware of PatREST’s limitations when dealing with asynchronous execution — like that of Google gadgets. I previously thought it would be better to limit the amount of data returned in an XML hit-list and use a second record query for and detailed info. I think I may have been a little short-sighted. At any rate, the lesson learned is that the more practical experience I have with PatREST, the more I’ll know what works and what doesn’t.

The upshot of all this is that I’ve expanded the result objects in any PatREST function that returns multiple records to include more information, such as ISBN, cover image, author, and record link. For those asynchronous folks, this will make life a lot easier. The new additions have been added to an updated specification. Existing PatREST applications (I don’t think there are many at this point) will continue to work, of course.

I was having serious doubts that I’d find the time to put something together for Talis’s Mashing Up The Library competition. But that’s what late-nights are for, right?

Anyway, my idea was to submit a suite of Google gadgets that, even if it doesn’t win, will serve another important purpose of providing a proof-of-concept for my PatREST specification. So I’ve written four gadgets using the Google Gadgets API. These gadgets then consume the PatREST service for their data. If you’re unfamiliar with the Google gadget, they are the little customizable panels on Google’s personalized home page. This is what the page looks like with all four enabled:

Like all the other gadgets, they can be dragged around the page and individually configured. Also, you can choose which gadget to install, if you don’t want all four. They are:

• tops.xml - - Displays the hottest items at the library. You can configure it to display books, CDs, books on CDs, or everything. You can also select the number of results you want returned.
• new.xml - - Displays the newest material at the library. You can configure it to display books, CDs, books on CDs, or everything. You can also select the number of results you want returned.
• curitems.xml - - Displays all your currently checked-out items.
• holds.xml - - Displays all your requested material.

The beauty of these gadgets is that they require no modification of the code at all in order to be used with other libraries. The catch is that the library needs to provide the PatREST API (and right now, that’s only AADL). My hope is that other libraries will see and recognize the usefulness of a patron-friendly API.

Installing the gadget is dead easy. First, you need to create an account with Google so that you can personalize the Google home page. Then, click the “Add content” button (top-left). You’ll notice a small option next to the search box, “Add by URL”. Click it, and paste in the URL of one of the XML gadget files above. If successful, you’ll see something like:

You can repeat this process for all of the gadgets, if you like. When you’re finished, go back to your personalized homepage, and configure your gadgets:

Configuring the Top Items gadget:

Configuring the Check-outs gadget. Note that you will need a special token. This is the token used to access your personal RSS feeds:

That’s it! I doubt it could be muh easier. AADL patrons can benefit from these gadgets right away. Hopefully other libraries will consider the PatREST specification, (vendors too!). Once I had done the prototyping, creating additional gadgets was very easy because of PatREST’s simplicity and accessibility.

Naturally, these XML files are released under GPL v.2. Feel free to modify and extend them as you like. I have a number of ideas that I just don’t have time for right now, but hope to add in the future.

Also, because of the quality of XML data I get out of the III system, and, what I think is a bug on Google’s end, the results occasionally do not display. Once Google clears it’s internal cache, however, things usually fix themselves. I think this little bug is out of my hands–at least until I can learn more about it.

Please use these, and enjoy them responsibly!

*** Update 8/19/2006 ***

Added subject search to the New Items gadget.

*** Update 9/1/2006 ***

Not sure why I didn’t do this before, but I added “Add to Google” buttons to the links in this post, as well as on my files page. All you need to do to use these gadgets is click on the button and confirm by clicking on “Add it now”. How’s that for simple?

A couple of notes regarding the status of PatREST.

First, two new functions have been added to the service. One provides access to tops (or popular items) lists. The other provides access to the new materials lists. I believe these are significant-enough additions to the service that they merit the 1.1 version number.

The top items query is scalable by result size and can be paginated, just like the search results. In addition, it can be scoped by material type: books, cd, dvd, or bocd (books on CD). When applied to the AADL XSLT, it looks something like this:

The new items query is similar to the top query in that it can be scaled by material type, size and be paginated. You can also search new items using their subject headings–useful for querying those new knitting books, Ed… It looks something like this:

Second, and probably more importantly, I’ve finally drafted a specification for PatREST which includes an explanation of it’s XML schema and some documentation for it’s various functions. It’s about time, I know. It can be found in the files section, or downloaded here. (PDF)

I’m not going to go in to too much detail about the two new functions in this post because the new documentation contains everything you need to know to get started with them.

An interesting, but low-key thread unfolded over at Panlibus earlier last week. I found it to be a good starting-point for a larger discussion about how Web 2.0 and Library 2.0 technology and software could come together in a cohesive manner, instead of the traditional ad hoc, piecemeal, vendor-driven method.

In response to Hennepin’s new commenting capability, Talis’s Paul Miller asks the question, “Participation is an important part of moving forward. How much better might shared participation be?” What he’s talking about is allowing other libraries to access Hennepin’s comments in an effort to provide a more enriching search experience beyond Hennepin’s OPAC, say, at Ann Arbor, or wherever.

What Paul goes on to propose in a follow-up post is a shared collectionof user participation much like the UK’s archival project. This would provide a central database and, presumably a set of web tools to access and interact with the data. Libraries anywhere in the world would have access to add and read content. It would be a shared, collaborative clearinghouse of participation.

I’m all for it–but with some caution. Isn’t that what Amazon is now? If you take away the e-commerce, Amazon is a collection of reviews, tags, and ratings on an insanely large amount of material. Interesting? Indeed. Useful? Of course. But I feel the need to point out that libraries are community-based institutions. They are supported by local taxpayers and are run, mostly, by members of the communities they serve. As such, wouldn’t we want any social element that is incorporated into our OPAC to reflect the tastes and opinions and personality of our community? I think so, and so does Ed Vielmetti:

…here in Ann Arbor there are a lot of book readers, and it’d really be rather nice to read comments from people who shared the same town with you. If I want to read random untrusted comments from people all over the world there’s already Amazon.

I mentioned some of this a while ago, though never specifically addressed the local vs. global social data repository idea. All this is not to say that in addition to community-driven social software we can’t access and make use of a shared data store. In response to a comment I made to Paul’s second post on this, Fiona Leslie made two very good points that she has seen come up repeatedly.

1. Libraries have reading groups and staff who create reviews, and there is no mechanism for getting those reviews “available” beyond posting them on notice boards, or perhaps on the library’s web pages. A few of them have an OPAC implementation that allows the reviews to be viewed in their OPAC.

2. Libraries have few or no reviews, but they see the value in having them, and would really appreciate a kickstart by having access to a shared repository of reviews created by other readers and staff in other areas.

Ok, so I’ll address each one separately. First, she is absolutely right, there is no de facto method of integrating participation in to our OPACs. This is compounded by the fact that our OPACs themselves tend to be unalterable beasts and we must rely on vendors themselves to make changes and enhancements to them. Many of you who follow what I write here know that’s a contentious issue for me, but I’ll keep my hackles down for now and simply remind everyone that this is another reason to demand a few basic rights from our vendors.

But even if we did all have unfettered access to our OPACs, or were resourceful and persistent enough to subvert the plain vanilla foisted upon us, what would a socialPAC look like? Fiona specifically mentions reviews, so lets stick with that for the purposes of this post. Actually, let’s not, because it doesn’t matter what the implementation looks like–that’s the fun part you and your development team get to mess about with when you do your redesign. What’s important is what we do with that review data after we get it and the value it adds to the process of searching for material. I’d suggest that the data be made available via two conduits. First would be the end-user interface. That is, the website or application patrons use to both consume and produce the content. How you weave this in to your OPAC is ultimately up to you (or… up to your vendor).

Richard Wallis weighed in ad responded to my comment. He writes:

So what are my assumptions then? Well firstly, the contributions of the citizens of Ann Arbor would be of great use, interest, and value to a far wider audience than just their district. Secondly, contributions to any global pool should be tagged as to their source and type. Thirdly, because of that tagging, selection of results should be able to be via many filters such as library, library authority or institution, library type, country, language etc.

So following through those assumptions in John’s situation, I would hope that contributions for my community would add value to the global pot; be displayable locally in isolation as a coherent set; and optionally could be supplemented by those from other appropriate communities around the country and the rest of the world.

I suppose I was a little unclear in my comment on Panlibus. I’d agree with Paul that, once the data is in, it would be nice to have a way to share it with other libraries. And I also agree with Richard that there is a place for supplementing existing data with a larger pool. In fact, I believe we have an obligation, as libraries, to do some manner of both. I envision Ann Arbor’s system providing a very lean web service on top of this entire system. Using this model, we will be able to share our community-driven social data beyond our borders. Libraries who do not enjoy the same community support that Ann Arbor, has will still benefit from the data. I believe this distributed approach to generating and maintaining socialPAC data will ultimately offer both redundancy and diversity. The thought of hundreds of libraries making their data available is certainly a more appealing alternative than that of the monolithic database. Metadata itself is an archive–it tells a story.

Fiona’s other point was that kick-starting a service may be difficult, especially in communities that are not likely to respond to and prime a service like this. Personally, I think we all might be surprised at the response that socialPACs will have with our constituents. Almost everyone has an opinion, and most people want to share it. That aside, however, Fiona is right. There will be cases where social software is not successful, popular, whatever.

So how do you evaluate your own situation with respect to social social software? Can your community sustain a socialPAC in perpetuity in a manner that will continually reflect a unique attitude and personality? If it can, how do you get it started?

First, you’re going to have to be honest with yourselves about the project itself. Do you want to pursue social software because it’s cool and hip, or do you really want to change the way your users interface with your collection in profound and personal ways while building a legacy at the same time? You can get a good feel for the level of Web 2.0 participation your community engages in by using existing Web 2.0 services which often let you dial in on specific locales. This may give you a good indication of whether a program like this might be a success.

If you’re convinced that your community will support a socialPAC, the next step is to come up with a a design and interface concept that will truly let your existing catalog shine while providing all the Web 2.0 immersion people expect. (easier said than done). This is where the innovators need to step in and start coming up with tangible examples of how this might work. I suspect that most libraries that do this will pursue a variation on a theme, but bear in mind that there are a lot of directions to take this stuff and in the end, it’s the one-of-a-kind feature that will give your OPAC its fingerprint. I suppose that vendors will dial in on the more popular and successful models and run with those. I have no problem with that as long as they adhere to the Web 2.0 spirit.

What about the initial “jump-start”? While I was writing this, my thoughts kept drifting to sourdough and I remembered a good friend of mine who, on occasion, liked to bake sourdough bread. It was this person who introduced me to my first sourdough starter. A shapeless blob that lives in your refrigerator and which, on occasion, you feed. At any rate, he was telling me how some sourdough starters have very rich and colorful histories because they have been passed down, literally, through generations. Some are closely guarded, while others have been disseminated and passed around liberally. It’s pretty fascinating.

But before I digress completely, Fiona’s concern about kick-starting can be addressed if we make our metadata available to systems starting up. Instead of one or two large repositories, however, wouldn’t it be great if we could choose from hundreds and all we had to do was send a request against a web service to get started? The tools are in place to allow this kind of interaction. All it takes is a willingness to communicate and share.

I suppose I may be searching for blue sky here, but Web 2.0 gives us a chance to do things properly from the beginning. Ultimately, the successful system will be rich with good data and useful to your patrons. The deeper significance of a unique repository will not emerge right away, but in time, you’ll see how data, like buildings themselves, can add to the legacy of a place. Make it available to the larger library community and we’ll see some very interesting things, indeed.

Since library camp, I've been pondering the plight of "tech-depressed" libraries--that is, libraries that don't have at their disposal either the staffing or the equipment to provide the services they would like. The problem is not so much purchasing software, since almost all of the good software is free. Open source, for instance, doesn't cost a penny in licensing fees, but it does require expertise, experience, and finesse to mold it into an implementation of your vision...

...Which leads me to believe that envisioning the future of tech in libraries requires someone who is passionate about technology and all the great things it can do. In fact, without that one person, or those few people who create the impetus, a library is often left doing things like foisting their website development off on someone who once experimented with exporting word documents to HTML back in the nineties. But what if your small, tech-starved library does have someone who is raring to launch headlong into a project like the dreaded website redesign? Say you are that person and you've scrounged up enough money to buy a decent new server, the box arrives and it's sitting in your office. How do you get from point A (server in a box) to point B (a bangin' new website with all the bells and whistles you want) if you don't even know which operating system should go on the server?

Step 1: Take the server out of the box ..

Ok, so that's actually not what this post is about--I'll be writing in much more detail about website redesign over the course of this year. No, The point I'm trying to make is that you may be an extremely motivated staffer, but if you're not technically a techie, you're bound to run in to situations where you don't know where to begin and the idea of putting together a critical path completely overwhelms you. Where do you turn? There is some measure of relief available now if you know where to look, but ultimately that expertise needs to come from another library. That means that the more fiscally-fortunate libraries need to decide whether they are going to commit to being a resource for the larger library community. If so, how would that even look?

Paying it forward

We talked about the notion of "paying it forward" at some length during one of the sessions at Library Camp. One individual, Sean Robinson, has put together a wiki where willing parties can sign up, offering their expertise and services to other libraries. The caveat is that if you take advantage of another person's willingness to help, you, in turn, need to make yourself available to help someone else.

I think this is a great idea that may very well help a lot of people, though it does have some drawbacks. For instance, while I have volunteered my time and services on his wiki, I'm generally very busy and may not have time to help someone when they need help. There is also no assurance of the quality of information and help you'll receive. In addition, while Sean has started a wiki (which is a very nice gesture on his part, and I encourage other to participate), if a service like this grows, a fair amount of thought would need to be put in to developing a database and interface that would make accessing the right expertise fairly intuitive. Who knows, it might look like eHarmony for library geeks!

Officially adopt and open-source agenda

If you have coders in your library, make your administration familiar with open source. Make sharing your code official policy so that when you have written something useful that may benefit the larger library community, you can immediately release it without seeking approval. Know what type of license you'll release it under. Will you use GPL, Creative Commons? You'll also want to ensure that your vendor will not have a problem with you exposing their "process" via code.

Implement this process technically--set up a process through which new and updated products can be released to the public and current users can be notified of bug-fixes, vulnerabilities, etc. In my case, I use this blog to release potions of code and make a post whenever I do an update. Your library could do something as simple as making your CVS or SVN repositories available (CVS and SVN are open-sourced (of course) version control packages--I'll be talking more about those in the future).

Coding for everyone

If your library commits to distributing code for general consumption, the next logical step is to look at how your coders are coding. Does their product stand alone? Can it be ported easily to another organization? Are software libraries modular enough so that another library could start coding with them right away?

If not, then you may want to change your programming style. Write completely object-oriented software. This has many advantages not only in terms of making software reusable in other organizations, but you can reuse the code in-house as well, saving critical development time that may otherwise be spent duplicating work. Of course, most experienced programmers know this, though even the best coders can let bad habits slip in that will tax portability.

Devote resources to open source projects

Consider allocating a portion of your staff's time to contributing to open source projects. There are, literally, millions of projects out there and perhaps thousands that are pertinent to a library setting. If you're using a piece of software, consider giving a little something back. In addition to lending support to an all-volunteer community, you'll be helping to improve the tools we can all make use of.

Public documentation

Be sure to document both successes and failures diligently. This makes sense not only for future reference in-house, but when made publicly available, those notes can be a valuable resource to others. As libraries, we should be no stranger to maintaining documentation. Of course it's a matter of training yourself to write documentation on a daily basis--In IT, we're all busy and we all know that documentation is the first thing to slip off the table. Also, some details are sensitive, so you'll need to know which notes to make available and which ones to place under access control.

The point is that if we maintain a good working record of how we've done what we've done, whether it be in a blog, wiki, or even word files, we can point to it later when someone comes to us and asks, "how did you do that?" From experience, I can say that no matter how much time you spend on a project, if you walk away from it for a few months, it becomes very hard to recall specific details. Write it down clearly and concisely.

Tech "tracks" at conferences

I would like to see a "tech track" added to many of the larger library conferences. For instance, ALA could have a series of presentations that are geared toward the more technical crowd. Unless you're attending a self-proclaimed geek-fest like code4lib, the "tech speak" in most presentations needs to be watered down such that it's not very helpful for those who need to move on to the next level. Those are the individuals who are stuck in that frustrating nether region between power-user and full-blown geekdom.

A tech track could cover topics such as best practices for deploying Linux in libraries, how to use squid and dansguardian to provide both filtered and unfiltered browsing, using iptables to create a secure computing environment, an introduction to flash and amfphp, Subversion and CVS for version control. There is a lot of great material in that strata that doesn't see the light of day at conferences because it's too technical for the organizers. I believe a good number of conference-goers would be interested and could handle the elevated level of technical difficulty.

Co-ops & consortiums

If libraries can pool their resources to build an inter-library loan solution, can they not do the same with IT? For example, couldn't five or six small libraries get together and agree to co-locate a server or a set of servers? A co-op could even share expertise in a much more formal arrangement where response times are more predictable. The cost would be a fraction of what it would be to pay for those services outright. This would take a significant amount of planning and developing up front, but the payoff would be huge for a group of small, tech-deprived libraries libraries.

Reallocating resources

Of course, I've talked about this before, but I'll say it again. The 21st century library faces an entirely new set of challenges that can only be addressed through the judicious use of technology. As such, the planners and budgeteers need to make some decisions as to where money is spent. Maybe less needs to be spent on material (gasp!) one year so that it can be spent on technology. Look at where your patrons are spending their time, get a sense of what they want and need. It may be that your community is happy with what you're doing, or it may be underwhelmed by what you're not. As always, identifying what they want should drive spending, it shouldn't be the other way around, where patrons are forced to use what we've spent money on.

Long-term planning

I was interested to hear from one individual at Library Camp who was in the middle of a strategic planning initiative. I was thrilled by the fact that she had come to the event as a way to help her hash out some of the ideas she and her institution were working with as they plugged away at their planning. Radical new ideas are the cornerstone of long-term planning. A willingness to change and adapt to technology is another, so when it comes time to map out the next ten years of library service, there should be a recognition that technology is playing an ever increasing role in our institutions, as well as a commitment to ensuring a place for it on the mantle of public service.

Libraries as family

If we were like our profit-seeking commercial counterparts--not charged with the noble mission of preserving and promoting knowledge and thought, the very idea of sharing our successes with one-another would seem ludicrous. One of the reasons I love working in a library is because of that mission and because the ultimate goal is not to hoard, but to share--an act that can often times be completely counter-intuitive to human nature. But we can reach out to each other and extend ourselves using the full measure of our humanity because, in the end, we are all one library, just as brothers and sisters are all one family. Family takes care of its own--no other public institution is quite like us which is why we'll always help out another member whether they've found themselves stumped in a technological quagmire or ravaged by flood.

[update]
After publishing this post, I received an email from Glenn Peterson of Hennepin Public Library. He's just completed work on a new site called EngagedPatrons ... not to be confused with a service for soon-to-be betrothed library users, EngagedPatrons strives to assist qualifying libraries meet some of their online goals. From the site:

We provide website services for public libraries. We enable you to offer your users a more engaging and interactive web presence. EngagedPatrons.org (EP) services fit seamlessly into your existing web site. To your users, it appears they have never left your site!

Be sure to check out the FAQ as well as it fills in some of the interesting details about how the service works.

Fantastic work, Glenn! This is exactly what I'm talking about when I say libraries take care of each other.
[/update]