Metadata that Moves Content

In the early days of Digital Asset Management, it was common for people to define metadata as “data about data.” And while this definition remains true at its core, it’s not complete. This article shows how metadata can be used to manage content development pipelines and facilitate user communications within those pipelines.

Metadata as a Verb

When you tag a picture of a flower as “pretty” or “yellow” or any other adjectival attribute, you describe content. Some refer to these types of values as descriptive metadata.

But what path did that flower take to become all those adjectives?

During the development pipeline, digital content moves between people and stages. What might start out in the hands of a photographer, becomes the retouch responsibility of a digital artist, the approval of an art director, and the selection of a layout artist. What’s more, at each stage of the process, an asset might be assigned a new status, such as “In Edit” or “Approved.”

We can think of these terms as “action metadata.” Granted, one could argue that these verb-like status attributes also describe content, but there is a subtle distinction: Descriptive metadata largely stays the same throughout the content lifecycle, while action metadata might change regularly.

More important than that, action metadata describe important attributes that are not all reflective of the content within the digital asset. In other words, while it’s unlikely that a photo of a flower and a video of a crime scene will share the same descriptive metadata values, it’s not unlikely that they would share the same “action metadata” values.

Context-based Metadata Classification

For these reasons (and others), it’s better to think of metadata fields in groups or classes that are based on the context and purpose for each value. In other words, don’t define a single, monolithic metadata schema that must be used across your entire asset collection. A one-size-fits-all approach to metadata schema design results in a DAM that is either overly complex (too many fields) or not detailed enough to adequately describe the content therein.

Just as a car has a mileage and interior color, and a human has an age and eye color, individual assets need metadata schemas and values that accurately describe them. Though you could use the same Age and Color fields for both types of objects, the meaning of the values in those fields would not be clear to users. What does “Color” apply to when the subject is a human? And what does “Age” have to do with the distance a car has been driven?

The trick is that you don’t want to end up with too many metadata fields appearing on each asset. You want only what you need to describe the asset, and not a single field more than that. Picturepark uses Adaptive Metadata technology to ensure that each digital asset has only the metadata fields you intend it to have.

Temporary Metadata Field Sets via Adaptive Metadata

In most cases, the shelf life of action metadata is limited. For example, an asset wouldn’t be “In Approval” forever.

DAM users have traditionally changed an asset’s status by updating a metadata field configured for this purpose. This enables users to see the asset’s new status, but it doesn’t provide any of the additional information that would be required to act on the status change.

When you think about it, virtually all status changes come with considerations that must be factored into whatever action is taken.

Consider the status change: “I’m hungry.” Taken on its own, this bit of information doesn’t provide much to go on. Unless we make some decisions about what comes next, we’re going to remain hungry indefinitely.

The “action” information we would need to act on this new “hunger” status would include:

• “What am I hungry for?”
• “How soon would I like to eat?”
• “Would I like to cook or go to a restaurant?”

Considering this “status” in the context of all the supporting information you’d need to take action, it becomes clear that a simple metadata change isn’t enough. Defining this status even deeper would be dietary restrictions, a budget for food, the time of day, and many other considerations.

When it comes to satisfying our own appetites, we subconsciously answer all these questions without thinking about it. But as soon as another person is involved, the questions arise. And when it comes to DAM, there’s always someone else who needs to be shown the information that you might take for granted.

Picturepark’s Adaptive Metadata enables you to proactively provide answers to these status- or lifecycle-based updates. When a Picturepark asset is “In Approval,” for example, new metadata fields can appear to handle the management of this lifecycle stage.

Example fields that would be useful for an asset “In Approval” include:

• Approver (Who is conducting the approval?)
• Expected by (By when is the approval expected?)
• Usage Restrictions (Can the content be used for any purpose before it’s approved? Maybe internal projects only?)

Lifecycle-specific metadata fields like these can provide a rich depiction of an asset’s status for a period of time. But, just as the asset’s status will change, the value of having these fields will change.

Other DAMs rely on field-level permissions changes (if available) to hide outdated fields from users. For example, when the asset leaves the “In Approval” stage, the asset’s permissions are changed by an administrator so that those fields no longer appear to users. The problem is that it’s cumbersome to manage this for what could be thousands of assets changing status per day. Worse, permissions changes can have unintended consequences that are difficult to predict and track.

