Classifying metadata values along a “content lifecycle” timeline is an interesting exercise that can make your DAM easier to use and maintain. Applying the categories Historical, Current and Future, you’ll find that each metadata value describes something related to the content’s origin or history, its current state or its future use.
The most immediate benefits that come from this metadata categorization are:
- It’s easier to ensure all required metadata (and nothing more) have been considered
- It’s easier to wrap a meaningful per-field rights model around your metadata fields, which enables you to better govern who can edit and see each value.
Applying the Metadata Timeline
Think of your metadata values as each falling somewhere on a timeline, with Historical values on the left, Current values in the middle and Future values on the right. This visual exercise enables you to spot any holes in your metadata schema, and it also illustrates where your timeline might be overstuffed with values that are redundant or beyond your needs. (Rule of thumb: If you can’t imagine ever searching for or reporting on a given metadata value, chances are you don’t need it.)
Below are examples of some common metadata values and where they fit along the metadata timeline.
Digital cameras can capture a suite of metadata that are part of the EXIF metadata standard. Among these values are date and time, camera model, shutter speed and other values that describe the state of the camera in use at the moment the photo was taken. Other content types come with their own set of Historical metadata values, such the date of an audio recording, the frame rate of a video capture or the author of a document.
Values like these mark the beginning of the content’s Historical metadata timeline and they must be protected to ensure their validity. In fact, it’s good policy to configure your DAM so that Historical metadata values cannot be casually (or erroneously) edited by users. This is an important distinction between Historical and Current metadata values.
In addition to the “carved in digital stone” metadata that should remain unchanged throughout the lifecycle of your content, you’ll periodically add values to Historical metadata to reflect the content’s lifecycle journey. Examples include:
- Licenses -- To whom was the content licensed, and when
- Modifications -- When were updates performed, and where are those older versions
- Approvals -- Who granted approvals and when were they granted
- Distributions -- Where was the content shared or sent, and when
As with the content’s original Historical values, these values should be changed only in the case of error. And those changes should always be in accordance with official DAM policy, which might include reviews, audits and journal entries outside the DAM itself.
Current metadata values describe the state of the content right now. Here you find your descriptive tags, production statuses, ownership, etc.
We think of Current metadata values as being subject to change as the content evolves, but it’s not uncommon for some Current metadata, such as the subject of a photo, to remain unchanged throughout the content’s lifecycle. Though it’s tempting to think of these static Current values as being Historical, it’s a good idea to keep them in your Current classification for one reason: they sometimes do change.
For example, no matter what happens to a photo after it’s taken, the shoot date will never change. This makes “Shoot Date” a perfect candidate for Historical classification. But the subject of a photo can change. A photo captioned as the “2002 Dancing Dolphins Kayaking Club” might one day become, “Forth-sixth President of the United States, Nancy Reynolds, with fellow kayakers.”
All metadata values that affect or shape the content’s future are, not surprisingly, Future metadata. This is where you’d classify rights permissions, usage restrictions, target audiences and other such values that collectively influence future use of the content.
Values like “Expiration Date” or “Next-review Date” could be thought of as Future metadata, but because they do not contain perpetually future values (like a usage restriction), you might want to classify them as Current metadata.
Depending on your business and how you use your content, you might have few or no Future metadata fields. But don’t just lump any Future values you do need in with Current values, because you’re likely going to treat them very differently when it comes to user rights management.
Rights Management Made Easier
The metadata timeline can also make rights management and user permissions easier to imagine and manage because it organizes metadata in a way that nicely aligns with how many organizations define their user roles and, by extension, their rights management.
Let’s examine a few common roles to see this in effect.
The people responsible for adding content to your DAM obviously need permission to add new content to the system and, perhaps, edit some default values. You might also entrust these folks to verify and, if necessary, edit any EXIF values captured by the DAM.
But these are not necessarily the same individuals who will be making content edits, creating new versions, or determine the production status or distribution rights.
Metadata editors and designers
Working somewhere in the middle of the metadata timeline are those who tag your content and use it in production. These roles require edit-access to existing records, and they need to be able to create new versions.
Legal and Management
Decisions about the future use of content are often made by those who had nothing to do with the creation or perfection of that content. These are the managers that decide when content is ready for distribution, and they are the legal professionals that draft the usage restrictions that govern what happens to the content once it leaves your direct control.
These individuals probably don’t need write-access to the Current metadata that describes the content, and there’s probably no good reason for them to be able to edit Historical values either.
Metadata Organization and Presentation
The metadata timeline also makes it easier to know which fields to group together on your DAM forms and layouts. Not only does this make things easier to understand for users, it can simplify your system management too. For example, if you decide you need a new field to track licensees of your content, you must define:
- What should the field be called?
- What field type should be used?
- On which layouts should that field appear?
- Who should have read-access?
- Who should have write-access?
If your system was metadata-timeline based, your directive to your DAM administrator could be as simple as:
Please add a Historical metadata text field called “Licensees.” “Future metadata” roles should have read-only access, and “Historical metadata” roles should have read-write access. The field should appear on all “Historical metadata” forms.
This sure beats having to list every layout or form on which the field should appear, and it greatly decreases any chance of breaching your policies by inadvertently granting access to someone who shouldn’t have it.
File-specific metadata (file creation date, name modification date, location, size, etc.) fits well onto the metadata timeline too. As you might guess, File Creation Date would be Historical while File Name, Size and Location would be Current. Absent in file metadata are Future metadata values, because these all come from you or your policy.
Try It Yourself
If you’re a visual person, you might want to create a left-to-right timeline and place your existing metadata values along that timeline where they fit best. Alternatively, you could categorize your existing metadata in a spreadsheet, with Historical, Current and Future column headings.
You might find that you’ve already done a great job of covering all the bases. But you might find that you’ve been so focused on different ways to tag your kids’ photos as “adorable” that you’ve completely forgotten about leaving notes for the sitter that explain what they should eat for dinner, what time they should go to bed, and at what number you can be reached to extend these rights.
Image courtesy of karen roach (Shutterstock)
Editor's Note: Interested in more of David's thoughts on digital asset management? Read Digital Asset Management's Missing Context of Discussion