The Library of Congress Portals Applications Issues Group, List of Portal Application Functionalities

To promote the Bibliographic Control of Web Resources: A Library of Congress Action Plan work item 2.1, that calls for development and enhancement of portal functionality for the benefit of the library community in general; and,
To examine portal products which meet the reference and research needs of Library of Congress staff and users, and to define functional requirements for a portals application for the Library.

As a result, the LCPAIG devoted nearly one year in market analysis to study portal functionality of particular products in order to identify existing features of such products. The group concentrated on the interface, searching, results presentation, and output capabilities of portal products. Three applications in particular were examined and tested extensively by Library staff from diverse operational areas. The LCPAIG is pleased to acknowledge with appreciation the products utilized and the vendors that made them possible:

ZPORTAL™, available from Fretwell-Downing, Inc.
MetaLib/SFX, available from ExLibris (USA), Inc.; and
ENCompass/LinkFinderPlus, available from Endeavor Information Systems.

What is a Portal? The Library of Congress perspective:

Early in its deliberations, the LCPAIG discovered that there was no single, universal understanding of the term "portal". Charged with examining portal products which supported the reference and research needs of Library of Congress staff and users, the LCPAIG therefore focused its explorations and testing on portals as tools for organized knowledge discovery rather than as enterprise interfaces. As defined by the LCPAIG, portals may be characterized by their ability to:

Assist users in identifying and selecting appropriate target resources
Help users determine the target resources most useful to their research by providing effective search interfaces and an architecture that supports groupings and rich descriptions of resources.
Provide federated searching and information retrieval from diverse target resources: The portal provides federated searching and information retrieval of descriptive metadata from multiple, diverse target resources, including but not limited to commercial or licensed electronic resources, databases, Web pages, and library catalogs. It assists users in setting up and controlling searches, and ensures that search results can be reliably duplicated.
Integrate and manage search results: The portal presents retrieved information in an understandable format and allows the users to interpret and manipulate their search results.
Save and export search results: The portal offers users appropriate options for saving and exporting search results (such as printing, email, and file downloads).
Link search results to full-text or other content delivery options: Where possible, the portal links users from search result citations to full-text digital content or provides other options for content delivery.
Manage access to target resources and portal functionalities for authenticated users: The portal configures access to target resources and portal functionalities for authenticated user communities based on various user classes and roles.

Two complimentary definitions of portals as discovery tools are presented in a May 2001 ARL Scholars Portal Working Group Report:

<http://www.arl.org/access/scholarsportal/may01rept.html> and at the 26th European Library Automation Group (ELAG) Library Systems Seminar --"Semantic Web and Libraries" -- held in Rome, Italy, in April 2002:

<http://www.ifnet.it/elag2002/workshop.html>.

The Library of Congress Environment:

Characteristics that may distinguish the Library of Congress from other libraries include:

The user base (Congressional users, staff, other libraries, onsite patrons, offsite patrons)
The necessity to service a variety of users with varying expertise: e. g., expert analysts in the Congressional Research Service and the Law Library and the remote general public. Unlike most academic libraries, the Library does not have to provide support for academic courses or provide other services expected by faculty and students.
Expectations of customized services in specialized reading rooms (e.g., for access to foreign language or special format content)
Requirements specific to US government agencies

Thus, the list of functionalities offered below may not include applications that other kinds of libraries would specify as either required or desirable. For example, academic libraries are likely to want portal products that can interface with courseware. In short, the list produced by the LCPAIG is that for a general research library of a large and complex nature. Additions or subtractions may be appropriate according to the needs of other kinds of libraries.

Executive Summary

Portals Functionalities:

Mandatory and desired portal functionalities emerged from the LCPAIG's research and testing. To clearly express the functionalities important to the Library, the terms "target" and "target resources" need to be defined for the purpose of this document:

"Target" is used to identify the heterogeneous local and remote electronic resources accessed directly from the portal application. Examples include library OPACs, freely available websites, and licensed resources (e.g., ProQuest®, Academic Search™ Premier, OCLC's FirstSearch Electronic Collections Online, or RLG's Eureka®).

"Target resources" is used to identify individual electronic resources contained in a target. Because many targets are themselves aggregators of electronic content, the term "target resources" identifies, for example, the electronic journals found in aggregator databases.

Portal functionalities are organized under broad headings: General Requirements, Client Requirements, Searching and Search Results, Knowledge Database, Patron Authentication, and Portal Administration and Vendor Support. All of the functionalities designated as required were present in one or more of the three applications (ZPORTAL™, MetaLib/SFX, ENCompass/LinkFinderPlus) tested during market analysis.

Generally Applicable Mandatory Portal Functionalities

General Requirements

