Facebook Librarian is an extremely useful application to bring Facebook users (for many of us academic librarians, that translates to the overwhelming majority of our user population) and librarians together. Facebook, as we all know, is a social networking site. Its audience is largely college and post-college people, although there are both younger and older members. Heck, I'm one of those older Facebook users having graduated from school several years before the Web was born.

Facebook Librarian is an application that any Facebook member can add to their profile. Once added, it provides links to a range of resources, including WorldCat, Google Scholar, Internet Archive, Amazon, and so on. But that's not the really interesting thing -- this is: there's an "Ask a Librarian" link in the application that will either link to a librarian at the user's school (if one has signed up through Facebook Librarian) or elsewhere (another school's librarian who volunteered to take questions from all comers). Plus, if a library creates a very simple HTML page and provides the URL of that page to Facebook Librarian, that "widget" is displayed within the application.

This works because college-aged Facebook members are generally associated with an educational institution and Facebook makes that association available to application developers. So if anyone at the University of Michigan with a Facebook account goes to the Facebook Librarian application, they will be able to "Ask a Librarian" (me, in this case) or search our library catalog, journals collection, database collection, or web site from within Facebook. Any library can both register to be a contact for a particular school and/or provide a library widget.

This is a very useful and truly wonderful example of putting the library where the users are.

Kudos to Brad Czerniak, who developed this application, a student at the Library and Information Science program at Wayne State University. You can read more about Facebook Librarian on his blog: Hawidu. Or, to try it yourself, go to http://apps.facebook.com/fblibrarian and click "Add to my profile."

Content, having reached the age of majority, has left home and is out trying to make its own way in the world. Some "digital parents" are reflexively clutching at their wayward bits, trying to keep on the on the home site. Others are preparing for the all-but-inevitable day, right around the corner, when content grows up and lives on its own, occasionally calling home to say hello and see if there are any updates.

We are on the cusp of what Steve Rubel terms the Cut and Paste Web. In this version of the web -- the building blocks are already there -- you can "you can take any piece of online content that you care about - a news feed, an image, a box score, multimedia, a stream of updates from your friends - and easily pin it wherever you want."

Rubel, who writes for Advertising Age, offers three strategies for thriving in this new era where content is consumed in places far removed from the web site:

1. Think web services, not websites
2. Connect people
3. Make everything portable

As our profession evolves from being gatekeepers to publishers of information, we need to work more actively to expand the ways our patrons use what we have. Or would use it, if only it were offered. Any online tool we build or buy for our library's patrons should be able to provide the same functionality in another venue. Our databases should be searchable (with authentication, of course, where required) from anywhere our patrons want. If someone is building a wiki on a subject, relevant search results should be included right there, live from the database. Ditto for the library catalog, without the authentication. And the same is true for any other tool we offer our patrons in an online environment. Of course, these tools should be equally accessible on a cell phone as on a full PC-based web browser. And the output of patron research should be available in open formats -- so it can be reused and republished. Licensing of content needs to reflect the realities of use, not the other way around.

Rubel concludes as follows: "In the very near future portals including iGoogle, My Yahoo and Netvibes as well as social networks will be able to easily inhale the smallest pieces of content from across the web. Don't wait. Start now to make everything on your website embeddable. Traffic is becoming something that happens elsewhere, not just on your site." Syndication is the next wave of innovation.

Of the many interesting cans of worms that content syndication tools -- RSS feeds in particular -- open, one of the most significant is copyright. The issue becomes particularly interesting when the RSS feed is the same as the site -- that is, when the blog's author chooses to republish the entire content of an article via RSS.

I think many people assume that, by making content available through RSS or other syndication tools, the content's author has implicitly permitted that content to be used by others. Common practice shows this to be a frequent interpretation. I'm sure many of my fellow bloggers have been as annoyed as I am when I discover that RSS4Lib's content is being reproduced, in its entirety, on another web site whose sole purpose appears to be selling advertisements.

Common practice notwithstanding, reproducing blog content wholesale is wrong, barring a license explicitly granted in the feed or on the originating web site. RSS feeds are protected by copyright just as much as any other work.

There are several mechanisms, of course, for stating your licensing terms. While copyright law (in the United States, at least) does not require an explicit statement of copyright for the item to be protected, it's common sense to do so. You can put a statement on your blog -- and it's probably wise to do so on each post or page, using your weblog software's templates. It's also possible, and advisable, to put copyright statements in your feeds:

• The RSS 2.0 specification includes a copyright statement for the entire feed, in the channel's <copyright> field, but not for a particular entry.
• The Atom draft specification has a <rights> field for both the feed and individual entries.

In practical terms, of course, whatever the rights are and however they are declared, they're hard to enforce.

