A version is defined as a particular form or variant of something. In the case of Digital Asset Management (DAM), versions apply to digital assets and their respective metadata. Versioning can involve updating, editing or changing assets and/or metadata safely. A version often involves a correction or an improvement by editing.
Versions are not variations nor renditions
Be careful not to mix up the concept of versions vs. variations vs. renditions.
Versions in a DAM are important to maintain control over edits. We should be able to have full control of versions and accountability of the version history so we can save/restore older versions if an error is made. Older versions can remain available as needed.
There is rarely one true “final” asset, but rather multiple assets with variations, depending on the use or situation, which may be used in different places. It is highly possible to have different versions of the same asset. We may also need different renditions of an asset which may have different file types (different file extensions) of similar content.
A version is not a child asset either. If we want to start talking about parent-child relationships between assets, that will be another rabbit hole we can tumble down in the future.
No version control needed here?
Don’t think you need version control nor version history in a DAM? Then you must not make any mistakes nor does anyone else. Ever. Good for you! Some of us wish we could live in your world.
Now back to reality…
When we start accumulating assets for projects, we are bound to have corrections.
Without version control or version history, changes are more permanent (like an overwrite) which can yield more work if the last change (or changes) were an error. Without version control, there is no going back even if we need to. There is little record as to what was done to reach this point without version history. The lack of version control does not help job security either. At some point, a version will be selected and it may be the latest version.
If we do not have/use version control in the DAM, we are left with few options to add a new version by overwriting an existing asset, by deleting an asset or by uploading the asset again as a new asset. These are bad ideas either way.Why?
First, these are very poor workflows with near term repercussions. These are also archaic options.
Second, if we overwrite asset on top of asset, we are bound by failure on top of failure with no recourse except for more failure (and it still equals fail).
If we have version history without full version control, that is simply having the ability to watch disasters after they happen, but yet again have no ability to fix them.
If we upload a new asset followed by uploading more edits of this asset (as separate, new assets) with a occasional “final edited” new asset upload, we are creating digital dump ground of more incorrect assets and this will likely confuse most users on which happens to be the correct asset to use, since there is no version history nor version control.
Referencing backups are possible, but how often are backups done and which backup is relevant to your need?
No ‘single source of truth’ can exist without proper version control in the long term. That goes for brand consistency or any consistency as well.
Metadata versions for assets
There are plenty of reasons to edit an asset, but what about the respective metadata of that asset? Whether the metadata is embedded or associated, version control may still be needed. There are DAM systems with full version control for assets and metadata, even down to a single character change within the metadata. You either have full version control or you do not have full control of versions for assets and metadata. Test the DAM and see for yourself.
When selecting a DAM system…
When reviewing DAM systems for the one that best suits your business needs, be sure to check:
- Can the DAM support version control?
- How does the DAM handle version control and to what degree?
- How does the DAM display version history to users?
- How does the DAM represent versions?
- How does the DAM handle an asset version?
- How does the DAM handle a metadata version? (yes, metadata sometimes needs to change even if the asset does not)
- How can DAM users see the version history of an asset and/or its metadata?
- If the DAM can handle both asset versions and metadata versions, are these handled as one version jointly or separately?
- Can we edit the metadata of an asset to only version the metadata (a credit for example)? Or does a version affect the asset and metadata combined? Which is edited more often?
- By testing with common assets and metadata, which need full version control?
- What happens to UIDs when versions occur in the DAM?
- Can the version in the DAM be handled in a programmatic way or by human users (one asset at a time) only? Yes, versioning can sometimes be automated, but can the DAM handle this automation? Or is that handled manually?
October 3, 2012 at 10:47 AM
I always seem to get the same questions about asset versions, derivatives and relationships. I have generally banned the term “version” from workflow discussions with users. In our DAM, that handles versions correctly, the system assigns version information to assets that have been “revised” by the user. A revision can be a correction or an update but it is not a derivative asset or a rendition. People revise, the system versions.
It took me a long time to understand how this worked in our DAM (OpenText) and it wasn’t until I used all the version attributes (I think we had 3 or 4 distinct ID) during an integration with a CMS that is made sense to me.I generally recommend collecting a core set of use cases and testing the system’s version tracking against those use cases. The simple use case “do I want to always use the most current asset version or the current version at a specific point in time?” will tell you volumes about how capable a DAM is.
I can’t think of a media workflow where versions aren’t important. I used to think curators didn’t need versions but I no longer believe that to be true. A DAM without version control is really just a repository.