D-Lib Magazine
November 2001

Volume 7 Number 11

ISSN 1082-9873

Lessons Learned

The Development of Electronic Reserves at the University of Calgary


Linda Pearce
Information Resources
University of Calgary
Alberta, Canada

Red Line



This article will lay out the issues surrounding the in-house development of a fully featured electronic reserve platform known as Allectra at the University of Calgary in Alberta, Canada. It will move through every issue surrounding digitization in general, with the added topics of authentication and copyright management. To show the scale of this pilot project, during the winter 2001 term, the 85 documents on Allectra for 22 courses at the University of Calgary were accessed more than 5,000 times.

Why Provide an Electronic Reserve Service?

Why provide an electronic reserve service? An electronic reserve facilitates access to readings in a way that paper reserves simply cannot do.

  • It is useful for large enrollment courses where traditional copyright allows only one copy of a document to be placed on reserve and for distance education students who cannot come to campus to access readings.
  • For courses taught at other institutions, the electronic format solves the problem of delivering multiple copies of readings to a remote site.
  • Users can access the documents 24 hours per day, rather than just during the library's open hours.
  • For pre-reading assignments, an electronic reserve is particularly valuable, since students have not yet come on campus.
  • The secure access to readings via sophisticated authentication mechanisms satisfies copyright holders and, therefore, gives students access to important learning materials
  • This system provides faculty with a structured and documented approach to copyright clearance, in a way that putting up documents through course web pages does not.
  • Staff are given the document management capabilities that are so necessary for a volatile and dynamic document store like e-reserve.
  • An Electronic reserve provides a more unified service approach that builds on established services, countering the document "scatter" that is becoming more evident in print reserves, digital documents accessed via instructor course web sites or through web-based course management systems like WebCT, or direct links from catalogues to full text services.

Some of these benefits cannot be derived through traditional means, and this added value is difficult to quantify in dollars:

  • Learner and faculty time saved,
  • Time and computer storage space saved by individual departments/faculties,
  • Delivery of core materials supporting learning in a discipline,
  • Recruitment of students through effective use of technology,
  • Efficient record keeping, and
  • Effective partnerships with copyright holders.

All of these enhance the learning experience and address the library's strategic directions.

History and Funding of the Electronic Reserve Project at the University of Calgary

Our electronic reserve system was first conceived by Dr. William Reeves in the Department of Sociology at the University of Calgary as a way to deliver readings to students at Red Deer College who were taking University of Calgary courses. With Dr. Reeves, Mary Westell, Assistant Director, Technology, in Information Resources successfully applied for provincial government funding to do a pilot project. The resulting Learning Enhancement Envelope (LEE) grant was to be used to develop an electronic reserve platform for the University of Calgary, the University of Alberta and Red Deer College, with the University of Calgary as the 'lead institution', responsible for development and implementation.

While we would have preferred to purchase appropriate software and, indeed, went through a fulsome Request for Proposal (RFP) process, we found that although several companies had digital delivery systems, none of them handled copyright management and full authentication. It was decided, therefore, to write the software in-house at the University of Calgary, in Information Technology Services (ITS). Specifications were written based largely on the RFP in extensive consultation with staff at the two partner institutions and the University of Calgary, particularly reserve staff. A programmer who had been hired earlier to do some of the authentication and web development for the project was asked to write the electronic reserve system from scratch.

Almost half the LEE grant went toward programming, and another 10% to system administration. The largest single expense after programming was the cost of an IBM RS6000 server with 52 GB of disk space -- enough to run the software and to store at least the first few terms' digital documents. We have spent only $1,000 on the purchase of small pieces of supporting software for the programmer. We spent $10,000 on microcomputers and scanners for the University of Alberta and Red Deer College, and another $25,000 on equipment and a print station for the University of Calgary. For copyright clearance, we have spent $12,000 at the University of Calgary and $7,000 at the University of Alberta. In addition, $5,000 has been set aside for Red Deer College for future readings. We also spent $39,000 on the development of a Remedy-based workflow system that we called Forethought, which tracks the progress of all items from request through copyright clearance and through scanning, uploading and metadata creation.

We spent money on travel and training as well, since we had many meetings with our partners in Edmonton and Red Deer, gave a couple of introductory and training sessions for staff at the University of Alberta, and did a number of presentations on Allectra at conferences like Access2000 [1], Interface 2000 [2], and Netspeed [3]. Funding has been spent to complete the business plan and perform ongoing user evaluation.

