Working with metadata in Assets Server

From a system administrator's point of view, working with metadata (in general and within the context of Assets Server) can become quite complex quite quickly, with many different standards, options and settings to be aware of.

This article provides a high-level overview of working with metadata in Assets Server. Use the links to find out more detailed information about each subject.

Core file versus working files

In Assets Server, definitions for metadata fields are stored in various files which are combined into new files at the moment Assets Server is started.

The main concept is as follows:

1. All standard metadata fields in Assets Server are stored within the system in a central file.
2. Any changes to these standard fields as well as definitions of custom fields are made in a separate configuration file.

This way, the central file is always left intact, thereby making it possible to revert to a default configuration in case any configuration errors are made.

When Assets Server is started for the very first time, the central file and the configuration file are combined into a new file.

A duplicate of this file is made and this file is now seen as the 'base' file containing the correct settings.

When Assets Server is started a following time, the central file and the configuration file are again combined in a new file, thereby overwriting the original 'new' file.

This time the new file is compared against the duplicate file from the previous start-up so that any changes can be detected and validated.

When the validation fails, the original duplicate file is retained and errors are logged in the log file.

When the validation passes, the original duplicate file is overwritten to act as the new base file.

This process is shown in the following diagram:

See also:

• Changing the default metadata field options in Assets Server
• Creating a custom metadata field in Assets Server

XML standards

Various industry standards exist for storing metadata values. This means that values of the same type are not always stored in the same fields for each file.

Example: In one standard 'tags' are stored in the 'Keywords' field while in other standards 'tags' are stored in the 'Subject' field.

When a file is imported in Assets Server, some metadata values may be moved to a more generic metadata field in Assets Server (such as the 'tags' field for values from the 'Keywords' and 'Subject' example above). When the file is exported from Assets Server, the values are put back in their original field according to the standard that is used in the file.

See Working with embedded metadata in Assets Server.

Availability to assets

Metadata fields can be made available to all files within Assets Server or can be restricted to specific files only. This is done by making the metadata field part of a particular level within a hierarchical structure.

This structure is referred to as the 'Asset Type Base' structure and is shown below.

Example: To only make a metadata field available to audio files, make it part of 'AudioFields'. Because of its place in the hierarchy, an audio file will also have access to all metadata fields that are defined in all levels above it in the structure (from 'RootSystemFields' to 'ImageAndVideoFields'). Any fields that are defined in 'VideoFields' and 'FlashFields' are not accessible for audio files.

For an explanation of this structure, see Controlling metadata field availability in Assets Server.

Understanding the XML structure

Info: Some basic knowledge of XML is required.

Metadata in Assets Server is organized in XML format with the following tree structure:

<fullAssetsInfo>

   <assetsInfo>
   ... //settings for default metadata fields
   </assetsInfo>  
   
  <assetsInfoExt>
	
		<fieldGroups>
		... //group definitions
		</fieldGroups>
		
		<assets>
		... //custom metadata fields
		</assets>
	    
		<fieldExtensions>
		... //extensions to default metadata fields
		</fieldExtensions>
   
   </assetsInfoExt>
   
</fullAssetsInfo>

This structure can be viewed in the full_assetinfo.xml file (location Assets Server location/Elvis Hot Data/elvis-data/assetInfo).

This file is generated during the start-up of Assets Server and combines the settings of the central file with that of the configuration file (see Core file versus working files).

Default settings

The settings for the default fields are defined at the start of the file between the <assetsInfo></assetsInfo> tags.

Extended settings

Any settings for non-standard fields are defined between the <assetsInfoExt></assetsInfoExt> tags, where 'Ext' stands for 'Extention'.

This section contains 3 sub-sections:

1. Groups are defined in the <fieldGroups> section. (See Groups below)
2. Custom metadata fields are defined in the <assets> section
3. Changes to default metadata fields are defined in the <fieldExtensions> section

For more information, see The metadata structure of Assets Server.

Groups

In Assets Server, related metadata fields are combined into groups. This way, related fields can be quickly found and easily worked on.

Figure: Related metadata fields are displayed in groups, as seen here in the dialog box for choosing the metadata fields to display in the Metadata panel of Assets.

For an overview of all groups and their fields, see Metadata field information for Assets Server.

A metadata field always needs to be part of a group. This can be an existing group or a custom group.

Changing the group to which a default Assets Server metadata field belongs can be done by overruling the group option for that metadata field.

Metadata when importing files

When files are imported, their metadata is added to the Assets Server search index.

During the import process, metadata that is specific to Assets Server is also added (such as the ID of the file in Assets Server).

Embedding

For a typical metadata field, the values are stored in the search index and only optionally in the file itself.

Embedding metadata slows down the processing and thereby negatively affects performance.

When overruling default metadata field options, you can control whether or not the metadata should be embedded.

For custom fields the values are always embedded.

Exporting

When exporting a file from Assets Server (for example by downloading the original file), the metadata values are placed in the fields according to the XML standard used in that file.

Example: When the values were extracted during the import from the 'Keywords' field and placed in the 'tags' field in Assets Server, all values from the 'tags' field are placed in the 'Keywords' field.

