[This column was originally published, after additional editing by somebody who actually knows what they're doing, in the September 2007 issue of Computers in Libraries magazine. Which means I wrote it in July 2007, at which point I thought I was going out on a limb suggesting that folks would start to look at Facebook differently. Seems passe to say so now, but I thought I'd still add my $.02 sooner rather than later.]

The hottest social network of 2007 seems to be Facebook. I entered university in 1989, and we had a paper facebook. We used it for all the reasons college freshmen at a Big 10 school used a facebook. And somehow there was always that one guy who had to pose with his guitar in the frame - and a few short minutes perusing facebook.com indicates that that same guy is still out there with his guitar.

Facebook has done interesting work with its platform API, and its integration with “meatspace” human networks just might make it the first online social network that offers some sort of sustaining value beyond being “where the online hipoise hang out this year.” Last year that place was MySpace; the year before that it was del.icio.us, before that Orkut, and Friendster before that. Somewhere in there LinkedIn popped up for a “more serious” crowd, too, among other services such as Flickr for the photo-takers, and YouTube for the vid-makers. (No word yet on which web 2.0 startup will secure the vital demographic of butchers, bakers, and candlestick makers.) And there’s always Twitter for the status-obsessed, along with myriad competitors and copycats of all of the above.

I’m resisting Facebook, seeing as I’ve tried most of these other networks and found little substance beyond the initial excitement of finding out yet again that yes, I am indeed within six degrees of separation from kbacon22. What’s the point of hopping onto the newest network? The answer just wasn’t clear to me, especially since we librarian types aren’t exactly early adopters. Face it, facebookers, most of us weren’t on Facebook a few years ago when it was really a students-only application, and by now a lot of those early users have graduated or moved on to whatever new apps you’ll be reading about in CiL in 2008 and 2009. This is not your daughter’s social network application - or, at least, not any more, it isn’t.

You’re the Star

Meanwhile at my new job, we’ve been debating which metadata fields to capture and index on the project I’m working on. Which fields are which isn’t really worth mentioning here, but I’d like to reflect on something I’ve learned about metadata after having done this about ten times in five different environments. There are a lot of things to keep in mind, and distinct needs to balance, when deciding how to describe resources:

• descriptive metadata must provide access points to support discovery, relating of like items, and distinguishing between very similar items
• metadata values must be indexed so that common user search patterns will lead to relevant items, because an easy, useful search box at the top of every page is how most of your users will use your applications
• choices for metadata value forms (such as authorized headings or standardized date values) must support necessary user interface functions, like result sorting, browsing by topic, or viewing results on a map

The last two of these items seem pretty obvious - after all, if you want to sort views of your resources by date, you’ll have to let somebody line your dates up consistently somewhere, and if you want people to find your stuff, you have to make sure the terms they use to search actually find them what they want. But it’s that first point - the clear definition of access points - that always seems to clinch metadata schema decisions. Maybe we’ve come a long way since the Author-Title-Subject card catalog, but concepts like “main entry” are still deeply important. Systems and software give us more flexibility than ever before to tweak indexing algorithms or relate data in innovative ways, but if you’re a developer like me and you don’t have a clear sense of what your most important access points are, you might deliver a system that works well, but only for people who don’t really want to find what they’re looking for.

And this is why I think I get pulled back in to the each of the next, best, hippest (or even “hippest” in the sense that “now it’s mainstream and there are a ton of people in there even if it’s not really cool and new anymore”) social networks. I log in, create a profile, and identify a few friends because I am an access point.

And so are you.

In the decade since web use went mainstream, there’s been a lot of talk about what’s now known commonly as “the long tail”, or the ability of large-scale systems to help people with like interests find small-scale products none of us might otherwise learn about. We’ve talked about it before in this column, like when I wrote about the ability of Amazon.com’s servers to point you toward a musician or kitchen appliance you hadn’t heard of before but that a lot of people with otherwise similar tastes to you might have chosen happily over some better-known artist or brand-name product. In web 2.0 parlance, this is known as the “network effect” of the “architecture of participation”, which I’ve also written about here before.

