<%BANNER%>





FEATURES DESIRED IN A DIGITAL LIBRARY SYSTEM
Initial draft prepared for review and comment by G. Clement (FIU) and L. Taylor (UF), with additional editing by
M. Sullivan (UF) and L. Dotson (UCF), April 30, 2009

Working Definitions

Bibliographic item: All the pieces that together form the basis for a single bibliographic
description. Can be a book, map, website etc. Bibliographic items can be simple or
compound objects. Even simple objects (a single photograph) will likely have multiple
manifestations.

Simple object: a single file or set of related files with no hierarchical relationship
between the files; associated with a single descriptive metadata record.

Compound or complex object: a set of files with a hierarchical relationship, associated
with a single descriptive metadata record.

Manifestation: version of a given bibliographic item with a specific file format (e g PDF,
JPEG images, full-text file, etc.)

Collection: A named grouping of bibliographic items based on some common
characteristic, such as provenance or subject

Requirements

A. Architecture

1. Architecture facilitates library staff in setting up collections and assigning or ingesting
items to collections

2. There are no conventions that must be followed for naming directories or files or the
conventions are documented, verified, and easy for library staff to follow or created and
followed through an automated process as part of a tool or application.

3. Collections are logically, not physically, defined; they are easily created, deleted and
redefined by library staff

4 A bibliographic item can easily be added to a collection, assigned to a new collection,
allocated to multiple collections, or deleted from a collection by library staff.

5. Text can be stored in Unicode and/or UTF-8.

6. Indexes can be updated to include new or changed content without having to reindex
the entire database. Indexing runs in the background (no downtime for using the system
during indexing).

7. Collections can be created, populated, and viewed by authorized library staff users
while remaining invisible to unauthorized users.


Digital Library Requirements Draft for Comment


Page 1











8. Customizations can be tested by library staff in a way that is invisible to unauthorized
users and that does not affect the rest of the system.

9. The system uses an affordable and dependable relational database system, and an
affordable and dependable operating system that will require minimal additional
support (existing support already available and existing knowledge/skill with the
operating system).

10. System natively supports content in multiple languages and multilingual interfaces
(automatic support if library staff provides translations; set search terms already
automatically supported with translations already in place).

11. All content from the current PALMM Textual Collections and Visual Collections can
be imported into the system with no loss of information or functionality

B. Content
All of the content from the PALMM collections can be supported in terms of file format, file
relationships and structure, including multimedia collections

1. The system must support at least the following formats
tiff and jpeg images
jpeg2000 images (server-side support)
pdf
full text
audio and video
streaming audio and video (i e URLs to streaming server)

2. The system supports the following special genres:
EAD finding aids (structured display, links to digitized content, XML to HTML
translation and option to also display as PDF)
Serial display with hierarchy (for newspapers, journals, and other serials)
Audio for simple object (music file alone) and for complex/compound objects
(oral history with a transcript that can be displayed while audio is played)
books/monographs (structured table of contents, page turning and "go to")

3 Must allow integrated multimedia collections can have text, images, audio, video,
etc all in the same collection.

4. Must support related objects, defined as groups of objects with some relation to each
other:
if one is retrieved, all are retrieved
the relationship among the objects is made clear
related objects do not have to all be in the same format
any number of related objects can comprise a group


Digital Library Requirements Draft for Comment


Page 2











C. Metadata


1. System has documented, verifiable support for ingest, display, and translation of the
primary descriptive metadata in use (simple and qualified DC, MARC21, MODS).

2. DL System has a readily available easy process and tools for library staff to
input/update metadata, add local fields (including administrative fields not shown to the
public), ingest existing records, edit ingested existing records, and export records.

3. Has input forms and edit routines for descriptive metadata in:
simple Dublin Core
qualified Dublin Core
MARC21
METS/MODS

4. It is possible for library staff to design our own metadata input/update templates.

5. It is possible for library staff to add local fields to any supported metadata format.

6. It is possible to include technical and administrative metadata elements which do not
display to the public.

7. It is possible to enable and maintain a controlled vocabulary (standardized or user
generated) for any given field. A tool or method is available for making desired changes
easily in a manner that meets library staff needs.

8. Bibliographic records from the Aleph library catalog, OCLC records, or any MARC
records from anywhere, can be easily imported into the DL system. If using an Aleph
record, records can be re-imported automatically when they are updated in the catalog.
It is possible to import pre-existing metadata saved in file formats such as tab-delimited,
CSV, and XML

D. Ingest