I suspect many of us are happy to have our content included in services like Google Reader, Bloglines, and the like -- after all, we're writing to be read. Short or long excerpts from our posts being used in the context of another blogger's post are also fine with most of us -- that's how discussion happens. At the other end of the scale, I would bet that most of us are less sanguine about our content being reproduced, in whole, for financial gain, by someone else.

Somewhere in the middle is a potential Google project -- described at TechCrunch in a post titled Google May Add Comment Feature On Shared Reader Feeds -- in which users could comment on blog posts within the context of Google Reader. Such a project, if implemented, would move the conversations and discussions about our blog posts from our blogs into "Googlespace," which all too often is akin to a black hole: things go in, but don't come out. I'm not knowledgeable enough about copyright to weight in on the legality of appropriating bloggers' content, reproducing it, and fostering interaction around it without explicit permission, but to me, it's questionable. If this project comes to fruition, it could seriously infringe on the way we as bloggers -- librarian or otherwise -- interact with our users and our patrons.

Like many standards, the RSS 2.0 Specification provides detailed instructions for what elements must or may be in an RSS feed and, in broad terms, how to format them. However, the specification does not -- nor should it -- provide detailed guidance on what to put in the various elements.

That's where the Really Simple Syndication Best Practices Profile comes in. Published by the RSS Advisory Board, the group that has responsibility for maintaining the RSS Specification, the RSS Best Practices Profile offers guidelines on how to format an RSS document for the widest possible audience of aggregators, feed readers, and other tools. The Board tested feeds against a range of aggregators: Bloglines, BottomFeeder 4.4, FeedDemon 2.5 (2.5.0.10), Google Reader, Microsoft Internet Explorer 7, Mozilla Firefox 2.0 (2.0.9), My Yahoo, NewsGator Online and Opera 9 (9.22).

This document is aimed at developers more than at bloggers -- the blog tools we all use already create RSS feeds -- but when we build systems that generate RSS for our users, doing so in the format that has the best chance of providing users with the same experience, regardless of where they consume the feed, is a good idea. For each required or optional element in the RSS specification, this document says what the specification requires and how best to implement that requirement in practice. Some selected recommendations from the guide:

