One Big Library.

Wednesday I spoke at the TCDL 2009 conference about why I think Linked Data is important for libraries. I've given talks about this twice before, once at the code4lib 2009 pre-conference on linked data, and a variation on that talk at the TCDL 2009 developers forum pre-conference Tuesday.

This was the first time I spoke about this in a room not entirely filled with hackers, though, so I couldn't just start talking about conneg and RDF models. It needed more context. As far as I can tell, the context that matters most is that we've been building a web for fifteen years, now, and we've continually changed how we build the web as we've changed how we use the web. So I spent most of the talk stressing how adhering to the four rules of Linked Data can help us make our libraries' stuff more relevant, more connected, and more likely to be found and used by improving how we link things together.

First, though, a comment about the contents of the slides - I work for the Library of Congress, but I wasn't representing the library at this talk, which I traveled to and gave off work hours. So that second slide is for real - the opinions are my own. You'll see a lot of LC examples, there, though, for two reasons. One is that I see these sites and think about them a lot, much like the rest of you, just more so because I'm there. When I can show an example from an LC site, it's likely something most people in a room have seen before and understand. The other reason is that LC has a long history of doing digital library stuff, so long that a lot of what's up there looks prehistoric in some ways, but at the same time, there are a lot of cool new things happening there, not all of which get a lot of attention, like LCCN Permalink. I don't work directly on any of the systems which have screenshots in these slides, so when you see images of those systems, you're not seeing my work. I know a few scattered details about the systems and am lucky to get to interact with many of the people who work on building them, but when I spoke about them at TCDL I had no intention of representing their work, and said so. My comments probably seemed more critical than promotional, but I meant them to illustrate situations we all find ourselves in at all our institutions, that we all know well about already, so it's not news to anybody that we all need to improve how we do things.

So, right, disclaimer doubly disclaimed. On with the slides:

I really enjoy events like TCDL - a single track, a healthy mix of public services, technical services, IT, managers, and administrators, and a tech focus but with a broad perspective necessary to talk tech in a roomful of diverse skills and interests. It really focuses my attention on the one or two issues that are at the core of the changes in technology coming at us. It seemed like people received the talk well, as I heard several comments from non-coders and coders alike about how it made sense that we should move in this direction.

Unfortunately I had to leave early but I'd encourage you to look at the abstracts and learn about all the great work being done in the Lone Star state.

It's 4am and I just woke up from an absurd dream wherein I delivered the worst talk of my life to a dwindling group of college graduates at their commencement. I have no idea why I was doing that, but it had something to do with the Preamble of the Constitution, which makes even less sense now than it did during the dream itself.

The upshot of this dream was that my talk had one great "slide" which seemed to be worth sharing. It read:

• You can never have too much openness.
• You can never have too much freedom.
• Remember the 7 Ps (courtesy of my late cousin, who served as a Ranger):
  

  Proper Prior Planning Prevents Piss-Poor Performance.

• All of the above means you're going to have to work like hell.

Of the hundreds who entered the ceremony at the start there were only a few dozen left when I finished making these points, but I got the feeling that they got it, and that was enough, and then I woke up.

