Digital Image Asset Management Software Recommendation

Rotch Visual Collections, MIT Libraries

April 27, 2005

Analysis Committee:Sheryl BrittigMelanie HowellCarl JonesPam NicholasSamuel SadowMerrill SmithJohanna Woll

Contents

Introduction and Background…………………………………………………….3

Statement of Needs…………………………………………………………………….3

Evaluation of ApplicationsARTstor……………………………………………………………………………4CONTENTdm…………………………………………………………………..6DSpace…………………………………………………………………………….8Narravision……………………………………………………………………10

Recommended Application………………………………………………………12

Funding and Support………………………………………………………………..13

Metadata Issues…………………………………………………………………………14

Intellectual Property Issues…………………………………………………….15

Appendix 1: Standards…………………………………………………………….17

Appendix 2: Digital Workflow for RVC……………………………………18

Appendix 3: Comparison Grid of the Four Applications……….21

2

Introduction and Background

As changing pedagogical methods demand new instructional media, RVC must extend its

services to include managing and delivering digital images for classroom teaching. By providing

access to existing visual assets that are used as primary teaching tools by faculty in the School

of Architecture and Planning, and by focusing our initial digitization efforts on course-driven

content, we will meet our patrons’ teaching need and keep pace with the evolving visual

resources environment. This new faculty demand is driven, in part, by technological and

industrial changes: consumer demand for digital capabilities has led to a cessation of industry

support for 35mm slide technology. Our image vendors are rapidly switching to digital content

and are decreasing their slide holdings. All too soon, replacement parts for failing classroom

slide projectors will be unobtainable, and faculty will be left with no means with which to use

our analog collection materials. We have already witnessed some forward-thinking professors

in DUSP and other School of Architecture departments (Larry Vale, Arindam Dutta, Dennis

Frenchman, to name a few) scanning hundreds of RVC slides used for teaching. They have now

ceased coming into the unit to borrow slides, although they occasionally drop by to inquire if

Libraries has yet decided to implement a digital images program or to ask for recommendations

for digital image management and classroom presentation software. Other faculty members

(Caroline Jones, Erika Naginski, Michael Dennis, Tunney Lee) are vocal proponents of a digital

image program.

What do we need?

To continue serving our users’ teaching needs, we must start digitizing parts of our collection

and step up efforts to acquire licensed digital content. RVC needs to store our digital images

on a server or servers with good backup and recovery systems in place, to organize the files in a

logical manner, and to attach rich descriptive metadata for search and retrieval capability. We

need to be able to add to this management system regularly (should be scalable), to edit and

update materials in it periodically, to refresh the system as needed, and to pull our content

back out easily or to migrate if necessary. We need to authenticate access to the images,

restricting use of protected material to the MIT community. We need a well-designed user

interface that clearly outlines licensing restrictions, permissible usage, and Fair Use guidelines,

and which allows for searching on several fields or even keywords. When results are returned,

3

thumbnails (~400 pixels on long side) should be displayed with key descriptive data and links to

related records. Users should be able to click to a medium-sized image (~800 pixels on long

side) and more detailed descriptive metadata. Users should be able to choose multiple

thumbnails for re-display as a found set, and possibly even to manipulate images into a certain

order, before being allowed to batch export/download large projection-sized images (~3000

pixels on long side) to desktop or course tools of their choice. RVC needs to generate reports

on image usage (“circulation” stats). Because we do hold the copyright to some of our

materials, it would be nice to have some type of “shopping cart” functionality to help process

the permission to publish requests that both the RVC and Aga Khan subject specialists receive

regularly.

Reports from visual resources colleagues tell us that many faculty members have high anxiety

over the prospect of using digital images, even though they realize it is a necessary evolution.

They require, at least initially, much one-on-one training and support, even when the system in

use is fairly intuitive. We should strive to implement something that is user-friendly, with

online help/tutorials built-in, and to design good instructional handouts and training sessions.

Evaluation of some systems that may give us what we need

The Analysis committee looked at several systems, and chose ARTstor, CONTENTdm, DSpace,

and Narravision for evaluation in the report.

ARTstor

A nonprofit entity, initiated by The Andrew W. Mellon Foundation, that provides curated

collections of art images and associated data for nonprofit, noncommercial and scholarly,