Design of the Allectra Electronic Reserve System

The functionality of Allectra had to equal that present in many small, integrated library systems, since the ability to create, edit and delete metadata records was required along with the ability to upload and remove documents, create usage reports, and manage and authenticate users. A front-end equivalent to an OPAC was designed with full search and retrieval capabilities and extensive help screens. All this was complicated by the need to support staff at three institutions who would be working on the same system, and students and faculty at three institutions wishing to see only the documents appropriate to them.

Design specifications were written in ITS based on a great deal of internal input, especially from our reserve unit, external input from our partners, and information gleaned from other electronic reserve systems. Allectra is written in Perl. It had no underlying database management system, which was acceptable when only supporting a very limited number of documents and users, but which clearly would not scale up when the system took off. We are just finishing the migration to a MySQL database.

Features of Allectra

We knew that we needed the following features in order to deliver our initial service in the fall of 1999, and we did, in fact, manage to provide them:

  • Digitization and storage of all documents for the sociology courses
  • Ability to log in and be authenticated at all three sites, preferably at the course level
  • Ability to search documents by title, author, course and instructor
  • Ability to view the first screen before being asked to authenticate
  • Ability to print copyright notices
  • Ability to report to CanCopy the number of times a document had been accessed, and to pay them accordingly
  • Ability to view full .pdf documents with Adobe Acrobat Search
  • Ability to allow use of public domain materials without requiring authentication
  • Links from 856 fields in OPACs
  • Ability to associate courses with more than one instructor, and documents with more than one course
  • Ability to generate statistics
  • Provision of help screens

Allectra System Overview

The public view

Through Allectra users are able to retrieve a wide variety of image types, including but not restricted to .pdf, .html, .gif, .jpeg, and audio and video files. They are able to search by author, title, instructor or course, using Boolean search capabilities. The system incorporates Soundex searching, which can compensate for most misspellings. Users have access to extensive help screens for such things as logging in and viewing materials.


Allectra Home Page

Figure 1: Allectra home page.



To gain access to most items, students must be registered in the appropriate courses and sessions. However, users are not asked to log in for initial searching or to look at the first page of an item (known as the document preview screen). A login is only required when a user chooses to see the full document, image, webpage, etc. For full views of subsequent documents, only the password needs to be re-entered.

At the date of writing, users can see all documents available at all three institutions. For access to Allectra, the user can go directly to the Allectra website at <>, or can get there via the Sirsi (University of Calgary) and DRA (University of Alberta and Red Deer College) web-based OPACs. An 856 link in a bibliographic record in the library catalogue can take the user directly to that document in Allectra, with an intervening login screen only if the item is copyright protected. Users cannot view or print documents to which they do not have rights through their institution's copyright agreements.

Based on feedback from users and partners throughout the preceding sessions, a new look with added functionality and cosmetic changes was implemented for the Winter 2001 term.

The instructor's view

Instructors have access to a report that provides the usage of items for their courses. This does not show which students have accessed the items (since we do not retain this information), but the report does show the number of accesses and the dates the documents were accessed. This usage information can be quite important for course planning.

We are working on another piece of functionality for faculty members and instructors, which is the ability to submit a request for an item to be added to the system. Through a short series of wizards, the instructor will be asked to submit three kinds of information:

  1. Information about the course -- course name, number and session; dates; number of students enrolled; names of all instructors.
  1. Information about copyright requirements.
  1. The actual citation, and information about the availability of the item.

Eventually, we may integrate all requests for items to be placed on reserve through submission of one form, leaving the decision of whether to provide paper or digital access up to the reserve staff, based on copyright permissions and costs.

The staff view

Electronic reserve staff are given access to a large number of tables internal to the Allectra system. Since there is no software client that must be resident on their microcomputer, reserve staff do all their work via a web browser. They can add/edit/delete institutions, departments, courses, instructors, rightsholders, metadata records, and document owner records. The system makes use of a persistent ID number for each object (the PID), representing each item, whether it is a .pdf document, a website, or an audio file. The metadata record PID matches the file numbering system, and this ability to track an item by a unique number is very important when managing large numbers of items.

