drupalib A place for library drupallers to hang out

fedora_rest is a module for building custom interfaces to Fedora Commons repositories. The Fedora REST API module provides a programming interface to invoke Fedora Commons REST methods. By itself, the module can be used to create a simple presentation layer for a collection of objects in the repository, without any module development or PHP coding. But its real power is as a rapid application development tool to code custom modules for creating, managing and publishing collections of complex digital objects.

The module provides a programming interface to invoke Fedora Commons REST methods, including a PHP class that encapsulates all the REST API methods so they can be easily invoked from other Drupal modules and PHP applications. It also defines a type of node (fedora_object) that represents a digital object in the repository. This content-type can be extended by defining a new content-type in a custom module and invoking the fedora_rest module's hook implementations to add the Fedora object attributes to the node. A template .module file is included to simplify the process of creating modules that extend the fedora_object content-type.

This module is based on work I did for the Digital Humanities Observatory which is described here: http://www.slideshare.net/gourley/integrating-drupal-fedora. The DHO and I are eager to work with other organizations and repositories to use and enhance this module for other use cases.

We get a lot of requests for movies by categories not easily gathered by the catalog, like movies based on graphic novels, or the "Scary Children" list that features "The Exorcist" and "The Ring," for instance. One of our librarians built a database in MS Access of these lists. I suggested we take that database and give it the Drupal treatment complete with a custom (zen) theme.

I wrote a custom script to import her Access database into a custom node module for the movie entries. We use cover art from Book Letters, so rather than download the images, the module uses image URLs to display covers, and links them to the catalog entry for the particular movie title for easy placing of holds, etc.

For easy addition of covers, a custom screen scrape incorporates the book cover search into the website and some javascript enables staff to click on a cover to add the URL to the node form (no copy/paste) as a block.

At the top of each lists, there is a download button where, via Views Export, the list is exported as a text file so either we can print off a copy to give to patrons, or obviously, they can have the list at home.

For each node, we have added links to related entries on Rotten Tomatoes and IMDB.com, and summary information from the catalog.

Beyond the custom theme and module, the site is basically nothing more than taxonomy and Views. It's a simple, small mini-site, run in a multisite setup. We have talked at using this as and basis for an online community, using Fivestar for ratings, and enabling comments for patron reviews/discussions. I know many public libraries have staff who keep various lists designed to meet local needs. This simple site shows that lost lists can be gathered and sharedvia an expedient, straightforward interface.

Matt Weaver
Web Librarian
Westlake Porter Public Library

The Keene Public Library has had a Dreamweaver HTML site for years. Last year, the City of Keene hired a local Drupal site development firm to re-do the City’s site. We (the library) wanted a similar site, but didn’t want to just use the city’s template with a departmental link – that would have been a huge step backward from our old site, which of course had its own nav bar and hundreds of pages. So we got the city’s template and a development site on their server and we mostly took it from there. We did need some help to get the CSS and the template (and the Views!) correct. We now do know a bit about Drupal, but feel we have only scratched the proverbial surface. We're looking forward to adding more modules and functionality to the site in the future. (SOPAC?!)

The Drupal Toolkit is a modular system that handles the creation and manipulation of metadata in accordance to the XC schema format within the Drupal content management system by:

• Defining metadata
• Importing and exporting metadata
• Storing and retrieving metadata
• Searching metadata
• Extending and modifying metadata
• Controlling user access to metadata
• Generating fully customizable XHTML and CSS output

Some modules are part of the Toolkit however can be used independently from it. These are:

• OAI harvester
• NCIP integration
• Integration of Syndetics Solution services
• URL rewriting to EZProxy server

All of these core functionalities will be handled by XC defined hooks for Drupal that will allow XC modules, and perhaps any future contributed modules, to plug into and extend the features of the XC Drupal Toolkit.

The Library is responsible for auditing non-academic aspects of theses, dissertations, and graduate-level projects submitted at Simon Fraser University. For over four years, we have required that students 'submit' their theses (i.e., register with the Library) using a simple web form that populated an Excel spreadsheet, which in turn was used by our Theses Office to process the semester's batch. Even though we still require that students submit a printed thesis, we have found that most students (over 90%) provide a PDF version for submission to our Institutional Repository.

This January we launched our second-generation thesis submission and management system. It is a Drupal 'application' in the sense that it focuses on narrowly defined user tasks, triggers, and back-room workflows to a much greater extent than most general CMS-based websites do:

1. Students log into the site using their library credentials, and their student ID, SFU email address, and full name are prepopulated in the submission form (a CCK node edit form) from their library record.
2. After they log in, they enter their thesis title, abstract, supervisor's name, pagination details, keywords, and call number, and they can upload one or more files.
3. Students can log in at a later date, but if they do, they cannot edit any of the fields they have populated the first time they logged in; they can only upload and replace files.
4. A series of receipt emails are generated when the student registers a thesis, including one to the student and one to the departmental graduate secretary. Other triggers that generate emails include when the Theses Office enters a date in the "Submission complete" field and when the Theses Office completes its audit.
5. The Theses Office audits the submission for requirements such as approval from the academic department, ethics review and copyright documentation, and technical requirements such as title page and document formatting.
6. Theses Office staff can send emails from within the application detailing specific problems with the submission. Responses from the student are not recorded in the app, however.
7. The app can generate various PDF forms containing submission-specific values, using a custom module that incorporates the TCPDF library. These forms include copyright licenses the student must sign and slips attached to each thesis containing details to be used by the bindery service.
8. Uploaded files are automatically renamed to incorporate the "ETD ID" for a thesis, a unique identifier based on the node ID generated by Drupal. Also, on upload, the application generates JHOVE output for each file, and records basic preservation metadata on all files in a database table.
9. The app provides comma-delimited files to Grad Records staff listing all students who have completed their submission requirements. Grad Records logs in, clicks on a link to a view, refines their query, and clicks on a CSV icon to generate the file. Thanks Views and View Bonus Pack!
10. We generate DSpace import packages for theses after they have been audited, and corresponding MARC records for loading into our ILS. One interesting (i.e., nerdy) feature we've built into the app is for an XML-RPC client in the script that creates that MARC records to automatically update each thesis record in the Drupal app with the URL in our DSpace IR.
11. The site runs on https, since students are entering personal information and Grad Records is downloading lists that contain the same information. Apart from buying the certificate and configuring Apache to use it, we had to do nothing to configure Drupal to use https.

Lessons learned: Manipulating CCK fields via form_alter() can be a real pain in the behind (example threads on d.o.); it's very important to think about system-level CCK field naming conventions before you touch a keyboard, since you cannot change them; the core upload module, and the way Drupal 6.x handles files in general, pales in comparison with the rich APIs available for manipulating nodes.

We are working with Grad Studies and other units on campus to remove the requirement for the student to submit a printed version of their thesis, and this new submission and management application will prepare us very well to go paperless.