Libraries need to take a note here. In an ideal world we would develop some crazy software suite that our patrons would install and then use to efficiently find their library and information resources. If we wrote the software ourselves we would be able to control all the issues involved with data compatibility and interoperability with electronic library resources. However, we don’t live in a perfect world and we can’t afford to write such software ourselves.

What Hinchcliffe points out is that the can piggyback on the universal platform of the web browser. With technologies like Ajax that are maximizing the levels of interactivity and fluidity of GUIs on the web, we can develop constantly changing software that resides on our servers. If digital library services are delivered using technologies that emulate richer software and acts more like desktop software, libraries will minimize the amount of burden that they will impose on patrons. The software is a living service that is adapted and tweaked with user feedback and updated as needed. Since the software resides on the web server and is only ever launched through a web browser all of the issues that should be transparent to patrons, such as updates for security or usability reasons, we will never need to force someone to install a latest version. A patron never needs to realize she is using a piece of software. Instead, she simply needs to go to the library’s website.

My library has a lecture series called “Evolving Directions in Academic Research and Resources” where we invite a faculty member to talk about his/her research and comment on the role of the library: its strengths and challenges in the world of a researcher or scholar. The last speaker was a historian who in an offhand comment mentioned that the one thing that is missing from the online environment was an experience comparable to browsing the stacks.

I brought this up with a number of colleagues when talking about the state of the library catalog and of course everyone immediately said that we do have such an experience: our online catalog’s browse by call number feature. But there is a significant disconnect between what librarians know about resource discovery processes and how much our patrons know about those processes. This is where one of Dave’s comments was particularly poignant: “One thing I think libraries need to think harder about: the actual production and presentation of, and not just the collecting of, cultural materials.”

This is a problem that boggles my mind: we have got the goods but we don’t know how to tell people. However, I am convinced that we are on the brink of breaking through this barrier. For example, I have recently seen Jeremy Frumkin’s great work with LibraryFind. This is an example of applying the slickness and sheen to library world a la Google, iTunes, Flickr.

I get inspired by these things, too. I took some time to mock up what might be a better virtual browse the stacks display so that we can start thinking about how to bridge the gap between how a faculty member thinks about the online research experience and how librarians think about it. Dave, I think we are undergoing a change, but it is a change in process more than anything else…

Karen Coyle has is right and Renear/Choi are confused in there concept of FRBR Group 1 entities. Coyle states, “I tend to consider all aspects of metadata to be abstract in nature, since it is a representation of something else.” Renear/Choi state

The argument is simple: FRBR describes works as abstract and items as concrete. If all properties of “higher” entities are inherited by “lower” entities then items inherit the property of being abstract, and therefore items will be both abstract and concrete. But nothing is both abstract and concrete – therefore there is no unlimited general property inheritance in FRBR.

They mistakenly seem to think that because works model something abstract that the model has some kind of “is-abstract” attribute or property while items, which model concrete things have an attribute on par with “is-concrete”.

There is no “is-abstract” attribute for works, expressions or manifestations and there is no “is-concrete” attribute for items. The attributes of an item might be things like “copy number” or “location code.” The attributes of works might include a unique identifier that serves as a reference to collocate related expressions. However, that ID is still a concrete thing (likely an integer, see below). Or a work might have an attribute like “uniform title”. Expressions might add an attribute like “transcribed title” or “language”. Manifestations … well, you get the point. (See, for example, page 32 of the FRBR document.)

There is nothing abstract about an implementation of FRBR. Even if the Work was represented as nothing more than an arbitrary identifier in a system, it is still a concrete thing. Works may be no more concrete than integers, but it is important to remember that in a modern system integers are the thread that binds together the cloth of the fabric of content in a RDBMS. The work entity is simply the thread that binds together the more substantial entities one level down: the cloth-like expressions.

The hierarchy of the inherritance relationship still works because there is no logical conflict between any attributes of a work and any of an item. Renear/Choi come close to acknowledging this in their paper:

It may be objected that this argument is sound but irrelevant as the only properties ever at issue were the attributes (or attribute values, or attribute/value pairs) explicitly specified in FRBR. So for the work entity the only relevant properties are ones such as title, form, context, and so on; but not the property of being abstract. On this account only specified attributes (and/or attribute values) are inherited and the argument given does not apply as “abstract” and “concrete” are neither attributes nor attribute pairs. We believe that even this limited version of inheritance is misconceived, but before presenting our arguments against it we explore it further.

But what I think they miss is that works do not have a property of abstraction at all. I am not sure that Romeo and Julliet the work has any property of abstractness. As Meriam Webster points out “the word poem is concrete, poetry is abstract.” However, investigating the properties of poetry (being the productions of a poet, being poetic) we do not find a property corresponding to abstractness. It is the same with FRBR entities. “A work is an abstract entity” (FRBR document), but that does not mean that Romeo and Julliet the work has the property of abstractness.
Is this moot anyway?

The conflict they raise may actually be desirable. I think there is a bit of a tension between a theoretical model here and a practical model. I live in a practical realm and think about ways to implement a FRBR-based application. In the practical world there is at least one important solution to the conflict of interest that Renear/Choi raise: overriding an attribute (or behavior).

Take a programming language like Java as an example. In Java it is possible to override the behavior or attributes of an inherrited class in a subclass. In implementing a system and working in one of the prominent object-oriented programming languages you might be able to define works as abstract and items as concrete. This could then have useful implications in the display of items in your collection. A user interface could browse works and items differently. When just looking at lists of items you see things that you do not when merely taking a look at the work-view of a bibliographic entity (such as a shelf location).

Incoming Library terms:

• abstract frbr paper
• frbr call number
• frbr Renear & Choi
• renear entity relationship model

