This little feature uses data from our opt-in patron history system. Since we've been offering that system for about a year now, we've been able to accumulate over 300,000 data points. This is another great example of how to reuse your existing data to enrich use experience. Like I've said before, you need to use the data you have to its full potential--even if it's not the data's primary purpose.

Ok, so let's look at the nuts and bolts of this. I was able to cobble this together with two SQL queries. Actually, I was able to get the same results with a single nested query, but for some reason, non-cached results took upward of ten seconds, so splitting the query seemed like the right thing to do.

Anyway..

So basically, you can see what's happening here. First I get an array of all the other users who have checked out this item. Then I get a list of items that three or more of those people have checked out and display it randomly (so it's not always the same list). Pretty easy, of course you need to grow that data before it becomes useful. 300,000 records makes the results pertinent, 300 does not.

If you're curious, head on over to AADL's catalog and test it out.. you might stumble on something new.

The next step, of course, in all this SOPAC business is to try to determine how check-out patterns are changing and whether it will have an impact on collection development.

It only took a year, but I finally got permission to go ahead with implementing what I've dubbed "The SOPAC" here at AADL. That would be "cute-speak" for Social OPAC. The SOPAC represents a slew of features that I've wanted to implement for quite some time now. I'm rather excited to see if library users will respond to these tools in an OPAC setting as much as Web 2.0 users have to commercial social networking sites. I'm fairly confident they will. Mainly, I'm relieved that I no longer need to talk conceptually about features I've been planning to build on top of the catalog.

So what is the SOPAC? It's basically a set of social networking tools integrated into the AADL catalog. It gives users the ability to rate, review, comment-on, and tag items. The concept is nothing new, but the nature of our systems do not yield readily to this kind of retrofitting--something I plan to really start tackling in earnest, but that's a topic for another post.

If you're wondering (and didn't know already), AADL's automation system is III which recently released a software package called "Encore" that does some of what the SOPAC does. We did not purchase it, nor do we intend to. Instead we're going to use the money we saved to buy a Lexus. *grin*

Anyway, I've been messing around a bit with Snapz Pro, and thought that since this is a pretty big upgrade to AADL's site, I would include a screencast covering most of the new features. So for those with 15 minutes or so to kill (ignore the screaming kids in the background):

SOPAC Features

The "front door" to the SOPAC is, of course, the main catalog search screen. Drupal's API made development of this code relatively painless. For example, the blocks on the right-hand side use Drupal's hook_block function, making the development of those blocks simply a matter of writing a function that would return the content. In this case, the right-hand column contains search, tag, and review information.

Let's take a look at some of those blocks:

These two blocks represent the contextual nature of SOPAC. The first block appears in the regular SOPAC, while the second is displayed in the use management tools.

Here are some sample review pages:

Top of review page:

Reviews themselves:

Public view of all my reviews:

Private view of all my reviews:

While writing a review, you can simultaneously add tags for the item you're reviewing. Or you can simply tag catalog items without reviewing them. Here are some same examples of the tag system:

Personal tag cloud (My tags in cloud-vew mode):

Personal tag list. This is where users can manage their tags. Delete, modify, view, etc.

List of items in the catalog tagged with "dogs":

Feel free to visit the AADL catalog to tag and/or review some items. You do need an account to create content, but you don't need a library card to get an account, so these features are not limited to cardholders in any way.

Because I feel that this version of AADL.org is a significant milestone, I've made a tarball of the source code publicly available for download. Included in the tarball is our middle-ware "glue" that allows us to interface Drupal with the III server in addition to all the SOPAC code and supporting libraries. Bear in mind that this code will definitely not work out-of-the-box but could definitely be made to work with any III server with XMLOPAC support.

You can download the package here, or from my files section.

There are a variety of ways to characterize library materials. The type of reader believed to be interested in a particular item is one. Such an indicator, generally known as the audience level, is potentially useful for a variety of activities, including the development of new ways to improve information relevance for retrieval, reference services (including readers advisory) and collection development. Audience-level filters could be implemented in existing retrieval systems to assist users in finding content based on their information needs.

