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
Upload assets
One click on the button Upload new asset will allow the user to send files to the system either via HTTP or FTP.
Access to asset download functionality is conditional on the result of a security rule on the insert action of the objectdata domain for the object damimport.
To be allowed to upload files on the system the user must have the right to insert new instances in the damimport object.
Sending assets via HTTP
This feature allows a user to upload one or more assets to the system from their workstation.
The user selects a set of assets from his workstation and sends them to the system.
Assets downloading via FTP
This feature allows the server to connect to an FTP server and retrieve all the files available to it.
Caution | Here it is the Wedia server that connects to an FTP server. |
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.
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:
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.
Note | When indexing in the background ends, the user is informed via a back-office notifications.  |
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.
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.
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/naturein thedamimportobjectcreate a trigger in the
damimportobject that will fetch the value of the IPTC meta-data and place it in the associateddamimportobject property
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.
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:
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...
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
damobjecttag at the object configuration levela
fileproperty withattachmentand having tags:gallery_thumbnailbecause an instance is most of the time represented by its previewgallery_multi_uploadtag 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.