1 Supports automatic batch upload to the ingest process of the files in their supported
formats as listed above. If any translation/conversion is needed prior to batch ingest, a
documented process with a tool/application is available that library staff feel is
sufficiently simple and has adequate support for their needs.

2. Provides immediate verification of ingest success or, in the case of ingest failure,
provides error messages that communicate to staff what needs to be fixed for successful
ingest.

3. Tool is available that meets library staff needs for uploading their content from their
local workstations.


Digital Library Requirements Draft for Comment


Page 3










4. Ingest processing is speedy enough to meet library staff needs. (For each DL System
under review, discussions over the value of increased speed should consider the
benefits of that speed in relation to the costs/delays for staffing, software version
upgrades, etc).

5. Multiple file formats can automatically be created from TIFF images on ingest. For all
of the derivative formats, a tool or documented process should be available so that
library staff can evaluate the process for their needs. The documented process should
be testable so that library staff can evaluate the product (multiple manifestations
created from the TIFF file) for quality and any other needs. File formats available for
automatic creation from TIFF include at minimum:
searchable full text via OCR
thumbnail images
JPEG2000 images, with library-defined resolutions (not just a default set that
cannot be changed)
page level PDF files
document level PDF files

6. Ingests are indexed into the system and made available to users for search and
retrieval on a regularly scheduled basis.


E. Search and retrieval

1. System has a Z39.50 server.

2. Users have the option to search or to browse.

3. For serial publications, the user should be able to search for individual articles by
author and title The user should also be able to list and browse the tables of contents
of issues, listed in reverse chronological order.

4 The user can choose to search metadata only or both metadata and full text together.

5. Both Google-like simple search (all fields, one search box, all terms OCRed) and
advanced search (choice of specific fields, limits, choice of Boolean operators) are
allowed

6 Users can search and browse
within a single collection
across all collections
across groups of collections predefined by us
across groups of collections defined by the user

7. Assistance for search and navigation is provided through
Alternate spelling suggestions when no results found
Faceted browsing


Digital Library Requirements Draft for Comment


Page 4










Clickable links within metadata (author, subject, format, etc)
Pre-determined canned searches

8. Hits are displayed in a way that makes sense to the user; it is clear whether an object
is a book, photo, recording, etc.

9. The results returned from a search should be sortable by author, title, publication
date and relevance; any of these can be set as the default.

10. The results returned from a search can be represented visually in document space
ala AquaBrowser or similar tools.

11. When performing a cross-collection search and retrieving hits from multiple
collections, it is clear to the user which collection each hit comes from

F. Display and Use

1. An outline or table of contents display is available for complex structured
bibliographic items. It is possible to expand and contract any heading in the outline
hierarchy.

2. When a textual object is retrieved by a full text search, the search term is highlighted
on the page.

3. When both image and full text manifestations of pages are available, they can be
displayed simultaneously on the screen.

4. Branding is obvious for both collection owning repository (could be library, museum
or agency) and the digitizing repository (could be library, museum or agency).

5 Users can display, download, print and/or email content (unless these functions are
restricted for a particular computer file, bibliographic item, or collection).

6 Restrictions on access and use can be implemented at the computer file and/or the
bibliographic item level by password and by IP filter.

7 There is a portfolio ("my collection") function.

8. The implementation can control display characteristics such as what fields and labels
are used.

9. The end user can control some display characteristics such as the number of hits to
show on a page and how the results are displayed with options such as thumbnail,
citation only, title only, and hierarchical (for newspapers and volume/issue materials).

10. Easy to understand help files and/or tutorials are available to assist users with
search, display, and use functions.


Digital Library Requirements Draft for Comment


Page 5










G. Export


1. The system can export simple and complex objects as packages with METS
descriptors.

2. Bibliographic data can be exported in standard MARC21 format for import into a
catalog system.

3. There is an OAI broker capable of exporting metadata in oai_dc format.

4. All content can be readily re-deposited from DL to FDA automatically, without
additional effort (sending, processing, any manual work) on behalf of library staff

H. Management and reporting

1. Ad hoc and canned reports can be run Documentation is available on existing
automatic reports and samples of reports are available for evaluation by library staff for
their needs.

2. The system automatically logs use and provides usage statistics, at a frequency of no
less than monthly, on:
number of searches (by collection and by date/time)
materials accessed (by title and aggregated into various categories)
users
user sessions
sample usage reports are already available for review by library staff

I. Budget

1. The DL System has a clear budget for the existing system and enhancements.

2. When evaluating the DL System, cost considerations should include:
licensing cost
cost per record
costs of additional software for the DL System host
costs of additional software/tools for each of the libraries
costs of customized programming to accommodate the libraries' needs (staffing
costs, with timelines available for review that detail implementation plans)
costs of hardware and/or support for hosting the DL System (server space, other
equipment, staff)