This is not the first OCLC service PatREST has taken advantage of. PatREST has been incorporating data from OCLC's xISBN service for quite some time. By pulling in the data they make available, the data PatREST is able to return becomes significantly more valuable.

Because AADL's PatREST implementation relies heavily upon III's XML server, I've added OCLC's Audience Level functionality to the PHP XMLOPAC class code which is freely available from my files page or you can directly grab it right here.

In addition, Ryan has written up a couple great how-to's on getting item data and featured lists from the XML. I, for one, had no idea it was possible to grab featured lists this way. Ryan Eby has been documenting III's XMLOPAC for quite some time now and he's certainly one of only a handful of authoritative voices on the feature.

David Walker is another, and a very industrious voice at that. Today I had a good chat with him on the Code4Lib IRC channel after he showed me his totally amazing catalog based off his equally cool Shrew project. What he's been doing is exactly what I've been looking for. Even though the Shrew project is currently written in C#, he has plans to port it to PHP5, taking advantage of DomDocument. It's a project I'm completely willing to commit some time to myself, if he asks. The shrew project is "a system that converts the Innovative XML Server into an SRU/SRW and OpenSearch server." He's put a great deal of time into writing XSLT that will translate the III server's output into MARC-XML, Dublin Core, or MODS 3.0. My XMLOPAC class for PHP5 utilizes an older version of his MARC-XML XSLT, but I think when he pulls off this port, the need for my code will go away altogether--his way is preferable.

We also discussed some inherent problems with III's XMLOPAC--of which there are a number, and some potential enhancements. Chief among them would be the ability to conduct business--placing items on hold and such. A lot of work needs to be done, but I'm feeling much more optimistic about my OPAC aspirations now and, thanks to David and Ryan, a renewed sense of enthusiasm. Thanks guys!

[update] Ryan reminded me that Rob Casson is the individual who was kind enough to provide hosting for the wiki [/update]

[tags] OPAC, XMLOPAC, XML, XSLT, Library, Code4Lib, PHP, C#, SRU, MARC, DomDocument, Web Services [/tags]

First, this code is written for use with III's XMLOPAC and requires my PHP XMLOPAC class. That said, an astute PHP coder could easily port this app and make it usable on another system (I heartily encourage that). Someday, I plan to make it completely generic so that all you need to do is pass it the data itself. I'm a little busy at the moment, however.

I am not releasing the card stock images that AADL uses. There was no license info associated with the original images. Until I can contact the folks at UPenn and find out what the deal is, I'm not going to make them available. It'd be very easy to create your own stock, however.

Same deal with the fonts. I was able to freely download them--so should you.

At present, this code is really meant for developers, it is not a "package" that will work out of the box. You must know what you're doing in order to get this going.

I'm releasing it under GPL for all the world to use freely, forever and ever.

Included in the tarball is a README file with some basic instructions. Be sure to read that before emailing me your questions.

Enjoy. I'm looking forward to some possible creative uses. Please email me if you get it working as I'd love to see what you're doing with it. If you come up with a particularly interesting use, I'll be sure to showcase it here.

[tags]PHP, Programming, Virtual Card Catalog, AADL, Web 2.0, Library 2.0, Open Source[/tags]

In addition, I've included an XSLT file written by David Walker which I've modified slightly. It allows me to easily extract subject headings from the XML, so yes, this class now will return an array of subject headings!!

So, be sure to download the latest version. As always, you can grab it anytime from the files section.

Every time this crops up, I've fixed the problem, but it's sort of like putting your finger in the dike--another leak springs up somewhere else. Anyway, the 1.9 update goes a long way toward applying a broader fix to those problems. I'd recommend that anyone who is currently using this class to update because it'll greatly improve your results.

Travis Ennis writes:
Not all libraries have the good fortune to have these kinds of people on their staff, so what kinds of communities will emerge to develop and share these applications?

Lib 2.0 writes:
Let me also say that it is not merely the existence of coders or big budgets which separate the haves and the have not's. There has to be a fundamental attitude and a willingness to change, so when your hacker comes up with some crazy idea, there are a whole bunch of people who are excited about making it work, willing to promote it and test it and document it and train people about it. Just hiring someone who can program, no matter how brilliant, is only a small part of it.

As you might imagine, I've got some opinions on the matter. Before I can address the question of coders in the library, however, I need to revisit my thoughts on vendors, and how better to do that than to respond to Talis's Richard Wallis. Richard wrote a response to my "Road Ahead" post in which he talks about "Orchestrated Library Services" as a framework of tools to enable non-technical staff to produce a constellation of integrated services via the presentation layer. In my post, I stated that there was a disparity between libraries with coders and libraries without coders. Richard writes:

So what is the solution to this technical apartheid - a coder for every library? With today's technology, where an understanding of SQL, database schemas, and programming languages is required, probably yes but that is impractical on anything but a small scale.

First, I don't consider the disparity between the have-coder's and have-no-coder's an apartheid--it's a resource problem. The solution to which is to either hire interested coders, or find someone in your organization who has an interest in coding and foster their desire. I'd beseech libraries not to agree with Richard when he says that having developers on staff is "impractical on anything but a small scale." Yes, in a Library 1.0 world, an emphatic NO in an L2 environment (btw, I tag/categorize my posts with "Library 2.0" for the technorati's and use the shorthand L2 because it seems to not overwork the term). For medium-to-large size libraries, having a developer on staff is just part of the L2 face and shouldn't just be considered a luxury. We need to accept that, and get used to it because it's just part of a larger strategy by which libraries take back the creative development process. I'll say it until I'm red in the face: if we want to be pertinent, the curent model needs to change. The model that we should be adopting looks more like a meta-coop in which libraries work together via a developer's network using a set of platform independent, standards-based tools to create open-source projects, programs, and snippets. That is the real Utopian vision.

But, what if configuring and orchestrating web services became as easy as it now to produce a web page? And, what if the web service based library services supported by library system components became as ubiquitous and standard as say HTML is now? And, what if the tools to do the orchestration became as easy to use as say MS FrontPage [no recommendation as a tool, just an example]. Would, in that situation, the librarian orchestrating his/her Library's service to its customers need to be a coder? No more than they would, to be able to put a Word macro together today.

I see a couple problems with this idea.

First, in order to make such a tool usable to the average user, it would have to be severely limited in scope. To incentivise librarians to use the tool, it'd have to be somewhat simple and intuitive. It would be a major challenge to create a simple, easy-to-use tool that can "orchestrate" services at any great level of complexity.

Second, the services we're talking about are far more complex than html. You can't even compare html to web services/APIs. HTML is a very simple language that is parsed and presented. When you start introducing complex data sets, you've increased complexity by an order of magnitude. There is very little you can do to simplify the process at that point, especially when it comes to debugging and pinpointing the data you need inside a data set.

Third, it's one more third-party, proprietary tool to learn. Library staff struggle enough with the actual administrative interface of an ILS, giving them another tool to learn is not going to make them very happy. It's much better to make business logic ubiquitous and present it using developer lexicon.

Fourth, it adds an extra layer to the development model we're asking for. This seems like an unnecessary "middleman" when it comes to development.

Finally, like I've said before, there is no way for vendors to anticipate every need of every customer. Are vendors going to develop software to integrate and manage patrons' wireless devices? Are vendors going to develop an integrated game tournament system? Will they write a module for every CMS on the market so that it can be integrated into the ILS, or will they just write their own CMSs and expect us to use them?

Vendors need to stop assuming that they know what we want better than we do. For instance, find me a single library coder who does not want read-only SQL access. We're telling you want we want. If you want to know what will drive a library coder to coffee in the morning, it's the spectre of non-technical staff believing that they can hack together a "Library 2.0" site on their own because they've been sold a bill of goods that tells them they can.

This leads into another topic I touched on in my post when I pointed at our own institutions as barriers to change. This is a component of Library 2.0 that vendors should not be addressing because to do so would be placing undue influence on fundamental policy shifts that need to take place inside our institutions. Yes, libraries are experiencing internal struggles as these changes unfold, but these are struggles that vendors have no right to be a part of.