educational use. It is designed on the JSTOR model for journals that provides archiving and

stability, and may extend to other (non-art and architecture) disciplines in future.

Pros

● Hosted (less involvement of Library Systems staff)

● Offline viewer is free (with membership) and works with JPEG2000

● Vast collection of images, and growing (500,000 by 2006)

● Hosting of personal/institutional collections to be added in Fall ’05 (costs TBD)

● Can use Offline Viewer to pull images from ARTstor and create slide shows (student

review/print images are small and of low resolution. Note “classroom” images are not

downloaded locally, but a session with ARTstor is initiated through the Offline Viewer)

● Institute-wide license (not limited number of seats)

● Stable URLs

4

● Can generate reports on usage statistics

● A personal collection tool for faculty is being developed, release date TBD

Cons

● Not a true asset management system

● Significant gaps in collection (weaknesses include architecture and architectural plans,

maps, didactic/background materials, modern and contemporary works, even some

core materials for teaching Survey are missing)

● Inconsistent image quality (e.g. UC San Diego slides in its Image Gallery)

● Duplicates not removed so multiple images of same work exist (faculty really don’t like

having to review/evaluate multiple versions, but ask for best choice to be only offering)

● Local content/personal collections must be loaded into proprietary program (Offline

Viewer)

● Not interoperable with other repositories (e.g. DSpace) that may contain needed

teaching content

● Metadata quality is inconsistent and sometimes bad, no real standards for metadata at

this point in time

● Cannot handle complex relationships among images/works (e.g. hierarchical or

associative)

● Very small download size (400 pixels on long side) outside of proprietary viewer because

of licensing issue

● Content not available via other image viewers; lack of interoperability (images

encrypted so viewable only with ARTstor’s Offline Viewer; adds a layer of complexity in

working with non-ARTstor digital images)

● Hosted collection version does not allow customization of user interface; subscriber

must accept ARTstor designed interface.

● If subscription lapses, immediate loss of expected content for teaching

● Costs: $40k one-time plus $20k per year, plus costs of hosting a collection (if that

option is desired—TBD, and costs of “manipulating” images and metadata for hosting

TBD based on level of ARTstor time/labor involved in such manipulation)

Summary:

ARTstor is a content provider that, due to intellectual property issues, restricts use of its

images for meaningful learning exchanges to one tool—the offline viewer. This will force

faculty to adopt a highly non-interoperable tool for using any RVC/MIT/personal images for

teaching when also using ARTstor content.

5

While ARTstor may be a likely candidate as a source of teaching content, it is just one of many

sources required to answer teaching needs. It seems a less likely choice as an image

management system, since it was not originally intended as such, and is only recently adopting

some features of a DAM system for hosting collections in hopes of attracting new subscribers,

with guidelines, workflow, and pricing still being worked out. The ARTstor-as-image-

management system would be the most costly as well as the most restrictive in terms of

interoperability and functionality.

CONTENTdm, distributed by OCLC through Nelinet

CONTENTdm provides tools for everything from organizing and managing to publishing and

searching digital collections over the Internet. CONTENTdm handles documents, PDFs, images,

video, and audio files and is used by libraries, universities, government agencies, museums,

corporations, historical societies, and a host of other organizations to support hundreds of

diverse digital collections.

Pros

● Vocabulary control by field (CONTENTdm is one of the few products that provides some

type of authority control on metadata)

● Certain fields may be suppressed from user view

● OCLC host or local server option

● Supports Latin-1 character set

● Supports VRA Core; uses templates for descriptive, rights, and administrative metadata

● Catalog directly in CONTENTdm or import metadata from tab-delimited application

● Supports XML

● Allows for Compound Objects—multiple files linked by relationship (parent/child and

sibling/sibling possible; unknown about associative relationships)

● Records can be linked to local web OPAC

● Fully compliant with OAI-PMH v2.0

● Global changes possible

● User grouping of images into My Favorites (multiple folders possible, saved indefinitely,

shareable with others)

● PowerPoint Plug-in for My Favorites

● Accepts JPEG, GIF, or TIFF images, WAV or MP3 audio, AVI or MPEG video, PDF, and URLs

for storage and display

● Supports JPEG2000 for panning and zooming of images

● Can automatically create lower resolution display images

6