Federated searching must enable access for novice and advanced users to heterogeneous targets with diverse metadata and must ensure reliable duplication of search results. Search queries must be processed efficiently, including queries that generate a large number of search result records.
The portal must help users identify and select one or more targets most useful to their research. through a combination of locally selected groupings of targets and rich descriptions for targets (preferably searchable) that can incorporate guidance from reference staff and different ways of characterizing and evaluating targets to facilitate the selection of relevant targets.
A novice or occasional user must be able to understand the choices for specifying search queries, manipulating and exporting search results, and navigating among portal functions. Users must be able to move easily between the portal and the 'native' search interface of a target database. Error messages (e.g., when a search can not be fully executed because a remote database is unavailable) should be comprehensible to novice users.
Support for personalized user profiles (for session parameters, target selection, saved queries, etc.) must respect laws and institutional policies relating to user privacy.

Client Requirements

The web client must work in a browser-neutral environment on a variety of hardware platforms running various operating systems and must comply with Section 508 requirements.
Screen displays must be locally-customizable to support different user communities and "levels" of searchers (expert, skilled, novice), allowing local branding, labeling, and search session defaults. It must be possible to incorporate community-appropriate help and link to digital reference assistance.

Searching and Search Results

A novice or occasional user must be able to perform information-seeking tasks in an iterative manner using the search history, saved searches, marked metadata records, and linking to full text or other related resources through OpenURL support.
A novice or occasional user must be able to view search results by target and to merge search results from different targets. They must be able to understand how the search results and which search result records are linked to accessible digital content.
A novice or occasional user must be able to save and export selected search result records from one or more queries without additional log-in requirements. Users must be able to email, print, and download records. They must understand the formats in which they can receive their exported data (e.g., citation, citation with abstract, full text, tagged metadata records) and how to choose the record format.

Knowledge Database

The vendor must maintain basic descriptive metadata and configuration information for core target databases, including target title or name, subject terms, publisher, standard identifiers, and supported features such as full text or tables of contents.
Knowledge database must be updateable online and through batch processes that use update requests expressed in an open format (such as a specified XML schema).
Contents of the knowledge database must be exportable in an open format (such as a specified XML schema).

Patron Authentication

The architecture must allow the use of different methods to authenticate users and recognize various user roles or classes of users. Authentication processes must provide security against unauthorized use and privacy for users.
The portal must allow administrators to configure the set of targets and portal functionalities displayed to an authenticated user based on information about the user and role/class.

Portal Administration and Vendor Support

The portal application must provide access to Z39.50 target servers and one or more mechanisms for accessing non-Z39.50 target servers. There must be no effective system limitations on the number of targets or resources within these targets.
There must be no effective system limitations on the number of simultaneous active retrieval sessions. The system must be able to support a substantial portion of institutional users with less than 1% downtime. Institutions must be able to control system processes which impact response time (such as the number of simultaneous sessions and session time-out values) and must be able to prioritize access for local users.
The application must interoperate with related library systems and applications, such as integrated library systems, an open URL resolver, ISO interlibrary loan protocol-compliant messaging software, and document delivery applications.
eb-accessible administrative interfaces must be secure, and private information (such as passwords and user profile data) must be stored in an encrypted or secure environment.
The application must provide for complete and robust recovery in case of operating system failure.
Tools and comprehensive machine-readable documentation must be available, with permission given to excerpt and adapt documentation for local use. Tools must be provided to allow local systems staff to configure and monitor the system to permit summary transaction reporting, system resource metrics, transaction logging, error and exception reporting, and statistics on use of targets and portal functionalities. Tools must also be provided to transfer location configurations, customized help files, knowledge database contents, etc. to upgraded software.
The vendor must be available 24x7 for problem resolution, and procedures and response mechanisms for handling bug reports and enhancement requests must be clearly defined. Institutions must also be able to use direct support from target vendors when appropriate.

Generally Applicable Desirable Portal Requirements

For a high performing portal application, the LCPAIG identified several highly desirable functionalities not yet present in some or all the products tested during market analysis. These desirable functionalities are offered to vendors for consideration as they enhance their products.

General Requirements

Users should be able to begin evaluating partial search results before complete search results are received.

Unicode should be supported throughout.

Searching and Search Results

Searchers should be able to apply"search relationship identifiers" (such as Boolean operators, truncation, wildcards, and nesting ) in a single advanced search query.
Between search sessions, users should be able to save, modify, and delete both search queries and the targets associated with these queries (most likely through personalized user profiles).
Searching options should include more than "keyword anywhere" support. Users should be able, for example, to search keywords in specified fields or browse a "left-match" display of fields in an ordered list.

Novice or occasional users should be able to understand how search results returned from different targets are ordered as well as how and when search results from different targets are deduped.
The application should incorporate subject-based retrieval tools to enhance queries.

Knowledge Database