When filling in the metadata record, staff are required to enter two URLs:

  • The first URL is the Preview HTML Tag, which controls what the public sees on the document preview screen. This is, in fact, quite a powerful and flexible feature, because although the primary purpose of this screen was to display the first page so the user would be sure he had the right document, it is possible to use this tag to put anything on the preview screen -- announcements, copyright or contact information, links to instructors' websites or other related websites, etc.
  • The second URL is the actual link to the item itself. All such links are written as URL's.

    For example, if the PID of an article called "Collapsing waveform technology" by H. Fremantle was 50312, then metadata record #50312 would include a document URL of,
    the first three characters of the filename being taken from the author's last name.

    The Preview HTML Tag might be
    <img src="">
    since the first page of the item is being put up as a separate image.
  • Lastly, staff can generate usage reports that are the basis for copyright payments to rightsholders and that are also useful for tracking the history of the database over time.

Processing is time-consuming, and we soon realized that we needed to develop a Workflow Tracking System to monitor the entire process from the initial request through copyright permission, scanning and metadata creation. Ideally, an integrated module of the Allectra software would have been best; however, because of staffing considerations we have opted to work with University of Calgary Information Technologies to build a workflow system based on the Remedy software. This system will eventually interface with the faculty request forms and Allectra metadata records. This application, called Forethought, has been successfully and heavily used to manage the Fall 2001 readings.

The system administrator's view

System administrators are able to do many extra tasks, chiefly associated with security (see section on authentication). In addition, they can:

  • Post announcements
  • Post onscreen messages (an example would be for the Freedom of Information and Privacy statement)
  • Add institutions
  • Read error logs
  • Change the wording of system error messages
  • Change the hosting and uploading locations of documents
  • Add metadata fields
  • Add messages and error messages in other languages or for specific institutions.

Allectra Challenges and Issues


Before even developing an RFP, we were aware that our main challenge would probably be copyright, rather than technological feasibility. In very early discussions, CanCopy (Canadian Copyright Licensing Agency) indicated a willingness to test the concept of an electronic reserve provision with us as long as certain stringent requirements for system security were met. Most documents cleared through CanCopy, for example, had to be restricted to students registered in the course for which permissions had been granted. Course readings should not be those normally included in course packs. CanCopy should have access to Allectra to satisfy themselves of proper use. Documents must display a copyright statement. Because of all these requirements, one of the key elements of the electronic reserve project was demonstrating effective and secure copyright management to CanCopy.

Our campus copyright officer, Wendy Stephens, proved pivotal to our developing relationship with CanCopy in this project. She negotiated what we believe was the first agreement for digital rights between CanCopy and any Canadian institute of higher education. All subsequent clearances have gone through Ms. Stephens, who has had increasingly greater success obtaining permissions, both through CanCopy and directly through publishers. Initially, as the concept was new and rightsholders were understandably wary, it took months to obtain those permissions which we were able to get; now, however, many items are cleared within a week or two.

The University of Calgary and the University of Alberta do not have identical licensing agreements with CanCopy, which may pose some small difficulties with system security requirements. We are working through those issues now. Two other issues that have turned out to be particularly problematic are the inability to repackage full text for which we already have paid access through an aggregator, and delivering newspaper clippings. In the first instance, there are technical and political issues. In the second instance, newspapers typically get their articles from news bureaus and do not have the rights to redistribute articles or photographs, as the copyright belongs to the news agency, the journalist, or the photographer.

To date the copyright costs vary so widely that it would be impossible to provide an estimate of average price. Some rightsholders charge according to the number of students enrolled in the course, some charge per use, some charge a flat fee, and many, surprisingly, have given free permission. We at the University of Calgary know that we will soon have to roll over the copyright costs -- perhaps into some kind of centralized campus funding or into the book budget. As a beginning, for the Fall 2000 term funding was provided from the University Planning Initiative Fund to support the expansion of the electronic reserve.

In the future, it is probable that the cost of obtaining digital permissions will become a decision point around which our provision of access will turn. In other words, if one reading for one course would cost $1000.00, we would likely provide access in traditional paper form rather than digital. There is no correlation between the copyright costs and restrictions for an article in paper format and for the same article provided in digital format. It is usually much cheaper to provide the student with a paper copy at the reserve desk, and it is also probable that the processing costs for digital delivery will exceed traditional costs by two or three times. However, the benefits of digital delivery are immeasurably greater.

