Versions Compared

Old Version 1

changes.mady.by.user Jules DELEUZE (Unlicensed)

Saved on

compared with

New Version 2

changes.mady.by.user Jules DELEUZE (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Important
 The galleryelement object is not a DAM and a DAM is not a galleryelement.

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.

galleryelement still exists and remains as planned at the base namely that it is a project content-bin and NOT a DAM.