As a library web developer with practical experience processing MARC data, I believe the first indicator of the 856 field is useless. It is useless for two reasons. First, the access method for a given URI is usually built into the URI itself. The vast majority of the URIs found in subfield $u of an 856 field will tell you the access method is, for example, based on the File Transfer Protocol (FTP) or the Hyper Text Transfer Protocol (HTTP). That is why our URIs have prefixes like ftp:// or http://. The second reason it is useless is because there is already a subfield $2 that can be used if you need to be explicit about what the access method is.

When I have MARC data that looks like the following (in pretty-print form, of course):

856 40 $u http://digital.library.wisc.edu/1711.dl/AldoLeopold $z Available through UW Digital Collections

That first indicator is redundant. I know that the access method is HTTP by the URI itself. Furthermore, if it was absolutely necessary, it could be coded like this:

856 40 $2 HTTP $u http://digital.library.wisc.edu/1711.dl/AldoLeopold $z Available through UW Digital Collections

This would free up a valuable indicator to be used to say whether the electronic location is for a resource with open access. A value of 0 could indicate not open access and a value of 1 could indicate open access. This could be taken a step further in the case where the resource is not open access. There could be a recommendation for local copies of the catalog record to use a subfield which says for whom access is restricted, such as, “Faculty, Staff and Students.”

At present I am working on a project that we have given the code name UW · Forward. Forward is a union index over the library collections within the UW System. Currently the UW System Libraries has 14 different ILS Catalogs, one for each of the 13 four year campuses and another one for all of the two year campuses. Forward searches the data across all libraries.

We deduplicate all of our MARC records so that we can have a single record for items held at multiple locations. As part of the process of deduplication, for certain MARC fields, we add all instances of a given field into the combined record. We do this for holdings represented in 852 fields and for URLs in 856 fields.

The Problem

MARC capture of URL description has proven to be inadequate in our context. We simply do not have the kinds of information coded in 856 fields to clearly present access to online representations of library items.

Licensed Content

When a particular campus has access to a licensed online resource, the local version of the URL used is incredibly important. The library in question usually needs to proxy the URL through a campus authentication & authorization mechanism to provide off campus access to databases and e-journals. These are arguably the most important online resources in our catalogs – they are not only carefully selected, like all online resources, they are also some of our patron’s preferred library resources and the ones taking up greater and greater percentages of the library budget.

This is where the first problem lies: the MARC 856 field does not provide any indication that a given URL is for a licensed resource that has restricted access. This problem is complicated by the fact that sometimes a UW System campus catalogs a URL in its proxied form and other campuses insert a proxy string at runtime. In this case the cataloged form of the URL is not proxied but the OPAC software inserts the proxy prefix when it outputs a web page. A “restricted access” or “deep web” indicator would be great here. Alas, the indicators are already reserved.

What makes this more complex here at the UW System is the fact that the Forward project is a union index and provides a single view for all campuses. So we have the added problem of not just telling the end user what the correct URL is, but for whom that URL is valid. Traditionally this kind of information is coded into the free text public note subfields (usually $z). As a free text field, the way any given library indicates that a URL is available only to certain users is all over the place. There is nothing consistent enough in our MARC records that come from multiple sources that I can address in code.

Free Online Resources

The free online resources that have been cataloged in our OPACs are also extremely problematic when introduced into a consortial/union context. The following scenario represents a huge missed opportunity. There are certain resources that have been cataloged by one or a few of the campuses within the UW System. A great example would be our own UW Digital Collection Center’s site for The Aldo Leopold Archives. Forward currently has a record for this archival collection, for which the data comes from a few schools within the UW System. A close inspection of the MARC data in question the staff view raises a few problems:

There are two URLs, each cataloged 6 times by different schools. However the digital collection that has been cataloged should clearly indicate that it is available to the entire patron base of faculty, staff & students from the entire UW System, not just the six schools who contributed records. We are missing an opportunity to let the other schools who did not catalog the resource themselves benefit from the cataloging provided by the 6 schools that did catalog this digital collection. Again, it would be nice to have an indicator which states this is an “unrestricted free online resource”. The same indicator but opposite value as what is needed for licensed online resources.

Furthermore, there is no agreement among the schools who did catalog the resource as to whether the URLs in question are for the thing itself or a related resource. Notice the way that the second MARC indicator is applied inconsistently in the 856 fields. Some campuses consider both URLs to be related to this resource, while one school thinks one of the URLs is for the resource itself and another thinks that both URLs are the resource itself. The inconsistencies here make it impossible to write code that efficiently displays to an end user how to use the resource in question, which is to say that the descriptive function of the cataloging in question is failing in our unified context.

Steel cage grudge match!

In this corner we have Licensed Resources, weighing in at a hulking 60% of your library budget. In the opposite corner are Free Resources, nimble, agile and known to fell a giant or two. Get your tickets. The fight will be phenomenal and sensational.

Finding solutions that make sense for free online resources are proving to be the opposite solutions that work for licensed content. For example, for free content, the best thing to do is drop any affiliation with the school who cataloged the resource in question, deduplicate the set of URLs and display a small set of links to everyone. However, for licensed content the affiliation between school and URL is important so that the end user can authenticate and prove she has the credentials to use the resource in question. And all the while there is nothing in the MARC data that tells me a given URL is restricted to a particular subset of the population for whom we intend will use our union catalog.

The API works well, though my institution is only using Voyager 7.1 and so we are using one of the early versions of the APIs and it has parts that are not documented well or that are a bit sloppy. There are seeming mismatches between some of the XML values returned and the data the element names represent. For example, when placing a request there is an expiration date that is returned. However, the timestamp that is returned corresponds to the time the request was placed.

Additionally, it is difficult to find complete documentation from Ex Libris on all the different cases for which data is returned. When staff process a request made by a patron, there are many stages that the request steps through. The documentation is a little light on what numeric codes correspond meaningful stage names. Or certain elements appear and disappear as a request is put through different stages, but it is difficult to know this without nearly reverse engineering the process.

These are places that the API could be improved (and yes, documentation is just as important a piece of an API as the API code and requests/responses themselves). But overall, I am quite glad that our ILS vendor is putting these services in place. It enables us to embed ILS functionality in places for which it would be unreasonable to expect the vendors themselves to put them. The work we are doing on our Forward project can also be used in places like the campus portal, where people manage their other accounts associated with university life.

We are writing a Ruby plugin for the Voyager API. We are starting with the basic functions we need:

• authenticate a patron
• return his/her ILS account
• renew items
• place a request for an item
• cancel requests for an item

Our code is not fully baked itself and not documented yet, so there nothing to share at this time. We do intend to share it more broadly in the future.

Just as David Berman urges residents to “leave Kentucky, come to Tennessee,” I can urge my shop to finally ♫ leave PHP, come to Ruby ♫. I have no problem with PHP, I would just like to move to Ruby for the small stuff as well as full-blown Rails apps. I have been looking for something to write simple one-off Ruby apps with, the kind of project that does not require a full Rails application because, for example, it requires no ORM as it has no database. Usually these one-offs were the kind of things I would punt over to PHP.

The particular case in which I am employing Sinatra is a one page web form for paying library fines with a credit card. Our campus has a central credit card payment vendor, so all we need to do is log someone in and figure out how much he owes according to our ILS. The form action submits somewhere else so we don’t need a full web app. We do need to take the logged in user’s ID and query our ILS through its API to get the fine amount. So we will wrap this web form in a campus login and before writing the form, make an HTTP call to the ILS to prepopulate the fine field.

The Sinatra app looks like the following:

./:
-rw-r--r--@ 1 myuser  admin   336 Dec  2 16:21 config.ru
-rw-r--r--@ 1 myuser  mygroup   623 Dec  3 07:54 application.rb
drwxr-xr-x  5 myuser  mygroup   170 Dec  2 13:10 lib
drwxr-xr-x  6 myuser  mygroup   204 Dec  2 16:22 public
drwxr-xr-x  4 myuser  mygroup   136 Dec  2 16:13 tmp
drwxr-xr-x  5 myuser  mygroup   170 Dec  2 13:10 views

./lib:
-rw-r--r--@ 1 myuser  mygroup  585 Dec  2 13:10 authenticate_patron.rb
-rw-r--r--  1 myuser  mygroup  441 Dec  2 13:10 my_account_service.rb

./public:
-rw-r--r--@ 1 myuser  mygroup    19 Dec  2 13:10 index.html

./tmp:

./views:
-rw-r--r--@ 1 myuser  mygroup  3552 Dec  2 13:10 layout.haml
-rw-r--r--@ 1 myuser  mygroup  2761 Dec  2 13:10 payfines.haml

Here is a breakdown of the files involved, getting the simple stuff out of the way first.

Rack & the ./tmp and ./public directories

Sinatra can be deployed as a Rack based app. On our servers we will run this application through Passenger/ModRails, so the tmp directory exists primarily for bouncing the app via

  $ touch tmp/restart.txt