Not only have us vendors got to get our act together in delivering the Library 2.0 technology in a way that fosters and enables the emergence of new processes and new ways of interaction between libraries, between libraries and associated institutions & commercial services, and between libraries and the consumers of their services; but the librarians in, at least a significant proportion of, those libraries must be ready to take their services in to the Library 2.0 world and most importantly understand why they should.

That's part of our struggle, yes. But as I wrote in a previous post, L2 as a concept is still in it's infancy. It'd be irresponsible for vendors to ramp up their marketing engines with a sight toward L2--especially since L2 is such a nebulous group of ideas. Yes, libraries have people who still want the card catalog back, yes we have non-technical people making technical decisions, we certainly don't have a mandate to start implementing all these wonderful changes. All of this needs to be worked out, and while that is happening the best thing for vendors to do is reevaluate their client relationships, take Occam's razor to their software, and work with library developers to come up with a standard framework of open standards and vendor interoperability.

I wanted to revisit the vendor issue from a different angle because it provides a context within which to consider the purpose of coders in libraries. Maybe a non-techie will disagree with me on all this, but I believe that it should not be the non-techies' job to make technical decisions. All of this brings me inexorably toward the million dollar question: should all libraries have a coder on staff?

If you look at a product like WordPress (much simpler than an ILS, granted, but the model scales), you'll see that you don't need to be a programmer to use it. Anyone, with a little time, can install WordPress and start blogging. But many of the really great WordPress sites are those that have been heavily customized and there are a large number of "contribs" (contributed code in the form of plug-ins) that made WordPress such a hit. In the current L2 landscape, you won't need a coder to have a good online presence, but you will need one if you want a great online presence.

Ultimately, MLS programs are going to have to start offering CS electives and eventually requirements. The profession itself is changing with the industry. Databases and networks, increasingly, are information's domain and if we want to be part of the vanguard, and if we want to call ourselves the stewards of that information, we darn well better know how to work with it. So to answer my own question, I'd say that libraries should strongly consider having a coder on staff. In five years, there's no question, you will have a coder on staff or you will be considered quaint.

Let me just give a few examples of how coders are influencing the work going on at AADL:

We have an exceptional high school student on our part time staff, Matt Hampel, who wrote a very useful search plugin.

I released my php xmlopac class for III, and Casey Bisson contributed two very useful functions. Casey's contribution inspired me to make public a bit of code to access and cache amazon images. This, in turn, caught Chris Deweese's attention who is now working on an ASP derivative.

I received an email yesterday from Ed Vielmetti who just wrote an AADL search module for duckytool using the RSS feeds I implemented last month. He's requested microformat output from our catalog to extend his tool, and I think it's a great idea.

DaveyP just announced his plans to work on patron catalog tagging--a project I've got my sights on for AADL. He's going after it with the energy of a terrier and has an idea for a cooperative database of tags. He's sharing his code, too.

Do you notice a pattern? Often times one bit of work spawns another, and so on. This type of collaboration is only going to proliferate. Make it a mantle-piece of library 2.0. This stuff is happening in the coder's workshop, it will do your institution well to take notice. It'll do you even better to take part.

Essentially, those of us who are familiar with the term "Library 2.0" all assemble in the same theoretical nebulae when we read and talk about it, and that's good enough for me. For the moment. But there is the real danger of getting mired in discussions like 'what does it mean to be Library 2.0ish'. That's why I think we ought to have a series of clear objectives that forge a path toward L2. I've put together a list of components that, for me, define a strategic vision for L2 in terms of general statements, questions that need to be asked, ideas that need to be drawn up, and unknowns that need to be discovered. It's important for me to do this for myself because any time I'm in "dev mode" I need to have an ideological framework to work with.

Ongoing discussion: What is Library 2.0?
This is where most of the current L2 discussion seems to be centered, and for good reason. Why pursue something if you don't know what it is, or whether it even exists? I love the current discussion because, despite everyone's differing perceptions of L2, there is a common denominator emerging that defines some interesting boundaries for the term. Naturally, a concise definition of "Library 2.0" is not going to happen--it'd be a house built on sand. Assuming that ongoing discussion is part of L2's foundation seems to be the pragmatic thing to do. Pursuing any subsequent action should acknowledge that L2 has a core set of ideologies that are interpreted differently by many.

