Child pages
  • Digital Asset Management conceptual overview
Skip to end of metadata
Go to start of metadata

Ready for implementation


Digital Asset Management in Magnolia:

  • provides basic- to intermediate-level management of media files for web publishing
  • differentiates between originals and their visual representations on pages
  • converts on-the-fly or in advance between different media formats
  • provides basic editing tools e.g. for last minute changes before publication
  • controls access to assets and edit functionality
  • protects a brand by providing easy-to-use means to lock and deprecate assets

The technical framework:

  • builds a bridge between basic document management and digital asset management
  • provides powerful, rich adapters to external DM and DAM systems
  • offers file-level access to tools used by designers to digital media stored in Magnolia and connected, external systems

Magnolia 5 DAM does not provide:

  • advanced editing functionality
  • tools for archiving assets to external storage media
  • a full catalog for working and managing assets throughout a company

Strategic placement

While digital assets in Magnolia are very well managed and integrated and this management offers many features, it's aim is not to replace a full-fledged DAM system e.g. used by media publishers or large companies.

In fact, Magnolia uses a three faced approach to Digital Asset Management:

  • on a basic level, assets are simply uploaded and attached to a single page. Such assets are not re-usable on other pages, but Magnolia 5 still offers a central overview showing all assets on all pages.
  • on an intermediate level, a separate Digital Asset Management module introduces internal storage, management of assets and basic editing capabilities, which cover all needs for medium, some times even large sites.
  • on an advanced level, adapters to DAM systems from other vendors allow Magnolia to access and possibly also change digital assets managed externally. Such systems may offer advanced capabilities such as extensive catalogs, archiving of assets and professional editing capabilities, but their assets and renditions are still available to Magnolia paragraphs through these adapters.


The Asset

The definition of an asset in Magnolia is best given by citing Wikipedia's definition of a Digital Asset:

A digital asset is any item of text or media that has been formatted into a binary source that includes the right to use it. A digital file without the right to use it is not an asset. Digital assets are categorised in three major groups which may be defined as textual content (digital assets), images (media assets) and multimedia (media assets) (van Niekerk, A.J. 2006).

Magnolia implements digital assets by referring to a common model, which defines an asset to be consisting of three integral parts:

  • Asset essence: the original binary file or a converted version of an original upload stored in Magnolia or in an external DAM
  • Asset metadata: the description of the asset essence providing additional, contextual information
  • Asset renditions: variants of the asset essence readied for use on web pages

Usually, the asset essence is a representation of highest quality, i.e. with maximum resolution and best audio quality. It typically comes in formats commonly used during capture (e.g. MPEG 2 for video or RAW for photos) and has to be transcoded to a web-suitable format first before it could be used on a web page. In Magnolia, the asset essence is never directly published, even if your intention was to directly publish it in the format it comes in and with no additional editing applied. Instead, you create one or many asset renditions first. A rendition is a description of a different visual representation of an asset essence and includes instructions for the target format (e.g. JPEG, PNG for images or H-264 for movies), applied editing operations (e.g. for a cropped image or to apply a fade-in/-out transition to connect two movies). From the perspective of the user, it is irrelevant if a rendition physically exists as a working copy of the essence or whether it is always generated on the fly based on the rendition instructions.

Finally, the asset metadata contains additional information on the who, where and how of an asset. It is important to enable proper management of an asset and is attached to the asset essence. It typically contains data on the actual asset content (a description, some keywords or tags); the format used by the essence as well as possibly hints for encoding and decoding it; data on the location, time and settings of the capture (provenance); and on ownership. The metadata also defines general access to an asset and as such also specifies, who may edit and publish it.

The Asset Type and Asset Set

First, the asset type serves as classification of an asset and may denote if an asset is an image (photo, clipart, ...), movie, audio file, presentation, office document or normal file. This is connected to the format an asset comes in or is transcoded to, but merely provides a way of making assets of a certain type available in the user interface. Asset types are configurable in Magnolia; you may want to add a type "panoramas" and assigning it photo formats typically used to represent panoramic images. An asset type may only be defined using a set of formats and no other characteristics an asset might have.