The public directory is what Passenger uses for the application root in the Sinatra app. We are deploying to a sub-URI on the server so we have the following in the apache conf:

  RackBaseURI /fees

And in the document root for the server a symbolic link to point to the public directory:

  $ ls -l /path/to/apache/docroot
  lrwxr-xr-x myuser mygroup somedate fees -> /path/to/sinatra/webapp/public

The ./views directory

I place the HTML views in this location. I use a layout file for the full template for my website with a yield just like I would in a Rails app. The other file, payfines, is a view that corresponds to a matching route defined in the ./application.rb. This info renders the HTML form.

The ./lib directory

I am using this location to keep files that map the XML responses I expect to get back from my ILS into objects that will be available in my payfines view. I am using HappyMapper. The great thing about Sinatra is that you can require 'rubygems' and then use any Gem in your application.

The app itself and deploying

application.rb

The following is my first version of the application file itself. It is in need of error handling and refactoring, but I include it to show just how simple an app can be.

# application.rb
require 'rubygems'
require 'sinatra'
require 'haml'
require 'happymapper'
require 'lib/authenticate_patron'
require 'lib/my_account_service'
require 'net/http'

get '/payfines' do
  h = Net::HTTP.new('localhost')
  hresp, @auth_patron_xml = h.get('/fees/auth-patron-response.xml', nil)
  @patron = AuthenticatePatron::ServiceData.parse(@auth_patron_xml, :single => true)
  hresp, account_xml = h.get("/fees/my-account-response.xml?patronId=#{@patron.patron_identifier.patron_id}&patronHomeUbId=YYYY", nil)
  @account = MyAccountService::ServiceData.parse(account_xml, :single => true)
  haml :payfines
end

config.ru

The final piece is to create a configuration file for Rack. The Sinatra Book has a section on deploying to Passenger. You can also Google for examples like the following:

• Deploying Sinatra on Dreamhost With Passenger
• Phusion, Rack, Sinatra, and sub-domains

• Functional programming and looping
• Understanding map and reduce
• MapReduce, with inspiration from functional programming

There is something that just feels right about creating three applications all working in concert to do the job of a single application: it feels a little bit messy, but good messy. It is not that the code is sloppy or carelessly composed. And while I wouldn’t necessarily go so far as to use cliches about the whole being greater than the sum of the parts, the messiness is what makes the application lifelike. In other words, it is like a library. It is as if each individual application comprises a different department making a contribution to the entire teaching and research mission of the library.

Part of this line of thinking is influenced by an excellent article my colleague Allan forwarded, “Design in the Age of Biology.” In it, the author discusses what he calls the rise of service design. He characterizes service in the following way:

Robert Lusch [14] wrote about changes in marketing, describing a service-dominant logic in which “value is defined by and co-created with the consumer rather than embedded in output.” The “make-and-sell” strategy of linear value chains gives way to the “sense-and-respond” strategy of self-reinforcing “value cycles.” Lusch described traditional goods-centered dominant logic as focused on “operand resources,” tangible assets with inherent value. He contrasted that logic with emerging service-centered dominant logic focused on “operant resources,” intangible assets, which create value in their use, such as skills, technologies, and knowledge.

In our case looking at the way in which our applications operate, the value is derived from continuing to further develop their service orientation. Their value is initially based on the service providing behavior: they expose data that is reused and repurposed by other applications. But now I am finding that there is a self reinforcing cycle that is beginning to emerge as we discover other ways to put that data to work.

Which is to say, these applications are beginning to take on a life of their own.

What is the significance of the network in the 21st century? What we understand as the network is a contemporary realization, or maybe the automated reality, of the old adage that the total is greater than the sum of its parts. And quite frankly this realization was made possible by the amazing things that computers are doing with data.

Page Rank is arguably the shot heard throughout the Web. With their Page Rank algorithm Google was able to solve a problem that was plaguing relevancy in Internet search results: we’re all a bunch of dirty rotten liars. Back in the Yahoo/Alta Vista early days of search engines people were figuring out ways to game the system by lying through their metadata. In order to have their crappy cover band’s web page show up when a user searches for the Rolling Stones the cover band simply needed to put ‘rolling stones’ into its metadata.

Page Rank came along and solved the problem by saying, ok, we will let the network sort out the relevancy and if the network can prove that your website is a good one, you will be rewarded in search results rankings. This is the significance of the network. For better or for worse, the network can prove whether or not the data byproduct of the people is in fact worth what those people claim it is worth.

As Ian Ayers points out in his book Super Crunchers, the world is now using data to make better predictions than traditional experts. What is more, the statistical models being used by doctors, corporations, governments and non-profits are able to leverage the network effects of large data sets to verify how well those predictions are performing and improve those predictions instantly as new data becomes available.