What are our current impediments?
I've talked a lot about the culpability of vendors when it comes to stifling innovation. I think the nature of vendor-library relationship is perhaps the largest battle we're going to fight on this winding road and I predict a casualty, or two, among vendors who refuse to make way. Many vendors are still building SUVs in a hybrid world.

But vendors are not the only impediments to L2. It might be worthwhile to look a little closer to home. Your largest obstacles may lie within your own organizations. Perhaps you need to finally have that sit-down with your IT department. Maybe some of the changes heralded by L2 are threats to the old-timers. I have a feeling that many of you read about L2 and think to yourself, "it'd be nice to take our library in that direction, but..". Finding solutions or workarounds to those caveats needs to be an important part of the collective discussion.

A perfect example, that has been discussed a little, is the fact that many librarians wish they had coders to implement their ideas. It's a good example because having coders is the dividing line between the have's and the have-not's. At this point, it's inevitable, but in the long term, that is an unacceptable disparity. For now, however, it's the libraries with coders that have the burden and responsibility to build the prototypes for next-generation online services.

How do we overcome those impediments?
Librarians are smart people and I have faith that no impediment will go unaddressed. Of course, different problems have different degrees of complexity, but discussing and brainstorming possible solutions is the first step in dealing with any setback.

I previously mentioned that vendors are a large part of the problem, therefore it stands to reason that vendors need to be a large part of the solution. We need to be able to use the correct language when we draft RFPs or talk to their support teams. I drafted the ILS Customer Bill-of-Rights for two reasons. First, I wanted to give other libraries a very basic set of demands to present to their vendors. If vendors hear it enough, they might just crack the tiller over a degree or two and chart a new course. Second, I wanted to throw down the gauntlet with vendors themselves and, hopefully, open up a discourse with them. Of course, Talis is the only vendor to respond so far, and they are the only vendor to publicly acknowledge the existence, let alone the importance of L2. I think L2 scares the pants off most of the others.

It's important to demand change not only from your vendors, but from anyone else who is stifling your library's progress. Share your ideas and success stories so the rest of us can see how you overcame adversity. Also, share an analysis of your failures because those are just as important when it comes to making futures decisions and laying plans. Ironically, in the Web 2.0 world, being open and honest about your failures tends to bolster your credibility.

Who is going to facilitate this change?
You, for one. But before L2 can enter the mainstream, we're going to need an "official voice" that endorses L2 from both a technology and human perspective. Once this happens, it'll be easier for everyone to bring L2 up in an organization and make headway when it comes to implementation and, especially, buy-in. Of course, ALA comes to mind, but multiple voices of less authority can suffice, depending on context. For now, the debate over how much L2 matters is pertinent, but at some point it becomes farcical to defend the merits of L2 philosophy. An official ratification of L2 as a label would certainly shake loose some acceptance within organizations as well as put pressure on vendors to turn their sights toward L2. If you can, lobby for L2, spread the good news!

What, precisely do we want to offer?
I think we are at the point now where we need to be discussing, in detail, what types of features and services we want to offer under the auspices of L2. Tag cloud mock-ups, prototypes, RSS feeds, collaborative development, memes, and library blogs all serve as hard evidence of a life after Library 1.0. Aside from all that, however, so much focus is on ubiquitous web 2.0 sites like flickr and delicious. Events like Internet Librarian and the Code4Lib conference will undoubtedly serve as periodical collective brainstorming sessions, but what would be great is a clearinghouse of off-the-wall ideas for the practical application of Web 2.0 in the library setting. There are a few of us in the library-coder community who could certainly draw from that pool to create some interesting prototype services and applications.

