Page Comparison

The Digital Asset Management setup require specific setup steps in addition to a standard Wedia project setup :

• Setting up the Asset Waiting Area

• Setting up the Asset Cart

• Setting up the Video Transcoder

• Setting up Thesaurii

In the following subsection, you will go through a deep understanding of these subjects.

What is it?

A DAM is a location where binary resources are stored.

A DAM must:

• be able to feed

• be annotated

• be able to be classified

• be able to store binaries

• provide research tools

A DAM could but should not have WXM properties: language, media, mediagroup, etc

One or more DAMs in an application

There is no rule or limit. An application can contain as much DAM objects as it needs.

• In some projects there could be several technical DAMs:

  • one containing the videos

  • one containing the images

  • …​

• In others there could be a big DAM with everything inside.

• In others there may be several functional DAMs:

  • one containing public documents

  • one containing private documents for marketing purposes

  • one containing private documents for management

  • …​

Basis of a DAM object

A DAM object in the engine is therefore a standard object with two elements mandatory:

• a damobject tag at the object configuration level

• a file property with attachment and having tags:

  • gallery_thumbnail because an instance is most of the time represented by its preview

  • gallery_multi_upload tag to enable mass import (assets waiting area)

• and full of other application properties…​

Assets waiting area

Place the gallery_multiupload tag on the file type property as an attachment to enable this feature.

This makes it possible to massively upload images via FTP, HTTP, etc. and to sort, analyze, document and complete them before they are released.

Whatever the DAM object, this waiting area uses the system object damimport and will move the instances to the correct DAM object when the documentalists will index them.

In this area, it would be possible to have a workflow that would be placed on the damimport object. Thus it could allow documentalists to have steps such as:

• To watch

• To validate

• To index

This depends on the customer’s needs.

You will find more information in the assets waiting area section.

Annotation

The instances of a DAM must be annotated.

There are three complementary and non-exclusive approaches to this.

Complementary properties

For example a property representing the instance title, which will be an i18n property marked with the gallery_title label.

Application properties as in all projects: child to the creator of the binary, etc

Normally in a DAM with a binary should be stored the rights to use the binary.
Did the people photographed sign a document authorizing the diffusion of the image?
The company that stores this image has the rights until when?

These documents could be stored in childmultiplesLongDb to an object like damlicence.

Use of Thesaurus objects

DAM instances are always annotated with keywords, geographic locations, etc

These keywords can be stored in Thesaurus objects that provide notions of synonyms, tree structure…​

So it is possible to add to the DAM object one or more childMultipleLongDb to a Thesaurus.

Use of flat objects

DAM instances can also be annotated with closed or open but non-tree value lists.

It is therefore possible to add to the DAM object one or more childMultipleLongDb to a non-tree object.

Likewise, it may be useful for the client to know that these instances of the DAM come from an order he placed with a reporter…​ this could be a child to a damorder object.

Prohibition

DAM objects must not have Wedia-specific properties.

The object galleryelement should never be marked as a DAM object.

At the data model level, the fact that DAM objects do not have Wedia-specific properties (such as lang/master/media/mediagroup/etc) is wanted because we want to be able to clearly separate DAM objects from WXM objects that have their own business rules and operations.

In addition, WXM must be able to work without DAM, just as a DAM must be able to work without WXM.

This is one of the reasons why the object galleryelement does not have this famous damobject label because it is not a DAM object in the proper sense of the term.

galleryelement should be seen as a workspace for WXM projects with its own internal business rules for WXM projects and not as a DAM object.

WXM/DAM

If there are DAM objects then a bridge is created between WXM and the DAM objects.

When the user imports the asset from a background a copy of the asset is made in the object galleryelement to be used as a project resource.

DAM workflow

DAM objects have their application workflow like any standard object.

...

Principles of operation of the waiting area

The waiting area will be available on your DAM objects as soon as these items will have the tag gallery_multi_upload on one of their file property.

It will allow users to:

• mass upload new assets onto the system

• insert the assets later into the destination DAM object

Image Added

Indexation of the assets

Regardless of the upload method used each asset will be the source of a new instance in the damimport object in which the property having tag gallery_multi_upload will be feeded with the uploaded files and property name will be feeded with its name (ie: my_picture.png).

Indexing will then allow a user to chain the creation of new DAM objects instances from files previously uploaded via mass download.

A click on the button Index all assets will allow the user to access the asset indexing interface.

Image Added

The assets to be indexed are presented in thumbnails on the left of the screen. Navigation buttons allow you to move from thumbnail to thumbnail.

The form in the central area is used to fill in property values instances to be created in the destination DAM object.

By default, the forms will be preloaded with the instance data represented by the highlighted thumbnail on the left with its stored data in the damimport object.

