We’ve launched the LibraryThing for Libraries demo site. After CIL we pushed everything back a week to work on speed, add fielded imports, and make some interface changes to the tag browser.*
Here’s the demo site: http://www.librarything.com/forlibraries/
So far we have about two dozen libraries and consortia interested enough to send us ISBNs. Over the next few days we’ll be getting back to people with directions on testing the service out.
- It seems right to tie the price to the number of ISBNs that LibraryThing can potentially enhance. For public libraries, this is about 50-70% of ISBNs. For academic libraries it’s more like 25-50%. So, my thought was to make it $.02 for the first 25,000 ISBNs, and $.01 after that. (The two levels try to get at the shape of interest in a given ISBN; it’s more valuable to enhance Harry Potter than some obscure book.)
- So, a small city in New England (pop. 75,000), has 84,612 ISBNs. 57,312 (67%) are enhanceable by LibraryThing. That comes to $823/year. That seems like a very good deal.
- Clearly a consortium needs to pay more than a single library with the same number of ISBNs. After all, the consortium will have multiple copies of the item spread around the various consortium members. But a consortium of fifty libraries won’t actually have fifty copies over every ISBN, and there ought to be some “bulk” savings for them anyway.
- This lead me to charging consortia a multiple of the square root of the number of members. So, for example, a library with 284,742 enhanceable ISBNs would pay $3,097, and an identical consortium with 28 members would pay $3,097 x SQRT(28) = $16,390.
- Then you have the “branch” problem. A large city signed up for a beta test. They have 270,002 ISBNs—$2,950. But they have some 30 branches, a population of 600,000, and a library budget of $30 million dollars! This doesn’t work.
So, I think I need to get total collection or circulation figures, and multiply them by the percentage of ISBNs we can enhance.
I wish we could expand our pay what you want program…
*Among other things, we normalized ISBNs, moving from storing a 13-character string in every table that needed them, to storing a four-byte integer tied to a table that mapped the integers to ISBN. Normalizing textual data happens all the time here, but normalizing something already so compacy and inherently unique was force on us by the dawning realization that we’re going to be handling dozens or hundreds of millions of bibliographic records. So now LTFL tosses around arbitrary ISBN keys like mad, without ever knowing what ISBN they represent. O brave new world…