Ultimately, what are we trying to achieve?
Every now and then, stop and ask yourself why this is all so important. Maintain perspective on your goals. For my part, I'd like to see L2 reach a 'critical mass' within the next two years. That's an ambitious time-line by any standards when it comes to libraries, but think about the fact that the sooner we start harnessing the intelligence of our communities, the sooner we will be creating a living record of our time. Doesn't that cut to the very core of our mission as libraries? What you want to achieve personally and what you want for your institution need to be aligned so that you can set a clear agenda for yourself as you begin tackling your projects.

L2 is not a fad.
Despite what some people may say about L2, it is not a passing fancy bandied about by a few hypertechno-literate librarians. L2 is part of an evolution that is taking place worldwide--a movement in which the threshold between technology and individuality is giving way. Those two seemingly disparate concepts are starting to bleed together, creating the emergence of a new culture. We can be a part of it, or we can be relics. As libraries, I think we have a unique moral obligation to usher our communities into it.

Bear in mind, this post is a brain-dump of questions and ideas that orbit L2 in my head. I'm certainly no authority on the future of L2, but I do have strong convictions about it and, therefore, my interpretation of L2 may reflect that. My desire is to build interesting, useful, and immersive tools for our users. A simple goal with a very complex path.

[update]
Michael Stephens pointed me in the direction of this month's SirsiDynix OneSource in which Stephen Abram takes a look at Library 2.0. Bear in mind that even though only Talis has engaged in public discussion, other vendors are quietly listening and developing strategies behind the scenes. What we don't want, is a mud-slinging contest between vendors. They certainly don't want that either, so expect most of them to inch in slowly and quietly.

It's also worth noting that Sirsi actually does comply fairly well to the ILS Customer Bill-of-Rights, which is not an endorsement since I have no hands-on experience with their ILS, just a statement of fact. Any SirsiDynix customers want to review their API?
[/update]

This script requires the latest version of the III-XMLOPAC class (1.6), PEAR::DB, MySQL (of course) and PHP5 (or PHP4 with SimpleXML). In addition to that, you'll need to have your own Amazon Dev token, etc.

Essentially, I wanted a way to get more cover art into the catalog. If you currently use Syndetics, you'll know that you almost never get any cover art for CDs and DVDs. My solution was to write this. Just to warn you, though, this script will not return ASINs and cover art for all the items in your collection. Far from it. There is about a 30% hit-rate. I could easily get that higher, but then accuracy drops off, and I want 100% accuracy.

So, I plan on working with this script, massaging the search to figure out ways to get that 30% up. Please feel free to hack away at it yourselves too, but bear in mind, that I'm looking for accuracy above all else. If you're really interested in how I'm determining an accurate hit, take a look at the code. Basically, I'm doing an initial search, then I match the UPC number on the amazon record to the stdnum info from the Bib record. Doing it this way, I haven't seen a wrong match yet.

Incidentally, here is a hit list with images from this script:

To use it, you'd basically do something like this:

<?php
 
$bibnum = "123456";
echo  '<img src="/azImgSrc.php?bnum=' . $bibnum . '">';
 
?>

As a side bonus, you'll have a nice table with Bib#-to-ASIN data. You can even manually add data to that table to ensure your favorite records have images associated with them.

Because of his function, however, I've changed the way get_opac_data() is called. The change is completely backward compatible, so don't worry about anything breaking after you upgrade. The new prototype looks like this:

<?php
$bibinfo = get_opac_data($bibnum, $extend = NULL);
 
// Of course, you can just call it like this:
$bibinfo = get_opac_data($bibnum);
?>

Essentially, Casey's function will only be called if $extend is TRUE (or some value). I've implemented it this way because this class gets some heavy use and I don't want it polling OCLC every time I grab a bib record. I envision the $extend flag to be used in cases where external web services are queried. By default, those features will be disabled.

Also, in 1.6, I've fixed a pretty bad bug that would often times return an invalid ISBN. I've broken that bad ISBN number off into the "stdnum" key instead.

If you're using this class, you definitely should upgrade to 1.6.

[update]
Actually, grab version 1.7. I didn't add a test to make sure a record has an ISBN before it's shunted to Casey's function. As such, you might get a PHP warning depending on your error report settings. Nothing major, just an annoyance, 1.7 fixes that.
[/update]