● Can scan directly into CONTENTdm from TWAIN devices

● Image Rights Tool allows watermarking, branding, or banners for copyright designation

● Item Level security possible

● Authenticated access to collections by username or IP addresses (certificates); very

flexible permissions structure

● Administrator review of images/metadata in pending queue before adding to collection

● HTML-based Search client PC/Mac/Unix platform, IE browser recommended

● Batch loading possible for both images and metadata (or load singly)

● Cross-collection searching

● Can get data back out of system easily

● Open source software that adds Z39.50 compatibility to any CONTENTdm digital

collections server is available

● Use of Tiny URLS/persistent URLs

● Includes Report Generator

● Hierarchical searching, can be set by User per session for persistent searching

● Light table feature

● Fully searchable and scalable up to millions of images (max items in single collection

limited to 16 million)

● Customizable interface; offers much flexibility in use of style templates. New version

(May 2005) will support PHP

● Multi-site server available for collaborations between institutions/organization

● Pricing for locally hosted option: 8,000 objects = $7K plus annual fee of $1300 after

first year at low end, and unlimited objects = $40K plus annual maintenance fee of

$6800 at upper end

● Pricing for hosted option: 500 objects/200 MB = $1200 annually, 4,000 objects = $4000,

8,000 objects = $6600, 12,000 objects= $9000 (no annual maintenance fee)

Cons

● Proprietary software

● Doesn’t support non-Latin characters

● Limited support/training mechanism for end users (Library would have to train/support

users)

Summary:

CONTENTdm offers a great deal of needed functionality at a reasonable cost, and has stable

OCLC backing. For a Fall ’05 solution, the hosted version, at 4000 objects, could work. As a

7

longer-term solution, we may well quickly scale to needing local hosting for a larger number of

objects. The “My Favorites” PowerPoint plug-in would provide a tool for faculty use, should

they require it, without additional cost or software, and without additional layers of training in

use of ancillary products.

DSpace

A digital repository created to capture, distribute and preserve the intellectual output of MIT.

As a joint project of MIT Libraries and the Hewlett-Packard Company, DSpace provides stable

long-term storage needed to house the digital products of MIT faculty and researchers.

Pros

● Open Source

● Already in place at MIT

● Easy to upload data (image batch loading capabilities?)

● Persistent URLs

● Accepts multiple media formats

● Ability to organize by collection

● Backup, mirroring, refreshing media, and disaster recovery procedures already in place

and part of DSpace maintenance

● Access control at collection and item level

● Thumbnails display in search results as a list, not a matrix across the screen

8

● Metadata can be batch loaded

● Content can be exported in simple XML format

● Already implements MIT security model (certificate-based authentication)

Cons

● MIT DSpace policy specifies work must be produced, submitted or sponsored by MIT

faculty, and contributors must sign a deposit license—policy would have to be changed

to allow inclusion of our licensed and copywork images that are not original MIT content

and for which we, as contributor, are not the authors/rights owner and for which we

cannot execute legal deposit license

● No side-by-side image comparisons

● No light table feature (faculty “lay out” slides on light tables and make selections for

inclusion in lecture as they arrange their slide presentation, so no visual means to

compare/contrast possible choices before export from DSpace may significantly

influence their decision of whether or not to utilize DSpace as a tool for

searching/selecting images for teaching). At the very least, a way to select large

numbers of images and then re-display chosen set is essential

● Downloading batched images to desktop for classroom use (50-80 images per lecture) is

not available; the process for selecting and exporting batched images is cumbersome

● No native VRA Core support; crosswalks to Dublin Core show multiple deficiency points

for key search fields (no equivalent DC element/qualifier)

9

● Restricts search terms to title, author (creator), date—choices would need to be

expanded for image searches (culture, style, period, site name, reconstruction or

restoration date, built work view, etc.)

● Search/retrieval interface may need some redesign to fit returned images, tombstone

metadata, and links to related works on the page so that multiple records display

without much scrolling

● The DSpace storage allocation is inadequate for our anticipated needs—our average file

size will be 18MB, and we expect to have about 1500 files per course and load two

courses per semester. DSpace storage allocation has an annual storage limitation of

300Mb for a small community (less than 50 contributors) and 1,000MB for a large

community (over 150 contributors), with total storage after five years of 1.5GB for