In the case of you and I as access points, we’re talking about the difference between an online shop telling you that “people who liked Bonnie Raitt also liked Shelby Lynne” and a social network telling you that “your friend kbacon22 likes Dansko shoes.” In the former, you can find Shelby Lynne’s music if you search for Bonnie Raitt, and vice versa. But in a social network, you can find Dansko if you befriend kbacon22, and vice versa. Everything in the metadata requirements bullet point above for an access point applies here, too:

• it supports discovery - “ooh, new Dansko clogs, thanks kbacon22!”
• it supports relating like items - “oh, I see that kbacon22 likes The Hold Steady, and so does sjparker212.”
• it supports distinguishing between similar items - “oh, kbacon23 can’t be the guy I was in a movie with, because kbacon23 is actually a 27-year-old librarian in Modesto.”

This might be a painfully contrived example, but it’s not that far off from the truth. Recently in facebook (yes, I’ve now logged in a few times), an old college mate I hadn’t spoken with in over a decade befriended me. How did he find me? Our university was the first access point, I’d guess. And then how did he know I was the same guy he’d studied with? Well, that’s easy - my last name is unusual. But if it weren’t, he could, in theory, look at some of my “added entries” to see if I still like the same kind of music we both liked while in college, for one thing, or if we’re still reading the same authors (I think he still has one of my books, actually).

Maybe Facebook will be the social network that finally breaks all the way through to be as mainstream and widely used as major news sites and search engines, or maybe it won’t. But if it does, we’ll all need to get in there, because we’re all main entries for something, and added entries for something else, and if we’re talking about a Facebook For The World then we’ll need all the access points we can get.

Commoditizing the Reverse Supply Chain

There’s a down side to all of this talk of things “social”. As soon as you become an access point, you also become a data point. Make no mistake - Facebook and MySpace wouldn’t still be around if they couldn’t make a lot of money off of each of us, so remember that while your use of these services makes it all seem better for everybody else, the sites’ owners are skimming profit right off the top of that network effect.

One ugly phrase that gets to this truth effectively (which might be what makes so many people react to its ugliness) is “user-generated content.” I know, I don’t like it, either. But what does it really mean?

Do you know about supply chains? If you don’t, look up the term, or if you’re impatient, just think about your car, or your computer. They’re complex products, made of lots of tiny little parts (keys and power window switches) and big parts (screens and bucket seats) alike. Your computer maker and car manufacturers don’t make all those parts - they assemble final products from parts supplied by hundreds-to-thousands of other companies. (Actually, computer assembly is typically outsourced, too.) These other companies - suppliers - could be anywhere in the world, and they might specialize in those parts to the degree that they don’t care where the parts end up, so long as the contracts are lucrative enough. It’s the carmakers’ and computer companies’ jobs to design products in concert with negotiating contracts with suppliers to ensure they can break even on sales after you add up all the costs of individual parts, their transportation, storage, assembly, and final delivery to customers.

The information business mostly works the same way. There are authors, editors, and other creative producers who source, revise, assemble, and deliver products that ship to different markets like readers or libraries or publishers of magazines like this one. In most cases, the money flows back into the information supply chain through advertising dollars, subscription fees, and consumers paying for each item they purchase. Knowledge about who buys what provides feedback to the suppliers, the publishers, and the authors alike so that they can consider how best to reach the buying public with their next product.

What I don’t like about social networks is that they’re also a marketplace for a reverse supply chain. Instead of some pre-packaged information collected, arranged, and assembly for delivery to your doorstep or web browser each day, you (yes, you, in the shiny mirror on the 2006 Time Magazine Man of the Year issue) become both the consumer and the supplier. If you are an access point, then you are a connecting point of critical feedback about products, fashions, and social patterns that the people who make products, fashion, and political movements alike can use to mold their next product lines. You provide the raw materials - your main entry and added entries, lists of who you work with and where you went to school and which musical groups you like and books you read. In turn, the social networking sites become the collectors and assemblers, and they produce packages of information for their old line suppliers - the people who buy ad space, and want you to listen to their new band, or buy their new shoes, or see the new movie starring kbacon22.

