“Sticky” Metadata Templates in Picturepark

Using templates that apply metadata en masse saves time and helps ensure metadata consistency. Picturepark metadata templates go a step further by retaining connections to their assigned assets so that updates made to template values can be instantly propagated across the system.

Picturepark Metadata Template Advantages

Picturepark metadata templates offer a few important advantages over the templates used in other DAM systems, including hierarchical structuring and “sticky” assignments, which means that when the templates are updated, all previously assigned assets can be updated automatically.

Template hierarchy

Picturepark metadata templates can be hierarchical, which means that value assignments can be nested.

For example, say you have a series of templates that provide default values for client projects. Let’s say that for each client project, you want to track the following:

  • Client Name
  • Client Contact
  • Account Representative

To make this easy, you’d create a new template that provided these field values:

  • Client Name: Divasera Enterprises
  • Client Contact: Stan Richmond (sr@divasera.com)
  • Account Representative: Hugo Martinez (x912)

When this template is assigned to an asset, those values are added to their corresponding fields. This is how metadata templates work in other DAM systems, too.

Picturepark’s template hierarchy makes it possible to nest templates within templates, so that when a child template is applied, the values of parent templates are applied too.

Let’s take that Divasera Enterprises example further and say you manage product-related projects for each client. For each product line, you track the following values:

  • Product Family
  • Product Manager

In Picturepark, the structure of these templates might look like this:

The advantage of this is that when you apply the “Outdoor Living” or “House and Home” templates to a set of assets, those assets also receive the values provided by the “Divasera Enterprises” metadata template.

In a single template assignment, you’ve added all the metadata you need.

Note that Picturepark template groups can be configured as “exclusive,” which means that you could prevent an asset from being assigned both the “Outdoor Living” and “House and Home” templates, if it made sense to do so.

No data redundancy

Using hierarchical templates helps you avoid the need to create multiple templates that contain redundant data. For example, without being able to create a template hierarchy, you would have to build the following templates:

  • Divasera Enterprises (used for client assets not associated with a product)
  • Divasera Enterprises – Outdoor Living (used for assets associated with this product family; contains duplicate values from Divasera Enterprises template)
  • Divasera Enterprises – House and Home (used for assets associated with this product family; contains duplicate values from Divasera Enterprises template)

The problem with this approach is that when the values for the Divasera Enterprises template must be updated, those same changes must be made to the two product templates too.

Though this example is simple, many real-world scenarios have hundreds of such templates. Keeping all those values in sync would not only be time consuming, it would be a process prone to metadata errors that would be difficult to catch and correct.

One-stop metadata updates

Unique to Picturepark is that metadata templates “remember” the assets to which they have been assigned. This enables you to update a template metadata value and have all previously assigned assets updated instantly, without any searching, bulk edits or other user actions.

At the most basic level, this means you can, for example, update your copyright notice in one place, knowing that new value will be instantly propagated to all previously assigned assets. There’s no guesswork to figure out which assets should be update—it’s all done automatically.

This benefit is especially important for metadata values that are embedded into assets shared or made available for download. Picturepark doesn’t embed metadata values into assets until the asset is requested by the user or workflow. So, by updating a single metadata value in a single template, you can instantly correct metadata errors or provide updated information in the very next download request.

Thinking more broadly about this capability, you could elect to have virtually all asset metadata provided by templates. Carefully structured metadata schemas can be represented by default metadata values that you might find suitable to provide 90% or more of the required metadata values for any given asset. Attributes like copyright, photographer name and contact info, department owner, audience, distribution rights and limitations, and more can all be represented by default metadata values. With only a few unstructured fields, such as a caption or notes, you can have a complete, well rounded metadata profile for every asset.

Creating and assigning metadata templates

You create metadata templates in Picturepark using the tree. The first step works exactly as it does when you create a new category. Like categories, templates can be moved to new locations in the tree, renamed and deleted by permitted users.

Right-click on any item in the Picturepark tree to create a new item. Once created, the item can be moved elsewhere in the tree, if needed.

Once a template is created, you choose the metadata fields it should affect and then provide any default values you want assigned.

This images shows the “Release” template, which is assigned to any assets approved for release. Default values are provided for the metadata field that determines the regions for which the asset is approved. These values can be changed for each assigned asset, if needed.

There is nothing more you need to do when constructing template hierarchies: Picturepark knows to assign “parent” values when child templates are assigned.

You assign a template to a selection of assets by dragging those assets onto the template in the tree.

Metadata Template Value Overrides

If a metadata template value that has been assigned to an asset needs to change just for that asset (or a subset of assets to which the template has been assigned), users can edit the value on the asset record, just like they would any other metadata value. Even after a metadata template value has been overwritten by a user, Picturepark remembers the templates that have been assigned to the asset. This enables permitted users to “reset” any metadata template values changed by users.

What’s nice about the way this works is that users can see which assets have user-edited values. This helps ensure that user edits that should not be reset are left alone.

Picturepark shows when any assets previously assigned to a template have had the template’s default values edited. This image shows that 1 asset has a diverging value in the Date of Approval field. The edited value can be seen and overwritten, if needed.

Metadata Fields Added if Needed

Picturepark Adaptive Metadata means that not all assets within a single Picturepark system are required to have the same metadata schema. In fact, the point to Adaptive Metadata is that each asset have a metadata schema that makes sense for it.

Fortunately, Picturepark metadata templates can provide any missing metadata fields when they are assigned. For example, if an assigned template provides a default value for the metadata field “Product Family,” and that metadata field isn’t available on the assigned asset, it will be added automatically. This ensures that the application of a metadata template yields the result users expect.

Metadata Templates vs. Category Assignments

Rather than use metadata templates to add specific field values, such as a client name or contact information, you could also build a category structure that is used for the same purpose. In other words, you would have categories for each value and assign each asset to each of those categories. This is the standard “solution” one would employ in a DAM that didn’t offer metadata templates.

The limitations of this approach include:

  • Standardized application of metadata — It’s difficult to ensure that each asset has been added to all applicable categories. Users would have to be trained on when each should be assigned. They would then have to remember to make those assignments.
  • Category tree complexity — When using categories in place of metadata field values, you might have to build a category tree that includes thousands (or more) categories. This can be difficult to manage, and it would make mobile access far less convenient.
  • Embedded metadata values — Metadata values that are applied directly to metadata fields can be written back (embedded) into assets that leave the DAM. Though category assignments can also be embedded by some DAMs (including Picturepark), those values are all assigned to a single “categories” field in the asset’s XMP metadata structure. This means you lose context with regard to the meaning of each value, and “round-tripping” is virtually impossible.

Metadata Templates vs. Picturepark Classes

Those familiar with Picturepark already know about classes, which are the building blocks of Adaptive Metadata. In fact, a Picturepark metadata template is nothing more than a class. When a given class provides metadata fields in addition to default values, this is effectively Adaptive Metadata schemas in action.