small community and 5GB for large community. Cost for deposits beyond this allocation

is $5 per GB

Summary:

While DSpace holds promise as a management system for RVC’s digital content, significant

changes would have to be made to address several usability concerns. A policy change for MIT

DSpace to include non-original content is not a trivial decision. Changes required to DSpace,

such as providing for easy batch downloading of images to desktop, redesign of retrieval pages,

and incorporation of VRA Core 4 metadata scheme or a much-expanded Dublin Core set, may

require longer lead time than we have to implement a DAM system by Fall ’05 or even Spring

‘06.

While the display of thumbnail images in the search results list is now possible, and one site (U.

Delaware) has incorporated JPEG2000 functionality which is invoked when the user clicks on the

thumbnail image, there is little indication that sites are looking to make significant

improvements in the way DSpace presents image content. The system remains comparatively

awkward when seen in the context of tools like ARTstor or CONTENTdm, which were designed

with image content presentation from the ground up. Rather, most sites have plans for either

using DSpace as a back-end repository for some other application which does the search and

display of images; or are waiting for DSpace 2.x which promises a more modular design and may

10

allow "plugins" to provide specific content handling functionality. Under this scenario it might

be possible to imagine a light-table module or side-by-side image comparison functionality

being incorporated into DSpace much more easily than is possible now.

Should content guidelines be changed and functionality added to make search/retrieval, image

selection, and batch downloading of images much more streamlined for end users, DSpace

could certainly be a logical choice for an image management system back-end. Even if a

separate instance of DSpace were created for RVC, not restricted by MIT DSpace content

guidelines, the same changes to layout and functionality would be required, again very possibly

exceeding our timeframe, budget, and staff resources.

Academic Computing "Narravision" (aka m:media) Pilot

http://oki1.mit.edu:8080/narravision-web/

Narravision is a recently developed tool to support image delivery and display for classroom

teaching. Currently its primary use is to support the "Visualizing Cultures" 21F.027J course being

taught by John Dower and Shigeru Miyagawa, a course that makes extensive and rich use of

image content. Although Narravision shares the same "core engine" with m:media (the former

Metamedia) the end-user interface seems to have fairly basic functionality, being limited to

search by title, medium, keyword; and click on thumbnail to enlarge. It does not support

things such as content annotations or the creation of virtual collections at this time. A

Narravision java "client" is under development that will provide a much richer user experience

for creating and editing content and perhaps it is this tool that will provide some of these

"missing" features.

Each course using Narravision can have its own look and feel. The templates are based on the

needs of the current participants, but are not limited to this particular look. In future, AMPS is

seen as playing a role in helping professors customize their sites.

Pros

● Basic search and retrieval, browse thumbnails by title, medium, keyword; click on

thumbnail to enlarge

11

● Java client for creating and editing metadata under development and will be ready for

production by October 2005

● User interface functionality is basic but Academic Computing would like to work with us

on reviewing functionality and prioritizing features to add

● Interface HTML is customizable for each course, AMPs may be able to play a large role

in helping sites to configure their pages.

● E-commerce module built-in

Cons

● Narravision is still only a “pilot” project; future status is unknown. We don’t know that

the long-term commitment to providing a production system built around Narravision

will last

● IS&T DAM system not yet implemented (need to find more details as to its status and

design), timeline unknown

● Uncertain whether DSpace could be used in place of IS&T’s planned DAM system (or if

that’s desirable)

● Metadata—the amount of work needed to structure the metadata to the point where it

is available for search and retrieval is unknown

● No “My Favorites” equivalent virtual collections

● No side-by-side image comparisons

12

● No JPEG2000 capability for pan and zoom

● User interface is basic but serviceable for the short term if faculty know it’s under

development. We would expect more functionality by mid-fall

● Most likely limited to using IS&T’s planned institutional DAM system at this time (status

of system unknown, will it seem like a collision with DSpace?)

Summary and Questions

Jeff Merriman had proposed a pilot project to Jerry Grochow and Vijay Kumar to work with the

Libraries to further develop Narravision as a web application for image delivery and Narravision

java client for metadata authoring. RVC/Rotch image content would be a continuation and

extension of the work they have already committed to do for Professor John Dower’s

“Visualizing Cultures”. They have target dates already in place (October for Narravision client)

