Attachment J4 - Requirements Traceability Matrix (RTM) for Analysis.xlsx
XLSX spreadsheet 110 KB Posted
- Solicitation number
- 030ADV22R0036
- Issued by
-
Library of Congress
View the file
Other files
Show all 21
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Overview
| Project Name: Library Collections Access Platform |
| Document: Attachment J4 - Requirements Traceability Matrix (RTM) for Analysis |
| The contractor shall work with the Library to convert the requirements included in this Draft RTM into features, epics, and users stories to guide implementation. See Task Order #1 Statement of Objectives, Task #1. It is included here for informational purposes and the vendor is not required to provide a line-by-line response. |
&14Respondent: Library of Congress Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
1.0 Cross-functional
| Functional Area: | Cross-functional | ||||
| Description: | The requirements below apply to all functional areas of LCAP. | ||||
| Unique | |||||
| ID | Category | Requirement | Description | Questions | Priority |
| 1.1.0 | Reporting & Analysis | ||||
| Summary: | The Library must have the ability to generate a variety of reports and queries on workflow processes, collection usage and availability, collection content, preservation condition and status and acquisitions and fiscal data to support operational and planning needs. Such reports may be “canned” and delivered as part of the LSP or may be custom prepared by Library staff using standard reporting tools to meet specific management information needs. They may be run on a scheduled or on an ad hoc basis. The general business needs for reporting and analysis are described below. | ||||
| 1.1.1 | Reporting & Analysis | Full access report creators should be able to report on any data element in any record in the system, as well as workflow information (such as the number or items that are waiting to be processed), and system status and diagnostic information (such as database tasks being performed in real time or number of users logged in to the system). | 7.1.1 How does the system handle reporting in general? Is it a separate module within the system? Is it web-based? Is it an external application? Please describe the general reporting architecture for your system. |
7.1.2 How does the system handle querying and reporting MARC data?
7.1.3 How does the system handle querying and reporting non-MARC data?
7.1.4 How does the system handle querying and reporting of both MARC and non-MARC data together? How much is response time affected by such complex queries?
7.1.5 What output formats are available via querying (MARC, Excel, CSV, API, etc.)?
7.1.6 Can all MARC fields be accessed by the reporting module? If so, how is that done? Does the user have the ability to sort, filter, and limit on any variable or fixed field or subfield in any MARC record type (bibliographic, holdings, authority)?
7.1.7 Is there a limit on the number of records that can be returned for a report in your system?
7.1.8 Can reports be scheduled to run at specific times? Can the output be automatically e-mailed to a user?
| 7.1.9 Is it possible to add custom statistical fields to the database for institutional reporting needs? | Highly Desirable | ||||
| 1.1.8 | Reporting & Analysis | The Library needs the ability to create user-friendly reporting interfaces for novice and intermediate users running regular reports | A user-friendly reporting interface is needed for novice and intermediate users who typically run the same reports with slightly changed criteria so that these users can run their own reports with minimal support or intervention. | 7.7.1 What tools does the solution offer to help novice users run reports? |
| 7.7.2 Is the reporting module capable of hosting a searchable Help section for common troubleshooting and documentation such as data dictionaries (accessible to novice, intermediate, and advanced staff users)? | Highly Desirable | ||||
| 1.1.10 | Reporting & Analysis | The Library needs the ability to integrate data from external systems into standard and ad-hoc reports | In many cases, staff need to combine data from back office functions and or discovery with data from another system (e.g., an external database where conservation treatment is recorded). | 7.9.1 Is it possible to integrate data from external systems for reporting and analysis? |
7.9.2 If not, can the solution interface with external reporting tools such as Kibana or Tableau?
| 7.9.3 Can end-user or externally provided lists (such as lccns) be used to build reports? Are there any limits (quanity or type of data) on this? | Highly Desirable | ||||
| 1.1.14 | Reporting & Analysis | The Library needs standard overlap, failed OpenURL resolution, and statistical reports. | LC staff need ejournal and ebook overlap reports to assist with subscription decision support. They also need failure reports, including target service requests that fail to complete successfully (e.g., bad linking syntaxes, invalid or insufficient metadata, target server timeouts, etc.). There is also a need for statistics (e.g, usage by source, target, ejournal or ebook item, or service; service menu clickthroughs; failed searches, etc. - including how often, when, and from what address a functionality has been used). | 7.12.1 How do users access the OpenURL knowledgebase? |
7.12.2 What standard reports are available from your OpenURL resolver application?
7.12.3 What error files and statistics are retained?
7.12.4 How do you support access to your analytics?
| Highly Desirable | ||||
| 5.11.2 | Reporting | The Library needs a way to search and report on the audit histories of holdings and item records. | Library staff must monitor the security of materials and be able to search and create reports on operator edits (who and when) to locations and item information. | Highly Desirable |
| 5.11.3 | Reporting | The system should provide the ability to create a stack survey identifying where an item is located in the stacks. | Highly Desirable | |
| 1.2.0 | Application Integrations | |||
| 1.2.3 | Application Integrations | The solution must exchange data with the Library's repository services and digital content management tools. | Staff need the ability to exchange data with the Library’s suite of repository services and other digital storage systems so that they can view information about digital collections such as file location and size alongside other descriptive metadata and information about physical collections. In some cases staff may need to extract information from repository-generated payload listing files and locally stored descriptive metadata in order to enhance descriptive and administrative metadata. In other cases, staff may need to pull file format planning or processing history to support preservation planning. | Highly Desirable |
| 1.2.7 | Application Integrations | The system must exchange data with the Conservation Division tracking system. | This is separate from the current ILS. | Highly Desirable |
| 1.2.15 | Application Integrations | The system must exchange data with or replace the Library's workstation productivity applications. | Highly Desirable | |
| 1.2.16 | Application Integrations | Thesystem must exchange inventory, circulation and collection management information with the off-site storage inventory management system for high-density storafe via common APIs and exchange protocols. | This is separate from the current ILS. | Highly Desirable |
| 1.3.0 | Data Migration | |||
| 1.3.3 | Data Migration | The Contractor must migrate authorities data from sources outside the Voyager ILS to the new system in a manner that preserves hierarchies and linkages between the records. |
| Highly desirable | ||
| 1.3.4 | Data Migration | The Contractor must migrate conservation data from sources outside the Voyager ILS to the new system in a manner that preserves hierarchies and linkages between the records. |
| Desirable | ||
| 1.3.5 | Data Migration | The Contractor must migrate descriptive metadata from sources outside the Voyager ILS to the new system in a manner that preserves hierarchies and linkages between the records (including records in MODS, Dublin Core, and locally-defined XML schemas) |
| Highly desirable | |||||
| 1.4.0 | Workflow Support | ||||
| 1.4.3 | Workflow Support | Ability for Library staff to send custom or boilerplated messages, both to users within the system and to designated email addresses outside of the system (such as vendor contacts). Staff also need to be able to trigger automatic messages within a workflow such as reminders and alerts. | 1.1.3.1 What messaging features are available in the solution? | Highly Desirable | |
| 1.4.4 | Workflow Support | Ability to support the automation of recurring tasks and to minimize duplicative or manual work and paper-based workflows | In order to maximize accuracy, efficiency, and transparency while supporting processing and production at scale, the Library needs to automate wherever possible and minimize duplicative or manual work and paper-based workflows. | 1.2.2.1 How does the solution allow for scheduling and automation of tasks such as URL checking, gathering together bibliographic records for export, processing records for authority control, batch updating of holdings, etc.? | Highly Desirable |
| 1.4.6 | Workflow Support | Ability to create custom templates for generating business documents from Library data | The Library needs to be able to create custom templates for generating business documents from Library data (such as request for offer emails, reminders to suppliers regarding open claims, etc.). In most cases, staff will need to pick from a standard list of templates that have been approved by the Library’s Office of General Counsel, but authorized users should also have the ability to configure new templates | 1.2.3.1 What features exist for generating business documents from system data? | Highly Desirable |
| 1.4.7 | Workflow Support | Library ability to implement keyboard shortcuts, task-oriented macros, and keystroke recording for staff client automation in a web-based, multi-script environment | 1.2.4.1. Are such shortcuts and macros customizable by staff? | Highly Desirable | |
| 1.4.8 | Workflow Support | Support for full audit trail capabilities of all actions taken by user ID or by record (including deleted records) | The solution should provide full audit trail capability of all actions taken by user ID or by record (including deleted records), so that authorized staff can view all actions taken by a user or all actions performed upon a record. In some cases, authorized users should have the ability to roll back changes one or more steps to undo erroneous work. This especially true of acquisitions workflows where granular logs are essential to the audit trail and purchase orders, vendor records, and check-in records occasionally need to be restored after deletion. | 1.2.4.1 What functionality does the system offer for audit trails and rolling back changes? |
1.2.4.2 Are there any limitations to this functionality (e.g., the ability to cancel transactions, or workflows)?
| Highly Desirable | |||||
| 1.4.9 | Workflow Support | Support for granular logging to track collections materials throughout their lifecycle for preservation and legal purposes | Library staff need to be able to take advantage of granular logging to track collections materials throughout their lifecycle for both preservation purposes (e.g., how many times has an item been loaned for exhibit) and legal purposes (some acquisitions types are governed by legal obligations and the Library needs to be able to demonstrate compliance). | Highly Desirable | |
| 1.4.10 | Workflow Support | Library ability to create and save custom processing checklists, context sensitive help, decision trees, policy information, and help pages to guide staff users’ work within the system. | 1.3.1.1 What functionality does the system offer for "help features" within the system? | Highly Desirable | |
| 1.4.12 | Workflow | The system should have the ability to prioritize and assign/reassign collections, items and groups of items for processing, including date assigned and completed. Processing should include the ability to assign items to preservation workflows. | Highly Desirable | ||
| 1.4.13 | Workflow | When requested items are not located, staff need an automated way to: follow up and declare the item lost after a specific amount of time; complete an audit trail to demonstrate the actions that were taken to locate the item; and notify staff to attempt to replace the item, etc. | Highly Desirable | ||
| 1.5.0 | UX |
Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
2.0 Acquisitions
| Functional Area: | Acquisitions | |||||
| Unique | ||||||
| ID | Category | Requirement | Description | Questions | Priority | |
| 2.1.0 | Acquisitions Workflows | Acquisitions Workflows | ||||
| 2.1.7 | Acquisitions Workflows | The Library needs the ability to have a document repository directly linked to acq & bib records | Access should be role based with data partitioned. Data should be able to be directly linked to other documents. Currently documents are stored on shared drives and must be assembled manually for either response to management data calls or communication with vendors / donors / partners. LC will have to comply with upcoming NARA records mandate: NARA will no longer accept paper-based federal records as of Dec. 31 2021. Requirement is known as NARA’s M-19-21 mandate and NARA 2022 | Highly Desirable | ||
| 2.1.9 | Acquisitions Workflows | The system must provide a mobile interface for the Acquisitions module | OvOp staff will use LCAP for acquiring and cataloging materials, often via mobile device (for example, creating an acquisition record for a book on a mobile phone while standing at a bookseller’s stall). | Highly Desirable | ||
| 2.1.11 | Acquisitions Workflows | The Library needs the ability autogenerate acquisition related documents | While efficiency and ease of use is always a priority in acquisitions, this is especially important during the End of Year acquisitions period when accurate documentation must be generated quickly. The Library needs a system that can autogenerate documents based on the acquisitions stream, such as creating an email, attach business or legal guidelines. These related documents need to remain linked or co-located. | Highly Desirable | ||
| 2.1.13 | Acquisitions Workflows | The Library needs the ability to flag damaged items for replacement | The Library needs to be able to identify and flag items which are damaged in transit, or via irradiation at the screening stage so that replacements can be acquired | Highly Desirable | ||
| 2.2.0 | Vendors/Donors | Vendor and Donor Information | ||||
| 2.2.6 | Vendors/Donors | The Library needs the ability to associate vendor records with Library acquisition units | This is particularly important for exchange, gift, transfer and other non-purchase vendors | Highly Desirable | ||
| 2.2.7 | Vendors/Donors | The Library needs the ability to display a vendor's default payment and billing currency | The Library has some vendors that bill us in a foreign currency, but we pay them in US$ | Highly Desirable | ||
| 2.2.8 | Vendors/Donors | The Library needs the ability to have access to information on which institutions use specific vendors. | Needed to help Library select new vendors. | Desirable | ||
| 2.2.9 | Vendors/Donors | The Library needs the ability to impose vendor usage controls | The system should have ability to make certain types of vendor records unusable on specific types of POs or invoices. |
-PO type and vendor type should be consistent (Copyright, exchange, purchase) -should not be able to use non-purchase vendors on invoices
| -ABA staff should not be able to use the same vendors as the Copyright office | Highly Desirable | ||||
| 2.2.11 | Vendors/Donors | The Library needs the ability track communication with vendors and donors | Staff need a way to track communication with vendors so that they can retain important details about the history of collection, such as the negotiation process or accretion details. In some cases this may include images of collections materials or other supporting documentation, some of which may need to be restricted to authorized users. | Highly Desirable | |
| 2.3.0 | Acquisition Planning/Material Acquisition Request Service (MARS) | ||||
| Summary: | The Library supports a variety of types of acquisitions, including Proactive (LC seeks to acquire materials, e.g., gift, exchange, purchase, etc.), Reactive (An individual or an organization offers materials to LC, e.g., gift, exchange, purchase, etc.), Passive (Automatic submissions such as Copyright materials). Each of these methods requires planning and approvals which include the participation of multiple offices or divisions prior to the actual acquisition, all of which need to be tracked and retained for auditing and collection management purposes, even if the acquisition is not ultimately approved. | ||||
| 2.3.1 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to plan and prioritize future acquisitions | Authorized Library staff need a way to track and prioritize potential acquisitions so that when funding becomes available, they can move quickly while ensuring that the Library has the resources to store and process the newly acquired items. This is particularly important at the end of the financial year (EOY) when acquisitions must be made and executed quickly based on an existing request list. | Highly Desirable | |
| 2.3.3 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to plan for future rights and restrictions management | In many cases, the rights and restrictions associated with a given collection may change over time, as in the cases of an embargoed collection, or copyrighted materials that may enter the public domain on a specific date. Similarly, some deposit agreements stipulate that after a certain number of years, items on deposit become part of the Library’s collection. In these situations, staff need a way to assess potential future changes in rights and restrictions while planning for the acquisition, both so that these changes can be taken into account when evaluating the acquisition and so that they can create automated reminders to check on the status of collection rights and restrictions at the time of the anticipated change. Some collections may need to be restricted to specific locations only, e.g. CRS | Highly Desirable | |
| 2.3.7 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to notify interested parties of the status of an acquisition throughout the workflow. | Recommending officers need to be notified when a requested item is available. Often other interested parties, such as other recommending officers who endorsed the purchase or divisions impacted by the purchase will need to receive this information as well. | Highly Desirable | |
| 2.3.8 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to create and maintain case files associated with the acquisitions process | Staff need the ability to track administrative details of pre-acquisitions, including site visits, pre-sorts, non-selects, etc. | Highly Desirable | |
| 2.4.0 | Financial Transactions | ||||
| Summary: | Order and invoice data needs to be stored in relationship to bibliographic and item data, including, but not limited to, linking an order record to multiple bibliographic records and to supporting documentation. | ||||
| 2.4.3 | Financial Transactions | The Library needs to ability to automate the updating of currency module rates. | The system should have the capability to update the currency module in real time. | Highly Desirable | |
| 2.4.5 | Financial Transactions | The Library needs the ability to communicate the status of payments and credits. | The system should keep both staff and vendors updated on the status of their invoices or disbursements and clearly record how credits are applied to specific invoices so that both staff and vendors can see this information/cost adjustment to paid invoices. Preferable to have details available from LCAP / 2 part notification - Momentum flags details to be sent from LCAP | Highly Desirable | |
| 2.4.10 | Financial Transactions | The Library needs the ability to attach acquisition-related documents to LCAP records | The system should have ability to attach acquisition-related documents toLCAP records such as vendor invoices, authorizations, agreements, title lists, emails and other communications in order to eliminate paper files and comply with Record Management standards. Some documents would be one-time specific to a given PO, invoice, etc.; others would be standard documents to attach to all out going POs, e.g. Business Guidelines. | Highly Desirable | |
| 2.4.11 | Financial Transactions | The Library needs the ability for direct ordering from vendor websites | The system should allow direct ordering to vendor websites whereby vendor directly receives order information from the LSP. For example IPP.gov functionality /batch loads/APIs to vendor sites. Vendor as well as bibliographic data should also be able to populate LSP. Security steps are needed so that no order can be filled without proper approval/authorization. | Highly Desirable | |
| 2.4.17 | Financial Transactions | The Library needs the ability to report cost data at a granular level for identified types of material | The Library needs the ability to identify heritage assets and other high value/special items and collections, etc. so that granular cost reports can be produced for senior management. Note this is not a requirement for a cost accounting system. | Highly Desirable | |
| 2.5.0 | End of Year Spending | End of Year Spending | |||
| 2.5.3 | End of Year Spending | The Library needs the ability to put a hold restriction on fund balances so that specific amounts can only be used for specific purposes &/or obligated by specific users | Authorized Library staff need the ability to put a hold on funds pending use for a specific item, especially during end of year spending, when many transactions will be processed simultaneously. For example, gift and trust funds are often liquidated and loaded into the LSP only upon a fund manager's approval for a specific item(s). These funds should NOT be able to be used for other, non-specified, items on a first-come-first-served basis. | Highly Desirable | |
| 2.5.4 | End of Year Spending | The Library needs the ability to streamline and automate the Request for Offer workflow | Currently the Request for Offer workflow is largely manual and time consuming which is problematic during the End of Year purchase period, when transactions must be processed quickly and accurately. LC staff need a system that can autogenerate an offer from bibliographic records and pending purchase order data; send offer to vendor with return response form; autogenerate and send Library acknowledgement / acceptance / agreement terms. | Desirable | |
| 2.6.0 | Continuations/Subscriptions | Continuations and Subscriptions | |||
| Summary: | Subscriptions and other continuations present unique challenges for acquisitions because the Library is restricted in how it can spend money across financial year boundaries | ||||
| 2.6.3 | Continuations/Subscriptions | The Library needs the ability to accurately associate check-in records with bibliographic records | Staff need to be able to see bib record in the check-in screen to verify that they are checking in the issue to the correct record. In order to ensure accuracy, the Library needs to be able to set up warnings when staff attempt to check in an issue against a title that is no longer active or an active title for which intermediate issues are missing. Warning correlation to Holdings data, second date in 008 field. | Highly Desirable | |
| 2.6.7 | Continuations/Subscriptions | The Library needs the ability to create predictve publication patterns | Predictive, complex patterns are currently used by LC and are needed in LCAP if full implementation of the MARC holdings standards is NOT part of the new sysytem. Predictive check-in must be smart - able to be associated with bib/holdings data, e.g. flag 310/fixed field frequency changes, 008 dates, etc. that would help determine an end to predictive issues. | Highly Desirable | |
| 2.6.8 | Continuations/Subscriptions | The Library needs the ability to retain the publication patterns used in OCLC records | Efficient use of publication patterns requires the ability to import/retain existing patterns from outside systems. | Highly Desirable | |
| 2.6.11 | Continuations/Subscriptions | The Library needs the ability to automate the renewal process | The system needs to prompt for renewal of continuing orders, memberships, etc. and restrictions on cancellation/renewal, etc. The system should report on whether there are any dependencies, e.g. membership to a society, in order to receive a journal. | Highly Desirable | |
| 2.7.0 | Non-Purchase Acquisitions | Non-Purchase Acquisitions | |||
| Summary: | In FY21, the Library acquired 516,764 items via purchase (25 percent of the total acquired), and 1,586,859 items via non-purchase (75 percent of the total acquired). Of those non-purchase items, 34,552 were acquired from exchange partners, 72,128 were transferred from government agencies (federal, state and local), 864,560 came as gifts, 100,345 were received through the Cataloging-In-Publication Program, and 515,274 came in via copyright deposit. Additionally, some material was not counted on an item by item level, but in the aggregate, such a manuscript collections. The Library needs a system that can support the acquisition of material via non-purchase workflows, hybrid purchase/non-purchase workflows, and for managing the distribution of material to exchange partners. | ||||
| 2.7.2 | Non-Purchase Acquisitions | The Library needs the ability to interact with Copyright Deposit workflows and systems | At this time, the extent to which the Copyright Office's eCO system will be integrated with the LCAP has not been determined. "The eCO Steering Committee (eSC) is tasked with ensuring that IT systems development efforts for the eCO system align with the business and strategic objectives established by the Copyright Office as a whole, while facilitating the operations of all the business units dependent on the system." "Through publisher education and enforcement of mandatory copyright deposit, the Copyright Acquisitions Division (CAD) acts for the US Copyright Office as an essential intermediary between the Library of Congress and sources of creative works. CAD diligently secures, selects and transfers required materials to the Library for its collections to help preserve the nation’s cultural heritage and support its creative future." LCAP may need to import the current status of receipt of a work that has been registered in the eCO system, and export metadata for later use in eCO. | Highly Desirable | |
| 2.7.3 | Non-Purchase Acquisitions | The Library needs the ability to support Exchange agreements with partner institutions | Every year the Library acquires a significant of number items via exchange agreements with other institutions, the majority of which are serials. The Library must be able to identify missing issues of non-purchase serials and claim them on a title-by-title basis. LCAP needs to be able to identify missing serial issues and flag inactive serial titles. Production of automatic email notifications directly for partner institutions or for Library staff to forward to partner institutions is desirable. | Highly Desirable | |
| 2.7.4 | Non-Purchase Acquisitions | The Library needs the ability to autogenerate email notifications | Production of automatic email notifications for partner institutions or for Library staff to forward to partner institutions is desirable for serial claims, missing/damaged issues, inactivity, etc. | Highly Desirable | |
| 2.7.5 | Non-Purchase Acquisitions | The Library needs the ability to track and report on exchange statistics | Currently an MS Access database for recording non-purchase statistics has been in use since 2001 to credit exchange partners for material received and selected for the Library's collection. Statistics are entered by designated users from each unit on a quarterly basis, after which error reports are run and distributed for corrections. Prior to input, most units record the amount of material that they receive by format on tally sheets after the material is selected. A partner’s annual quota is based on the Library of Congress receipts from the partner during the previous fiscal year and takes into account the exchange of serials, monographs and materials in other formats. LCAP needs to support crediting exchange partners for the full range of material received from them. | Desirable | |
| 2.7.7 | Non-Purchase Acquisitions | The Library needs the ability to efficiently support gift acquisition workflows | Currently, the management of gifts is done by using an Excel spreadsheet. Statistics are based on manually collected curatorial area reports.The Library needs a systematic approach to prioritize gifts, manage the documentation associated with each, report the status of the acquisitions process to Recommending Officers and other staff, and protect confidential information associated with the process. Integration with the Library's Development Office is needed (currently using Raiser's Edge). | Highly Desirable | |
| 2.8.0 | Licensing/Agreements/Contracts | Licensing, Agreements, and Contracts | |||
| 2.8.3 | Licensing/Agreements/Contracts | The Library needs the ability to report on license, agreement, contract data | Management regularly issues data calls that can not be met efficiently or quickly. Reporting parameters should include statistical data in specific time spans, material format, acquisition method, specific terms, ability to track conversions (deposit), etc. LC currently has to track via spreadsheets that are not widely available or able to be maintained efficiently. | Highly Desirable | |
| 2.8.4 | Licensing/Agreements/Contracts | The Library needs the ability to effectively manage license agreements and terms of use | Effective management of license information and the clear communication of terms of use are essential to efficient collection management. This is particularly true at the Library of Congress, where patron access is currently restricted to on-campus use only, methods of access may change over time and it is often possible to access the same content through different streams, each associated with different rights and terms of use. In order to better manage subscriptions and ensure that patrons can access content over time, the Library will need granular support for management of and reporting on licenses and terms of use. | Highly Desirable | |
| 2.8.5 | Licensing/Agreements/Contracts | The Library needs the ability to efficiently manage e-resource licenses and terms of use | Staff would like to be able to generate terms of use directly from a license, including applying terms of use from an aggregate such as an e-resource package or a collection to the individual items in that package or collection while still being able to edit individual terms of use for specific items within the aggregate. | Highly Desirable | |
| 2.8.6 | Licensing/Agreements/Contracts | The Library needs the ability to efficiently search licenses and terms of use | License and terms of use data should be indexed and searchable, with the ability to link and correlate to other documents and records. | Desirable | |
| 2.8.7 | Licensing/Agreements/Contracts | The Library needs the ability to reuse and clearly display license and terms of use data in other related systems and applications | License and terms of use data need to be exposed for reuse in other systems, such as a discovery layer. Exposure is complicated based on what the discovery layer will be, etc. Terms of use do not necessarily need to be eye-readable to patron or staff, but could be invoked via data conditions/flags. Staff need to be able to know what they can serve and how to patrons; this need will grow over time, especially if LC allows for off-site access to our resources. | Desirable | |
| 2.9.0 | Rights Management Metadata | Rights Management Metadata | |||
| 2.9.2 | Rights Management Metadata | The Library needs the ability to automatically serve content based on access rights metadata | The Library would like LCAP to store access rights metadata and expose it to the Library's digital content access systems in a manner that allows those systems to permit the correct level of access to users. | Highly Desirable | |
| 2.9.3 | Rights Management Metadata | The Library needs the ability to record use restrictions status milestones | The Library needs a way to record and report on restrictions status milestones such as the end of embargo or expected date in public domain so that staff can follow up on status of rights and restrictions. | Highly Desirable | |
| 2.9.4 | Rights Management Metadata | The Library needs the ability to flag use restrictions milestones | The system should be able to flag upcoming restriction use milestones so that staff can take any needed action | Highly Desirable | |
| 2.9.5 | Rights Management Metadata | The Library needs the ability to integrate Copyright data into the LSP | Staff need the ability to exchange data with Copyright so that they can view copyright status (expired, in force, date of expiration) and current rights holder as well as registration and renewal information including claimant, registration number, date of publication, etc. alongside bibliographic and holdings information in order to inform processing and digitization prioritization. Staff also need to be able to record notes about copyright information locally. | Desirable | |
| 2.9.6 | Rights Management Metadata | The Library needs the ability to provide a limited public view of Copyright data | A public view with more restictive access is also needed; other libraries using other systems would benefit from ability to export Copyright metadata. This should incorporate a cost recovery flag. | Desirable |
Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
3.0 Bibliographic Control
| Functional Area: | Bibliographic Control & Cataloging | |||||
| Unique | ||||||
| ID | Category | Requirement | Description | Questions | Priority | |
| 3.1.0 | Standards and Schemas | |||||
| Summary: | The cataloging data prepared by the Library represents several different descriptive standards, and the structural schemas vary as well. For the MARC records in the ILS, bibliographic records represent cataloging standards adopted over a century, from early LC and ALA rules, to the AACR family of standards, and records following Resource Description & Access for books, serials, cartographic materials, and music scores cataloged since 2013. Special collection cataloging areas may follow other descriptive standards, such as the suite of Descriptive Cataloging for Rare Materials (DCRM) standards, the Archival Moving Image Manual (AMIM), Describing Archives, a Content Standard (DACS), etc. We need a system that continues to allow the integration of bibliographic data from such various content standards. Regardless of the standards used for description, the Library attempts to keep access point fields in MARC records synchronized with authority records (NACO records for names and titles, LCSH authority records for LCSH subject access points), although it is understood that there are many bibliographic records with access points that don’t correspond to authority records for various reasons. We also have many records with subject access points representing thesauri and subject systems other than LSCH, some developed and maintained locally at LC and others that come into the catalog from other sources. LC also creates metadata representing finding aids following the Encoded Archival Description standard, MODS records for a significant number of resources (typically e-content), locally defined non-MARC schemas, etc. These non-MARC records are not represented in the current ILS, which allows only MARC records. It is expected that the Library will need the ability to create metadata in the format most appropriate for the collections being described. To that end, the Library is developing and testing the BIBFRAME standard, and it expects that a future solution will include the tools to create, index, maintain, and perform access point control/identity management in a BIBFRAME and MARC environment. | |||||
| 3.1.2 | Standards/Schemas | The system must support the management of metadata in whatever structure or schema is most appropriate for the collections being described, including locally defined schemas | In addition to MARC21, the Library currently supports MODS, Dublin Core, EAD and localized XML-based structures in a number of databases to describe collections. Examples of localized schemas include http://memory.loc.gov/ammem/legacy_xml/collection.xsd and | |||
| https://memory.loc.gov/ammem/legacy_xml/document.xsd | 3.1.2.1 How does the solution accommodate multiple XML based structures and schemas including, but not limited to, MARC21, EAD, MODS, PBCore, EBUCore, VRACore, Dublin Core, and BIBFRAME? | |||||
| 3.1.2.2 Are there plans for incorporating future containers, alternative vocabularies and cataloging description methods? | Highly Desirable | |||||
| 3.1.3 | Standards/Schemas | To support the ability to flexibly map and transform metadata from one format to another, the system must provide tools to manage transformations and mappings | Library staff need to be able to define and save crosswalks for import, export, and validation of metadata. Staff will need the ability to develop mappings on the fly, save mappings for future use, share mappings with other staff, and use existing mappings developed elsewhere. | 3.1.3.1 What functionality does your system offers to meet these needs, including any conversion tools or utilities that will translate from one metadata schema to another? | Highly Desirable | |
| 3.2.0 | Granularity/Relationships | |||||
| Summary: | In order to effectively manage and provide access to its collections, the Library needs the ability to create, manage, and display complex relationships between entities in a way that can be logically represented. | |||||
| 3.2.1 | Granularity/Relationships | To meet the Library's growing need to create and a manage metadata for subcomponents of a given title (such as articles in a journal, chapters in a book, issues of a newspaper, maps in an atlas or set, or tracks on an album), the system must allow for the easy establishment and robust functionality of subcomponents, hierarchies, and networked relationships | Currently most of LC’s bibliographic description is focused on the title level; however, the Library has a significant number of records for items in collections or subcollections (e.g., a single photograph in a pictorial collection) that need to be related. Relationships can include hierarchies (items in a collection, titles in an aggregator package, components in an EAD finding aid) as well as networks or clusters (earlier and later titles, variants of works or expressions, different formats, different derivatives, different language versions, related titles). In some cases, staff may will need to associate a single work to multiple items, or multiple works to a single item, e.g., “bound withs” or multiple tracks on a single disc. Staff also need the ability to create or update records based on these relationships, such as items level records inheriting rights and restrictions information from the collection record, creating reciprocal linking, or enhancing a record with data from related records. | 3.2.1.1 What tools does your system offer to support metadata for subcomponents that expresses necessary relationships between parents, children, and siblings? | ||
| 3.2.3.1 How does the system support the creation, management, and representation of complex relationships? | Highly Desirable | |||||
| 3.3.0 | Linked Open Data | |||||
| Summary: | While the Library is committed to making its data available in the MARC standard, it is also committed exploring ways that creating, distributing, leveraging linked open data could bring new value and efficiencies to its metadata offerings, including support for the BIBFRAME standard. | |||||
| 3.3.1 | Linked Open Data | The vendor will have a well-developed Linked Data Strategy | Describe your long-term strategy for leveraging linked open data and semantic web technology in your application now and in the future both for staff who manage metadata and users of the collections. | |||
| 3.3.1.1 How does your strategy align with the conformance levels that are outlined in the Appendix document “BIBFRAME expectations for ILS vendors”? | Highly Desirable | |||||
| 3.3.2 | Linked Open Data | The vendor will be able to demonstrate linked data functionality. | Describe current and planned support for linked open data within your application and how it brings efficiencies and value not available in traditional library metadata workflows. |
3.3.2.1 How will your linked data application interface with existing MARC-based services like OCLC?
| 3.3.2.2 Will system functionality differ for MARC-based data when compared to linked data? | Highly Desirable | ||||
| 3.3.5 | Linked Open Data | The system will have a set of linked data tools, covering the data work from linked data creation/conversion/storage to linked data indexing and publication. | Highly Desirable | ||
| 3.3.6 | Linked Open Data | Multiple ontologies, local or external, will be supported. | Describe how the system will interact with ontologies that are locally maintained or hosted versus those that are externally maintained or hosted. |
3.3.6.1 What ontologies do you plan to support?
3.3.6.2 Do you intend to create and maintain a separate system-specific ontology, or use extensions to existing ontologies?
| 3.3.6.3 What are some examples of system-specific properties or classes that you would create? | Highly Desirable | ||||
| 3.3.7 | Linked Open Data | External contributions/knowledge graphs will be supported, including the system can grab entities from external knowledge graph to be used by LC and the system can turn MARC into knowledge graph entities. | 3.3.7.1 How does the system take advantage of the knowledge graph by allowing contributions from outside LC? | ||
| 3.3.7.2 How will traditional MARC records relate to knowledge graphs? | Desirable | ||||
| 3.3.8 | Linked Open Data | It will be possible to establish the provenance of linked data. The system will be able to get the level of provenance of the linked data that LC would need/request (graph level provenance, resource level provenance, etc.) | 3.3.8.1 What functionality does the system offer to track the provenance from outside contributors and ensure data quality? | ||
| 3.3.8.2 Is it possible to have preferred sources/contributors for specific data elements? | Desirable | ||||
| 3.3.9 | Linked Open Data | The system can provide/adjust/develop semantic web tech. support for LC's metadata processing and retrieval based on LC's workflow and user needs, such as user friendly SPARQL query. | Desirable | ||
| 3.4.0 | Cataloging | ||||
| Summary: | The creation of MARC bibliographic, authority, and classification records is a critical activity for the Library of Congress in order to support the Library’s collections as well as to provide cataloging to the nation’s 122,000 public, school, academic and research libraries and other institutions around the world that rely on the Library’s bibliographic and authority data. In a typical year, the Library adds between 300,000- 400,000 bibliographic records to the current MARC-based ILS. About 150,000 -200,000 records represent original cataloging, but the Library also uses “copy cataloging” to supplement original cataloging, typically using Z39.50 clients to access a limited number of sources for cataloging copy. We also receive, pre-process, and load records from vendors of library materials and other partners that range from minimal “in process” records to full “shelf ready” cataloging (around 75,000 records per year). Bibliographic data is also generated from spreadsheets provided by vendors converted to MARC21. The Cataloging in Publication program maintains a Pre-Publication Book Link system that takes information from publishers to generate bibliographic records that are then loaded to the catalog (50,000-60,000 titles processed each year). The cataloging operations are distributed among several divisions on the Washington, D.C. campus, but cataloging data is also created by offices in Culpeper, Virginia and six field offices around the world (Jakarta, New Delhi, Cairo, Nairobi, Islamabad, New Delhi, and Rio de Janeiro). The catalog records represent published and un-published resources in any format, in hundreds of languages, and using several non-Latin scripts. Some of the bibliographic data created by the Library is not exposed to the public discovery layer, typically because the resource was a) not acquired by the Library and b) this decision needs to be retained for auditing or efficient processing of unsolicited receipts. The Library’s ERM application currently holds 1.9 million bibliographic records, most supplied from a vendor, but some locally created records as well. The Library expects the annual growth volumes to increase as data from legacy systems at “end of life” is added, and metadata available for digital deposit increases. Due to the high volume of cataloging production, the Library seeks a cataloging environment rich in features to maximize the efficiency of data creation and maintenance. The Library currently makes available a number of “helper” applications to assist with pre-processing, importing, validating, and transliterating non-Latin scripts. Note that some business needs applicable to cataloging are discussed in the Global section of this document (e.g., bulk record changes, imports, exports). | ||||
| 3.4.3 | Cataloging | The Library should be able to specify the fields/data elements used in a cloned record (e.g., block the cloning of an ISBN, LCCN, or other identifier that would not be appropriate to the new record such as a new edition of a work) | Highly Desirable | ||
| 3.4.4 | Cataloging | The system should allow the use of various helper tools such as shortcuts, hotkeys, function keys, macros, stored strings, character/diacritic combinations, type-aheads, dropdown lists, or other mechanisms for the efficient and accurate recording of data with limited keyboard activity. | 3.4.4.1 Does the system have a built-in macro creation tool or macro creation function to create and manage macros by user and/or across all users? |
3.4.4.2 Is the system compatible with macro creation tools like Macro Express?
3.4.4.3 Are the macro tools Unicode compliant?
3.4.4.4 Is it possible to have shared and individual macros?
3.4.4.5 If cataloging interface is web-based, how does the solution support keystrokes or other shortcuts?
3.4.4.6. Can the Library specify the elements appropriate for dropdowns?
| 3.4.4.7 Can the Library specify the source of the dropdown content (e.g., specifying a vocabulary in id.loc.gov, the RDA vocabularies, or local vocabularies)? | Highly Desirable | |||||
| 3.4.5 | Cataloging | Staff should have the ability to configure personalized home screens. | Describe options for personalizing the cataloging interface with frequently used tasks, templates, and languages or character sets, font and background colors, etc., to make cataloging more efficient. | Desirable | ||
| 3.4.6 | Cataloging | The system should support alternate methods for data input such as the ability to add data via scanning, voice recognition, or other methods that reduce keystrokes. | Desirable | |||
| 3.4.8 | Cataloging | The system should have spell checking functionality | Staff need multi-lingual, user-customizable spell check capabilities in all data input modules. Staff also need to be easily able to toggle autocorrect on and off. | 3.4.8.1 Does the solution support spell checker functions? |
3.4.8.2 Can the dictionary be maintained locally?
3.4.8.3 Can spell check dictionaries be customized by each user and/or workstation?
| 3.4.8.4 Can spell check and/or multiple dictionaries be easily toggled on and off at the workstation level (for staff working in several languages and scripts)? | Desirable | |||||
| 3.4.9 | Cataloging | The system should support the verification of URLs recorded in individual records while catalogers are working in the editor to assure that it refers to an active page. | Highly Desirable | |||
| 3.4.10 | Cataloging | The metadata editor should integrate context-sensitive tools and guidance that are easily linked to, such as MARC formats, RDA Toolkit, RDA registry, id.loc.gov when creating or editing metadata. | Desirable | |||
| 3.4.11 | Cataloging | The system should have robust functionality related to "change history" | Given a sometimes complex workflow from the time of original record creation, completion, and subsequent updates and deletions, the system should provide a log to show who made changes to data, whether individually or in bulk. | Highly Desirable | ||
| 3.4.12 | Cataloging | The system should allow for authorized users to 'roll back' an edit to a record to an earlier stored version. | 3.4.12.1 At what levels can the 'roll back' be initiated (e.g., individual user, work unit, globally)? | Desirable | ||
| 3.4.15 | Cataloging | The system should incorporate MARC Library of Congress Classification records to assist catalogers in the selection of appropriate classification numbers within the cataloging tool. | Low | |||
| 3.5.0 | Third Party Metadata & Automated Metadata Generation | |||||
| Summary: | The Library needs to be able to take advantage of existing metadata for digital collections content in whatever form it is available so that we can efficiently improve intellectual control of our digital collections. This could mean harvesting metadata from digital files, leveraging metadata from associated files, incorporating metadata from third party systems to create new records or enhance existing records, and incorporate data from sources such as DBpedia, Wikidata, etc. | |||||
| 3.5.1 | Third Party Metadata & Automated Metadata Generation | The system will have the ability to harvest and use metadata embedded in digital files. | The Library needs the ability to harvest embedded metadata from digital files such as IPTC data, locations (GIS data, GPS data logs), BWF headers, and restrictions on use (e.g., copyright statements, Creative Commons Licenses, PLUS registry numbers) so that they can be incorporated into descriptive metadata. Similarly, the Library needs to be able to exploit all of the descriptive metadata stored in the structure of a digital file (such as article-level metadata stored within an e-journal) so that it can provide a better discovery experience to users. | Highly Desirable |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .