XMP and the DAM
Purpose
A DAM uses Metadata to describe its Assets, so if an existing standard is available that stores metadata in files, then perhaps there is a way that a DAM can utilize that data. A current standard for metadata in files is the Extensible Metadata Platform (XMP) which is defined as, “an ISO standard, originally created by Adobe Systems Inc., for the creation, processing and interchange of standardized and custom metadata for digital documents and data sets.”, Wikipedia. This means XMP is a framework for storing metadata about files, similar to how a Digital Asset Management (DAM) System stores metadata about Assets. To explore a relationship between XMP and the DAM one must first understand more about the XMP Structure then look at how the DAM can utilize that structure for Document Identification and Relationships. Finally, a brief examination of the User interaction points between the DAM and XMP Data in files will be presented.
XMP Structure
XMP uses a hierarchy based structure that groups Metadata Fields into Namespaces. The Namespaces represent different data storage users/actions associated with the data taken by XMP compatible Applications. Namespaces are also linked to other data storage standards like IPTC, EXIF, Dublin Core and even the application ACDSee. The XMP Standard encourages re-use of existing metadata fields, but it is possible for Namespaces to contain metadata fields of the same name.
A larger list of Namespaces currently defined for XMP can be viewed here, http://www.adobe.com/devnet/xmp.html, however XMP also allows for Custom Namespaces to be created as-needed, however, this practice is not encouraged due to decreased re-use and accessibility.
In the case of the XMP Media Management Namespace there are other specialty fields that also provide a Unique Identifier for the document. The overall XMP Standard defines how these identifiers are used in the Partners Guide to XMP for Dynamic Media. This includes how the DocumentID is generated and applied to the files as they are accessed, edited, saved, exported, etc. within an XMP compliant piece of software like the Adobe Creative Suite applications.
Document Identification and XMP Relationships
Since the XMP Standard defines the usage and process around the Namespace, this allows consumers of the XMP data to have confidence in the accuracy of the data. Accuracy is important, especially for Document Identification which is equally vital to Asset tracking within the DAM. Also keep in mind that in most workflows it is critical to know if the File imported is or is not a duplicate. XMP can assist with this using 3 specific metadata fields from the XMP Media Management Namespace:
A visual representation of the Identifier process within an XMP compatible application (PhotoShop) can be seen here:
The results of the above action provide 2 files that are directly related to each other within the XMP data. Even if the users don’t retain or remember the relationship on their own, it is preserved in the data. The XMP data will clearly show that the second file is a derivative of the first file by containing the same OriginalDocumentID (ODID).
As illustrated in Figure 2 the XMP data also has an Ingredients List and a Pantry consisting of even more data values about the contents/linked files. These combined with the ODID value can provide more complete information that represents several familial relationships between the files. These can then be represented in a DAM as Asset Relationships.
Since all of these different relationships can be populated using XMP Data, users don’t have to remember how assets are related. This allows the DAM to present a richer history and more complete story for a specific asset. Users can travel from one Asset to its Parent, and then to that Asset’s Parent traversing the full history and life-cycle of an Asset.
DAM Interaction with XMP Data
Now that it is more clear on how XMP stores and provides additional data, we are now able to discuss how a DAM can access and utilize that data. A DAM’s use is to store metadata describing assets. Meanwhile, users are expected to manually enter and create the metadata that will be stored in the DAM. But what if the DAM extracted items from the already existing XMP Data?
An important part of Process 2 is that the DAM creates a COPY of the XMP structure. This copy should be searchable by the users. This way users can search not only the DAM metadata, but also the Assets File based XMP data too.
In addition, specific XMP Data fields can be copied directly into the existing DAM Metadata structure by mapping specific XMP Metadata Fields to DAM Metadata Fields.
Once in the DAM, Metadata (the copied XMP information) can be updated directly using existing Metadata Edit processes. However, this data relationship should not only be a One-Way relationship — copying XMP Data into the DAM Metadata — but rather a Two-Way relationship where on Export, the DAM Metadata values are written back into the file’s XMP Data. This way the downloaded/exported file reflects any metadata changes made in the DAM.
This safety net is in place so if the file travels to another system the metadata entered in the DAM is not lost. Finally if changes are made to the XMP Data outside of the DAM an update operation can occur if a new version is imported back into the DAM.
One vital piece of the update process pertains to how the user should have the opportunity approve the metadata changes.
For example: Say the file was updated by an external vendor, making changes to the Creator not be desired in the DAM. If the external vendor was able to add additional information, such as a Rights Usage Description, that information can be added to the DAM.
This user approval process of XMP Metadata Changes assists in preventing data loss and verifying the XMP Data from the File is kept in sync within the DAM. The approval process also enforces that the DAM is the source of truth for metadata. Consequently, any files the user Downloads/Exports from the DAM will also have their XMP Data values overwritten with the approved DAM Metadata values.