to deliver production level functionality, so Jeff does not feel they are that far off. Jeff

envisioned the pilot extending the model to include Rotch/RVC content and provide support for

courses in the Art and Architecture Department.

A decision to go with Narravision would mean a loss in immediate functionality compared with a

tool like CONTENTdm, but the upside is that we would be closely engaged with Academic

Computing on a core project to a deliver a tool for faculty/student use.

Is there a strategy where we might pursue another delivery application for the libraries (e.g.

CONTENTdm) and still work with Academic Computing on Narravision for image delivery? Can

Narravision use DSpace or CONTENTdm as a back-end system?

Our Recommendation

Based on a review of these alternatives, for a near-term (one year) solution, we recommend

CONTENTdm. CONTENTdm offers both the functionality and flexibility we need (refer to

pros/cons listing); the program can be installed (or images loaded to host server), customized,

13

and sufficiently populated by our Fall ’05 target; and it will provide some low learning-curve

tools for faculty to use images in the classroom. This latter point is not specifically within our

charge to consider, but, with respect, we feel strongly that providing digital images to our

primary users without also considering some means for them to use the images in class is not in

keeping with the Libraries commitment to provide excellent service in support of teaching.

The hosted version will not significantly save STS staff time and involvement over a locally

hosted option, but we would not be dealing with server maintenance. At 4,000 objects (read:

digital files), the $4000 price tag is reasonable and possibly could be paid from RVC/KHAN

collection budgets for a one-year test period for digital image usage. If we were to host locally,

our cost would be $7,000 for 8,000 objects and we would need server space and maintenance.

The license fee could still be paid for with RVC/KHAN collection monies. We would recommend

the JPEG2000 Extension, costs for which are also based on number of objects, with the 8,000

object collection price set at $1500 with a $60 annual maintenance fee.

Toward the end of the academic year (Spring ’06), we will provide an evaluation of the

project’s success, functional strengths and weaknesses, and user comments and suggestions. At

that time, Libraries can reassess whether we should continue with CONTENTdm, or move to a

different solution.

14

For the longer term, we suggest that DSpace may be the most logical choice for a back-end

system. This would require changes to content policies, and changes to allow for use of VRA

Core for more robust metadata entry/searching, for batch loading of images, and batch

downloading of images to desktop (or export to course management tools or classroom

presentation tools). These changes will take time, and could be made over the course of the

year during which we utilize CONTENTdm.

Bearing in mind that faculty would become accustomed to the search and retrieval functionality

offered by CONTENTdm, and ARTStor, should this be licensed at MIT, and therefore would most

likely expect similar features in any system implemented afterwards, it would also be helpful to

create in DSpace a separate search interface for images, which would allow for

Copyright/Usage restriction statements, and also allow for a light box tool for faculty to “lay

out” images for easier evaluation and selection before export out of DSpace into various course

tools. It is possible that a separate instance of DSpace (RVCSpace?) could be created as a

management system for our images, which would eliminate the need for policy changes to MIT

DSpace, and which could be configured with the necessary user interface for search and

retrieval and for VRA Core data entry.

We further recommend that, if DSpace is to be used as the management system, the MIT

Libraries should engage in specific discussions with Academic Computing about how some of

their ideas for presentation tools (i.e. Narravision, M:Media, Princeton University’s open source

Almagest) could interoperate with DSpace; such a partnership would serve our users well in

providing robust tools for both image storage/retrieval and classroom presentation, and serve

to advance pedagogy in numerous disciplines.

Funding and Support

Either version of CONTENTdm, hosted or local server, is under $10,000. The cost could be split

between RVC and KHAN collection budgets for the first year’s test of the project. Various

“tweakings” and customizations to the interface could be done by the Rotch Local Technology

Expert, or may require the expertise of STS staff.

Should the decision be made to continue with CONTENTdm beyond the first year, it would be

preferable to use the non-hosted version. In this case, we would request central funding from

Libraries or MIT to pay the initial subscription fee (see fees in pros/cons listing). Beginning

15

with the second year, the only CONTENTdm cost would be the annual maintenance fee ($1300-

$6800 depending on number of objects in collection), which could be paid from central funds.

The installation, setup of users and passwords, server maintenance, and trouble-shooting would

require expertise of STS staff, unless the Rotch LTE were trained to support this application.

