What is an Asset Library?
An asset library is a centralized, searchable collection of media files and associated metadata, versions, permissions, and relationships. It supports governed storage, discovery, and reuse.
How Asset Libraries work
An asset library combines binary storage with indexed records that describe ownership, rights, renditions, versions, and relationships. Search and filtering run against those records, and in some repositories against the full text of documents, while access controls determine who may view or change each item. Unlike a simple shared folder, where a file is referenced by its path, a library can treat one logical asset as a series of versions with alternative renditions such as previews. In a publishing workflow it becomes the governed source from which approved media is selected and delivered.
Key facts
- Store the library’s immutable asset ID in your own records, not a path or display name, and check what that ID identifies. In the CMIS repository standard each version is a separate object with its own object ID, and only the version series ID stays the same across versions, so a reference must either follow the latest version or pin one exact version.
- An immutable ID does not by itself keep delivery URLs stable. Cloudinary, for example, assigns an immutable asset ID that cannot be used to deliver an asset; its delivery URLs contain the public ID, which changes when the asset is renamed. Before publishing URLs, confirm which identifier they embed and what a rename or move does to them.
- Matching cryptographic checksums computed over whole files, such as SHA-256, identify byte-identical files with very high probability, regardless of filename. A resized or re-encoded copy has different bytes, so a checksum will not flag it; finding it takes a similarity comparison such as perceptual hashing, where similar files produce close rather than equal values and you decide how close counts as a duplicate. Do not assume the library checks for you, or that a storage ETag can stand in for a checksum: Adobe Experience Manager 6.5 ships with its SHA-1 duplicate detection disabled, and an Amazon S3 ETag is not an MD5 digest for multipart uploads or for objects encrypted with SSE-C or SSE-KMS.
- Rights metadata records restrictions; it does not enforce them. In the IPTC Photo Metadata Standard, Rights Usage Terms is free text and embargoes are noted in the free-text Instructions field, so neither is a date that software can compare. If delivery must respect an embargo or a license expiry, hold it as a structured date or status, in the library’s asset record or in your own database, and check it when publishing; being able to find a file is not permission to publish it. A check at publication does not cover an expiry that falls later: if the right to keep serving an asset ends on a date, also arrange to stop delivering it then, for example by unpublishing it on schedule or by checking the date on each request.
When Asset Libraries matter
Applications use an asset library when teams must find and reuse approved media without creating duplicates. Permissions and version controls help prevent obsolete or restricted files from being published.
How Transloadit helps with Asset Libraries
Transloadit Storage, currently in beta, covers the storage, identity, and versioning part of an asset library. The /transloadit/store Robot stores Assembly files privately and returns an asset_id, a version_id, and the final path. The /transloadit/import Robot then selects a file by path (its current, mutable location), by asset_id (the current version, even after a rename or move), or by asset_id with version_id (those exact stored bytes). The /file/hash Robot computes a checksum during an Assembly and exposes it as file.meta.hash. Your application compares those hashes to find duplicates and builds the catalog, search, and permissions around what Transloadit returns.
Save the stored result’s workspace, asset_id, version_id, and returned path with your own application record, as the Robot documentation advises: imports read from your Workspace’s storage, and IDs remain subject to Workspace access and version retention. Storing to an occupied path fails by default; the overwrite conflict strategy creates a new version of the existing asset instead. A pinned version_id never falls back to the current version, and deleting the asset or removing that retained version makes the reference unavailable.
Sources
- OASIS CMIS 1.1: object IDs, version series, renditions, access control, and query
- Cloudinary documentation: the difference between an asset ID and a public ID
- Adobe Experience Manager 6.5: enable detection of duplicate assets
- Amazon S3 API reference: when an object’s ETag is not an MD5 digest
- NIST FIPS 180-4: Secure Hash Standard
- pHash: what a perceptual hash is
- IPTC Photo Metadata Standard: Rights Usage Terms and Instructions
- Adobe Experience Manager as a Cloud Service: asset expiration and on-time and off-time delivery windows