Picturepark makes this easier by enabling permitted users to simply remove the “In Approval” status that provided the fields.

By adding the In Approval tag (right), new fields appear that can be used to manage the approval and communicate status. When no longer needed, the tag and the fields it provides can be removed by removing the In Approval tag.

This is an example of how Adaptive Metadata works to provide temporary metadata fields when they are needed, and remove them again when they provide no further use.

Taking this example further, once the approval does come in, an “Approved” tag/class could provide new metadata fields for:

• Approver (Who authorized the approval?)
• Date of Approval (When was the approval granted?)
• Scope of Approval (For what use is the content approved?)
• Usage Restrictions (What limitations and requirements are placed on use of the content?)

Note that the fields Approver Name and Usage Restrictions are used in both of these classes. And while both make sense in the context of their use, the information they provide is significantly different.

In the first example, Approver describes the person conducting the approval. In the second example, the field is used to name the person who authorized the ultimate approval. In some cases, this might be the same person, but not always. For example, the first “Approver” might be someone who reports to the “Approver” who has the authority to release an asset.

The difference in Usage Restrictions is important too. In the first case, the field is used to describe any permitted use of the content before the approval comes in. In the second example, Usage Restrictions describes any final restrictions placed on the approved content.

When the final approval comes in, the “Approved For Use” tag can be added, which provides the fields needed for the approval authority information. (Left) Now that the “In Approval” fields are no longer needed, that tag can be removed. (Right) Note that the Usage Restrictions and Approver are different for each status.

Because Picturepark provides fields within the context of the classes that are configured to provide them, field names can be reused as needed. Each field is unique, so the value from one Approver field won’t inadvertently end up in any other field with the same name. This is particularly beneficial when controlled vocabularies are assigned to the fields.

For example, the first use of Approver might be connected to a vocabulary for Editors, while the second use is connected to a vocabulary for Managers. This ensures that only acceptable values will ever be available in each field.

Usage context also ensures that correct vocabulary terms are visible, even for fields that share names. In this image, you can see that even though there are two Approver fields, they are each distinct, with its own controlled vocabulary of user names.

When considered together, the use of a single name for multiple fields seems confusing. But keep in mind, these two fields would rarely been seen at the same time—once the approval comes in, the “In Approval” tag and fields would be removed. Alternatively, trying to come up with unique field names to describe each field would likely be more confusing to users. Users don’t care about the policy that governs an approval; they just want to know what’s approved for use.

Other examples of where temporary field sets can be valuable include:

• Error flagging — Fields appear that enable the reporter to indicate what’s wrong and, alternately, what needs to be done and even to whom the asset should be reported.
• Campaign information — New fields can be used to describe an asset’s use in a given campaign. The fields can be added or removed at any time. Best of all, they will be seen on only those assets used within the campaign.
• Distribution channel details — Most DAMs offer a single field for captions, but Picturepark enables you to have different captions for Web CMS display, use in a PIM or any other special use case you have. Instead of having to create additional fields called, “Caption (Web)” or “Caption PIM,” you can use the most obvious name, Caption, for all use cases.

By tagging this image “eBook DAM Survival Guide,” we get fields for eBooks that contain default values for this piece of content (title and URL). The “Advertising” tag provides us with fields that make it easy to choose a campaign, and describe the channel used. The “Partner Share Target” field appears because partners were included in the audience. The value in this field determines where in the Picturepark Partner Portal the asset will be appear to partners.

Hidden Advantages of Metadata Layering

In addition to enabling you to provide and remove metadata fields as needed, Adaptive Metadata makes it easier for you to manage granular, field-level permissions. (Field permissions describe the ability to hide/show or make editable to a user specific metadata fields. Some DAMs don’t offer this capability, but all Picturepark systems do.)

Each class configured to provide new fields is typically designed in accordance with some policy that dictates how content moves through the digital asset development pipeline. This offers you some perspective on when fields will and won’t appear. This, in turn, enables you to more easily determine who should be able to see and optionally edit the values.

For example, you’ll know that no field associated with the “In Approval” class should ever be available publicly. So, when configuring field-level permissions, you’ll be able to quickly set permissions for many fields at once, without having to imagine all situations in which each field should be accessible to users.