If DSpace is to be used as the management system for the longer term, funding will be needed

for the various programming changes required. Monies residing in the RVC Newman account

could be contributed to these expenses; the system houses and provides access to the digital

collection and the electronic infrastructure is integrated with the collection, so it would be

logical to use collection funding for this purpose. We would need the expertise of STS

programmers or to hire an outside programmer for this project.

Costs for storage for a locally-hosted management system (either CONTENTdm, DSpace, or

some other system) could also come from MIT/IS&T or Libraries central funding. IS&T server

storage and maintenance costs, according to their fee schedule, would run between $37,000

and $56,000 annually. If this is considered an “Enterprise-wide” project, we could be eligible

for hardware funding out of the Administrative Server Pool funds. RVC staff could manage some

aspects of data maintenance, uploading and editing of content, for example, while either the

Rotch LTE or STS staff may need to manage other aspects of the system, such as security.

With respect to funding digitization of content, both RVC and KHAN collection budgets will be

used to purchase digitized content from image vendors, as well as to cover costs of outsourcing

digitization of slides ($1.10 per slide with Boston Photo). We anticipate being able to digitize

one “Khan” and one “RVC” course each semester, partnering with teaching faculty to select

content for outsourcing.

Post-processing correction of digitized scans, loading to server, and creation of companion

metadata would be carried out by RVC staff and student workers, and so costs will be absorbed

into existing salaries. We are currently designing a digital workflow to lay over our existing

slide production workflow, and are thinking about a realistic time frame to announce that we

will no longer add slides to the RVC collection, although we will continue to circulate existing

slides.

Metadata Issues

RVC will continue to create metadata records in IRIS; in summer of ’05 we will be upgrading to

a new version that will take advantage of new functionalities in FileMaker 7, as well as the new

16

VRA Core 4 and Cataloging Cultural Objects recommendations. This upgrade consists of two

installations—one in summer of ’05 and the next in summer of ’06. This is because the Brown

University project manager and her part-time programmer could not complete all necessary

changes in one year. RVC has provided substantial input to the User Group discussion of

necessary and desired modifications for the new version, and some of our local modifications

have served as the basis for new tables and fields in this next version.

Regarding the management system’s relationship to the IRIS image cataloging database, IRIS is

capable of exporting data in tab-delimited format. If our image management system can

function in similar manner to an OPAC in terms of displaying records, it will be possible to

display exported IRIS data for images that are available in 35mm slide format only. The display

data could show that there is no digital image, and that the searcher would need to borrow a

slide from RVC. In this case, RVC’s second Technology Project of a Simple Search Interface to

IRIS would be unnecessary. It will be possible to export these Slide Image records to

CONTENTdm, and possibly to DSpace, but not to ARTstor.

Intellectual Property Issues

Rotch Visual Collections currently deals with IP issues in the following ways:

● limiting the number of slides copied from one source book/journal (except where

faculty insist on having 2 or more copies of the same slide in the collection)

● circulating slides for on-campus use to MIT community only (except when faculty are

traveling to present a lecture, or when School of Architecture requests that we

accommodate certain visitors by providing access to the collection)

● posting Copyright notices in RVC that inform users of Copyright law and its restrictions

● stating on the slide label “Duplication Prohibited”

● assuming faculty are complying with Fair Use guidelines in use of our materials

For digital materials, we propose to deal with IP issues in the following ways:

● limiting production of digital images to one copy per work/view and, where possible,

licensing the image from vendor source rather than digitizing existing copywork slides

● authenticating access to licensed and copyright-protected images in the online digital

collection to MIT community through use of certificates or other password protection

17

● providing Copyright and permissible usage statements to users, linked from the user

interface

● possibly water- or digi-marking the image (could interfere with in-class presentation of

images, however)

● assuming faculty are complying with Fair Use guidelines in use of our materials

The above measures are standard among visual resources collections that are providing access

to digital images in networked environments, and do meet requirements specified in our

licenses with vendors for use of digital material acquired from them.

18

Appendix 1

Standards

Scanning:

These standards will apply for RVC slides to be scanned, for digital purchases from vendors, or

from digital files we accept from faculty/students/other image donors.

● monitor calibrated regularly to (MIT classroom equipment calibration should be

matched for optimum viewing)