1. Author: The Board suggests that, for individually authored blogs (where everything is written by the same person), the item's author element be omitted in favor of the channel's managingEditor or webMaster element.
2. Category: The Board recommends that the category element provide the full hierarchy of the category term, not just the term itself. In other words, a category of "dogs" would be better as (and I'm making this up) "animals/canines/dogs".
3. Description: The Board makes the common-sense suggestion that, when there are links in an item's description element to other pages on the same site as the blog that the links be fully qualified URLs (for example, http://www.rss4lib.com/index.html), not relative URLs (/index.html).

By taking some simple steps to generate RSS feeds so they will be read and understood by the most common feed readers and aggregators, you can broaden the audience for your content and help ensure that your readers have a uniform experience regardless of where they consume your RSS content.

I've started compiling a list of "library labs" -- web sites where libraries of all kinds publicize their experimental, "beta," or trial services. The pages linked below offer a wealth of ideas and innovations.

• Massachusetts Institute of Technology (MIT) -- MIT Libaries' Betas
• University of Michigan -- MLibrary Labs
• University of Minnesota -- Digital Library Development Lab
• New York Public Library -- NYPL Labs
• University of Pennsylvania -- PennLabs
• University of Virigina -- Library Lab
• Vanderbilt University -- Test Pilot

The full list will be maintained as the Directory of Experimental Library Tools.

Please contribute your own library's site if it's not listed already.

I'd like to talk about a tagging project we just launched at my workplace. MTagger is a social bookmarking tool that we've integrated into several University of Michigan library resources. A tag cloud now appears:

• On almost all library web pages
• On item pages in Mirlyn, our library catalog
• On image display pages in our digital image collections
• On most of the electronic journals published by the library's Scholarly Publishing Office

Like del.icio.us and many other social bookmarking tools available on the Internet, MTagger allows users to bookmark and tag web pages using language that makes sense to them. Anyone can see tag clouds on pages and search MTagger; only users with valid U-M network logins can apply tags. (Individuals can, of course, opt out of sharing their tags with others if they choose.)

Unlike these other tools, MTagger offers the concept of "Collections" -- letting users restrict their searches for similarly tagged items to a specific collection (library catalog records, images, web pages, etc.). While tags themselves would allow people to serendipitously find items in other collections, the "Collections" metaphor will, we expect, help drive home that the library offers more than books, electronic journals, and databases.

More important than the tagging functionality itself is what MTagger will allow our faculty, staff, and students to do. MTagger brings a social component to research that we have not previously had. It will allow users to share knowledge about library resources with each other, to enable quick-and-dirty subject guides to be produced, and -- we hope -- to bring researchers together via their individual tag clouds. As research moves online, chance meetings in the stacks of researchers with overlapping interests become even more rare. Through tagging, we hope to be able to recreate some of those synergistic interactions as one researcher finds a tag of interest, and through that, the other researcher.

Oh, and just to keep this in the realm of libraries and RSS, anything that can be searched within MTagger can be accessed via an RSS feed.

A recent research paper, "Can Social Bookmarking Improve Web Search?" by Paul Heymann, Georgia Koutrika, and Hector Garcia-Molina, draws numerous interesting conclusions about the effect of taggers and tagging on findability. The authors used del.icio.us as the source for tags.

Several of the results they found:

• "Tags are present in the page text of 50% of the pages they annotate and in the titles of 16% of the pages they annotate" (p. 8). It seems that taggers are not particularly original in their tagging.
• "Pages posted to del.icio.us are often recently modified" (p. 4) and "approximately 25% of URLs posted by users [of del.icio.us] are new, unindexed pages" (p. 5). By monitoring tags of interest to you, you can find out what's new more effectively than you can by setting up standard search queries.

Their closing section, in which they discuss how tagging could be improved in the long run, bears quoting at length:

A French court has found that the publisher of a web site is liable for invasion of privacy because it republished rumors, via RSS feeds, that were themselves libelous. See French Websites liable for story in RSS reader (Out-Law.com). The publishers of the 3rd-party sites had to pay fines of between 500 and 1,000 Euro. Out-Law.com, a British legal news site, notes that, "while there has not been a test case in the UK on link liability," there is a legal precedent that could be relevant in English common law: "A Court of Appeal ruling ... found that a man who stood by a roadside placard drawing the attention of passers by to it was liable for its defamatory content, even though he did not create or erect the placard."

This French case may not have any relevance in the U.S., where the legal concepts of freedom of speech and privacy are differently construed. I find it interesting that one publisher could be guilty of libel by reproducing, without any conscious effort, an RSS feed from another source. One of the strengths of RSS is one of the drawbacks -- you subscribe to the feed, come what may.

Do any RSS4Lib readers have opinions on this? Fire away in the comments.

Thursday, 1 May 2008, is RSS Awareness Day. There's a grassroots effort to increase the awareness and use of RSS (and syndication tools in general). On the RSS Awareness Day site, it is claimed that "Feedburner recently reported that they track around 60 million RSS subscribers."

Of course, there are a lot more Internet users today than there were in 2005 (one estimate puts the total at 1.3 billion at the end of December 2007). I would go so far as to triple Feedburner's estimate to 180 million RSS subscribers, to account for all the users that Feedburner does not know about. And there have to be millions of them: people who "use RSS" without being actively aware of it, such as through "live bookmarks" in Firefox, Safari, and IE, or from web sites that themselves are amalgamations of feeds from other publications. People do not need to know what RSS is to use it.

Still.... even if we triple the number of users Feedburner thinks there are to 180 million, it is still only 13.8% of 1.3 billion users out there. That's not a particularly overwhelming market penetration figure for something as gosh-darned handy as RSS.

So -- talk about RSS on May 1, especially if you can do so without preaching to the converted. You and I probably do not need to be sold on the benefits. But our patrons do. But our parents probably don't. Take advantage of the first RSS Awareness Day to spread the word.

Copyright and fair use are poorly understood in the population at large (just ask high school teachers or college professors how much time they spend vetting submitted papers for flagrant -- let alone subtle -- plagiarism). However, syndication technologies such as RSS and Atom make it so easy to repurpose works that what's proper -- morally or legally -- is often overlooked. After all, feeds are purpose built to make content portable. If the author did not want others to copy the content, the author would not send it out in a format designed for its simple syndication.

The Australian magazine PC World runs an interesting article by Larry Borsato: "Who owns 'public' content? RSS feed ownership brought into question." In the article, Borsato recounts a recent incident in which a commercial entity reproduced, in toto, his blog posts via RSS on its web site. While Borsato has a Creative Commons non-commercial attribution license, he felt the commercial entity had violated it; they were, after all, a commercial entity. While the question was resolved amicably, it highlights, once again, the difference between how copyright is frequently viewed in the syndicated environment from how it is often seen in the print world. Borsato concludes:

Like many other facets of life in the Internet age, technological possibility is outstripping common practice -- and often outstripping common sense. Some of this particular misconception, about what can legitimately be done with online content, can be cleared up through experience and training. Some of it will inevitably be resolved through better technological solutions. But when it comes down to it, we as bloggers must take greater responsibility for tracking how our content is used.