Digital Library Requirements Draft for Comment


Page 6










CHARACTERISTICS AND SERVICES DESIRED IN A DIGITAL LIBRARY SERVICE PROVIDER

The Digital Library Service Provider is the agency responsible for implementation, maintenance,
documenting, providing administrative information about, and training library staff in the use of
the Digital Library System selected by the SUL community for digital collections development
and access.

In fulfillment of this role, the following responsibilities must be assumed and accounted for by
the SUL Digital Library Service Provider:

1. Acquisition, operation and maintenance of all hardware, software, licenses, and partner
agreements necessary to ensure a stable, reliable, continuously operating digital library
system.
2. Complete, specific, timely and accurate documentation regarding the features,
functions, configurations and custom settings and procedures that characterize the SUL-
specific instance of the Digital Library System which is managed by the Service Provider.
3. Complete, timely and accurate communications with appropriate representatives at
contributing SUS libraries regarding technical or other requirements that the library
needs to meet to fully utilize the Digital Library System.
4. Complete, timely and accurate notification to appropriate representatives at
contributing SUS libraries regarding changes in the DL system or its operations
5. Timely, accurate, and detailed analysis of possible impacts that any future scheduled or
expected change to the DL system will have on digital collections currently housed in the
DL System (whether in production or in test)
6. Timely, accurate, and detailed evaluation of impacts that an actual change to the DL
system has had on digital collections currently housed in the DL System (whether in
production or in test).
7 Both expert-led and self-directed training programs in the use of the DL system that
covers all functions and features available for use by library staff (Includes but not
limited to ingest new, edit, delete, creating and maintaining collections, use of both
library-mediated and author self-submission modules., trouble shooting for the full
range of object types supported by the DL (simple compound, complex, multiple
manifestation, individual and batch ingest or edit, etc.)
8. Responsive, expert, and ongoing library staff support and troubleshooting of problems
encountered in the use of DL system through an online, ticket-based system with a
published turnaround time for first response.
9. Initiation and support of a transparent and democratic process within SUL community
for suggesting, prioritizing and implementing enhancements or additions to the DL
system.
10. Regularly updated, accurate reporting and accounting of usage of all digital objects
contributed to the DL system by SUL's.
11. For any large-scale changes to the contents of the DL system, including but not limited
to migration, refresh, transformation, or copying of resources to another system,


Digital Library Requirements Draft for Comment


Page 7










prepare a written plan for comment and consideration by SULs. After the review process
is complete, publish the formal plan via a forum widely available within the SUL
community, and update as appropriate.
12. For any solutions, support documents, customizations, applications or templates
produced for one SUL, systematically make these resources widely available to the SUL
community as a whole.
13. Establish and follow SUL-approved procedures for researching or initiating possible new
projects for the SULs, a particular SUL (all entities at a particular university would be
coordinated through that SUL), external partners, and for independent research
projects; and reporting on such initiatives in a timely and transparent manner.


Digital Library Requirements Draft for Comment


Page 8




Features Desired in a Digital Library System (2010)
ALL VOLUMES CITATION SEARCH PDF VIEWER
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00103112/00001
 Material Information
Title: Features Desired in a Digital Library System (2010)
Physical Description: Archival
Language: English
Creator: Clement, Gail
Taylor, Laurie N.
Sullivan, Mark V.
Dotson, Lee
Digital Initiatives Subcommittee ( DISC )
Digital Initiatives and Services Committee ( DISC )
Publisher: UF Libraries
Place of Publication: Gainesville, FL
Publication Date: 2010
 Notes
General Note: Document prepared for committee review and comment by G. Clement (FIU) and L. Taylor (UF), with additional editing by M. Sullivan (UF) and L. Dotson (UCF), April 30, 2009. Reviewed and approved by the State University Libraries’ Digital Initiatives Subcommittee (DISC), September 8, 2010. History: Initial document, Features Desired in a Digital Library System to Replace FCLA'S Textual Collections and Visual Collections, created by the Florida Center for Library Automation (FCLA) and the Digital Library April 6, 2006 to evaluate DL systems, leading to the purchase of DigiTool in 2006.
 Record Information
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UF00103112:00001

Downloads

This item has the following downloads:

( PDF )


Full Text






FEATURES DESIRED IN A DIGITAL LIBRARY SYSTEM
Initial draft prepared for review and comment by G. Clement (FIU) and L. Taylor (UF), with additional editing by
M. Sullivan (UF) and L. Dotson (UCF), April 30, 2009. Reviewed and approved by the State University Libraries' Digital
Initiatives Subcommittee (DISC), September 8, 2010.

Working Definitions

Bibliographic item: All the pieces that together form the basis for a single bibliographic
description. Can be a book, map, website etc. Bibliographic items can be simple or
compound objects. Even simple objects (a single photograph) will likely have multiple
manifestations.

Simple object: a single file or set of related files with no hierarchical relationship
between the files; associated with a single descriptive metadata record.

Compound or complex object: a set of files with a hierarchical relationship, associated
with a single descriptive metadata record.

Manifestation: version of a given bibliographic item with a specific file format (e.g., PDF,
JPEG images, full-text file, etc.)

Collection: A named grouping of bibliographic items based on some common
characteristic, such as provenance or subject.

Requirements

A. Architecture

1. Architecture facilitates library staff in setting up collections and assigning or ingesting
items to collections.

2. There are no conventions that must be followed for naming directories or files or the
conventions are documented, verified, and easy for library staff to follow or created and
followed through an automated process as part of a tool or application.

3. Collections are logically, not physically, defined; they are easily created, deleted and
redefined by library staff.

4. A bibliographic item can easily be added to a collection, assigned to a new collection,
allocated to multiple collections, or deleted from a collection by library staff.

5. Text can be stored in Unicode and/or UTF-8.

6. Indexes can be updated to include new or changed content without having to reindex
the entire database. Indexing runs in the background (no downtime for using the system
during indexing).


Digital Library Requirements


Page 1










7. Collections can be created, populated, and viewed by authorized library staff users
while remaining invisible to unauthorized users.

8. Customizations can be tested by library staff in a way that is invisible to unauthorized
users and that does not affect the rest of the system.

9. The system uses an affordable and dependable relational database system, and an
affordable and dependable operating system that will require minimal additional
support (existing support already available and existing knowledge/skill with the
operating system).

10. System natively supports content in multiple languages and multilingual interfaces
(automatic support if library staff provides translations; set search terms already
automatically supported with translations already in place).

11. All content from the current PALMM Textual Collections and Visual Collections can
be imported into the system with no loss of information or functionality.

B. Content
All of the content from the PALMM collections can be supported in terms of file format, file
relationships and structure, including multimedia collections.

1. The system must support at least the following formats:
tiff and jpeg images
jpeg2000 images (server-side support)
pdf
full text
audio and video
streaming audio and video (i.e., URLs to streaming server)

2. The system supports the following special genres:
EAD finding aids (structured display, links to digitized content, XML to HTML
translation and option to also display as PDF)
Serial display with hierarchy (for newspapers, journals, and other serials)
Audio for simple object (music file alone) and for complex/compound objects
(oral history with a transcript that can be displayed while audio is played)
books/monographs (structured table of contents, page turning and "go to")

3. Must allow integrated multimedia collections can have text, images, audio, video,
etc. all in the same collection.

4. Must support related objects, defined as groups of objects with some relation to each
other:
if one is retrieved, all are retrieved
the relationship among the objects is made clear
related objects do not have to all be in the same format
any number of related objects can comprise a group


Digital Library Requirements


Page 2














C. Metadata


1. System has documented, verifiable support for ingest, display, and translation of the
primary descriptive metadata in use (simple and qualified DC, MARC21, MODS).

2. DL System has a readily available easy process and tools for library staff to
input/update metadata, add local fields (including administrative fields not shown to the
public), ingest existing records, edit ingested existing records, and export records.

3. Has input forms and edit routines for descriptive metadata in:
simple Dublin Core
qualified Dublin Core
MARC21
METS/MODS

4. It is possible for library staff to design our own metadata input/update templates.

5. It is possible for library staff to add local fields to any supported metadata format.

6. It is possible to include technical and administrative metadata elements which do not
display to the public.

7. It is possible to enable and maintain a controlled vocabulary (standardized or user
generated) for any given field. A tool or method is available for making desired changes
easily in a manner that meets library staff needs.

8. Bibliographic records from the Aleph library catalog, OCLC records, or any MARC
records from anywhere, can be easily imported into the DL system. If using an Aleph
record, records can be re-imported automatically when they are updated in the catalog.
It is possible to import pre-existing metadata saved in file formats such as tab-delimited,
CSV, and XML.

D. Ingest

1. Supports automatic batch upload to the ingest process of the files in their supported
formats as listed above. If any translation/conversion is needed prior to batch ingest, a
documented process with a tool/application is available that library staff feel is
sufficiently simple and has adequate support for their needs.

2. Provides immediate verification of ingest success or, in the case of ingest failure,
provides error messages that communicate to staff what needs to be fixed for successful
ingest.

3. Tool is available that meets library staff needs for uploading their content from their
local workstations.


Digital Library Requirements


Page 3











4. Ingest processing is speedy enough to meet library staff needs. (For each DL System
under review, discussions over the value of increased speed should consider the
benefits of that speed in relation to the costs/delays for staffing, software version
upgrades, etc).

5. Multiple file formats can automatically be created from TIFF images on ingest. For all
of the derivative formats, a tool or documented process should be available so that
library staff can evaluate the process for their needs. The documented process should
be testable so that library staff can evaluate the product (multiple manifestations
created from the TIFF file) for quality and any other needs. File formats available for
automatic creation from TIFF include at minimum:
searchable full text via OCR
thumbnail images
JPEG2000 images, with library-defined resolutions (not just a default set that
cannot be changed)
page level PDF files
document level PDF files

6. Ingests are indexed into the system and made available to users for search and
retrieval on a regularly scheduled basis.


E. Search and retrieval

1. System has a Z39.50 server.

2. Users have the option to search or to browse.

3. For serial publications, the user should be able to search for individual articles by
author and title. The user should also be able to list and browse the tables of contents
of issues, listed in reverse chronological order.

4. The user can choose to search metadata only or both metadata and full text together.

5. Both Google-like simple search (all fields, one search box, all terms OCRed) and
advanced search (choice of specific fields, limits, choice of Boolean operators) are
allowed.

6. Users can search and browse
within a single collection
across all collections
across groups of collections predefined by us
across groups of collections defined by the user

7. Assistance for search and navigation is provided through
Alternate spelling suggestions when no results found


Digital Library Requirements


Page 4










Faceted browsing
Clickable links within metadata (author, subject, format, etc)
Pre-determined canned searches

8. Hits are displayed in a way that makes sense to the user; it is clear whether an object
is a book, photo, recording, etc.

9. The results returned from a search should be sortable by author, title, publication
date and relevance; any of these can be set as the default.

10. The results returned from a search can be represented visually in document space
ala AquaBrowser or similar tools.

11. When performing a cross-collection search and retrieving hits from multiple
collections, it is clear to the user which collection each hit comes from.

F. Display and Use

1. An outline or table of contents display is available for complex structured
bibliographic items. It is possible to expand and contract any heading in the outline
hierarchy.

2. When a textual object is retrieved by a full text search, the search term is highlighted
on the page.

3. When both image and full text manifestations of pages are available, they can be
displayed simultaneously on the screen.

4. Branding is obvious for both collection owning repository (could be library, museum
or agency) and the digitizing repository (could be library, museum or agency).

5. Users can display, download, print and/or email content (unless these functions are
restricted for a particular computer file, bibliographic item, or collection).

6. Restrictions on access and use can be implemented at the computer file and/or the
bibliographic item level by password and by IP filter.

7. There is a portfolio ("my collection") function.

8. The implementation can control display characteristics such as what fields and labels
are used.

9. The end user can control some display characteristics such as the number of hits to
show on a page and how the results are displayed with options such as thumbnail,
citation only, title only, and hierarchical (for newspapers and volume/issue materials).

10. Easy to understand help files and/or tutorials are available to assist users with
search, display, and use functions.


Digital Library Requirements


Page 5












G. Export


1. The system can export simple and complex objects as packages with METS
descriptors.

2. Bibliographic data can be exported in standard MARC21 format for import into a
catalog system.

3. There is an OAI broker capable of exporting metadata in oai_dc format.

4. All content can be readily re-deposited from DL to FDA automatically, without
additional effort (sending, processing, any manual work) on behalf of library staff.

H. Management and reporting

1. Ad hoc and canned reports can be run. Documentation is available on existing
automatic reports and samples of reports are available for evaluation by library staff for
their needs.

2. The system automatically logs use and provides usage statistics, at a frequency of no
less than monthly, on:
number of searches (by collection and by date/time)
materials accessed (by title and aggregated into various categories)
users
user sessions
sample usage reports are already available for review by library staff

I. Budget

1. The DL System has a clear budget for the existing system and enhancements.

2. When evaluating the DL System, cost considerations should include:
licensing cost
cost per record
costs of additional software for the DL System host
costs of additional software/tools for each of the libraries
costs of customized programming to accommodate the libraries' needs (staffing
costs, with timelines available for review that detail implementation plans)
costs of hardware and/or support for hosting the DL System (server space, other
equipment, staff)


Digital Library Requirements


Page 6