I just came across this: http://drupal.org/project/bookpost

This is a nice piece that makes the process of building your own book site. From the project description: “The Book Post module makes it easy to post information about books. Any 10 or 13-digit ISBN placed between double curly braces in a post will convert into the book cover, title, author and publication info. All data comes from the Open Library Project, an open source catalog that allows users to add books and edit metadata. If there is no cover available for the book you want to post, go on the Open Library and add one!”

According to the description, the module also includes support for getting data from WorldCat, LibraryThing, and Google Books.

I’m still not entirely clear what Tim is saying in his comments above, but it’s nice to see that open source options are maturing.

Cheers,

Bill

As it stands, users can—and do—leave for other services. An API would, frankly, be less subject to that effect. People don’t use APIs to flee a service; they use them because they like it and want to use the data elsewhere. So your line of argument about the business case is just backward. I’d be happy giving that stuff out. But I signed a license agreeing not to. And Amazon’s remedy is to demand that all the data we retrieved from them be deleted. You want me to risk that by breaking their terms straight out?

One of the questions I raised in my original post was whether LT should move to non-Amazon data. We have a lot of other sources. But coverage would suffer a lot. Libraries have books, but not so many paperbacks. And nobody—but us!—has free covers; we’d have to buy them from Bowker or Baker and Taylor if we didn’t get them from Amazon, and under worse terms than Amazon has.

I too like OpenLibrary. It might give you some context to know that I was either the first or the second person to think of the idea, and start pushing for it. (Casey Bisson and I aren’t sure, but we were trying to get others interested in it before any of the current people got involved.) But OpenLibrary’s data is a fraction of what LT gets access to now through Z39.50 connections—and again doesn’t have paperbacks in great numbers. Like it as you do, have you tried to use it for a regular personal library? It’s not there. Not there by miles.

I just joined LT to see the export functionality — thanks for pointing that out. You are right, I did expect to see that on the api page –

RE: “The rest of your comment stems from that misunderstanding.” — yeah, not so much. I missed the csv export of book titles because that is not something you are exposing via an api — fwiw, allowing the same data people can export via csv to be grabbed and exported using your API’s would be more useful, and would possibly work to increase LT’s exposure. As LT currently works, I would never recommend using it — however, if I could set something up where users on a site could import their LT lists, and update those lists in real time, and have those personalized lists be searchable *within another site*, that would be useful.

But that would effectively break down your content silo — In very general terms, content silos exist because they are required by a business plan, not because of any valid technical reason.

As things stand, I’d much rather see services built up around OpenLibrary — http://openlibrary.org/ — This resource feels more useful when it comes to building tools that are freely available, and replicable. Although their apis are a work in progress, it’s already a powerful tool, and has none of the usage limitations of the LT api.

So, yes, I was definitely wrong about csv export. And, that’s a nice feature, and, as you point out, one that is shared by your competitors. But the rest of what I said still holds: users are better off avoiding the silo.

Cheers,

Bill

We don’t have an API to the same information for the reasons provided. To get the export you need to be signed in and it needs to be your account. Having an *API* to the Amazon data is expressly forbidden by the Amazon license.

The rest of your comment stems from that misunderstanding.

RE: “obviously a system should allow export—as ours does and always did” — Your system doesn’t allow export — your API’s, as described on the LibraryThing API page here: http://www.librarything.com/wiki/index.php/LibraryThing_APIs — allow for json embed, and/or querying the LibraryThing database. This is NOT export — this is querying the data contained within your silo. It’s nice, and handy, and all that, but it should not be confused with export. Also, the terms of your JSON apis explicitly forbid storing the data, with the unavoidable exception of browser caching. Your precise terms read: “Must be run as Javascript on user’s browser, not fetched by a server; cannot be stored, except for browser caching. Commercial use requires a hard (non-JS) link to LibraryThing on every page that returns results.”

This is a far cry from export. While it’s great that LT exposes an API, to claim that your data is open and exportable is a BIG stretch. Personally, I’m not that flexible.

RE: “25% users may be into data portability, but 100% are against involuntary portability.” — this is a complete red herring. User privacy, and the ability to export lists of books we like, and our recommendations of these books, are two entirely separate things. And the ability to export book data is easy to manage; while I understand the necessity in your business plan to hold that data close, and to manage its reuse via your api’s, claiming that there are technical limitations is just not accurate.

RE: “More generally, I think there’s an interesting discussion to be held about when open source hits large database systems. ” — What does this mean? Do you mean when large databases are accessible via open API’s? Or do you mean when large amounts of data are truly open and accessible via open standards, and content can be easily moved and recontextualized? Are there databases complaining that they have been struck, glove to cheek, by marauding open source code? Seriously, though, I don’t know what you’re referring to here.

Cheers,

Bill

Oh, and we just released 1,000,000 covers free to the world for both commercial and noncommercial use. I think that will decimate the business of selling covers to libraires within a few years. So, we’re doing some good..

More generally, I think there’s an interesting discussion to be held about when open source hits large database systems. Even if LibraryThing were open source in software, it would still need a series of honking database servers to power it. We have more bibliographic data than the Library of Congress, after all. Someone has to pay for that.

Further, you need a lot of it the data before the service itself is valuable. It’s like Google. Even if Google were open-source, you wouldn’t have Google if you had the software. You’d need the data–and the hundreds of thousands of machines that find it.

Opening the data isn’t the answer either. Most of our data is user data. You couldn’t make dumps of that available, because some users are private and most would never consent to their data being moved around by others. We’ve had competitors spider our members and rebuild their accounts elsewhere—users went through the f-ing roof! 25% users may be into data portability, but 100% are against involuntary portability.

So, while open-source software would be nice, and obviously a system should allow export—as ours does and always did, you can’t get away from all of the logic of a silo.

And for anyone else on LT, you can find me here (username: sicheiiyazhi).