LibData: Project Brief

Overview
The goals of this project are 1) to create a database (tentatively called LibData) that can drive the core portions of our web site, namely those portions that list the resources and services we offer, and 2) create an authoring suite for customized presentations of library resources. Currently we use the OLIP database to enter and display some of these resources. The OLIP database was originally written to drive Research QuickStart (RQS), and has done so admirably for 5 years. However, with the redesign of LUMINA in 1999, the current OLIP database began to be used for more than just RQS. It now drives some of the content for the Indexes pages, CourseLib, Subject Resources, Reference Sources, and various resource listings on divisional library sites like Government Publications and the Music Library. In doing this, various problems were discovered with the current OLIP database:

• The OLIP database is not flexible enough to efficiently allow for multiple uses of the same data. The OLIP database was not originally written to do this, only to run RQS.
• The OLIP database is broken into four main sections: Current Information, Background Information, Writing Guides, and Books. This is good for an undergraduate research tool, but extremely limiting when you want to expand its use.
• Proposed changes to make the OLIP database do exactly what we want have either proven impossible (due to the current data model) or too costly.
• The current configuration of the OLIP database makes it quite difficult to find appropriate resources that have already been entered into the database, to add to RQS pages.

These reasons, coupled with the desire to bring these projects "in-house," has prompted a small group of library staff to rewrite this database in order to make it more scalable, reusable, efficient, and user-friendly.

It is our hope that LibData will drive the content of these portions of our web site:

• Research QuickStart
• Subject Resources
• CourseLib
• Indexes
• Reference Sources
• Various divisional library sites

This can be considered Phase 1 of the project. It is also our hope that this system can tie in easily with other database products such as the Hours/Library Info database, the E-Journals database, other parts of the Information Literacy toolkit like QuickStudy, FAQ, and the Assignment Calculator, and especially the upcoming E-resource Inventory Database (aka the "Troubleshooting Database") sponsored and commissioned by the CDM Leadership Group and its E-Resources Steering Committee. MNCAT may also tie in to the database. In addition, a possible connection between LibData and the University's portal project will be analyzed. It is unknown at this time exactly how these systems will tie together, but every effort will be made to make the LibData database as flexible as possible. The sites and projects bullet listed above are only a beginning for LibData and, again, may be considered Phase 1 of the project. While these portions of the site will receive the bulk of the attention at the beginning, during the course of development other applications will surely suggest themselves.

Organizational Impact
Currently three teams, and the people in these teams, will be affected by the development of LibData:

ITS
Jon Nichols, team leader
The Web Services Coordinator will use the database to drive the content of the Indexes pages, Reference Sources pages, and Subject Resources pages on LUMINA. The Web Services Coordinator will also use the database to drive the resource listings of various departmental library pages under his direction.

RCS
Kay Kane, team leader
Reference librarians and RCS staff members will use the database to create the content for Research QuickStart, Subject Resources pages, and CourseLib. RCS staff will use the database to manage the categories and resources currently listed under Reference Sources in LUMINA. RCS staff members in charge of departmental web pages may also use the database to drive pages listing resources specific to the discipline covered by that library.

CDM
Charles Spetland, team leader
Bibliographers and CDM staff members will use the database to drive the content of the Subject Resource pages, CourseLib pages, Reference Sources, as well as any RQS pages under their domain.

It is extremely important that the team leaders above understand the potential impact that LibData will have on staff. Of course, the goal of the LibData project is to make management of these tools easier, but there will most likely be some resistance to its development. It will change how work is done, especially in relation to the Subject Resource pages. More than anyone, the Leaders of the affected teams must "buy in" to the project, and sponsor and champion the project. Team Leaders will be kept abreast of progress, changes to the scope of the project, and any problems the Design Team encounters. The Team Leaders will also have final authority over the project.
LibData Design Team

The LibData Design Team currently consists of six (6) members:

• Shane Nackerud, project lead, Indexes and Reference Sources lead
• Paul Bramscher, lead programmer
• Kate McCready, RQS lead
• John Butler, CourseLib lead
• Andrea Halverson, departmental/divisional library co-lead
• Laurie Nelsen, departmental/divisional library co-lead
• Laura Dale Bischoff, Subject Resources lead

It is expected that Shane Nackerud and Paul Bramscher will spend over 50% of their time working on the project until completion. The rest of the members will spend at least 10% of their time on the project, with the bulk of the work coming during the planning and interface design stages of the project. These percentages are estimates at best and may increase or decrease depending on the amount of work to do.