What frightens me the most about choosing to become yet another access point in yet another social network is that most people don’t realize just how much money their presence on these networks is worth to the other participants in the supply chain. And there isn’t always an option to withdraw, either - to withdraw money, or your access points. Some systems give you a “delete my account” option, and some, like Facebook, make it clear that even if you “deactivate” your account, they’ll still retain your data.

While some in our industry are fretting over selling out our assets to mass digitization efforts, others are lining up to make themselves yet another commodity in yet another social network-cum-information commodity supply chain. Just like we might not like what happens to our collected resources once well-funded profit-seeking ventures commoditize our cultural heritage, we might not like what happens to the descriptive elements of our own lives in the hands of profit-seeking ventures commoditizing our social heritage. I’m not against anybody making an honest buck out there from a hard day’s work in a harsh world. But how many more times am I going to give so much of myself away?

[This column was originally published in the February 2007 issue of Computers in Libraries magazine.]

Last month we began to consider what it might mean to build dynamic, instantaneous libraries based solely on the materials held on the computers of people in the same space. That's the goal of this column—to think about what libraries in computers need to look like for them to serve as well as libraries we already know. This month we'll get started thinking about design needs for libraries in computers.

If we were building a physical library, we'd follow some steps you might know well. We'd assess our needs, call for proposals, review bids by architectural firms, pick one, then work with a selected firm to design a space that meets our needs. Maybe you've done this, but I haven't. I have done something similar for software, though, but maybe you haven't. When software design is done well, you end up with something roughly like what you get from an architecture firm—diagrams of boxes and arrows, mocked up screenshots, cost estimates, and a timetable. Fortunately we don't have to worry about time or money here, and we can think of those diagrams and screenshots as pretty much the same thing for software as blueprints are for real buildings. And fortunately for both of us, blueprints are pretty easy to read.

So let's start there, with blueprints. When libraries were being built 100 years ago with Carnegie Foundation funding, one of the things the foundation offered as part of the process was a set of standard blueprints as a suggested starting point. (Jones, T., Carnegie Libraries Across America: A Public Legacy. Preservation Press/Wiley: New York, 1997.) You didn't have to follow them to accept funding, but if you needed a plan, you could start with these blueprints, and many communities did. We could fill a whole conference schedule with debates on what these particular blueprints have meant over time and their relevance today, but there's no debating that these baseline plans affected generations of libraries, library users, and librarians.

Today some of us might have an inkling of what a common design for libraries in computers could look like, but most of us don't. We probably do share a common mental model of the architecture of today's libraries. If you're like me, you probably think it's hard to imagine a library without service desks for reference and circulation, rows and rows of shelving for books, journals, and multimedia, a reading room or area, a reference section with its hefty volumes, separate browsing shelves for popular or newly acquired materials, oddly shaped files for maps, a children's section for a public library or locked stacks in a research library, and so on. There are also offices, public meeting spaces, copy machines, and restrooms—we cannot forget restrooms—a bulletin board, a big stand with a heavy dictionary on it, a daily newspaper section, and some items for sale near the front door.

With all that in place, the only things missing are the catalog, the computers, and the coffee shop.

Connecting the Dots

If that sounds about right to you, then we're definitely starting from the same place. You probably also have a particular library in mind as you think about this—maybe your local public library, or the one you work in, or one you remember from childhood or school. I can't help but think of several different libraries at once, including all of the 10 or so libraries I've known well from childhood on to where I work now. A funny thing starts to happen when I think back through time like that, though. I can almost feel my fingers flipping through catalog cards or spinning the dial on a film reader, and then my eyes can see the green screen of the dial-up terminal, and the color-coded keyboard of a CD-ROM station. Then I remember a lot of meetings about trying to solve problems on the general use public workstations, and then a lot of frustration trying to get wireless to work on laptops. At some point a few years ago that gets easier, and now when I arrive in the library I simply wake my machine up and get to work.

But to focus solely on changing technology is to miss the bigger picture. These lists of what you find in a library and how that's changed over time don't speak to how people move through libraries. Any good set of blueprints should give you a feel for how people will move in, out, between, and around the physical space of a library to get from one section to another.

