Link: http://lettuce.tapor.uvic.ca/~dbadke/scrapbook/pages/spread.php

Scraps Project Charter

Project Leaders:
Research: Chris Petter and John Durno
Technical: David Badke

Other Participants:
Marnie Swanson, Ken Cooley, Scott Gerrity, Alouette Canada

Roles

• Chris Petter: Project lead. Research and digital library objectives; providing quality images in digitized format; along with John Durno, implementing technology in the Library.
• David Badke: Technical development of database, interface, utilities.
• John Durno. Technology implementation in library.
• Marnie Swanson: Funding approval.
• Scott Gerrity: HCMC contact, general management/supervision.
• Ken Cooley: Prioritization of projects within library. Funding approval.
• Dodd’s Scrapbook Project: The “Scraps” software incorporates some code from other open source projects, but most of it is new code, unique to the project. The “Scraps” scrapbook software needs development for Dodds and similar scrapbooks but also, hopefully, for marking up individual articles in historic newspapers like the WW I Canadian Scottish Newspaper.

Funding

3 month term funding for David Badke’s salary. Dates: January – March, 2007. David will remain HCMC employee on term PEA appointment. Library will transfer funds to HCMC account to pay for David’s salary.

Purpose

The general purpose of the project is to create a collaborative virtual environment (tools) in which students and library staff can do mark-up, with approved metadata standards, of scrapbooks, and the Canadian Scottish WW I regimental newspaper, The Brazier.

More specifically, this project will equip cataloguers with tools to create granular, item level metadata of various collections of graphic and text materials. The scrapbook prototype and Image Mark Up tools are the primary technologies for the project. Data sets created during the project will be archived in a database and grown in future iterations of the project.

Both the educational process and project outcomes are important to the project. With these in mind, the tool features sets are being developed with an eye towards user-friendly GUI, version and permissions control, and easy administration of utilities to suit a collaborative project environment. The outcomes will be housed in a project repository on the TAPoR servers.

The McPherson library has funded the creation of the tool based on its potential for crossover application. The library has various books, scrapbooks, photo albums, archives, manuscripts and newspapers to which this technology could be applied.

History

July _Aug 2006: Work was scheduled for summer 2006 using the Image Mark-Up Tool for the Dodds Scrapbook which appears very promising at the first pass.

Benefits

• This development benefits the digital library research under question since few tools are available to provide access and display for complex multilayer items like the Dodds scrapbook.
• This development will provide archivist, librarians and students with innovative tools for collecting and displaying data for later transmission to a National portal.
• Project has high potential for application across the country: Small archives around the country could display and provide access for multi-layered digital files in this way especially scrapbooks and newspapers.
• Project provides opportunity for collaborative networking and development between Library and Archives units interested in digital media.

Scope

In past 2 months, David Badke has undertaken substantial troubleshooting and de-bugging of the Dodd's site. Engine, Help Files and a better administrative utility need to be added.

In scope (see project plan below) for his remaining time on the project:

• add a module to the prototype viewer to provide access to those items individual high resolution image scans.

• Fully develop the administration module to provide editing capability for the metadata and other configuration and maintenance functions.

• Add a program to provide page turning for multipage enclosures
• Complete documentation including a workflow manual for the project.
• Complete development, testing and debugging.
• Develop export capability to OAI specifications

Out of scope

• Enhancements to allow for linking of newspaper articles that need to be linked from two or more pages.

Constraints

• Formal change orders will be posted for approval. Scope of project currently demands full 3 months of development. New features or changes to plan may require additional funding and time.
• If project stalls or meets obstacles, HCMC Coordinator will address primary participants and work out a strategy for completing or ending the project.

Assumptions

• Image Mark up and scrapbook tools are primary technologies for the project.
• All images will be provided to the project in a digitized format.
• HCMC, TAPoR and the Library reserve the right to re-use the Scraps software technologies and code in other UVic related software developments. Scraps is Open Source and re-distributed as such under the Mozilla licence.
• David Badke will be working full time on this project throughout the 3 month period Jan. – Mar 2007.

• David will initiate tasks and document activity within the HCMC Project Blog in the same manner as all HCMC staff. He will update his activities daily, and break down tasks based on the plan.

• Project participants will use the blog for tracking and reviewing the project activity. Participants will be given access to make posts and add comments to David's posts, and should specify types of entries David should post if additional reporting is required.
• Project wrap up will be posted under formal documents in this blog where all participants can view and comment on it.

Risks

• Use for newspapers has not yet been determined. It may be that complex indexing of newpapers is not feasible. Moderate.

Development Plan

There are three major parts to the scrapbook software: Engine, Administration, User Interface. Each of these will need full documentation.

The Dodds scrapbook images and metadata will be used as a test case and first application for the Scraps software.

Conceptual Diagram

Engine

The Engine is the code that interacts with the database and artifact images and renders “components” in the browser. It is partly PHP code and partly Javascript code, and uses AJAX techniques.

• The Engine will have a set of “published” functions that can be called by the Administration program and the User Interface to interact with the data and render web pages – that is, the Engine is an Application Program Interface (API).

• The Engine will have “components” that can be plugged into a user interface to render web page fragments (e.g. a component to display the artifact page images, a search component, a metadata display component).

• The Engine will handle the hierarchical data transparently, allowing drill down from pages to items to subitems to any level.

• The Engine should be able to work with more the just PostgreSQL databases (e.g. MySQL, Exist) by segregating database functions in a separate, replaceable module.

• A single installation of the Engine should be callable by multiple applications.

Administration

The user needs to be able to configure the application, load data from Image Markup Tool files (possibly other files), maintain records, and perform other administrative tasks. The prototype administration application has facilities to load and maintain data and to produce reports. The following features are missing or incomplete:

• The program will work with “projects” that encapsulate one complete artifact, to allow a single installation of the application to manage multiple projects. (This is similar to what IMaP does; some IMaP code can be probably be used for this.)

• Functions will be created to allow the user to configure the scrapbook application. This includes the definition of metadata structure and database fields; set up of file locations, image types, and options; possibly assembly of user interface.

• The existing program can only load Dublin Core metadata from Image Markup Tool files. It will be able to handle metadata in any valid XML format.

• Functions to establish links between artifact pages and items will be created.

• An export function to create OAI-compatible output will be added.
• The program will use functions in the Engine wherever possible.

User Interface

The existing user interface is a rough prototype, suitable only as a proof of concept. The interface will be built from “plug in” components rendered by the Engine, so that the user can assemble an interface from standard parts.

• The interface is the user's responsibility; there will be no single fixed interface. However, there will be at least one fully functional sample interface, and more would be better.

• It will be possible for the user to modify a sample interface or create an entirely new one.

• The user interface will call functions in the Engine API to render data on screen. It will not access any data directly.

• Page layout will be controlled by CSS code.

Order of development

1. Engine: 80% of code (6 weeks)
2. Administration and User interface: (4 weeks)
3. Documentation (2 weeks)
4. User Approval and Sign off