Meetings will be bi-weekly/monthly starting in mid-late April with, again, the bulk of the meetings happening in the early stages, tapering off during initial programming and construction, and picking up again during interface design and data conversion.

Other people that have expressed interest in the group and a willingness to help include:

• Kay Kane, RCS
• Amy West, RCS
• Jim Stemper, CDM

Timeline and Project Stages

Preproduction
April - June 2002

Project brief
Desired outcomes
Project specification

Production
June - November 2002

Database model completion
Database creation and programming
Initial interface design
Interface design
Testing

Data Conversion
November 2002 - May 2003

Training/Maintenance/Evaluation
February - May 2003

Unveil
Summer semester 2003

Again these are estimates and are most likely wildly inaccurate. They should give a good idea, though, of the commitment needed for the project. Throughout the lifespan of the project there will also be "sneak peek" meetings for the staff of ITS, RCS, and CDM (hopefully).

Critical Success Factors
The bulk of these "critical success factors" will surface as we decide on desired outcomes in the pre-production phase of the project. However, some are already known based on problems we've already found in the current configuration of the OLIP database. Please keep in mind, though, that this is an incomplete list, and perhaps even an inaccurate list. I suppose it is really more of a "wish list" and I encourage others reading this document to start thinking about what else we need this system to do.

Project wide factors

• First and foremost, the system must be easy to use. It must make it easy to add resources, author pages, and present information. It must be easy to tie resources to resource types, categories, subjects, and use them across each individual project. Although this is difficult to measure, staff usability will be a very important part of the project.
• Different levels of authentication and authority should be available throughout the system. The system should allow ownership over specific subjects or pages.
• The system should make it easy to wade through the large amount of potential resources to select those resources to display on your page(s). The system should include a tool that can easily compare and contrast resources for inclusion on Subject, RQS, and CourseLib pages.
• The system should give information concerning date created, date last modified, and who owns/created/modified a page/subject/course page.

• It should be possible to assign a resource to more than one resource type (something can be an Index as well as a bibliography, etc.).
• It should be possible to assign a different description to a resource depending on subject.
• The current breakdown of Background Information, Current Information, Writing Guides, and Books should be retained (?).
• It should have the ability to cross-reference between subjects (suggest other subjects).
• It should allow for some subjects to show in RQS and not Subject Resources and vice-versa.

Subject Resources

• The system should allow for larger Subject Resource pages, more resource listings, more resource types, more flexibility in general. It should also be possible to create a Subject Resource page and an RQS page at the same time by selecting, perhaps, a subset of the resources on a Subject Resources page for an RQS page.
• The system should also allow for the creation of RQS and Subject Resources pages separately.
• The system should allow for the creation of Subject Resource pages that contain more specific resource type listings than within RQS. RQS currently has four main sections within its data model (listed above), with other resource types (encyclopedias, indexes, dictionaries, etc.) tied to one of these four. The system should allow for the creation of more specific resource types that aren't tied to these four main RQS types.

• The system should allow Indexes information to be extracted in alphabetical order, by specific subject, broad subject, full-text, CD-ROM, vendor, and "free."
• The system should allow Indexes to be easily turned "on and off" for vendor scheduled and unscheduled down times.

Reference Sources

• The system should allow for resources within the system to be connected to Reference Sources categories currently on LUMINA.
Divisional/Departmental Libraries
• It should be easy for an individual library, like Bio-Med, to create resource lists for their web site specifically. For example, it should be easy for Bio-Med to create a page listing Indexes specific to the Bio-Med library. Other library specific resource type listings should be theoretical possible.

Budget
As has been pointed out to me, just because we are doing this project "in-house" doesn't mean that we aren't spending any money. Staff time must be taken into account. An initial estimate of $100,000 in staff time has been suggested.

Initial discussions concerning hardware and software have led us down the path of "open source" development. Advantages of this approach include 1) no software licensing fees and 2) open source products make it easier for us to either sell our work or give our work away. A small library in Minnesota, for example, can install LibData without having to worry about Oracle and NT licensing fees. That is the hope anyway. Every effort will be made, however, to make the system as flexible as possible. This means if a person library wants to use Oracle, hopefully they will be able to.

A small budget for student workers may be needed when the time comes to fill the system with data. Obviously, we are first going to try to port the data from the old systems into the new system. However, we are building a new data model that may make this difficult.