To jump in here, let me assure you that LibraryThing does depend on
lots of hand-hewn metadata, and is grateful for it. Most of its data
comes from Amazon, who have strong commercial motivations for
providing their data. But a significant chunk--and the most valuable
one--comes from libraries that make their data available to other
libraries and to scholars through Z39.50.
LibraryThing does point in the direction of "collaborative"
cataloging. Some data is fashioned from multiple MARC records and the
"works" concept associates editions, much as FRBR does, but relies on
"regular people" to do it. There is, I think, something interesting
going on there--a move toward "Wikipedia-like" cataloging. But I don't
want to push this idea past where it can easily go. "Hand-hewn data"
will always be the beating heart of LibraryThing.
As I see it, the thing that LibraryThing has to contribute here is this:
LibraryThing is both more and less than an OPAC. I'm going to posit
that the more and the less are, in development time and other
resources, about equal--that adding circulation and the other things
LibraryThing lacks as an OPAC would not be much harder than it took to
give LibraryThing it's "social" and other distinguishing features.
This might be wrong, but I don't feel it's *wildly* wrong.
If it's not, then libraries should look at LibraryThing and ask, "How
does this thing take one guy 9 man-months to develop, and run on one
$2,500 box?"
Before I seem to be crowing, let me say that it ISN'T because
LibraryThing is special. LibraryThing is part of a trend. The last two
years have seen an enormous explosion in web aps. Building web aps was
very expensive during the dot-com boom. Servers were expensive.
Databases were expensive. You had to buy stuff or waste a lot of time
writing it yourself.
This has changed. Servers have become fast enough that many well-known
web aps run on one or at most a handful of machines. (Basecamp, for
example, ran on one box until very recently.) The languages people
develop web aps in are all open source--Ruby on Rails, PHP, Python,
Perl--as are the database systems underneath--MySQL, Postgresql. As
far as LibraryThing goes, I don't pay for ANY software, other than a
copy of BBEdit and Microsoft Word, for when I can't avoid it. I
certainly don't pay for the operating system. And as far as employees
go, lots of web aps have just one programmer. LibraryThing had one for
9 months. I'm scaling up now, but to work on extra-OPAC functionality.
It comes down to this. Web aps. are becoming radically easier and
cheaper to build and run. They are becoming almost a comodity. OPACs
*ARE* web aps. Therefore, OPACs will, or at least should, go down the
same path, and soon.
Convinced?
Tim
On 6/19/06, K.G. Schneider <kgs_at_bluehighways.com> wrote:
> > > Make the system friendlier, spend less money on hand-hewn metadata
> > > and more on books and services, etc. I have to wonder if a tool such as
> > > LibraryThing wouldn't support such a library's needs better than any
> > > traditional ILS.
> >
> > You do realize that LibraryThing is chock-full of "hand-hewn metadata?"
>
> Yes, actually, I do. If I my post seemed to imply that LibraryThing offered
> any sort of automated entity extraction, let me clarify that I wasn't trying
> to say that.
>
> > FWIW, I certainly would agree that cataloging as it exists now is much
> > more complicated, labor-intensive and expensive that it needs to be. So
> > greatly simplify it yes, but don't pretend that there's no human source
> > behind the metadata in services like LibraryThing.
>
> No pretensions whatsoever. My comment about LibraryThing was a broader
> observation on the order of "a significant amount [but by no means not most
> or all] of whatever it is we get from the traditional library ILS may be
> delivered just as well by LibraryThing." It's a parallel analogy to "cheaper
> metadata is not necessarily worse than expensive metadata." If two brands of
> potato chips are just as good, then buy the cheaper brand; it leaves more
> money for onion dip.
>
> Not only that, but just in case this point gets lost in this response, I
> also weighed in with my 2 cents that I believe librarians have a role in
> shaping and refining computer-assisted metadata.
>
> Infomine has some interesting capabilities in the automated-extraction
> department, and I'd really like to see the Infomine folks pitch in on these
> discussions. It could be that after all they've done in the web portal arena
> (in re iVia) one highly relevant application ends up being traditional
> library stuff.
>
> Karen G. Schneider
> kgs_at_bluehighways.com
>
Received on Mon Jun 19 2006 - 16:45:55 EDT