If you navigate from thumbnail to thumbnail, you will see the form update itself with the data of the instances present in the object damimport.

There are two indexing modes, single or multiple. It is possible to switch from one mode to another by clicking on the image button:

Image Added

Important

Regardless of the selected mode, access to the functionalities indexing of assets is conditioned by the result of a safety rule on the insert action of the objectdata domain for the DAM object in which the user wants to create the assets.

Single indexing

During a single indexing the records are created one by one when the user clicks on the button Start indexing.

When the master record is created, the form loads the following pre-filled record all fields with the values of the new record.

The checkboxes next to the properties allow you to keep the values properties to pre-fill the following records. Property values checked will have priority over the initial values of the card.

Note	When a master record is created in the destination background it is automatically removed from the indexing basket (damimport).

Multiple indexing

During a multiple indexing all records will be created automatically. The values used to fill records depend on of the checkbox next to each property:

• if the box is checked, the entered value is used.

• if the box is not checked, a calculated value is used.
  The calculated values can be: the default value of the field, the file name, EXIF/IPTC…​ property depending on the setting.

It is also possible to limit the creation to a few records by checking the following box checkboxes under the carousel vignettes located at left of the screen.

When the user clicks on the button Start indexing he will be able to choose either to index the files in the background by clicking on the button Index in background or index all files interactively.

Image Added

Note	When indexing in the background ends, the user is informed via a back-office notifications. Image Added

Pre-loading data into the system when uploading

The damimport object has two properties by default: name and file which allow you to store the name of the initial file and the downloaded file by the user.

These properties are then used to pre-fill out the indexing form of the DAM object in which the user will index the asset.

The DAM object generally has other properties and you want to often be able to preload these values directly into the damimport object when uploading assets to the system.

For each record the indexing form will load the data of the asset damimport and will use its data to pre-feed the indexing form for the destination DAM object.

Thus if there exists in the damimport object a xyz property of the same type and nature that a property named xyz of the destination DAM object, then the indexing form will be preloaded with this data.

It is possible to add to the damimport object as many properties as necessary.

Manual data preloading

The data can be pre-fed into the system in the damimport object by displaying an input form that will be presented to the user before downloading files to the system.

All instances of the damimport object that will be created in this case will be created with the data entered by the user in this form.

To display this form you must place tag dam_import_cart/prefill on the configuration of the DAM object.

The values entered in this form will be stored in the damimport instance to which the files will be attached.

The input form is based on the datanew form from the DAM object for which only common properties between the DAM object and the object damimport will be presented to the user.

In order to display an input for property named xyz in this form, the xyz will have to exists and be editable on both objects (dam object and damimport object).

Important

The facets of the dam object will be played on this form. There must not be any facets on the damimport object because they are useless.

Automatic data preloading

The data of the damimport object properties can be fed to the damimport object via a trigger in the damimport object, for example by reading the IPTC metadata of images or by loading data via a third party API for each of the imported assets.

Example of preloading IPTC data

To retrieve IPTC information on an image it is necessary to go through IPTC codes defined by the IPTC standard defined here:
http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf

So if, for example, you want to retrieve the stored creation date in the IPTC file, you will have to fetch the Date created property in the Application record, i. e. the key 2:55 stored in the application under the key: iptc: 2:55.

The metadata discovered by the engine are all visible on the the fileview action of the images by clicking on the thumbnails preview in dataview pages.

Image Added

For each of the properties of the DAM objects where you want to map properties with IPTC data it will be necessary to:

• find the IPTC key as read by the system, for example iptc: 2:55, for the date of creating an image,

• create a property of the same name/type/type/nature in the damimport object

• create a trigger in the damimport object that will fetch the value of the IPTC meta-data and place it in the associated damimport object property

Conversion of values

The engine recovers raw data in java.lang.String format only. So it is sometimes necessary to make conversions, it is the case of dates for example.

In IPTC the creation date is stored in yyyyMMdd format.

Doing a CTObjet.setProperty in a date-type property with raw IPTC data will trigger an exception when saving the data ⇒ it will then be necessary to convert it to a real date.

Multiple values

The asset properties (meta-data) storage format is a java properties String⇒String.

The IPTC format allows for some fields to store several values; this is the case of keywords for example. When there is more than one value for an IPTC key, it is advisable to set the following values recuperate in the following way:

Example

infos.getProperty("iptc:2:25"); // will bring back the 1st keyword
infos.getProperty("iptc:2:25_1"); // will bring back the 2nd keyword
infos.getProperty("iptc:2:25_2"); // will bring back the 3rd keyword
infos.getProperty("iptc:2:25_3"); // will bring null => there is no more keyword

About IPTC keys you will find here a document a little more digestible about them:
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html