But even that doesn't necessarily speak to the cognitive wayfinding that library users perform. The best libraries are designed to support the process of finding, studying, questioning, and recombining information. Some of this process requires close examination of individual items, one at a time, from beginning to end. A lot of the process requires making connections, too: You find a book by an author you don't know on the new acquisitions shelf, and before you leave you check to see what else the library has from the same author. Or you're studying politics or economics and you read about a city or region you don't know so you look it up in a map or encyclopedia. Or you get stuck on an obscure reference and ask a librarian for help, and are then led through an online database only to learn that the reference was to a book sitting on a shelf not far from where you first found it mentioned.

The Ultimate Mashup: A Library and Your Brain

These days we can accomplish many of the same tasks with a click through Wikipedia here, a quick look-up at Amazon.com there, and a link to a map server in between. Maybe doing so is qualitatively different from running around back and forth in the physical library to find the same answers to the same questions. Maybe the physical movement and its cognitive affiliation with what you learn and where you learn it builds a stronger mental connection, one that's more likely to "stick" over time. Maybe all these quick clicks lead us to remember where to click quickly, but not to assimilate what we find at the end of the clicks as thoroughly into our brains. Maybe so, but maybe not.

Whether one kind of knowledge acquisition tool chain (bricks and book stacks) is inherently better than the other (clicks and server racks) is also the stuff of academic conferences, and I'm not qualified to judge. Either way, what matters is the ability to make connections. You could spend weeks poring over census records and voting records and old maps, or you could spend days mashing up the same data with the Yahoo! map API, but either way, in the end, you might or might not find an answer to your question, and what you've produced might or might not be helpful to other people.

In a way, then, the function of Amazon.com's book catalog or Yahoo!'s map data in these scenarios is exactly the same as the function of the library book catalog or the library's map file. To me, longevity counts, and although Amazon.com and Yahoo! have been successful, they've only been successful for a few years. If you follow business news at all—or, come to think of it, library vendor news—you know that companies come and go. They swallow and get swallowed by each other on a regular basis. It's easy to imagine this happening with Amazon.com or Yahoo! because it happens all the time. And when it happens, there's no guarantee that services you might have depended upon yesterday will work the same way tomorrow, if at all.

Fleshing Out the Blueprints

What matters, then, in our mental blueprints for libraries in computers, is not just the availability of diverse resources, nor even the ability to connect and combine those resources. What we have to account for is that sometimes things can be expected to stay stable, sometimes they might seem stable but could disappear overnight, and sometimes they might come and go in the blink of an eye but be incredibly useful during that blink.

If we want our computers to act more like libraries, we can't take these dynamics lightly. When 25 people are in a room together and their computers are connected, working together like components of a single library, we know that each of those 25 people might cut his or her own unique path through what is to be found, just like they might in any of our familiar “traditional” libraries. We also know that at any moment, one or 10 or 24 of those people might up and leave, just like our favorite Web site today could become a dot-com memory tomorrow.

I don't mean for this to sound depressing or disheartening. When you design software, or a building, I suppose, one of the first things to account for is which elements will tend to change over time, and how often they will change. In this case we're assessing needs for libraries in computers—dynamic, instantaneous libraries that exist only in our computers and the computers nearby. A central element of our blueprints will just have to be “lots of other computers and the resources they contain coming and going all the time.”

My first exposure to Computers in Libraries was the 2001 conference, when I was on a panel with Roy Tennant and a friendly lawyer. Our topic was peer-to-peer filesharing. I gave a talk on how systems like Napster were really just a natural evolution of interlibrary loan (albeit wherein too many mutations had occurred at once), Roy talked insightfully about how these systems represented “pulsing content” as users and their computers join and leave constantly, and the lawyer graciously advised us all on where Roy and I had misspoken (not often, it turned out!).

Six years later I'm coming to understand just how prescient Roy's phrase was, and remains. Inherent in the Carnegie library program was a requirement that municipalities that received library buildings had to fill their libraries' shelves themselves. The process and outcomes of funding, selecting, purchasing, shelving, circulating, reshelving, and replacing library materials would look different from town to town, and in any single library over time, even back then. I've long thought of libraries as storehouses of great works, rare materials, and a lot of common stuff that comes and goes often. Maybe we've always had some pulsing content, but to build libraries from scratch today, it might help to recognize that all we have is pulsing content.