Content Alignment between Providers and Ex Libris Knowledgebase
- Last updated
- Save as PDF
Manifest - Ensuring Content Alignment Between Providers and Ex Libris
The Manifest is a file, maintained by the provider, which holds comprehensive record of all collections that the provider offers.
The Manifest file serves as a crucial component for maintaining data integrity and consistency between Ex Libris Knowledgebase and external providers. It acts as a comprehensive inventory of all supported collections within the provider's ecosystem, enabling Ex Libris to effectively track and manage changes in the provider's collection offerings. This file, maintained and updated by the provider, is regularly uploaded to an FTP/MFT server, prompting Ex Libris to compare the latest version against the existing collections in Ex Libris Knowledgebase. Through this comparison process, any discrepancies between the Manifest file and the actual content provided by the provider are identified and flagged for further investigation.
This proactive approach ensures that Ex Libris Knowledgebase are always aligned with the provider's latest collection offerings, preventing potential gaps or inconsistencies in data availability. The Manifest file's unique format streamlines data exchange and simplifies the process of identifying discrepancies, safeguarding the integrity of Ex Libris's Knowledgebase.
The list of collections within the Manifest file is only used in order to identify discrepancies, it will not serve as the actual ingest of new collections into Ex Libris Knowledgebase.
How to Deliver a Manifest
To ensure that mutual customers can find the collections they need within Ex Libris Knowledgebase, multiple providers already furnish Ex Libris with a Manifest file. This file serves as a comprehensive index of all supported collections.
To successfully ingest the Manifest file, Ex Libris has established a set of minimum requirements:
- Download the Manifest file template: Manifest Template_March_2024.xlsx
- Populate the Manifest file: Each row in the Manifest file represents a collection. Fill in the columns for each collection as described in the Manifest Template Structure table below.
- Mandatory fields: Two mandatory fields must be populated for every collection:
- providerCollectionName - The name of the collection as offered to mutual customers by provider
- providerCollectionId - The ID of the collection as recognized at the provider system
Populating the remaining columns in the Manifest file with additional information can significantly enhance the ability to locate discrepancies.
- First time only: Contact Ex Libris Provider Relations team at: Provider.Relations@exlibrisgroup.com to coordinate whether the Manifest file will be placed on Ex Libris servers or the Provider's servers.
- Ongoing: Update the Manifest file whenever a collection is added/removed from your catalog and load it to the server.
- Ex Libris will query the server on a daily basis in order to see if a new Manifest file was loaded.
Manifest Template Structure
The table below provides a detailed explanation of each column in the Manifest template file:
Column # / Mandatory? | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Column name | CollectionName | CollectionID | CollectionURL | CollectionType | FileName | FileLocation | DateAdded | DateFileUpdated | RecordCount | UpdateFrequency | LinkingSupported | CollectionDescription | PreviousCollectionName | FreelyAccessible | Notes | ExlibrisCollectionType | ServiceType | ContentType | DataFormat | CharacterSet | DateAddedToPlatform | CollectionStatus | Perpetual | FullOverwrite | FileUrlOrSftpSite | DirectoryPath | exlibrisCollectionName | exlibrisCollectionID |
Column explanation | The name of the collection as identified by the provider in their system | The ID of the collection as recognized by the provider internal system - this ID must be unique and should not repeat in other | AKA "Level URL" - the URL used to access the content of collection as seen by the end user |
Possible values which are under the NISO standard:
|
The name of the KBART list file |
This path is relevant for the followinf 3 use cases:
|
On what date was this collection first included in the Manifest file? This should be formatted in the following format: YYYY-MM-DD |
Date of the most recent update to the collection's title list file |
Number of titles within the collection |
Possible values:
In case the above values do not match the update frequency, please add a custom value |
AKA "Linking Level"
|
Up to 255 characters |
This column should be populated in cases where the collection name has changed. THe column should include the name which the collection had preior to the newly given name |
|
Free text. General note, this will not be reflected to users. |
Possible values which are supported by Ex Libris:
|
Possible values which are supported by Ex Libris:
|
Possible values which are supported by Ex Libris:
|
Possible values which are supported by Ex Libris:
This is relevant only for the collection level - MARC feeds are not part of the expected information. |
UTF8 (This is the value ExLibris works with) |
When was the collection added to the provider platform? This should be formatted in the following format: YYYY-MM-DD |
|
Does the collection contain perpetual items?
|
AKA as "negative load"
When updating a collection in the KB and we see that there are less titles in the KBART file, from the past load. If marked as yes, the missing titles will be deleted. If selected as No, the titles which do not appear in the new feed will be preserved |
File location where the KBART title list of the collection can be found This path is relevant for the following 3 use cases:
|
In which directory is the file located?
|
Leave Blank For Ex Libris internal purposes |
Leave Blank For Ex Libris internal purposes |