Pinterest (http://www.pinterest.com/)is the latest social media tool to emerge from the fringes to the spotlight. It's something of a social media bulletin board for interesting images. Once you set up an account (invitation only, but you can request an invitation -- mine came within hours), you are given a bookmarklet tied to your account so that can start pinning images you find on the web.

When you're on a page that has an image you want to "pin," you click the bookmarklet. Pinterest shows you thumbnails of all the images on that particular page. You select the thumbnail image you want and the board you want to add it to (you can create as many boards as you like).

Uses of Pinterest for Libraries

Pinterest has some interesting uses for libraries:

• Some libraries are putting up cover images of new books, best sellers, or interesting books from the collection. The Darien Public Library, unsurprisingly, was an early adopter. The library's Pinterest page has lists of books on various themes ("Best Books for Babies & Toddlers," "Newberry Medal Winners," and a board for their "One Book, One Community" reading program -- images related to the books selected for adults and children.
• Promoting images from special collections. The Bluffton University's archives have a Pinterest board with selected images from their special collections and archives, including images of beanies (the hats, not the stuffed toys) and time capsule covers. The Staley Library (Millikin University) has a set of images related to the university's history.
• Put up photos of your library's staff along with brief bios or areas of specialization. I haven't been able to find a library doing this, but surely there is. Anyone?
• Create boards related to popular books. The Westerville, Ohio, library has boards for The Hunger Games and Memoirs of a Geisha.

Copyright Questions

One of the interesting challenges faced by Pinterest is that of copyright. Pinterest works by copying a thumbnail image of whatever it is that you pin. When you pin an image, the original is linked from the thumbnail. While probably not, strictly speaking, allowed by copyright law, I suspect Pinterest is operating under the theory that if Google can cache a thumbnail of an image (or even of an entire web page) for its search tools, then they can do the same.

Complications arise, though, when one Pinterest use copies an image from another. You can "repin" another user's image to one of your own boards. At that point, you've created another copy of the image on your board that links to the "original" -- that is, the thumbnail on someone else's board -- and not to the original artist's. There's been quite a kerfuffle about this of late.

There's a very nice summary of the issues around "pinning" things at the University of Minnesota's Copyright Librarian blog (and a follow-up post) that I encourage you to read. It summarizes the issues far better than I can.

Pinterest via RSS

Pinterest doesn't document its RSS feeds well, but I stumbled across some instructions for how they can be made.

1. To get an RSS feed for all of a particular user's boards, add "feed.rss" to the end of the user's Pinterest page. So, for example, for RSS feed for the Darien Public Libraries Pinterest account is http://pinterest.com/darienlibrary/feed.rss.
2. To get an RSS feed for a specific board, remove the end "/" from the board's URL and then add ".rss". So the Darien Library's Best Books for Babies and Toddlers board has the feed http://pinterest.com/darienlibrary/best-books-for-babies-toddlers.rss.

Happy syndicating! (And don't ask about the potential for copyright issues when we you re-publish an RSS feed of a Pinterest board that itself has copyrighted but unlicensed images on it.)

An interesting proposal was made at SXSW this week to standardize the way we bloggers, and other content aggregators and curators, make reference to those from whom we get interesting tidbits that spark a thought (a 'hat tip') or are the source of our post (a 'via'). The glyphs are called Curator's Codes. They are Unicode characters meant to be a standard (if not a real one, a standard of practice) for giving where credit is due:

Symbol	Purpose	HTML Code
ᔥ [Unicode 1525]	Via	<span style="font-family:sans-serif;text-decoration:none;">&#x1525;</span>
↬ [Unicode 21ac]	Hat Tip	<span style="font-family:sans-serif;text-decoration:none;">&#x21ac;</span>

The symbol itself is the link to the source. Curator's Codes could be rendered in line, much like a brief citation, or used as freestanding blocks. Or, really, in any way that's sensible to the author. As in, for example, the hat tip for this post: ᔥ David Carr, "A Code of Conduct for Content Aggregators".

What's the point? To quote the folks at ᔥ Curators Code:

While we have systems in place for literary citation, image attribution, and scientific reference, we don't yet have a system that codifies the attribution of discovery in curation as a currency of the information economy, a system that treats discovery as the creative labor that it is.

As we madly link from thing to thing, and others, in turn, pick up our post and run with it, quoting here, paraphrasing there, it's all too easy for something one author says to be lost in the expounded thoughts of another. Making a simple, standard, way for authors to cite others is a good thing. And to quickly indicate the kind of citation -- are you quoting or paraphrasing, or giving credit to someone else who sparked a thought? Standardization may be a good answer. It could even lead to better machine parsing of interconnections between blog posts, tweets, Facebook, etc. -- if adopted.

Update 13 March 2012: There's an interesting contrarian view at The Brooks Review.

Web Scale Discovery systems (products like Summon, EBSCO Discovery Service, Primo Central, and so on) make their customers love them through their comprehensiveness. These systems index hundreds of millions -- some approach a billion items -- from scholarly and popular sources, library catalogs, institutional repositories, and more. No matter how esoteric the topic you are looking for, you're almost certain to find something that's related. Or close to being related.

With their vast reach, these discovery systems open the door to being almost omniscient alert services. Their coverage is vast, so whenever something new is published on a topic, it is likely to find its way into the discovery index. The challenge, it turns out, is in letting people know when something new is available.

Discovery systems are primarily retrieval systems. They cast a wide net, and sort their results in relevance order. When something new is added to the index and the same search is run, the new items appears somewhere in the list. This is the challenge for any kind of current awareness system (whether it is RSS or email alerts).

If the system simply runs the search again and provides an RSS feed of the 100 most relevant results, for most searches, the new material will be nowhere near the top and the feed will contain exactly what you have already seen. For many topics, the new items won't even make the relevancy cut and will be excluded.

If the system runs the search and provides an RSS feed in reverse chronological order (newest items on top), the newest items may well be so far down the relevancy ranking that they are, in fact, nearly irrelevant. Try a couple experiments. Do a search in your favorite tool and move down to the 5,000th result. Is it the item you've been looking for all your life? Almost certainly not. Do the same search, but resort by publication date (newest first). Is the top result relevant to your query? Again, probably not.

So what is needed is some sort of hybrid, database structure. The items from the original search result set that pass some relevancy threshold need to be saved. Whenever new items are added, these new items are compared to the existing list. If they are more relevant than items in the previously seen list, they are added to an alert, and the list of previously seen and previously alerted items grows. Figuring out which are new (to the user) items is not trivial.

Discovery and RSS are almost inherently at odds with one another. Any ideas on how to build a usable RSS feed to stay apprised of a topic?

Google recently announced that they are soon to relaunch Google Reader with a new design and are "going to bring Reader and Google+ closer together, so you can share the best of your feeds with just the right circles." Although I am not a huge fan of Google+ (Aside from the coolness of Hangouts, I haven't seen a reason to convert from Twitter and Facebook; my social circles don't see to be active in Google+), one of the things that has griped me about Reader is that there has been no way to share RSS items with my Plus circles. If nothing else, that will soon change.

Something else that will change is that the Google Reader API (an unofficial, undocumented, and formally unsupported API) will at some point be phased out. This doesn't make a difference to users of the Google Reader web site, but does matter for anyone who has been using Google Reader to track what has been read in applications like FeedDemon and others.

If you want to get your data from Google, they will continue to offer an OPML download of your feeds, but will be augmenting the list of subscribed feeds with your other personal data, including your shared items, friends, likes, and starred items. What you do with them then is your business.

A recent research report by Hillary Mason of Bit.ly explores the lifespan of a link shared through social media. Her findings are that links shared via Twitter, Facebook, etc., have remarkably short life spans. She measured the half-life of shared links (the amount of time it took for a link to receive half as many clicks as in the previous time period) and learned that, for most links, the half life is two-three hours. (The outlier exception is links shared from YouTube, where the half life of a shared link is a whopping 7.4 hours.)

Graphs and the full report are available on the bitly blog.

Of course, this post is immortal, because as we all know, blog posts never die. Right?