● scanned at least 3000 pixels on the long side, 8-24 bit depending on source material,

saved as TIFF or JPEG

● derive smaller JPEG files (if the management software doesn’t do this dynamically) of

about 800 pixels on long side for classroom projection size and between 200 to 400

pixels on long side for thumbnail size

Metadata:

● descriptive metadata created in IRIS according to current VRA Core (version 4 to be

released later this year with accompanying XML schema) and Cataloguing Cultural

Objects recommendations, may be mapped to an extended Dublin Core set for which

needed qualifiers would have to be created

● rights metadata will be recorded for each image for which such data is known or

discoverable by RVC catalogers

● administrative metadata will be captured/recorded for each image

19

Appendix 2

Digital Workflow

I. Preparation Phase (before sending images out for scanning)

o Collect slides returned by faculty or TA after class use

o Separate b&w and color

o Make eithera) new photocopy of returned slides (after they have been checked in)—orient all in

same direction, ORb) photocopy original circulation photocopy BEFORE checking slides in (before because

easier to read without cross-outs)

o Enter slide information in Excel log including OLD accession number or NEW surrogatenumber [log should include columns for course number, instruction, semester/year, etc.)

o Assign sequential reference numbers to each image and record in log

o Enter reference numbers in IRIS [?, perhaps in Assets table; can reference numberbecome/be same as digital asset number?]

o Record orientation of slides with arrow and written description in log (e.g. largest purpleblotch is in upper left)

o Unbind film from glass Gepes

o Clean film with Pec

o Place film in glassless mount

o Write reference numbers in pencil on glassless mounts

o Stamp glassless mounts with RVC or RVC Khan

o Make X in bottom left of glassless mount to mark orientation

o Reassemble glass Gepe or old mount (with rubberband) [clean glass of re-useable mountsnow or later?]

o Write reference number on glass Gepe or old mount

20

o File glass Gepes or old mounts, in order of reference number, in boxes (use box markedwith corresponding course number and semester/year)

o Arrange glassless slides in order of reference number

o Place in boxes and seal

o Assign and record batch number and date picked up by BPI

II. Metadata and Cataloging

o Create or review Work record in IRIS

o Create or review Surrogate record in IRIS

o Enter course number in appropriate field in Surrogate record

o Send source numbers or surrogate numbers to S.Sadow or S. Brittig for approval

o Approve records

o Generate new labels

o Affix new labels to new white (front) glass Gepes and old (if possible) grey (back)

o File labeled mounts in order of [reference number]

o Generate new guide card labels where needed

o Interfile new guide cards with labeled mounts

o Batch load records to DAM

III. Post-Processing Phase

[Process digital images in order of file name (which should match sequential referencenumbers); Use check list that includes name of processor and date of processing and screencolor calibration settings, and each step in post-processing]

o Compare digital image with original film using light table, loupe, and properly calibratedcomputer screen

o Make color and/or contrast adjustments as needed

o Crop digital image to our masking

o Check orientation against original film and/or log notes; adjust orientation if needed

21

o Enter digital asset information in IRIS including:ResolutionPixel dimensionsFile typeFile sizeColor-bit depthColor protocolPersistent URL?Etc.

o Pass original film on for re-mounting and re-shelving

o Batch load post-processed digital images to DAM

IV. Re-Mounting and Re-Shelving Phase

o Get slides from post-processing

o Locate corresponding glass Gepes (with new labels)

o Clean glass

o Clean film

o Check spreadsheet notes and scanning mount to verify orientation

o Re-mount film in glass Gepe

o Erase marks from glassless mount and file for re-use

o Place slides in re-shelving area (with new guide card attached with rubber band whereappropriate)

** we will want to have check lists for each phase and/or for entire process—people can initialand date each step upon completion

22

23

Appendix 3Storage &Archiving, Collection Management, Rights & Security

Store/preservemaster andderivatives(and on-the-flycreation ofderivatives)

Storeassociatedmetadata

Preservelinksbetweenimageandmetadata

Preservelinksbetweenrelatedrecords

PersistentURLs

Backupnightlyandnotifywhenfailure

Refresh/migrate

Acquire(capture,create, edit,convert,reformat)

Describe(user inputmetadatausingtemplatesand IRIS)

ARTstor Yes(no)

