Add Books only searches one catalog?
Join LibraryThing to post.
This topic is currently marked as "dormant"—the last message is more than 90 days old. You can revive it by posting a reply.
Please correct me if I'm mistaken. Or is there a "Search All" somewhere in the Add Books interface that we're not seeing?
I guess if it were me, I would have just manually entered it... everything I came up with for roll-over searches, either going through every library or just through ones added to "Search where?" still didn't seem like it would address his issue.
But it does make me sad that he had problems and settled on Goodreads. I just wish there was a better way to provide search for users that wouldn't result in them having to manually go through and search one library at a time out of the hundreds you have available.
Not trying to attack or anything; I have much love for LibraryThing (was just writing a review of it in fact, which will be published on my site on February 2nd as part of a series reviewing different online library/cataloging sites), but I was a bit surprised when I looked into this myself and discovered that each library has to be selected manually (though it does appear that my friend misinformed me when he claimed that search terms have to be re-entered; it looks like LT retains that, thankfully).
Amazon is a better place to search for paperback books than most libraries, but searching Amazon AND 690 libraries is not worse—it's better. Libraries contain hundreds of millions of books not on Amazon. But leveraging the system does require understanding that not every one of the 690 is going to be as good for the book you have in mind.
Hm. Tim would it be at all possible for LT to query WorldCat itself when a book is added and use that to decide on the source to use?
I understand fully the resource and optimization issues involved in searching so many sources, but I don't know why you don't allow for searching on all libraries simultaneously by default. You could solve any potential alienation issues by providing an output for each addition showing which library it was pulled from. Yes, that's a LOT more load on LT's end, but drastically improves the search service offered.
Plus, you get into all sorts of issues dealing with sorting of the results, etc. The fifth result from one source might be much more relevant that the first result from the rest, but we can't know that. It all goes down hill fast, at least from a usability standpoint.
The alternative is to present the results as separate result lists but you're not really gaining much from a usability standpoint there.
We are working on a solution that interposes a layer between LT and the sources, so we know where to look, basically. It's a major, major endeavor. Indeed, we're hiring someone just for it.
Well, there's a fall-through paradigm; search source A first, and go to source B if and only if there are zero results. That would seem to deal with most use-cases where searching lots of sources would be useful, without most of the added problems in terms of bandwidth and sorting (though not in terms of your time to develop the feature).
(I'm imagining a scenario where users can prioritize a few sources, so that they could basically just do the same "search my favorite five sources" sequence that they do now automatically rather than manually.)
Frankly, I can't imagine wanting to do a search over even 10% of the available databases at one time.
Would this be for failed searches, in sequence or are you thinking it would do what's called a "federated" search—get send out requests simultaneously to X libraries, wait until the last one comes back (ie., the search is as slow as the slowest of all searches). Federated searching is a problematic thing for the speed reason, and because it's hard to relevancy rank when each system has already relevancy ranked based on criteria you can't see.
A serial searching method could be implemented but it wouldn't help in many circumstances because many times there ARE results returned, just not the one you are looking for. But for those cases where zero results return we could do serialized searches. We'd also have to implement custom sorting of the source list, but that's pretty minor in the big scheme of things.