Re: [CODE4LIB] next generation opac mailing list
> That by trotting out their Endeca powered catalog, they've finally > gotten the tangible that we nerds have been unable to get > institutional support for. Now every librarian in the country wants > clustering and faceted search. Ah, and look how they did it. To paraphrase an olde-tyme Internet expression, they declared their vendor an obstacle and routed around it. For years they had said "the OPAC sucks." But targeting ILS vendors wasn't effective. Not enough people in LibraryLand care. What was the incentive for a vendor to change over the occasional scattered peeping of a few nerds? So they layered a faceted search engine on top of an existing product. In doing so, they incidentally demonstrated the "missing module" of the library catalog--user navigation. Not sure every librarian wants clustering and faceted search, but one can only hope. Btw, for you grow-your-own types, do check out Flamenco, open source faceting software. Flamenco + indexer + stemmer + spell check + some homebrewed SLA tool might equal a pretty nice search engine to compensate for YOUR missing module. Strategery--catch the fever! Karen G. Schneider [EMAIL PROTECTED]
Re: [CODE4LIB] next generation opac mailing list
At 2:25 PM -0400 6/6/06, Teresa Victoriana Sierra wrote: Maybe you ought to sit with a reference librarian and ask why and how the catalog and OPAC are used. Are you a reference librarian who can please explain why and how today's catalog and OPAC are used, so we can think about how libraries of tomorrow can be designed to best accomplish these functions? My point is not that library catalogs are not useful things today- obviously they are. My point is that many of their functions are best accomplished in tomorrow's library without using a catalog per se. By catalog, I mean a local institutional indexed storage system containing detailed metadata records about items in a library. Let's consider one function of todays catalog- inventory control. A lot is known about inventory control systems- they're used in industry for everything from autoparts to supermarkets. It seems to me that a well designed inventory control system for tomorrows library would probably involve RFID tags- that way the library Inventory control system (LICS) could know where the books are in stead of only where they should be. Let's consider another function of a library catalog- resource discovery for users. Does anyone here really believe that in TEN years Google and/or competitors (maybe even mine) won't be able to hook into an inventory control system and deliver full-text, faceted, clustered, instantly relevant, translated search results out the wazoo from all the content in your library? If today's catalogs did an acceptable job of search we might be able to start a discussion. We need good global metadata catalog/registries. Which of today's catalog functions will require a local institutional catalog tomorrow? -- Eric Hellman, DirectorOCLC Openly Informatics Division [EMAIL PROTECTED]2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything
Re: [CODE4LIB] next generation opac mailing list
Eric Hellman wrote: > We need good global metadata catalog/registries. Which of today's > catalog functions will require a local institutional catalog tomorrow? I think this is an interesting question. My opinion is that the libraries of tomorrow will have a distributed catalogue: some of it local, some of it non-local. It makes sense to me that libraries invest in describing resources which are produced locally (i.e. as publishers, or institutional repositories), as well as in cataloguing resources which are locally appreciated in a distinct way. Institutions might just want to deal with a few facets of particular local interest, i.e. tagging resources according to some local vocabulary, and otherwise rely on other catalogues for their metadata. As well as their MARC records, each library of the future will collect a growing variety of metadata about their holdings, lending histories, reviews contributed by users, clusters harvested from usage patterns, or from full-text transcriptions, etc, etc, all of which they will want to make use of in conjunction with other catalogue data. Some of this data may be of general utility, but other data will be local in scope (and privacy laws may prohibit some data exchange in any case). These distinct information systems have to be easy to federate, efficient, and work transparently to users, so that institutions can confidently "walk on two legs"; relying on outside services for some data, while concentrating their own efforts on the areas where they can add most value to their users. Con
Re: [CODE4LIB] next generation opac mailing list
On Jun 7, 2006, at 9:35 AM, Conal Tuohy wrote: As well as their MARC records, each library of the future will collect a growing variety of metadata about their holdings, lending histories, reviews contributed by users, clusters harvested from usage patterns, or from full-text transcriptions, etc, etc, all of which they will want to make use of in conjunction with other catalogue data. Hear, hear! I assert that the "catalog" is not really a "catalog" (inventory list) at all, but more like a finding aid -- a tool used to identify, acquire, and use information pertinent to the information needs and expectations of a libraries primary clientele. This tool includes stuff from a traditional catalog, but it also includes stuff not necessarily owned by libraries, such as pointers to licensed materials (increasingly journal articles), the full-text of electronic books, pre-print archives, selected materials from OAI repositories, etc. -- Eric Morgan I'm hiring a Senior Programmer Analyst. See http://dewey.library.nd.edu/morgan/programmer/.
Re: [CODE4LIB] next generation opac mailing list
Eric Hellman wrote: Let's consider another function of a library catalog- resource discovery for users. Does anyone here really believe that in TEN years Google and/or competitors (maybe even mine) won't be able to hook into an inventory control system and deliver full-text, faceted, clustered, instantly relevant, translated search results out the wazoo from all the content in your library? If today's catalogs did an acceptable job of search we might be able to start a discussion. So, the argument is-- basically, very watered down-- that because the current OPACs suck, we need to abandon them, and make $global_vendor_catalog our default search entry point... which won't suck, and will also allow greater access to global resources? (and not worry our pretty little heads about it) I have always taken this problem from the other side of the equation-- (perhaps because it is the side I know I can have an effect on). Because local OPACs suck, we need to replace/improve them, not abandon them. This is part of our motivation in the Evergreen ILS project (open-ils.org). I believe we're doing a decent job, and our public and staff useability surveys back that up. I think NCSU also has the right idea. Who knows-- various vendors may come out with much-improved catalogs in response to the competition? One of our project goals is to push innovation in the larger library world. Let me be clear: I am not saying that a global catalog is not useful or shouldn't have a prominent role, but I think it should be secondary to the local, /at-fingertips collection/ and catalog (which doesn't suck). The local catalog should access the larger global resources when appropriate. We do this within our consortium-- we show the user what is immediately available on the shelf, what is up the street at the library in the next town, and then what is available throughout the state. There are going to be materials that local libraries will only want to make visible/accessible to their local users. One good example we're wrestling with here is one of our library systems has a subscription to an e-book service that only its patrons can "check out". These are the kind of materials that should only show up in that library system's "local" catalog. The uber-cat would need to know about these rules and associated boundries. (and that's just one simple example) -=-=-=-=-=-=-=- Brad LaJeunesse PINES System Administrator Georgia Public Library Service
[CODE4LIB] Announcement: Evergreen ILS Beta Release
The Evergreen software development team is proud to announce the Evergreen ILS Beta release. Evergreen is an open-source ILS being developed by the Georgia Public Library Service for PINES[1], a consortium of over 250 public libraries. The Evergreen ILS is scheduled to go into production in PINES this fall. Please see our blog[2] for information on the Evergreen public demo server and where to download the software. [1] http://www.georgialibraries.org/public/pines.html [2] http://open-ils.org/blog/ -=-=-=-=-=-=-=- Brad LaJeunesse PINES System Administrator Georgia Public Library Service