Note: For custom metadata fields it is not possible to define to which standard the values should be exported which is one main reason why not to use custom metadata fields and use existing fields instead (and rename them).

Searchable and non-searchable fields

Some metadata fields store data that should not automatically appear in the search results. These fields can be configured in such a way that their values are excluded from the search results. It can still be made possible to search for the values by directly referencing that field.

Example: The default metadata field that stores the folder path (folderPath) is typically not a field of which its value should appear in a general search result. However, users should still be able to search on the field when they want to.

Editing metadata

Of course, metadata can also be edited in Assets Server. Users who have been given sufficient access rights to edit metadata can do so by using any of the client applications such as Assets.

Metadata and checked-out files

When a file is checked-out by a user, it should not be possible for other users to make changes to the content of that file.

This rule does not apply to the metadata of the checked-out file: it is still possible to edit the metadata by using Assets while the file is checked-out.

When the checked-out file is checked-in again, any changes to the metadata of the file that were made by other users while the file was checked-out are kept; any changes to the metadata of the file that were made by the user who checked-out the file are lost.

Metadata values on check-in

Info: This feature requires Assets Server 6.107 or higher.

When users of Assets 6.107 and higher check in a checked-out file or when they replace a file, they are presented with one of the following options:

• Replace metadata
• Keep original metadata

When the 'Keep original metadata' option is chosen, the metadata values of the original file are left intact and not replaced by the metadata values of the file that is checked in.

In certain circumstances though, it could be necessary to replace specific metadata values of the original file with values from the file that is checked in (such as the copyright information of the file that is checked in).

For these scenarios, the 'keepOnCheckIn' option for that metadata field can be set to 'false' in the custom-assetinfo.xml file.

This way, the metadata value for that field in the original file is replaced by the metadata value of the file that is checked in, even though the user has chosen the 'Keep original metadata' option.

For more information, see Controlling metadata values when checking in or replacing a file in Assets Server.

Making metadata required

Some metadata fields store information that is important or even vital to track, such as copyright information. For such fields, users should at least be made aware of the field or even be required to enter that information.

This awareness or requirement can be configured in Assets Server for files that are imported or for files that already exist in Assets Server:

• For files that are imported, users can be notified or required to add metadata
• For files that already exist, users can be notified to add metadata

For more information, see Required metadata in Assets Server.

Highlighting metadata fields by using icons

When the user's attention needs to be drawn to specific metadata, an icon (also referred to as a 'flag') can be added as a visual indicator (a process also known as 'flagging').

Example: You may want to visually display a status or indicate that a field contains specific information such as copyright info.

Such icons appear above thumbnails in the search results and can be set for any standard metadata field or custom metadata field.

Figure: Files in Assets showing icons for the Status, Approval and Copyright fields.

See Highlighting metadata in Assets Server by using icons.

Custom metadata fields

In case none of the provided metadata fields fit the kind of data that you want to store, a custom metadata field can be created.

See Custom metadata in Assets Server.

Using pre-defined values (taxonomies)

When a value is added to a metadata field it is important that this value is correctly entered. This is preferably done by all users using a generally used term and the correct spelling. When this is not (consistently) done the chance exists that the file is not included in the search results when users search for the file (using these general terms and correct spelling).

To streamline this process, a metadata field in Assets Server can be set up to use a 'taxonomy list' from which the user can choose a predefined value to use.

This saves the user from having to enter the term manually and thereby ensures consistent input.

See Using taxonomy values to populate metadata fields in Elvis 6.

Renaming

The name of a metadata field that is shown in the user interface of a client — such as the Metadata panel in Assets — can be replaced by a custom name.

You would do this to:

• Use a default metadata field under a name that more fits your needs and requirements (a recommended alternative to using a custom metadata field).
• Localize a label of a metadata field in another language.
• Provide users with a more user friendly name for a custom metadata field (which always starts with 'cf_' and cannot contain spaces or special characters).

For more information, see Renaming a metadata field in Assets Server.

Viewing metadata field descriptions

To see a description of each metadata field, use the Select Fields window for adding fields to the Metadata panel in Assets.

Creating a metadata report

At some point, it may be needed to create an overview of all the metadata fields and their values (if any) of particular files. This can be done by creating a Metadata report. This will create a report in .csv format which can be further worked on as for instance a spreadsheet.

For more information, see Creating a metadata report in Assets Server.

Synchronizing file variations

Info: This feature requires Assets Server 6.52 or higher.

One of the ways of creating a file is by making a copy of an existing file (either directly in Assets or via the integration with Studio).

This creates an exact copy of the original file, including the metadata field values.

When a copied file is updated by changing the values of its metadata fields, it may be that these changes also need to be made in the original file and all other copies of it. Think of metadata fields containing important context or legal information such as the description, tags, copyright details, usage rights information, and so on.

The process of synchronizing metadata fields across file variations can be automated: when a field is updated for a file of which variations exist, the value of this field is automatically updated for all these file variations.

For more information, see Synchronizing metadata across file variations in Assets Server.