On Jan 31, 2008 8:11 AM, Bidd, Donald <[EMAIL PROTECTED]> wrote: > > > can someone tell me how to get off this list...thanks
According to the header of the emails from the list: List-Unsubscribe: <http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://list.georgialibraries.org/pipermail/open-ils-general> List-Post: <mailto:[email protected]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general>, <mailto:[EMAIL PROTECTED]> So, simply go to http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general and unsubscribe, or send an email to [EMAIL PROTECTED] with the subject "unsubscribe" (without the quotes). > > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la part de > Chennakeshava,B > Envoyé : 31 janvier 2008 02:02 > À : [email protected] > Objet : Re: [OPEN-ILS-GENERAL] What are your requirements for Evergreen? > > > > what are the software reuired to evergreen installation for PC, kindly > inform me. > > Chennakeshava B. > > > On 1/31/08, Adams, Ken <[EMAIL PROTECTED]> wrote: > > > > > > As for the ILL module - along with ISO-ILL for communicating with OCLC, an > NCIP Responder would be useful. > > > > Ken Adams > > Montana Shared Catalog Director > > [EMAIL PROTECTED] > > > > ________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Deb > Bergeron > > Sent: Wednesday, January 30, 2008 4:27 PM > > To: [email protected] > > Subject: Re: [OPEN-ILS-GENERAL] What are your requirements for Evergreen? > > > > > > > > Ok Dan--thanks for bringing the conversation over here! > > > > You mentioned several modules. One important module is the OPAC. Here > we need both one for patrons and one for librarians. I've mentioned before > that it's always a balancing act that includes the 'necessary' information > for most librarians with those of the faculty and student patrons. I > realize there are several OS OPAC models out there, and perhaps one or more > of these could be integrated. Oh, and by the way, make sure that all the > information can be viewed and downloaded to not only a computer, but any > hand-held device. > > > > Someone mentioned an ILL module--thank you! We need a resource sharing > module that will accomodate not only resource sharing within a consortial > setting, but within a larger environment as well (i.e. the state, country, > world--why are we not thinking like Google?!). This module must have the > ability to 'talk to' the ILS and update the database in real-time without > human interaction. And, could you make this module modular so we can use it > with any ILS? > > > > So, based on the previous postings, we'd have: > > > > Cataloging > > Acquisitions > > Serials > > Circulation > > OPAC > > ILL > > Reports/Stats > > ERM > > > > After building the base modules, let's think outside the box and include > all the wizbang stuff students want (most of this is already available via > ENCORE, Endeca, and other products.) > > > > Reviews > > Tagging > > Chat--including voip > > IM > > Faceting > > > > Functionality not in an ILS (at least not that I've seen): > > > > Add the ability to customize and add functionality similar to Google and > Firefox. > > Throw in some social networking capability or allow it to be added on in a > modular fashion--again over several devices. > > > > Now I'm going to go think about this some more. > > > > > > Deb > > > > > > > > > > > > Dan Scott wrote: > > I would like to start a discussion thread on the following subject, as > > I believe it's incredibly important to the success of the project and > > I don't think we've had much discussion about it yet. Perhaps this > > discussion will also be able to feed into the Duke initiative to write > > a design requirements document for an academic library system. > > > > (Note that "Project Conifer" refers to the project to implement a > > consortial install of Evergreen for Laurentian University, McMaster > > University, and the University of Windsor.) > > > > "What are the base requirements that have to be in place before we, as > > an academic library, or consortium of academic libraries, can migrate > > to Evergreen?" > > > > I'll kick off the discussion by giving an overview of the basic parts > > of the library system (both functionality and "soft requirements" like > > docs and training) and my understanding of where things are. Please > > feel free to broaden beyond what I provide here, as I will undoubtedly > > forget or mangle some of these! I believe that the answers may differ > > for different institutions, of course. > > > > An acquisitions system is a given for everyone, and we're currently > > working on that in the acq-experiment branch, as documented in > > http://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 and > > http://open-ils.org/blog/?p=115, as well as in the wiki at > > http://open-ils.org/dokuwiki/doku.php?id=scratchpad:acq_serials > > > > A serials module is also a base requirement for everyone. On top of > > the acquisitions portion (subscription support, vs. basic one-time > > purchases), at a basic level we need basic patterns (overlay calendars > > with exceptions), a helpful check-in interface, and claiming. > > > > Academic reserves are another base requirement for each site. > > Essentially, give the system the ability to associate one or more > > items with one or more courses (instructor, course name, course code) > > and, by doing so, temporarily override the physical location of the > > item. Longer term it would be nice to have integration with courseware > > (WebCT / Blackboard / Moodle / Sakai) so that the reserve items would > > automatically be displayed as part of the course list, and it would > > also be nice if Evergreen could integrate with the campus academic > > system to know what courses a student was registered in and display > > those courses & reserve lists from the catalogue. > > > > Internationalization (i18n). One facet of this (internationalization > > of addresses to allow Canadian / American / arbitrary address formats > > from around the world) affects everyone. BC has already been able to > > customize Evergreen to support Canadian addresses, so a basic level of > > support is there. However, Laurentian in particular requires pervasive > > bilingual support - which is one of the development pieces I'm > > actively working towards. We hope to have this completed in the next > > few weeks; after that, we simply need to send off the strings to > > translation and our needs will be met. The new acquisitions system is > > being built to be i18n-ready from the ground up. > > > > Circulation: Are there circulation requirements beyond what Evergreen > > already offers today? > > > > Cataloguing: > > * We have added infrastructural support for being able to search > > multiple Z39.50 sources at once, which was one of the requirements > > voiced at the Conifer Acquisitions session. > > * Equinox has stated a number of times that they would like to > > rewrite the existing cataloguing client knowing what they do now. If > > our staff do not like the current cataloguing client, it might be > > possible to use a third-party cataloguing client (OCLC Connexion > > Client, for example) instead. > > * Authority control: there is some rudimentary authority control > > built into Evergreen today. > > * Bulk import of MARC records and authority records: the current > > interface for bulk imports of MARC records is the command line, which > > is not particularly friendly when you face the need to import, say, > > 12,000 records for a new set of Springer e-books. > > > > Catalogue: Do we have requirements beyond surfacing new functionality > > like academic reserves, acquisition requests, etc in the catalogue? > > > > Reporting: The current reporting module is extremely powerful, but it > > comes with no standard report templates. With that power comes a > > certain amount of complexity (it is essentially a nice GUI wrapper > > around the relational schema of the database, so understanding > > relational databases helps a lot) that means that our best approach > > for moving forward will probably be to define what standard report > > templates we want out of the box, then assign someone or some people > > to create those templates. > > > > Documentation and training: There is currently not much in the way of > > official (staff and librarian-oriented) documentation available for > > Evergreen. I started an effort to write "The Book of Evergreen", but > > that faltered when I turned my attention towards more basic > > infrastructure. > > > > Data partitions: in a consortial environment, what is necessary in > > terms of separating one Library's data from another's yet? For > > example: should a Laurentian acquisitions person be able to see > > McMaster's acquisition accounts and individual funds? > > > > Migration of existing data: Apart from bib records / holdings / patron > > records / authority records and open transactions (for example, books > > that are currently checked out), what other data do we want to migrate > > - complete transaction records dating back as far as our existing > > systems allow? Or would we be satisfied just exporting a static set of > > statistics so that we can combine data from the live system with the > > statistics from the old system (for example: circ counts by barcode by > > year)? Either way, we will have to define what data we want to > > migrate, then figure out how to migrate that into the new system. > > > > > > > > > > -- > > > > > > Deb Bergeron System Admin: User Support > > CLIC Consortium > > 1619 Dayton Avenue, Suite 204A > > Saint Paul, MN 55104 > > O:651.644.3878 C:651.487.7609 F:651.644.6258 > > -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