An asset set helps in organizing and filtering assets. An asset set consists of:

  • a location where assets are stored. This could be an internal storage location or referring to an externally connected DAM.
  • an organization scheme, which defines if assets are organized using folders and/or tags.
  • a set of asset types to select kind of assets should be available in the set. Alternatively, all assets available at the location can be visible as well.
  • possibly additional filters such as text filters, format filters, etc. to further restrict the assets available in the set.

Asset sets can be used to provide quick access to specific asset types such as all images or movies in a certain repository, but far more sophisticated usage scenario exist. Magnolia makes asset sets available to users as well as template designers. Thus, a designer may use an asset set to restrict where assets may come from in certain paragraphs. Imagine an asset set containing high-quality images suitable for the corporate front and section pages (only). On the other hand, an editor in Magnolia may only be given the right to use (and not add or edit) renditions of the company logo stored in one asset set, but she may be free to also upload new assets and add and edit renditions in a second asset set containing images used on an internal site.

Note that the same location may be made available multiple times with different or the same organization schemes and filters - this really only depends on the usage scenario and on the possibilities of the underlying DAM implementation. An asset set might be referring to an internal repository using folders to organize presentations. Another set could refer to a different internal storage location for images and using tags instead of folders, while a second asset set could show all movies available there. Finally, an external DAM organizing could make assets marked "important" available as an asset set using neither folders nor tags.

  • No labels


  1. I would like to propose two refinements. They come up as feature request in RFPs all the time.

    • PDF renditions. Generating renditions for media assets is not the only use case. We should provide PDF renditions of Office documents and web pages as a matter of fact. It is such a common request. This functionality can very well be componentized into a module, just like Documentum Media Transformation Services, and sold as an extra. My point is: don't make enabling the feature a hacking and hunting exercise.
    • Standard metadata. Let's agree on a metadata standard we support for DAM assets. The 15 Simple Dublin Core fields are so simple that we could declare support for them outright. Makes RFP work easier when we don't need to explain that we support a "subset" of Dublin Core.
    1. Standard metadata
      Dublin Core: absolutely. I've not mentioned this here yet as I see this leaning more to the implementation side of things. But maybe it would be better for all of us if we just make it explicit right from the start (smile) I'd like to discuss this with you soon, as my knowledge on DC is only basic.

      PDF renditions
      Yes, I see this as a must for Document Management in Magnolia. PDF renditions of web pages is a great idea - perfect for legal purposes -, but probably would have to work slightly different.

      This actually leads to an interesting topic. I'm mainly focusing Digital Asset Management (DAM) here, which covers media assets mostly (images, audio files, movies). Classically, office documents and even the presentations I mention above are handled by Document Management (DM) systems. DAM and DM have similarities, but differ significantly on the tools and services surrounding the actual file storage. Enterprises usually clearly distinguish between the two; in my experience, they require both topics to be somehow covered by a CMS, but don't like to see them being mixed up.

      Still, we could add media assets and documents into the same pool of assets from an interface standpoint. We could have two menu entries (e.g. "media assets" and "documents") or could just offer one ("assets"). I have my doubts, though, that people think of documents when they hear the term "assets", and finding a common term for both could be quite a challenge. For the implementation, however, I would want both DAM and DM be handled by the same architecture and suite of services. In fact, DAM and DM could be the same thing technically, but just have different configuration. That could be acceptable since we only cover basic and intermediate levels of asset management (see #Strategic placement above).

      What do you think? Should documents and media asset be mixed or treated separately?

      1. I agree that PDF renditions fall into the domain of Document Management rather than Digital Asset Management but there is no vendor consensus on where the line goes. Documentum and Day CQ mix them up while SharePoint keeps documents separate. Maybe this helps: Intro to Digital Asset Management: Just what is a DAM?.

        The reason I brought it up here is the term rendition. I thought it meant only derivatives documents whereas derivatives of DAM assets were proxy copies (yuck). I actually prefer rendition for all derivatives.

        1. Yes, thanks, that is an excellent article, I've read it, too.

          I thought that proxy copies were merely temporary files created e.g. for large media assets in order to reduce the strain on the DAM infrastructure?