We do not charge students for either copyright costs or access to the digitized items. Printing is 5 cents per page in the Information Commons.


Because our earliest negotiations with CanCopy had indicated that we would have to restrict readings to students registered in a particular course and section, we knew that we would have to build an interface from Allectra to some of the campus mainframe systems and to the user database in our Integrated Library System, Sirsi's Unicorn. To make a long story short, we now use information from our Unicorn borrower database together with that found in the campus ID system, the campus LDAP server, and the Registrar's office.

What is probably more interesting is the flexibility the system exhibits in its authentication structure. Documents can be protected by:

  • Proof that the user is registered in a course, as above
  • Campus authentication without the registration information
  • Simple password
  • IP check
  • An internal user list (for special users like CanCopy staff) or any combination of the above.

Documents can also be made available with no authentication at all. To date, this sophisticated authentication is developed only for the University of Calgary, but we hope to do more with it at the other institutions soon.


All users can choose to print the documents delivered through Allectra. To date, these have nearly all been .pdf documents, read with the Adobe Acrobat Reader plug-in. In the University of Calgary library, students in the Information Commons have access to networked printers. They are not charged for copyright or access, but they do have to pay for the printing by swiping their Campus Cards in the General Meters print control station. Printing at an attached printer -- as at home for instance -- is, of course, free.

Multi-institutional issues

Developing an application such as Allectra that can be used simultaneously by several institutions poses some special problems. Among these problems are:

  • How to restrict access to documents to a single institution;
  • How to do authentication against three or more completely different campus authentication systems;
  • How to provide usage statistics separately for each institution;
  • Whether to run a single copy of the software, or run several;
  • Whether to centralize the storage of images;
  • How to provide technical support for all institutions;
  • How to customize the front end and, more particularly, the help screens for each institution;
  • Whether to make separate metadata records when more than one institution is using the same item; also whether to duplicate the file itself;
  • How to deliver the files to the server without compromising security;
  • How to identify from which institution a user is coming.

At this time, we are doing distributed processing but the database and file storage are centralized. However, it is extremely easy to change this configuration, and it is probable that we will implement distributed file storage quite soon.

Having the choice of using a centralized Allectra or using a standalone system provides maximum flexibility for our partners and allows us to export a standalone version of Allectra for use at non-partner institutions. We have experimented using a Linux server with a standalone version of Allectra for the University of Calgary's Health-Education Cluster. (The Health-Education Cluster comprises the faculties of Education, Kinesiology, Medicine and Nursing.) The Cluster's Allectra object repository contains documents in many formats, including video clips and interactive images.


We made the decision early in development to use the Dublin Core metadata standard with additional fields where required. Allectra uses a single long screen for all record types.

The fields are:
Spacer Title of article/chapter
Spacer Author of article/chapter
Spacer Title of journal/book
Spacer Volume and issue
Spacer Edition (if book)
Spacer Year of publication
Spacer Publisher
Spacer Record type
Spacer Format e.g., .pdf, .jpeg, .mpg, .wave, etc.
Spacer Size e.g., Number of pages; Number of KB, minutes, etc.
Spacer Rightsholder
Spacer Availability (Active/Inactive) (Inactive is usually used when
      copyright permission is pending, to make the document
      unavailable; the system does not allow access to it
      when this flag is set)
Spacer Dates the access is valid from and to
Spacer Persistent ID
Spacer Creator of metadata record
Spacer Date created
Spacer Date last modified
Spacer Preview html tag
Spacer Document url


While we hope one day to get documents in digital format directly from the publishers, at present we are scanning the articles/chapters ourselves. In order to maintain quality control, we prefer to do this in-house rather than to receive scanned files from instructors. We use a flatbed scanner with a sheet feeder and Photoshop software; the scanned documents are then converted into .pdf format, while the image of the first page is saved in .gif or .jpeg. The programmer has written some excellent scanning standards for the project. They are freely available at <> by searching the author name "Vandenbeld". The documents include:

  • "The fine art of scanning"
  • "Principles and practices for resource digitization"
  • "Scanning procedures for PhotoPaint"
  • "Scanning procedures for Photoshop"

