Comments below at >>>. Hope this helps.
Stuart Miller -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Scott Sent: Wednesday, July 02, 2008 10:44 AM To: Evergreen Discussion Group Cc: David Larsen Subject: Re: [OPEN-ILS-GENERAL] Requirements for academic reserves: request for comments > 1. This is fine as far as it goes, but it's based on all print--half of our > reserves are electronic. We don't make photocopies any more--anything that > needs copying is scanned and files stored locally; anything that is in an > online subscription resource gets pointed to that resource. Any course > reserve module has to be able to deal with virtual as well as physical items. You are correct, the current RFC is all based on print. But given that there is no course reserve support in Evergreen today, I would argue that building course reserve support that deals with half of the course resources is better than no support at all. Perhaps I should rename the proposal "Academic reserves (print materials)" as that is currently what it is aimed at; our university is a world in which the ILS and the course management system are two completely separate worlds. The RFC is therefore based on the practices that I am most familiar with, so in replacing our current ILS with Evergreen the requirements expressed in the RFC would meet our present needs. On the other hand, with the help of you and others, perhaps we could add the requirements that would be needed to offer a better solution than what we have today. For example, adding the ability to maintain a list of URLs (with basic citation info) for electronic materials in online subscription resources is not much of a stretch. >>>We would not/could not use a course reserve module that did not support both >>>print and e-reserves. There would be no point in moving to a CR module that >>>didn't offer both. I really think many academic libraries--at least in the >>>U.S.--have embraced e-reserves with a vengeance. And there are just >>>different processing requirements--a scanner interface, for instance. > 2. We no longer offer a course reserve catalog to the public because access > is provided via Blackboard so only those registered for a class have access > to the course list--which is what we want for copyright compliance. We want > something that can be tightly integrated with a course management tool like > Blackboard. Interesting. So in your institution, when a print item is placed on reserve it is no longer available to anyone outside of the course? Or is this restriction only for digital materials - and even then, only for locally scanned digital materials (as presumably your online subscriptions continue to be accessible to the rest of the institution)? >>> When any physical item housed somewhere in the library is temporarily >>> placed on reserve, the location, item type, etc. is changed to the reserve >>> location parameters. If a user finds the record in the online catalog, s/he >>> will see that it is on reserve. But users can no longer search by course or >>> by instructor to find reserve items. You have to be registered for the >>> course and access the list by going through Blackboard--we provide the URLs >>> to Blackboard. Any records (bib and item) created for a course packet, >>> e-reserve item, etc. are marked "staff only" which keeps those records out >>> of the online catalog but does not keep them off the course reserve list >>> accessible through Blackboard--the course reserve lists in our system do >>> not reference the "staff only" flag. [We consider this a very fortuitous >>> bug.] Out of interest, how does Blackboard integrate with other library systems? Does the company behind Blackboard have to provide the integration module, or is it possible to "roll your own" layer of integration? I was deliberately fuzzy on system integration beyond supporting basic standards like RSS feeds because at this point I don't want to get into a discussion of exactly how WebCT, Blackboard, Sakai, Moodle, etc. integration would work. I'm confident that OpenSRF will surface the required read/write mechanisms for any course management system capable of a customized integration layer - which is why I wrote the very generic: "To enable integration with other campus systems, the reserve materials for a given course should be able to be accessed via various methods". >>>I think you are correct to keep it general, but I would say that integration >>>with course management software is an essential requirement. Our integration >>>with Blackboard is really more of a kludge than anything else; I believe >>>Atlas worked directly with Blackboard on its integration with Ares. What it >>>does is essentially open a window in Blackboard that is in effect a front >>>end to the Ares product--one for those accessing the lists, another for >>>faculty to initiate course reserve requests. > 3. We are in need of copyright compliance features; there is no mention of > that. Can you describe what you mean by "copyright compliance features"? Is this strictly for locally scanned digital materials? Perhaps you could craft a few points to add to the RFC in a new "Requirements" subsection called "Copyright compliance" (which would also cover the visibility or invisibility of reserve materials that you mentioned above); that would be a great enhancement to the RFC. >>>Features that would let us comply with the requirements of the Millennium >>>Copyright Act which puts specific rules in place as to the number of times >>>you can use a copy of a copyrighted item for the same course within a >>>specific time period before you must pay for permission. For purposes of the >>>RFC, I would guess you would want to phrase it along the lines of whatever >>>is required by national copyright law. Of course, every country is different >>>so if we're talking ideal world here, this particular feature should be >>>designed so that installation would require you to select a country to get >>>the specific features you need. > 4. Making brief MARC bib records for copied articles, etc. has been the bane > of our existence for years--it has caused endless problems. We want records > created specifically for course reserve to be in a separate database. But > it's also true that when an existing paper title is temporarily placed on > reserve, we want to be able to change the location, loan period, etc. as > described in the RFC. Well, you're jumping ahead to implementation details, when the current RFC just talking about requirements. Note that in the requirements I didn't specifically say that this would result in a MARC record, I just said that "Staff need a minimal cataloging interface for ephemeral items". This could be a simple Web form with four text fields that results in a MARC record. Or it could be stored in a separate table entirely. That's something that we decide later. The current RFC deliberately avoids implementation details because they distract from the main discussion point: would a system that meets these requirements meet your library's needs? In your case, no: so you're helping by providing the additional requirements for your library. >>> When you say "cataloging" to me, I hear "MARC record". Course reserve >>> operations really should not need to be concerned about "cataloging"--just >>> making a comprehensible description of the piece in hand as needed. And >>> whatever format they are in, we at least would NOT want them available >>> through any type of "regular" search in our user interfaces. Which to me >>> almost requires them to be stored in their own database and appear only in >>> a course reserve listing. > 5. We definitely want to offer our faculty more options than sending us an > email of titles. Okay. So you agree with the requirement "Instructors must be able to place items on reserve with minimal effort."? >>>Well, yes, if that encompasses instructors having the option to supply >>>citations that could automatically be plugged into a course list so that our >>>staff wouldn't have to rekey anything. [That's what the Ares/Blackboard >>>interface allows.]