Descriptive metadata for individual electronic resources contained within aggregated targets (such as journal titles) should be available in the knowledge database.
Institutions should be able to access vendor-supplied descriptive metadata and configuration information on an ongoing basis.
Institutions should be able to add local descriptive metadata and configuration information to knowledge database records; this information should be retained when records are regularly refreshed.
The knowledge database should be able to integrate metadata from multiple external sources.

Portal Administration and Vendor Support

For reasons of security and privacy, the application should support secure user logins and enable institutions to determine what session-specific information will be stored and purged.
The application should be able to control access for different user roles/classes according to target-specific access control agreements.

Next Steps:

The LCPAIG welcomes feedback on its statement of proposed mandatory and desirable functionalities from individuals, libraries, professional organizations and vendors. Positive criticism will be gratefully received. Please send your comments via email to:<[email protected]>.

For Further Information

About the Library of Congress Cataloging Directorate's Bicentennial Conference on Bibliographic Control for the New Millennium and the Action Plan that resulted from the Conference, visit: //www.loc.gov/catdir/bibcontrol/

About the Library of Congress Portals Applications Issues Group (LCPAIG), visit:

//www.loc.gov/catdir/lcpaig/paig.html

Portal Application Functional Requirements for the Library of Congress

1. General Requirements

1.1 M Ability to target heterogeneous electronic resources (e.g., unrestricted web resources, restricted web resources, local databases)

1.2 M Ability to configure search and retrieval of diverse target metadata using standard, open protocols (e.g., Z39.50 keyword and scan (browse) capabilities, OpenURL, http gateways, XML gateways, etc.).

1.3 M Ability to support several "levels" of searchers (expert, skilled, novice)

1.4 M Ability for a novice user to understand choices for specifying search queries, selecting targets, manipulating and exporting search results, and navigating among portal functions

1.5 M Ability for user to associate one or more targets with a single search query

1.6 M Ability for user to search multiple targets either simultaneously or independently

1.7 M Ability for user to search targets through the portal client or directly through native target search interface

1.8 M Ability for user to set session parameters (e.g., number of records displayed per screen, preferred search targets, preferred search query type, etc.)

1.9 M Ability for user to save and modify session parameters in personal profiles

1.10 M Support for user customization which respects laws and institutional policies relating to user privacy

1.11 M Support for OpenURL resolver

2. Client Requirements

2.1 Client Technical Requirements

2.1.1 M Ability for web client to work in a browser-neutral environment (e.g., with support for various versions of Internet Explorer, Netscape, Opera, etc.)

2.1.2 M Ability for web client to work on a variety of hardware platforms (e.g., PC, tablet PC, laptop, etc.) running various operating systems and versions (e.g., Windows, Mac, Linux, etc.)

2.1.3 M Compliance with ADA/Section 508 standards, including the presence of icon and graphic mouse-over "Alt" text for normal functions, help messages, and error messages

2.1.4 M Incorporation of standard browser functions for common commands (e.g., page navigation, print, "stop," history, etc.)

2.1.5 M Support for clipboard and cut-and-paste facilities

2.1.6 D Support for Unicode in search boxes and web displays

2.1.7 D Use of session transaction status messages, including target-specific messages (e.g., Connecting, Searching, Retrieving Records, etc.)

2.1.8 D Ability to send search queries to target servers retaining case, punctuation, diacritics, special characters, and spacing specified by the user

2.1.9 D Ability to send search queries to target servers retaining non-Roman characters specified by the user

2.1.10 D Support for browser-specified fonts and/or keyboards (e.g., for non-Roman scripts)

2.2 Client Configuration Requirements

2.2.1 M Ability to locally create several interfaces to support different user communities

2.2.2 M Ability to locally customize labels, buttons, branding (e.g., headers, footers, etc.)

2.2.3 M Ability to locally set default search session parameters (e.g., number of targets able to be simultaneously searched, number of search result records returned, sort and subsort options, export options, length of search session, etc.)

2.2.4 M Ability to locally configure displays of target metadata to help users identify and select one or more targets most useful to their research.

2.2.5 M Ability to locally configure displays of search results (e.g., fields included, information on available formats of linked digital content, local access information for linked digital content, OpenURL menus, etc.)

2.2.6 D Ability to locally define and configure composite search qualifier groupings (e.g., to assign specific fields to groupings such as "name"/"author," "title," "subject")

2.2.7 D Ability to locally configure vendor-defined query methods, including the ability to manipulate and prioritize relevance ranking criteria applied to search results

2.2.8 D Ability to locally define a default Boolean operator for keyword and browse searches which can be overridden by user-specified operators

2.2.9 D Ability to locally configure displays of metadata for target resources to help users identify and select one or more target resources most useful to their research.

2.2.10 D Ability for system administrators to "lock" certain interface customizations from update by local administrators to preserve, for example, a institution-wide "look and feel"

2.3 Client Navigation Requirements