It takes a fine touch to produce a top quality scan of an article. Many items retrieved through document delivery have been of extremely poor quality, and often books and journals have been underlined or written on. These types of images require a good deal of cleanup, which is undeniably labor-intensive. We photocopy the articles before scanning so they can be fed into the scanner via the sheet feeder; in many cases, the photocopying also produces a crisper image for scanning.

The file sizes of the page scans can be a critical issue, as some networked printing solutions are less forgiving than others. Because some institutes have problems printing very large .pdf files, one of the institutes is doing Optical Character Recognition (OCR) to reduce the file sizes.

We would like to write software to support a workflow that allows us to scan documents into .tiff files, reprocess those into associated .jpegs, automatically generate the first page display image, and automatically name and store these files to a defined directory structure. This, in addition to the provision of a digital workflow equivalent to staff processing of paper reserves, would be an important addition to Allectra's functionality.

In 2001, we downloaded from the Internet a large number of documents, including many full texts (with copyright permission of course). This works well on campus, but some users with low-speed Internet connections may experience difficulties downloading entire books.

Implementation of the Allectra System

Allectra went "live" in September 1999, providing access to around 60 .pdf documents as well as to a couple of websites. Almost all of these were for the Department of Sociology at the University of Calgary. As time went by, we engaged the interest of a number of instructors in the Faculty of Education and, by Summer 2000, had several courses up for the Faculty of Education as well. In Fall 2000, the University of Alberta came on board strongly with a pilot project for their Faculty of Education, involving hundreds of documents. We now have experience with digitizing four complete books, one for the University of Alberta and three for the University of Calgary. Some special procedures were required to provide access to individual chapters.

During all six sessions that the University of Calgary has delivered documents, almost all the work has been done by staff in Information Technology Services (ITS), still in pilot project mode. At the University of Alberta, the reserve staff in their Education Library are participating fully, along with their ITS department. Red Deer College is also providing access to many of their readings through Allectra as of Fall 2001.

We at the University of Calgary have done initial planning to turn over the following functions to the appropriate areas inside Information Resources (consisting of the Library, Communications Media, the Image Centre, the University Press, etc.):

  • Receive and process requests from faculty
  • Initiate copyright clearance
  • Enter copyright information into the system once permissions have been received
  • Notify faculty regarding permissions status of materials
  • Retrieve items -- this may involve document delivery services
  • Photocopy, scan and upload files
  • Create metadata
  • Create a course record in the Sirsi Unicorn Webcat (our OPAC)
  • Handle special authentication procedures for distance education students
  • Produce statistics and listings
  • Print usage statistics at the end of each term for payments to rightsholders, and delete image files if required by copyright agreement.

Some of the questions regarding the allocation of work are not straightforward. Should scanning be done by reserve staff or the Image Centre? Should copyright information be entered by reserve staff or the campus copyright officer? Should document delivery procedures be incorporated into the reserve workflow or vice versa? Only after we have implemented the system more widely will the answers to these questions probably become obvious.

Allectra: Lessons Learned

We can quite quickly draw some broad conclusions from our experience so far.

First, one cannot underestimate the extra amount of work involved in putting documents on electronic reserve rather than paper reserve. While the shelf retrieval mechanism is the same, and photocopying is required in both cases, the additional steps of scanning with good quality control, creating metadata, applying for digital copyright clearance, and dealing with authentication issues for certain classes of users are very labor-intensive. It also turns out that the provision of access to entire books poses special problems and extra work, over and above the large amount of scanning involved.

Second, it is not particularly easy to persuade faculty that such a service has benefit to them. A critical mass will have to be achieved before faculty will come on board in great numbers. However, it is possible to start moving some of the traditional paper reserves into electronic formats, and this shift should convince faculty of the value of this new service. Other initiatives on campus, like those that provide the use of WebCT to instructors, are partly in competition with an electronic reserve service, but we see ways to enhance one another's offerings rather than detract or compete with them. Tests have shown that Allectra documents can be accessed from WebCT and vice versa.

Developing a piece of software like Allectra in-house is nothing short of a major undertaking, requiring literally years of dedicated labor. Particularly if the project is done in concert with other institutions, a large amount of time is spent in consultation and meetings. Software specifications change and grow on a daily basis. New problems arise. New standards must be developed. Hardware must be acquired and configured. Development using leading-edge technology is extremely difficult to manage and is vulnerable unless there is a team of programmers working together on the project.