Yes Yes No Yes N/a Not yet MyWorkfolder inOfflineViewer

Yes

Contentdm

Yes(yes)

Yes Yes Yes Yes ? Yes Yes Yes (usingweb-basedOASIS)

DSpace Yes—withtweaking(no)

Yes Yes No Yes Yes Yes Yes Yes

24

Narravision Yes(no)

Yes Yes ? ? ? ? ? Not yet

Storage &Archiving, Collection Management, Rights & Security (cont’d)Filemgmt(upload,log assetsinto sys)

Recorduse stats(at itemlevel?)

Displaymetadatain multipleformats

SupportsVRAANDconversionto uniformmetasearchschema

Licensedand non-MITcontent

Secureaccess

Admin modulefor managingprivileges

Digitalrightsmgmt

ARTstor Yes (butonly intotheirViewer)

Yes(itemlevel?)

Dataelementsvary basedoncollection

No (usesspecialmetadataelementset)

Licensed?Yes (non-MIT)

Yes Yes No

ContentDM

Yes Yes (Yes) Yes(VRA,DC, EAD,poss.METS)

Yes [?] Yes Yes Yes Yes

DSpace Yes ? Yes(VRA,DC)

Yes No Yes Yes No

Narravision Yes ? ? ? Yes Yes? Yes No

25

Search & Retrieval, DistributionIntellectualpropertyrightsmgmt

Simple(keyword)andadvancedsearch(Boolean,by field,with limitbycollection)

Refinesearch(searchwithinresults)

Browse(images bysubjectterms, bycollection,etc.)

Search onnative andconvertedmetadata

Sortresults

Displaysearchresults asthumbnailswithtombstonedata,copyright,subjectterms

Displaylinks torelatedrecords

Collectionhome pageswithdescriptions,copyrightandpermissionsinfo, searchtips

ARTstor No Yes(keyword,field, andBoolean)

No? Yes(browsingtaxonomy)

Convertedonly

Yes(exceptbydate)

Yes No No

ContentDM Yes Yes—all Yes Yes Yes Yes(andsub-sort)

Yes[copyright?]

Yes Yes

DSpace No Yes(keyword,field only)

No Yes planned ? Yes[copyright?]

? Yes

Narravision No ? ? ? ? ? Yes[copyright?]

? Yes

26

Search & Retrieval, Distribution (cont’d)Authenticateaccess for largerthan thumbnail

Batchdownloadfiles (usingcheckbox-likefeature)

SupportsJPEG 2000

Can turn offfeatures notin our scope

Get metadataand image filesback out of sys(linked byaccessionnumberelement)

Saving toCD orDVD,USB stick

Restrictaccess basedon privileges

ARTstor Yes Yes Yes (OV) N/a ? Smallformatonly

Yes(instructorprivileges)

ContentDM Yes Yes Yes ? Yes (OAI) Yes Yes (by item,by user, by IPadd)

DSpace ? No No N/a Yes Yes YesNarravision ? Yes ? ? ? ? Yes

27

Administrative, Interoperability, etc.Adminclient?Runs onmultipleplatforms?

Client(end-user)runs onmultipleplatforms

Works withmultiplebrowsers(Mozilla,Safari, IE,Netscape)

Web-based,useswebserver

Softwareclientrequired

Applicationhosted

Plug-insrequired

Customizationrequired (ofXYZ)

ARTstor N/a N/a Yes Yes Yes(OfflineViewer)

Yes Yes(Offlineviewer)Needed forJPEG2000?

Not allowed

ContentDM

Yes Yes Yes (IErecommended)

Yes ? Yes No No

DSpace Yes N/a Yes Yes No Yes No NoNarravision ? ? ? Yes No ? ? ?

Administrative, Interoperability, etc. (cont’d)Maintenancecontractoffered (techsupport)

Multi-seatsite licenseavailable(for Xnumbersimultaneous users)

Workswithmultiple DBs

Authenticationwithcertificates

Authenticationwith username andpassword

Databasesupport

ARTstor N/a (hosted) Yes (no limiton # seats,based onrange of IPadd)

N/A ? Yes N/a

28

ContentDM

Yes Yes ? Yes Yes ?

DSpace Yes Yes N/a Yes Yes ?Narravision ? N/a N/a ? Yes ?

29