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 > inhttp://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 > andhttp://open-ils.org/blog/?p=115, as well as in the wiki > athttp://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 <[EMAIL PROTECTED]> System Admin: User Support > CLIC Consortium <http://clic.edu/> > 1619 Dayton Avenue, Suite 204A > Saint Paul, MN 55104 > O:*651.644.3878* C:*651.487.7609* F:651.644.6258 >