We have learned that digital copyright permissions can be acquired and many rightsholders, as well as CanCopy itself, are very willing to participate in such projects. We have also learned that the costs assessed for digital rights vary so widely that no estimate can be made of what it might cost to put up the readings for a particular course unless all the articles come from publishers with whom we already have digital rights agreements.

Because of CanCopy access restrictions, we learned that it is indeed possible to authenticate users right down to the course and session level; this authentication system is extremely useful and portable to some other applications as well.

We have learned that usage of the articles will not be heavy unless the instructors make the readings a requirement for all their students. In addition, in the absence of heavy use it is very difficult to evaluate the service.

Tracking a large number of readings for a particular course through the process has proven extremely difficult, since readings will be in one of the following processes: document delivery, photocopy, retrieval from the stacks, scanning, awaiting copyright permission, waiting for the files to be uploaded, metadata creation, awaiting further information from an instructor, etc. Our new Remedy-based tracking system has been designed in such a way as to provide greater assistance with the workflow. It is proving to be a vital component of the electronic reserve procedure, since it is the chief method of communicating permission tracking between the copyright office and the library.

We learned that the issues around full deployment of the electronic reserve system are not simple, and it is not necessarily easy to decide where certain functions should reside or who should be finally responsible for them. It turned out to be remarkably difficult, for example, to get good citations for the dozens of readings included in the personal copies on reserve; these personal copies are usually binders full of readings from various sources the instructor has pulled together on a particular topic. Some thought was given to having cataloguers do the citations, but this turned out to be impractical. In the short term, the citations were done by ITS staff, but there were some instances where the citation was simply not available at all.

We learned how difficult it is to digitize and provide access to entire books, sometimes even when the digital files are supposedly already available. We digitized and provided access to three books and found the process technically challenging and hugely time-consuming. For one course, the books were so heavily used, however, that the effort was worthwhile.

We found the chief difficulty to be the short timelines between the receipt of personal copies for reserve and the time when the documents would be required online. Taking into account the time taken to get copyright permission and to find and scan the actual items, it was sometimes completely impossible to get the materials online fast enough.

We learned about the difficulties of marketing software, even with all the best will in the world. It always changes a project's priorities when the priorities are being partially driven by other, outside users of the software. As well, when doing cutting-edge development, there are real difficulties meeting deadlines and bringing the product into the mainstream, especially as it applies to "operationalizing" the functionality.

We learned that an electronic reserve may be the least of what could be provided with the Allectra software, that its capabilities far exceed requirements of a "reserve", and that it may be the basis for much larger library digitization projects in the future. In one sense, a digital object warehouse is much easier to support, because items do not go in and out as reserve documents do, nor do they have to be linked to courses, instructors or sessions.

And lastly, we found that our partners at the other two institutions were extremely valuable in every way possible. They provided insights that we may not have had working alone. They cooperated in reading and providing input to specifications, evaluating responses to the original RFP, testing, and developing standards. And sometimes they got us out of town! In every way, their involvement led to a better product than we would have developed without their participation. Our evolving relationship with all our partners was warming and valuable beyond words.

System Redesign in JAVA

Fairly quickly we had come to the conclusion that Allectra could be used as the underpinnings for many other digitalization initiatives, on and off campus, and we received quite a number of expressions of interest from other universities and organizations. The functionality and stability of even the slower Perl version were more than adequate to support a variety of services. After the system had been up for about six months, the programmer began a complete rewrite using Java, Java server pages, and MySQL as the underlying Database Management System (DBMS). The chief impetus for redesign was scalability. If we are to use Allectra for large-scale digital library projects, we need it to be capable of handling huge numbers of documents for a large number of concurrent users.

The redesign posed some difficult problems. Among them was the fact that there were few experts readily available for consultation on writing full-fledged applications in Java, so our programmer was breaking new ground on his own much of the time. Because we didn't want to distribute or support client software, the entire application for staff functions had to be web-based, which causes difficulties with session control and authentication. We wanted a smooth workflow for the staff, so the design of the administration module was critical to the long-term success and usability of the software. In order to improve performance, the programmer developed a method of intelligent load-balancing when delivering resources to the user. Some stress tests showed that the Java version of the software was performing up to 44 times faster than the Perl version.

