You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Date submitted

Project name

Brief description

Submitted by

Notes

1/20/2011

Fake project

A sample project description for the purposes of this form.

Nicole Hennig

Enter notes here (optional).

2/22/2011

1. SIMILE Exhibit Timeline

The MIT150 Timeline needs to live on after 2011. The timeline currently uses a vendor service, Dipity. Our contract with the service is scheduled to run out at the end of CY2011. The Dipity software is based on programming created through the SIMILE project. The current timeline content is exportable in XML.

We want to learn to use SIMILE and see this as a good experimentation project. Also, as part of MIT150 activities the Archives have been given historical “timeline” information from the School of Engineering and the Council on Diversity, chronicling their histories. We want to create timelines for that information, as well. It had been an original intent to create the MIT150 Timeline by using the SIMILE Exhibit/Timeline software. But lack of understanding of the software and uncertainty of the deliverables made it more prudent for us to use an established vendor option (which we had reviewed with Nicole Hennig).

Tom Rosko

Nicole to call Tom with questions.

 

 

 

 

 

2/23/2011

2. Cataloging and processing of the Industrial Relations pamphlet collection

The project represents completion and extension of a project begun in 2007. It has been on hold for several years.
This collection was developed 1938-1963. It consists of historic and unique materials on labor unions, labor-management relations, human resource management, and other topics related to the world of work. In 2007 the MIT Libraries contracted with AEL Data Co. in Chennai, India, for retrospective conversion of the collection records, using the shelflist. The card catalog is gone and the pamphlet collection is inaccessible until records are processed. There are approximately 27,000 records in this database; they have been added to Barton as suppressed. Approximately 3600 items have so far been barcoded, linked to records, and stored in OCC. This project will have three major facets: to finish linking items to records already in Barton; to apply the same level of cataloging to the remaining titles in the pamphlet collection, process and store them; and to process the intellectual content of the shelflist (original annotations and abstracts have been captured by AEL Data ) as an annotated online bibliography.

Anita Perkins

Barbara to talk with Anita for more info.

3/1/2011

3. Add E-books to new book RSS feeds

E-books do not get classified in LC, so they don't show up on our new book RSS feeds. There must be some way of getting them into the feeds are perhaps establishing parallel feeds of new e-books.

Michael Noga

Rich to talk to Michael.

3/10/2011

4. Maps in Barton

The goal of this project is to put more specific location information about items in Barton search results, similar to what O'Neill Library at Boston College (which also uses Aleph) does with Locate It! links in its OPAC: http://arc.bc.edu:8080/FloorMap/explain6b.jpg

Some have suggested that a map system like this for the MIT Libraries would require RFID or other technology to implement. However, part of the solution may already exist in the form of a FileMaker Pro (FMP) database that ID&LA already uses at Barker, Hayden, and Rotch to create consistent aisle tag/stack signs. Among other information, the database includes the library, floor, collection (stacks, reference, browsery, etc.), and start and end call numbers of each stack. The stacks information is quite accurate---minimally a library-wide check of stack signs is done each semester at Barker; during shifting projects or whenever staff or student workers notice a sign is inaccurate, the database is normally updated within a business day, if not immediately.

The Maps in Barton project would use a database similar to the existing FMP database to provide a link to the specific stack location (library, floor, and stack number), as well as a map of the appropriate floor pointing out the stack where the patron can locate an available item at Barker, Dewey, Hayden, Music, and Rotch. For other library locations (including LSA and Archives) and for non-available items (items that are checked out, missing, on order, etc.), instead of displaying shelf location, the link would display information about how the patron can access the material--e.g., placing a hold request, or using alternate services (PDF Article Delivery through WebDocs, BLC, Harvard Reciprocal Borrowing, BorrowDirect).

Roshni Gohil

Christine to talk to Roshni.

3/14/2011

5. Local Document Delivery Service (from campus libraries)

Provide PDF document delivery service from collections in Barker, Dewey, Hayden and Rotch libraries. This service would be based on the model in use at the Library Storage Annex, providing free PDF delivery of article-length documents from print-only collections for MIT faculty, students and staff.

This service could be implemented using technology already in place in the Libraries, routing users from Barton to our ILLiad request system via SFX. This service would require training of IDLA staff in library units in the use of scanning equipment and ILLiad request processing, and may require additional staff hours for request fulfillment. This service would also require purchase of scanning equipment and software for each IDLA service location.

Melissa Feiden

Barbara to talk with Melissa.

3/14/2011

6. URMS (Universal Request Mgmt. System)

Develop a unified interface for patrons to track all library requests, whether the requests originate from Barton, ILLiad or another request management system. This URMS interface would have links back to the native interface of each request system, so that patrons could return to that interface to place requests, etc.

Several years ago, the Document Delivery Task Force approached this topic, noting that an URMS doesn't have to accomplish all of the request and circulation tasks of the various systems it represents and will not be a single interface that controls request functions. Rather an URMS may be a system that aggregates and displays data related to requests and routes users to appropriate forms and services.

The task force created a mock-up of a potential URMS interface -- see:
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3858377d-0ca5-4f99-945e-359a71528454"><ac:plain-text-body><![CDATA[[http://web.mit.edu/feiden/www/index.html
]]></ac:plain-text-body></ac:structured-macro>
]
The "home" page of this mock-up shows an account that lists a variety of requests -- ILB articles, Barton book loans, even Ask Us! requests -- in a single user interface. We can now imagine new sections in this mock-up for WorldCat BLC borrowing, Borrow Direct and more.

This task force report also noted: As an example, North Carolina State University (NCSU) brands its ILL/DocDelivery/Storage services under a single banner: “TripSaver.” A user who is looking at their account in NCSU’s library system sees a combination of their requests (ILLiad requests for books, articles), satellite shelving (ILS requests) and distance learning requests (ILLiad requests), as well as local circulation transactions (ILS requests). This is accomplished through scripting behind the scenes that pulls ILLiad data into the NCSU integrated library system, and routes users back to their ILLiad account to make adjustments to these requests as needed.

Melissa Feiden

Nicole to talk with Melissa for more info.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • No labels