I believe that my issue here is all sematics and I may simply be quibbling over something petty. However, I am splitting hairs over this point because this is a troubling area for libraries in my view. If we get caught up in the mushy people narrative over one of the most significant cultural shifts that is occurring right now, we will miss the point and consequently we will miss the opportunities to maintain the cultural relevancy of libraries in the future. The danger, in my opinion, is similar to the paralogism that because I know the structure of a MARC record I understand how it is stored in a modern RDBMS.

It is imperitive that we know how Lucene/Solr works so that we can make better resource discovery systems. It is similarly imperitive that we understand how to get in the super crunching game. As Andrew and his colleague Lorcan Dempsey have noted on numerous occassions, we need to do much more with our data, because it’s the network effect, stupid.

(For the record, I do not intend to call either Andrew or his colleagues stupid, I am just leveraging a theme that he and I have been riffing on for a couple of years.)

The question is very simple and one that I think has been in the back of my mind for quite some time, but I just read an excerpt on statelessness on the Web from RESTful Web Services that provided me with a new way to frame the question. Richardson and Ruby write:

When you ask for a directory of resources about mice or jellyfish, you don’t get the whole directory. You get a single page of the directory: a list of the 10 or so items the search engine considers the best matches for your query. To get more of the directory you must make more HTTP requests. The second and subsequent pages are distinct states of the application, and they need to have their own URIs: something like http://www.google.com/search?q=jellyfish&start=10. As with any addressable resource, you can transmit that state of the application to someone else, cache it, or bookmark it and come back to it later. (emphasis added)

Here the user behavior seems to be: “Hey, Google, show me whatcha got for jellyfish.”

When I go to my library’s catalog and search for the word jellyfish I think my behavior is different because my expectations are different. I am not expecting the top 10 items on the topic. I am instead doing two different things:

1. First, determining whether anything exists on the topic at my library
2. Second, retrieving and evaluating a list of these items if they do in fact exist

The difference is that of course Google will have information on a topic because Google aggregates everything (or so it goes in the popular consciousness). The library on the other hand should have something on your topic if your topic serves one of the known collection areas of the library. Understanding the stateless nature of the Web seems to bring this out. The following URIs do not reveal the same state:

1. http://www.google.com/search?q=jellyfish: what are the ten best resources about jelly fish according to Google
2. madcat.library.wisc.edu…Search_Arg=jellyfish…: how many, if any, resources about jellyfish does my library have

In designing the interfaces for a library catalog front-end, it would be important to be mindful of this distinction since you are answering two very different questions.

The economist Joseph Alois Schumpeter had a name for this principle of capitalism: creative destruction. Perhaps nowhere does it play out more dramatically — and more rapidly — than in Silicon Valley, where innovation unleashes a force that creates and destroys, over and over.

Technology companies are susceptible to creatively destructive forces when they try to expand too far beyond their original mission. Technologies like computer programming can only be successful if they break problems into smaller pieces that individually solve only a single component of the larger goal. At the time of writing, a computer programming function is defined by the masses (Wikipedia) as “a portion of code within a larger program, which performs a specific task and can be relatively independent of the remaining code” (my emphasis). This principle of modularization at the most basic level of contemporary information technology is important to a technology organization’s business model.

Microsoft and Yahoo both fail so horribly at the world of search and Internet advertising because those problem domains lie at the heart of neither companies’ core service: the operating system/desktop platform and the Internet portal. The reason Google so thoroughly dominates the world of search and Internet advertising is because that is its only core. Everything it does revolves around this core service and all of its activities support this model. The moral of the story is that you must choose your core, your identity and your raison d’être and you must choose it wisely because trying to be all things to all people is a futile exercise.

What does this mean for libraries? In the techie realm of libraries, an institution needs to determine what its core mission is and decide how it will define itself in a world of creative destruction. It will need to be able to clearly and succinctly articulate what those goals are to its affiliate institutions: universities or local governments. The library must not try to do everything; as the current computing paradigm of APIs and web services demonstrates, technology works when it is implemented singularly and exceptionally, but in a manner that is open and unafraid of sharing its data and services.

And finally, the modern library must not be afraid to get in the game and take a turn at trying to creatively destroy the old guard, lest it fall prey to the fate of the Yahoos of the world.

“We believe that knowing who wrote what will significantly help users make better use of web content,” wrote Udi Manber, vice president of engineering, on the official Google blog.

The service appears to be a wiki-style hosting service that puts a premium on identifying authorship.