In terms of added functionality, we wanted to include full XML capabilities, and the Java version would have done just that. The system can read and write objects from and to plain text or XML or to the database or a variety of other devices. This sort of functionality would also make Allectra a powerful framework for the delivery of customized library services.

In a new version, we would want to add various IMS [4] metadata fields. These would include Resolution of images, MIME type, Fees for use, etc. The IMS standard being developed for educational institutions "specifies the syntax and semantics of learning object metadata, defined as the attributes required to fully and adequately describe a learning object. A learning object is defined here as any entity, digital or non-digital, that can be used, re-used or referenced during technology-supported learning."[5] We would like to reconfigure Allectra to provide for any new record types and allow for adding terminology from a specialized thesaurus for one application (although without authority control); those headings would then be searchable.

Unfortunately, in January 2001 our Java programmer left, and we elected not to continue development of the Java version within the library. However, the partially completed code is being evaluated by other parties at the university interested in digital object repositories. Because the Java version was developed through LEE funding, we are pleased to be able to share it with Alberta post-secondary education projects. We believe that some of these partners will continue development of the software, and we in Information Resources will be contributing expertise in metadata and design specifications. Meanwhile, the Library is proceeding with further upgrades to the Perl version as well.

Dissemination of Allectra to Other Institutions

The terms of the LEE funding award are that if we provide Allectra to other post-secondary educational institutions in Alberta, we must give it to them at no cost. We are not so constrained with non-educational bodies or with institutions outside Alberta. Because we think Allectra is extremely useful, we would like to see it deployed more widely and have thought seriously about open-sourcing or marketing Allectra in other ways.

This is not as easy as we would like it to be, primarily because of support issues. Without extra staffing, we could not afford to support the software, troubleshoot, assist with configuration or provide new releases. There are also training issues, time spent in meetings and consultation with prospective and existing "clients", difficulties with varying operating systems and hardware platforms, etc. Without being a software company, it is hard to see how we could provide good service in the absence of all the support units that such companies have in place. Apart from these factors, it is not our mandate to provide such a service, however much we would like to make the software available. We are wrestling with these issues as we work through the final development stages.

Having said that, we are already committed to providing the software to three or four "entities" in Alberta, and so we will have to carefully evaluate all these factors as time goes on. We have some experience with providing locally written software to others; we share both the Landru [6]data system (with many other universities) and our Webrelay [7] authentication system via something approximating a Gnu license, and we will consider a similar mechanism for distributing Allectra.

If you would like to contact us about this issue, we would be pleased to hear from you and answer questions. Contact:

Linda Pearce, Manager, Library Systems, University of Calgary
Phone: (403)220-6648

Mary Westell, Assistant Director, Technology, Information Resources
University of Calgary
Phone: (403)220-3764

Notes and References

[1] Access2000 Conference, <>

[2] Interface 2000 Conference, <>

[3] Netspeed 2000 Conference, <>

[4] IMS Global Learning Consortium, Inc., <>

[5] Extracted from the proposed IEEE standards document at <>

[6] LANDRU (Local Access to Networked Data Retrieval Utility), <> Contact Mary Westell, <>, for information about distribution of Landru.

[7] For distribution information about Webrelay, contact Mary Westell, <>, or Linda Pearce, <>.


We would like to express our particular thanks to the following people, and also to the many other staff at all three institutions who provided so much helpful input to the project.

Project Participants:

Grant Kayler, University of Alberta
Alice McNair, Red Deer College
Kristine Plastow, Red Deer College
Doug Poff, University of Alberta
Dr. William J. Reeves, Dept. of Sociology, University of Calgary
Wendy Stephens, University of Calgary
Josie Tong, University of Alberta
Mary Westell, University of Calgary

Staff at the University of Calgary:

Sandy Blazina
Amy Chiu
Robyn Herrington
Marie Mastracci
Mary Jane Pon
Ivan Runions
Alicia Texeira
Rob Tiessen
Donald Vandenbeld
Dan Woods

CanCopy staff

And ALL the other University of Calgary and University of Alberta faculty who were patient guinea pigs and early adopters of the service.


Copyright 2001 Linda Pearce

Top | Contents
Search | Author Index | Title Index | Back Issues
Previous article | Next article
Home | E-mail the Editor


D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/november2001-pearce