2.3.1 M Consistent and redundant presentation of navigational functions on appropriate pages (using buttons, breadcrumbs, etc.)

2.3.2 M Navigation between major portal functionalities must be understandable by the novice user (e.g., signon/logout, target selection, search, manipulation of search results, help messages, etc.)

2.3.3 M Navigation within search result brief displays (including moving within search results containing large numbers of records) must be understandable by the novice user

2.3.4 M Navigation within metadata records (including scrolling within long records) must be understandable by the novice user

2.3.5 M Navigation between portal client and native target search interfaces must be understandable by the novice user

2.3.6 D Navigation between available list of targets and user-selected targets should be understandable by the novice user

2.3.7 D Appropriate use of new browser windows for functionalities such as searching native target interfaces, OpenURL menus, and links to digital content

3. Searching and Search Result Requirements

(Note: searches will be executed against target servers and against target metadata stored in portal knowledge database)

3.1 General Searching Requirements

3.1.1 M Ability for user to search descriptive metadata in multiple metadata formats

3.1.2 M Ability for user to search by specific fields (e.g., name, title, subject, date, etc.) in advanced searches

3.1.3 M Ability to reliably duplicate search results

3.1.4 M Ability for a search query to contain at least 150 characters

3.1.5 D Ability to apply several search relationship identifiers (e.g., proximity operators, Boolean operators, truncation, wildcards, nesting, word order operators, etc.) in a single advanced search query

3.1.6 D Ability to specify search qualifiers and/or limits before a search is initiated

3.1.7 D Verification that searches initiated from application produce results consistent with searches initiated in the native interface