I agree with the fact that it is futile to try to beat these companies at their own game. That will never happen by a single library. They have more data and they have something that might be better than all the other kinds: intentional data. They can build their interfaces based on how people vote with their wallets through purchasing data from Amazon or library holdings data at OCLC. They can follow the money and we cannot.

However, this is not to say that libraries, and academic libraries in particular, do not have a niche in the information market. It is crucial for library systems developers to understand that libraries build collections. We make deliberate, careful and researched choices about what goes into the collection. We don’t have all the data at our disposal precisely because we don’t have unlimited budgets, so if we are doing our jobs well, we are only selecting the good materials for our collections.

Libraries can build a research map with a next generation library catalog. A good collection is defined not simply by the fact that it contains multiple items, but because their is some cohesion among the items collected. One thing that I cannot understand is why people cannot look past the physical containers of information objects. For an information collection, the cohesion which makes it worthy of the effort needed to build and sustain it is not based on the fact that they are all physically available items at the researcher’s disposal. That would simply make it a collection. What makes the collection good is the fact that it represents both a breadth and depth of knowledge required to conduct research. Or simply put, it contains good information.

I imagine a research process that is more like a partnership of the big research tools (Amazon, Google, OCLC) with the local library’s online research tools. In his discussion of the way that Wikipedia functions as a probability-based system Chris Anderson wrote in The Long Tail, “Wikipedia should be the first source of information, not the last. It should be a site for information exploration, not the definitive source of the facts.”

My take on the current state of research is similar. In the beginning of the research process it is advantageous as Nate said to go to a source that is not limited by physical geography. However, I think there are efficiencies that can be gained if libraries can get involved in the later stages of the research process.

After finding one good item at Amazon, you are offered “more like this” because someone wants to make a buck by selling you two books rather than one. At a library, where the collection has presumably been carefully selected, if you find the one good book you have a greater chance that the “more like this” offerings will also be more good information.

If Amazon wants to make another buck, what is our motivation? In the university environment in particular, we participate in the original reputation economy. A university employee inherits status from the status of the university. The university’s reputation is based on the quality of the research and scholarship it produces. Thus if I want to improve my reputation as a librarian, I have every incentive to make sure my researchers are finding quality information that makes their academic work as sound as possible.

In essence, I want to select and then make available a great collection. While libraries have been doing a great job building the collection, we are only now beginning to see how much work still needs to be done building systems that showcase those collections.

Incoming Library terms:

• catalogs>academic libraries>arguments
• purpose>catalog>academic libraries

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.

Incoming Library terms:

• www pokesearch

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 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.

This is a keen insight in my view since it really begins to get at the fun stuff that the Googles, Amazons, etc are doing with data that libraries long to do with bibliographic data. Coyle starts to articulate something here that I have not been able to put my finger on: the way that FRBR is a huge step forward but still only has an eye toward an implementation rooted in the way libraries have traditionally done things.

My library right now has been in discussions about subject guides and how to best build and provide access to them. I have felt for some time now that it would be great to get out of a next-generation catalog a system that imparts the kind of knowledge our librarians and subject liaisons put into these projects. Coyle’s post renewed this thought by framing the new catalog model in terms of a “Knowledge Management system,” which to my mind is the true aim of a discovery system.

In the past when I have tried to express a hybrid of a next-generation catalog and a subject discovery tool, I have always framed it in terms of applying graph theory to bibliographic data. I think Coyle’s post helps me to understand this. It seems obvious to use subject terms and call number ranges as one type of edge/vertex for nodes which are bibliographic items. However, her discussion raises the possibility of a new set of different kinds of edge types: translations, abridgements, extensions, etc.

More on this later…

Incoming Library terms:

• modeling things

I’ve had similar negative experiences with open-source software, and actually releasing something gave me a much better understanding of why things wind up like this.

A few years ago, our library decided to write a reference tracking system and pilot it at a few libraries across campus. Since I was, then, the only developer at our library, the task fell to me. Once the system had proven successful at Madison, I thought, “Hey, maybe other people would like this, too.” I got the OK from my boss to release the code under an open-source license.

This, it turns out, is tricker than it might seem. All of those steps I’d fumbled through to make the software run, I had to eliminate, or at least explain, to people installing this software on the servers they have on hand. Databases need to be created and populated with initial data. Web servers need to be configured. Did I want to provide a demo? Screenshots? Big software projects provide installation wizards, but writing those is a bunch of work, and from my boss’s perspective, the software was written and done, and I had other projects to work on.

Then, there were concerns over the quality of the code. There’s some ugly shit in there. Did I really want people looking at that, and pointing and laughing? What if there’s a security bug in the code that could compromise someone’s server? Even if it relies on server misconfiguration, I’d feel pretty lousy if my code got someone hacked. How will people find out about, obtain, and install patches? Seriously, I wondered, is it even worth the work it’s gonna take to release this code?

Finally, I decided that it was worth the work, and that I’d release it, warts and all, in the hopes that it would be useful to some people. In the time since then, I’ve realized that the motivations of an open-source developer are different from that of a commercial project manager. I don’t get any reward from wide adoption, except a warm fuzzy feeling inside and possibly bragging rights if I make something exceptionally neat.

The bottom line: There’s a large cost and a limited benefit to making an open-source project into an open-source product, and that work will never ever happen as long as the project is only used internally — it’s not needed.

Here’s the question, then: Is it better to release something half-baked, in the hopes that it will be useful, or to keep it purely internal and let someone else solve the problem?

(On the particular topic of not documenting the Pear::DB requirement: when Libstats was released, DB was part of the standard PHP install, so this wasn’t a common issue. Reworking the code to use Pear::MDB is the right option, but that’s nontrivial.)