Here are the slides (all one hundred and thirty-freakin'-five of them) from the keynote/"vision" talk I gave yesterday morning in Louisville, KY at NASIG 2007. I was very sorry to miss most of the rest of the conference, but was quite glad to have the chance to present this talk to a very engaged crowd (especially considering it was 8am on a Sunday) and catch up with several friends I hadn't seen in ages after the talk.

The name of this talk is -

A New Approach to Service Discovery and Resource Delivery

...and that's what it's about.

In it I reprised some slides and concepts from previous talks I've given at a NISO meeting last November and code4libcon this past March and a few more slides from an earlier Access talk. But rather than just rehash slides explaining why COinS and unAPI are useful, I tried to place their potential benefits in a critical light, and from that perspective, I tried to state a much higher standard we need to try to reach for, and not settle for less, and one obvious (to me) way to get started.

That path is through the dynamic service links we now see everywhere. In this talk you'll see a series of slides about 2/3 through that start to explain what I think we should work on next - a way to unify interfaces to those peskily incompatible service link boxes that would open up a ton of doors that would remain closed even if COinS and unAPI both really exploded.

So have a look, and, if they don't make sense on their own, rest assured that a healthy number of serials librarians (at least a good 1/3 to 1/2 out of several hundreds at one point or another) seemed to be nodding vigorously in agreement with the proposal early yesterday morning.

I'll do my best to give it a more direct blog writeup in the next week or so, but I'll be offline a lot this week for some old-fashioned Stuff To Do and Places To Go. In the meantime, enjoy the 135 slides. :P

(Last in a series.)

Last week I gave the talk I'd been leading up to. Here it is in a nutshell (photo by Nicole Engard):

The premise of the talk is: people are already starting to ask us "why doesn't the library work like iTunes?" By this they really mean (I think) "how come when I walk into the library everything in the library doesn't just show up on my machine like when I open iTunes and my friends' music just shows up on my machine?"

I think we need to take this question very seriously. Especially because there's no good reason we can't do just what that not-so-hypothetical user wants. A great candidate networking protocol (ZeroConf) is already out there, flowing in the network. We could layer OpenSearch over our metasearch interfaces, and intermingle search and resolver services fairly easily, and along the way *every* one of those steps would have side benefits: merging OpenURL resolution and metasearch UIs into a single view simplifies things for users; adding OpenSearch means you can put your library's catalog right into your users' browsers; using ZeroConf to announce your service makes it easy for everybody to find your interface from anywhere.

During the talk I demonstrated just how much ZeroConf is already flowing all around us - we're swimming in it!. Apparently the video didn't video, so to see how it works for yourself just try the follow the next time you're on a network with a lot of other users (like, a public wifi spot would be ideal, but it should also work at your workplace).

• If you haven't seen it before, turn on iTunes music sharing and look for people sharing their music. It's fun and incredibly easy.
• Install iStumbler and look at the bonjour services tab (note that this is also a useful tool for browsing wireless nets.
• Install Bonjour Browser to get a closer look at the network traffic underlying the more user-friendly screens in iStumbler.

The conference wireless AP was unreliable, so I bought my own and turned it on as an open wireless net (named "librarywebclique", in honor of librarywebchic). In the middle of the talk I invited participants to join the net so I could show the ZeroConf traffic in iStumbler and Bonjour Browser. In a matter of seconds, about 20 people had done just that and all of us could see who was sharing iTunes, who had visible web servers, SMB shares, or ssh ports open, among other things. From where I was standing, it was a pretty convincing demonstration, and all it entailed was showing everybody what their machines were *already* doing.

I can't stress enough how important it is to keep a close eye on what's already happening out there on the net at a global scale. The microformats.org project is frustrating in many ways but they're dead right in their insistence on recognizing what's already out there as primary (though I'd quibble over their self-consistency in enforcing that, but that's another story). This traffic is flowing on the network - lots of widely-used apps already use it - there's no reason we can't just hop aboard.

I'm attaching slides and audio as best I can, but imho it was the kind of thing you had to see - it's very easy to make a point about what's possible by showing that it's actually already out there. Still, try those apps above (they're OSX only, but the traffic isn't, so you can probably find similar apps on other platforms) and you'll get the point.

Near the end I took a few questions, but didn't think to repeat them. One was "what about remote access?", to which I responded that this model doesn't really improve much on that set of issues or make it much worse, though in theory by adding desktop-level discoverability it's possible it could improve things slightly. Another was "what do you think the interface to this would look like", which is a bit tougher to answer. There are examples like iTunes and Delicious Library to follow for what it should look like when a library just "shows up" on your machine. But I think my immediate answer was the right one - I don't know, but it could show up in a lot of places, like the browser, or a desktop app, or on server apps, because this is a platform/infrastructure level service opportunity. In one of those answers I stated that "if we don't provide this level of ease of use, then we're failing", and because we don't, I think we are. Failing, that is.

There is a lot of talk out there in biblioblogoville about "getting into the flow", but I can't imagine a better way to do that than to radically integrate our most flow-oriented services (metasearch and openurl service resolution) and advertise its availability on our networks. And it can be accomplished quickly, cheaply, uniformly, and with a variety of side benefits.

Which, of course, probably means that it'll never happen, because our community isn't really capable of this kind of realization, let alone acting quickly upon it at scale.

That doesn't mean that I don't think you should bother with it - of course not, I think this is all very doable, and I hope that I met my objective of trying to frame all of this in a positive light: see the last few slides, where I suggest how to respond to "can't we make the library work like iTunes?": we should respond by saying "yes, let's."

The slides are attached as pdf, and here's the audio to lead you through 'em. You can hear my clicky-taps to advance the slide most of the time.

Today I gave that talk at the NISO D2D meeting. I think it went pretty well despite having gone way beyond what I'd originally thought it would cover.

The first part basically introduces and gives background for why COinS and unAPI are useful steps forward. The second part argues that:

1. We should merge our metasearch and openurl resolver interfaces
2. We should layer an opensearch interface on top of that
3. We should register the opensearch interface as a DNS-based wide-area zeroconf discoverable service

Why? If we did all of that, then everybody visiting our domain could find our base search interface, and remote services visited by people from our domain could find our resolver interface.

The slides are attached as pdf. Sadly I botched my own audio recording, but tomorrow I'll plead for a copy from the soundboard guys, and will add that too if I can get it.

[Updated 2007-01-08] The audio is a little blotchy, but here it is.