3.1.8 D Support for search queries to recognize case, punctuation, spacing, diacritics, and special characters to enable queries to be sent to targets as keyed by user (rather than as normalized by application's software)

3.1.9 D Support for non-Roman scripts, including right-to-left input

3.1.10 D Ability to incorporate subject-based retrieval tools (e.g., browsable taxonomies; search term expansion using synonyms, broader terms, narrower terms, related terms; etc.)

3.2 User Customization of Search Parameters within a Session

3.2.1 M Ability for user to retain selected targets between consecutive searches

3.2.2 D Ability for user to specify a preferred sort order for search results (e.g., relevancy; selected fields (such as name, date, etc.)). If target source does not support requested sort order, user must be notified by a message understandable to the novice user.

3.2.3 D Ability for user to toggle on and off specified advanced search functionality (e.g., word stemming, treatment of stopwords, search term normalization (e.g., for case, punctuation, diacritics, special characters, etc.))

3.3 User Customization of Search Parameters between Sessions (may require personal profiles)

3.3.1 D Ability for user to save, modify, and delete search queries

3.3.2 D Ability for user to save, modify, and delete targets associated with search queries

3.3.3 D Ability for user to reexecute saved searches against associated targets on a predefined schedule

3.4 Supported Search Types: Keyword

3.4.1 M Ability to search using keywords in a record

3.4.2 Support for the following keyword functionalities (if target source does not support requested keyword functionality, user must be notified by a message understandable to the novice user):

3.4.2.1 M - Boolean operators (including information on how "not" processing is handled)

3.4.2.2 M - Right truncation

3.4.2.3 M - Proximity searching of word phrases

3.4.2.4 D - Nesting of Boolean operators to allow users to specify order of processing

3.4.2.5 D - Left truncation (with right truncation as a default)

3.4.2.6 D - Word stemming, preferably keyed to specific languages and/or scripts

3.4.2.7 D - Wildcards for a specified and non-specified number of letters (e.g., #, ##, #.#)

3.4.2.8 D - Wildcards placed at the beginning, middle, or end of search term

3.4.2.9 D - Proximity searching of words, with nesting possible to specify order of processing

3.4.2.10 D - Synonyms for words containing punctuation and blank spaces (e.g. *US* could retrieve US, U.S., and U. S.)

3.4.3 D Ability to search using keywords in specified fields. If target source does not support requested keyword searches, user should be notified by a message understandable to the novice user.

3.4.4 D Ability to search single words and word phrases in a single search query

3.5 Supported Search Types: Browse

3.5.1 D Ability to browse a "left-match" display of fields in an ordered list. If target source does not support requested browse searching, user should be notified by a message understandable to the novice user.

3.5.2 Support for the following browse functionalities (if target source does not support requested browse functionality, user should be notified by a message understandable to the novice user):

3.5.3.1 D - Right truncation

3.5.3.2 D - Boolean operators (including information on how "not" processing is handled)

3.5.3.3 D - Nesting of Boolean operators to allow users to specify order of processing

3.5.3.4 D - Left truncation (with right truncation as a default)

3.5.3.5 D - Word stemming, preferably keyed to specific languages and/or scripts

3.5.3.6 D - Wildcards for a specified and non-specified number of letters (e.g., #, ##, #.#)

3.5.3.7 D - Wildcards placed at the middle or end of search term

3.5.4 D Ability to scroll up and down within an ordered list

3.6 Supported Search Types: Other

3.6.1 D Ability to scan for a specific string of characters in a record or in a specified field. If target source does not support requested string searching, user should be notified by a message understandable to the novice user.

3.6.2 D Ability to search a range of data (e.g., a span of dates, classification numbers, etc.). If target source does not support requested range searching, user should be notified by a message understandable to the novice user.

3.7 Pre- and Post-Search Qualifiers/Limits

3.7.2 D Ability to limit by language of associated digital content, if appropriate. If target source does not support requested search qualification, user should be notified by a message understandable to the novice user.

3.7.3 D Ability to limit by language of metadata. If target source does not support requested search qualification, user should be notified by a message understandable to the novice user.

3.7.4 D Ability to qualify a search term by its location in a particular field or group of fields (e.g., name, subject, title, publisher, associated dates, standard identifiers). This includes the ability to handle metadata occurring in repeatable fields. If target source does not support requested search qualification, user should be notified by a message understandable to the novice user.

3.7.5 D Ability to optionally weigh search terms (e.g., term must appear, term must not appear, term is part of an exact phrase, etc.). If target source does not support requested search term weighting, user should be notified by a message understandable to the novice user.

3.7.6 D Ability to indicate whether search term should be sensitive to case, punctuation, stopwords, stemming, and spacing. If target source does not support requested search qualification, user should be notified by a message understandable to the novice user.

3.7.7 D Ability to limit by the presence of linked digital content (e.g., presence of full text)

3.7.8 D Ability to limit by format of linked digital content (e.g., Dublin Core type, MARC record type, etc.; examples of Dublin Core type include: text, sound, image, software, etc.)

3.8 Search Result Manipulation within a Single Search Session

3.8.1 M Ability to organize search results by target

3.8.2 M Ability to merge search results from different targets

3.8.3 M Ability to save at least 50 selected records from search results of a single search query (without separate log-in)

3.8.4 M Ability to save selected records from the search results of consecutive queries

3.8.5 M Ability to modify and delete saved search results records

3.8.6 M Ability to save search queries in search history; search history must include search query, targets associated with search query, and number of records by target in search results

3.8.7 M Ability to modify previous search queries to enable execution of secondary searches

3.8.8 M Ability to modify targets associated with previous search queries to enable execution of secondary searches

3.8.9 D Ability to dedupe search results from different targets

3.8.10 D Ability to save selected records from the search results of consecutive search queries by query

3.8.11 D Ability to resort search results from a defined set of sort options

3.8.12 D Support for search result sort normalization which takes advantage, wherever possible, of data fields (e.g., "<name> Smith, John, 1940- <title>Tennis guide" should file before "<name>Smith, John. <title>1940 tennis guide").

3.8.13 D Support for search result sorting which honors non-filing indicators in titles

3.8.14 D Support for search result sorting which normalizes diacritics and special characters in an order logical to the novice user

3.8.15 D Support for search result sorting which handles punctuation and spacing in an order logical to the novice user

3.8.16 D Support for numeric sorts which are arithmetic (e.g., 1, 2, 3, 10, 100 ... not 1, 10, 100, 2, 3) and which sort Roman numerals as Arabic numbers

3.8.17 D Support for script-appropriate sorting for non-Roman scripts

3.8.18 D Ability to configure search result displays to enable execution of secondary searches from hyperlinked fields (e.g., name, subject, publisher, etc.)

3.8.19 D Ability to configure search result displays to enable execution of secondary searches from fields such as name or subject to locally-specified name or subject authority/thesauri databases

3.9 Search Result Displays

3.9.1 M Presentation of brief search result displays in a format understandable to the novice user

3.9.2 M Presentation of full metadata record displays (e.g., labeled display, tagged display, etc.) in a format understandable to the novice user

3.9.3 M Ability to show number of records returned by each target

3.9.4 M Ability to generate error messages for failed searches using descriptions understandable to the novice user

3.9.5 M Presentation of search results in a format that makes subsequent choices clear to the novice user. Subsequent choices may include: providing expanded metadata, following links to digital content, moving to native search interface, following an OpenURL link, modifying a search, saving a search, initiating a new search, etc.

3.9.6 M Ability to display search context information on search result pages, including target name and the record number of a search result hit within the displayed search results

3.9.7 M Ability to indicate which search result records are linked to digital content, in a manner understandable to the novice user

3.9.8 M Ability to indicate that a search result record is from a target that includes full digital content accessible to institutional users

3.9.9 D Presentation of brief search results in an order explanable to the novice user

3.9.10 D Support for inline thumbnails of linked digital content, if available

3.9.11 D Provision of sufficient information in either brief search result or full metadata record displays to enable user to determine why record was returned in search result (e.g., if search term is found in the full text and not the metadata record, some contextual information would be provided)

3.9.12 D Ability to highlight search terms in search result displays. This includes the ability to suppress highlighting from terms included in Boolean "not" expressions (e.g., search for "business not economics" highlights "business" but not "economics").

3.9.13 D Ability to display diacritics and special characters appropriately

3.9.14 D Support for non-Roman scripts, including right-to-left displays

3.10 Search Result Output

3.10.1 M Presentation of export options in a format that makes choices clear to the novice user. Users must be able to determine that they will receive exported data in the formats they have selected (e.g., citations, abstracts, full text, tagged metadata records, etc.)

3.10.2 M Ability to save in one step the search result records displayed on a single page (e.g., without selecting each hit individually)

3.10.3 M Ability to save selected search result records while maintaining the user's position in the search results list (e.g., saving selected search result records does not force a user back to the beginning of the search results display)

3.10.4 M Ability to email selected search result records as a file or URL link to a user-supplied address (without separate log-in)

3.10.5 M Ability to print selected search result records only to a designated local printer (without separate log-in)

3.10.6 M Ability to download a file of selected search result records (without separate log-in)

3.10.7 M Ability to output search result metadata in various formats (e.g., tagged text, XML, formats used by standard bibliography packages, etc.)

3.10.8 M Ability to generate error messages for failed exports using descriptions understandable to the novice user

3.10.9 D Ability to save in one step the search result records displayed on multiple pages (e.g., without selecting each hit individually)

3.10.10 D Ability for search result metadata to retain diacritics, special characters, case, punctuation, and spacing in at least one export option

3.10.11 D Ability for search result metadata to retain non-Roman characters in at least one export option

3.11 Search and Display Capabilities for Knowledge Database of Target Servers

3.11.1 M Ability to browse a list of targets

3.11.2 M Ability to search target descriptions by keyword

3.11.3 M Ability to present different views of targets (e.g., by subject, user group, services, ownership (locally accessible), etc.)

3.11.4 D Ability to browse target resources (e.g., journal titles in aggregator databases) in hierarchical displays

3.11.5 D Ability to browse a composite list of target resources (e.g., journal titles in all aggregator databases)

3.11.6 D Ability to present different views of the target resources (e.g., by subject, user group, services, ownership (locally accessible), etc.)

4. Help Facilities, Error Messages, and Documentation for Administrators

4.1 Help Facilities and Error Messages

4.1.1 M Availability of context-sensitive help messages using language understandable by the novice user

4.1.2 M Availability for all system failures to generate context-sensitive error messages using language understandable by the novice user (e.g., search protocol diagnostic messages, access control messages, etc.)

4.1.3 M Ability to locally customize help and error messages to express desired remediation and suggestions appropriate for institutional users

4.1.4 M Ability to provide hyperlinks on any page to digital reference services and contact information

4.1.5 M Ability for system administrators to customize help messages for separate user interfaces

4.1.6 D Availability of online tutorials for searchers

4.2 Documentation for Administrators

4.2.1 Availability of comprehensive machine-readable documentation, with permission to excerpt and adapt this documentation for institutional use, including:

4.2.1.1 M - functional descriptions of major components (e.g., interface configurations, management of targets, search and retrieval, export of search result metadata, user authentication, etc.)

4.2.1.2 M - help and error messages, including default message texts

4.2.1.3 M - options for configuring the relevance ranking of search results

4.2.1.4 M - methods used for normalizing search terms (e.g., handling of diacritics and special characters, case sensitivity, punctuation, spacing, non-Roman scripts, definition of word and word phrase)

4.2.1.5 M - options for customizing access to targets using Z39.50 configurations

4.2.1.6 M - user authentication methods and user access functionality

4.2.1.7 M - user customization options

4.2.1.8 M - system level options for customizing the application, including tools for transferring local customizations to upgraded software

4.2.1.9 M - system transaction processing, including available statistics and information on how new sessions are determined

4.2.1.10 M - system level diagnostic and recovery tools

4.2.1.11 D - description and/or algorithms for deduping/merging and sorting search results

4.2.1.12 D - options for customizing access to targets using APIs

4.2.1.13 D - options for customizing access to targets using HTML- and XML-based configurations

4.3 Demonstrations

5.3.1 D Availability of onsite or easily accessible demonstrations of the portal application (e.g., how to use the application and for what purposes)

5. Knowledge Database of Target Servers

(Note: this database will contain descriptive metadata and configuration information for the targets and target resources accessible through the portal application)

5.1 Knowledge Database Structure

5.1.1 M Provision of a knowledge database initially populated by vendor-maintained configuration and basic metadata (e.g., title/target name, subject terms, publisher, standard identifiers, supported features such as full text or tables of contents, etc.) for core targets. In addition to vendor-supplied metadata, this database will also contain institutionally-supplied acquisition source and access control information.

5.1.2 M Support for ongoing vendor-maintained configuration and basic target metadata

5.1.3 M Ability to export contents of knowledge database in an open format (e.g., into specified XML schema)

5.1.4 M Ability to access the knowledge database using standard protocols (e.g., Z39.50, OAI, etc.)

5.1.5 M Access control to the knowledge database to ensure that only authorized users can add, modify, and delete knowledge database data

5.1.6 D Provision of a knowledge database initially populated by vendor-maintained configuration and basic metadata for target resources (e.g., title/target name, subject terms, publisher, standard identifiers, supported features such as full text or tables of contents, etc.)

5.1.7 D Ability to provide reports on changes to target resources

5.1.8 D Support for ongoing vendor-maintained basic metadata for target resources

5.1.9 D Ability to add local metadata fields and local index configurations

5.1.0 D Unicode support in database system

5.2 Knowledge Database Maintenance of Target Metadata

5.2.1 M Ability to locally manage the process of adding, merging, and deleting target metadata

5.2.2 M Ability to load and index target metadata in either batch or online modes

5.2.3 M Ability to import target metadata in a batch mode using requests expressed in an open format (e.g., through specified XML schema). Updated metadata must be able to be imported on a regularly scheduled basis.

5.2.4 M Ability to manage customized, locally-created target metadata, including the ability to retain locally customized metadata when regularly refreshing target information from files received from commercial sources. Customized local data may include passwords, locally-assigned subject information, local notes, access control information, etc.

5.2.5 D Ability to integrate target metadata from more than one source, including commercial sources

5.2.6 D Ability to integrate metadata for target resources from more than one source, including commercial sources. This metadata could include, for example, information from aggregators services identifying additions, modifications, and deletions to the individual electronic resources purchased for the institution's digital collections.

5.3 Knowledge Database Maintenance of Metadata for Target Resources

5.3.1 D Ability to locally manage the process of adding, merging, and deleting metadata for target resources

5.3.2 D Ability to load and index metadata for target resources in either batch or online modes

5.3.3 D Ability to import metadata for target resources in a batch mode using formats that openly express what is required (e.g., through specified XML schema). Updated metadata should be able to be imported on a regularly scheduled basis.

5.3.4 D Ability to manage customized, locally-created metadata for target resources, including the ability to retain locally customized metadata when regularly refreshing target resources information from files received from commercial sources.

5.3.5 D Ability to integrate metadata for target resources from more than one source, including commercial sources

5.3.6 D Ability to flag changes to the knowledge database resulting from the batch loading of metadata in a report. Such a report would enable local data administrators to review changes for possible data conflicts.

6. Patron Authentication

6.1 Authentication and Access Management

6.1.1 M Architecture that allows the use of different methods for authenticating users and recognizing various user roles or classes of users (e.g., IP-address linked to external identification systems, refer URLs, passwords, etc.)

6.1.2 M Ability to securely apply user authentication and user role information in configuring the set of targets, target resources, and portal functionalities displayed to each user Configuration options include the ability to display metadata and enable user access to linked content, to display metadata without enabling user access to linked content, or to suppress metadata and access to linked content.

6.1.3 M Ability to securely pass appropriate user authentication and user role information when following links to full content (e.g., through OpenURL version 1.0, etc.).

6.1.4 M Ability to log unauthorized attempts to perform transactions against the database

6.1.5 D Ability to securely pass appropriate user authentication and user role information when communicating with targets or following links to full content in a manner which takes information only when necessary, takes as little information as possible, takes information specific only to the request, and ensures that the information passed does not expose the receiver system to vulnerability.

6.1.6 D Ability to manage user authentication role or class information

6.1.7 D Ability to manage target-specific access control agreements

6.2 Password maintenance

(Note: A portal application for the Library should not require passwords to search and display metadata or to print, email, and save search result metadata. Passwords will, however, be necessary to support functions such as personalization or guest access for offsite users).

6.2.1 M Support for generic accounts (e.g., accounts for use at public reading room workstations)

6.2.2 M Support for "guest" logins with limited system access

6.2.3 D Ability for local system administrators to resolve portal password problems for their users. (Note: this requirement recognizes that the portal software cannot help local system administrators resolve password problems with user personalization profiles maintained in portal target systems, such as commercial aggregators).

7. Portal Administration and Vendor Support

7.1 Hardware and Software Requirements

7.1.1 M Compatibility with the institution's IT security policies and the institution's technical environment

7.1.2 M Support for a Z39.50 client that enables access to Z39.50 target servers. Z39.50 configurations must be locally customizable.

7.1.3 M Support for one or more mechanisms to access non-Z39.50 target servers (e.g., HTML- or XML-based configurations, APIs, etc.). Non-Z39.50 access configurations must be locally customizable.

7.1.4 M Support for an OpenURL resolver

7.1.5 M Support for batch transactions for administrative functions

7.1.6 M Provision for complete and robust recovery in case of operating system failure

7.1.7 M Provision of a secure web-accessible administrator interface

7.1.8 Ability to interoperate with related library systems and applications, including:

7.1.8.1 M - the institution's integrated library system (the Library uses Endeavor's Voyager system)

7.1.8.2 D - ISO interlibrary loan protocol-compliant messaging software (e.g., Ariel, OCLC ILL, etc.)

7.1.8.3 D - web content management systems

7.1.8.4 D - document delivery applications

7.1.9 D Support for secure user logins

7.1.10 D Ability to host application locally

7.1.11 D Modular architecture that permits interoperability with equivalent application components acquired separately (e.g., patron authentication systems, OpenURL resolvers, etc.)

7.1.12 D Identification of software components licenced from third-party sources, to facilitate impact assessments of third-party software on the portal application's rate of development

7.1.13 D Ability to send and receive data from Unicode-compliant data sources

7.2 Application Administration

7.2.1 M Support for role-based system administration within distinct institutional units

7.2.2 M Ability to store secure information in an encrypted or secure environment (e.g., passwords, user profile data, etc.)

7.2.3 M Provision of programmer tools for system customization, system configuration, system monitoring, and reporting

7.2.4 D Ability to determine which session-specific user profile data will be maintained to assure user privacy

7.2.5 D Ability to purge user profile data by specified parameters (e.g., locally-defined user groups, date, etc.)

7.3 Statistics and Reports

7.3.1 M Ability to provide summary reporting on transaction processing

7.3.2 M Ability to provide transaction logs and audit trails, including error and exception reporting

7.3.3 D Ability to provide readily accessible statistics on the use of portal functionalities (e.g., how many times, when, and by whom a functionality has been used; errors generated by incomplete transactions, information on the number of active sessions, etc.). Statistics should be captured at least hourly.

7.3.4 D Ability to provide readily accessible statistics on the use of targets (e.g., how many times, when, and by whom a target has been accessed; frequency of difficulty accessing specific target servers, etc.). Statistics should be captured at least hourly.

7.3.5 D Ability to provide readily accessible statistics on use of target resources (e.g., how many times, when, and by whom a target resource has been accessed). Statistics should be captured at least hourly.

7.4 Performance and Scalability

7.4.1 M No effective system limitations on the number of simultaneous active retrieval sessions. The system must be able to support a substantial portion of institutional users.

7.4.2 M No effective system limitations on the number of targets or target resources

7.4.3 M Ability to process partial search results before complete search results are received

7.4.4 M Users must be able to work on partial search results before complete search results are received

7.4.5 M Ability to efficiently process search results that contain a large number of records (for example, application could "warn" user if search results would return over a specified number of records)

7.4.6 M Ability to set inactivity time-outs for specific users and/or user groups

7.4.7 M Less than 1% downtime (e.g., for backup, maintenance, etc.)

7.4.8 D Ability to prioritize user access by patron authentication, IP address, or local network address

7.4.9 D Ability to locally control the number of simultaneous active retrieval sessions

7.4.10 D Modular architecture that enables specific application components to operate on separate server nodes or processors

7.5 Vendor Support

7.5.1 M Availability of 24x7 support for problem resolution

7.5.2 M Provision of appropriate communication mechanisms for problem resolution (e.g., email, telephone, site visits, etc.)

7.5.3 M Availability of maintenance contracts

7.5.4 M Problem resolution through effective 3-way communication between the portal vendor, target vendors, and the institution, including the ability of the institution to use target vendor support when appropriate

7.5.5 M Provision of references and customer satisfaction surveys and portal application and components, including OpenURL resolver

7.5.6 M Commitment to support current search and retrieval protocol standards and to incorporate relevant new standards into the portal application in a timely fashion (e.g., XQuery, ZING, OpenURL, etc.)

7.5.7 D Availability of user support groups

7.5.8 D Availability of vendor-maintained FAQs for system support

7.6.6 Testing and Implementation of New Releases

7.6.1 M Assurance that background activities (e.g., software maintenance, knowledge database updates, etc.) do not degrade system performance of the production application

7.6.2 M Ability to set up the application in local test environments

7.6.3 M Clearly-defined procedures and response mechanisms for handling bug reports and enhancement requests

7.6.4 M Willingness to work with the institution as an alpha or beta test site for enhancements

7.6.5 M Provision of tools for transferring local customizations to upgraded software. Customer support options must be available to resolve problems where software upgrades negatively impact local customizations.

Top of Page

Return to LCPAIG: Home, LCPAIG: Documents or LCPAIG: Site Map page.

Go to the Library of Congress Home Page
Go to Cataloging Directorate Home Page

Library of Congress
Contact Us ( January 23, 2003 )