Purpose
Overview of the current DAM implementation and open Issues/Questions.
Existing documentation
- Current Implementation
- Tracking DAM copies and uses
- DAM Workspace Structure
- Concept - DAM 1.0 future improvements
Concepts to clarify
Metadata
AssetProvider assembles the DamAsset based on the asset node from the workspace and the related DAM asset.
- Sets the Meta-Data source which allows for flexible changing the ways of how meta-data is fetched and from where (typically - from the asset node internals, but could be from wherever).
Stored informations on an Asset:
- mgnl:asset language Asset.getLanguage() --> returned type: String or Local ?
- mgnl:asset name Asset.getName()
- mgnl:asset title Asset.getTitle()
- mgnl:asset type ???
- mgnl:asset subject Asset.getSubject()
- mgnl:asset description Asset.getDescription()
- mgnl:asset caption Asset.getCaption()
- mgnl:asset copyright Asset.getCopyright()
- jcr:content extension Asset.getFileExtension()
- jcr:content fileName Asset.getFileName()
- jcr:content height Asset.getHeight()
- jcr:content size Asset.getSize()
- jcr:content with Asset.getWith()
- jcr:content jcr:data Asset.getBinaryData()
- jcr:content jcr:mimeType Asset.getMimeType
Information stored in the Meta-Data content node (these are the optional properties that a content node can have)
- mgnl:content caption Asset.getCaption()
- mgnl:content title Asset.getTitle()
- mgnl:content description Asset.getDescription()
- mgnl:content copyright Asset.getCopyright()
Questions
- mgnl:asset attributes are not exposed by the Asset Implementation (language/title/...). Is this correct?
- Meta-Data: Should we keep the concept of a MetaData object?
- copyright is this not a Asset attribute ?
- how to handle duplicate (title/description) defined on Asset and Meta-Data ?
- Should we introduce a concept of CopyRight ?
Proposal
Get meta-Data from DAM asset, and override it if existing on the content node.
Decision
Remove the Meta-Data concept.
Add caption and copyright properties under asset Node.
It will be to responsibility of modules using DAM to override these properties if they come from another place (STK, textImage model class)
Asset Node Type
Current DAM workspace hierarchy structure:
mgnl:folder
(nt:folder)mgnl:asset (nt:file)
description
title
...
mgnl:resource (nt:resource)
jcr:data (type="Binary")size
...
mgnl:asset (nt:file
...
Open Issues/Questions:
- Version: How to handle versions?
- For external provider we said that we should at least have one DAM Node pointing to the external Content (binary) but
the currentmgnl:asset
required amgnl:resource
with ajcr:data (type="Binary")
Should we introduce a new type for external Content ?
In addition from previous concept page:- 'Although assets could come from different sources, the asset node will have standard fields that will enable it to be displayed in lists etc'
- 'AssetNode has a field specifying assetProviderType'Not Implemented
- For multivariant assets (i18n-ed, multiple sizes etc.) it might support multiasset
.
Proposal:
mgnl:folder
(nt:folder
)mgnl:asset (nt:file)
assetProviderType
title
...
mgnl:resource (nt:resource)
jcr:data (type="Binary")size
...
mgnl:asset (nt:file)
...
mgnl:externalAsset (
mgnl:content
)assetProviderType
title
...mgnl:multiasset
(nt:folder
)
(mgnl:multiasset
) this way we could potentially group assets that should be presented as one within Magnolia, but still allow each variant to keep own set of properties and be indexed separately.
Still How to handle version?
Decision
Keep the current JCR structure.
MultiAsset, ExternalAsset will be better defined in another SPRINT.
Asset Provider functionalities
Extend the Asset provider functionalities:
- getAssets(Node, String) List<DamAsset> : If the Identifier refer to a DAM folder, return the list of child assets
- getAssetVersion(...)
General questions
- In previous STK/DMS collaboration - link to a document can be a path or a Identifier. Do we support path?
- Currently in info.magnolia.dam.asset, there are Asset, DamAsset, and DamAssetWrapper (And considering there is no more metadata)
(Im not talking about stk AssetWrapper here)- Do we really need Asset and DamAsset - why, is this just an artifact from DMS?
- What is the value of DamAssetWrapper
Decision
Only support Identifier link to DAM.
Review the current DAM API
- Remove DamAssetWrapper
- Rename DamAsset to InternalAsset
Open Questions/Tasks
Links (related to MGNLSTK-1048 issue)
Create a DAMURI2RepositoryMapping extends URI2RepositoryMapping (Equivalent of DMSURI2RepositoryMapping)
Create a DAMDownloadServlet (Equivalent of DMSDownloadServlet)
These two class should use the DAM class to get the correct AssetProvider. The AssetProvider should expose a method getLink(damNode) --> String tha return the correct Link based on the source storage (dam workspace, webdav...)
API review
DamAsset ? should we keep this class?
Should we create an equivalent of DMS document?
Should we remove or deprecated all STK dam package?
STKImagingSupport should use only STKTemplatingFunction to create Link for Binary content and not TemplatingFunction.
In STK for model class that use previously DMS, we expose a method that return the target as ContentMap. This content map is the representation of a JCR node.
How to handle external source ?
Should we return an Asset object instead? --> review and migrate FTL's
- Taken approach : Deprecate old methods. Expose a new method returning an Asset.
STK Model still expose method like getDMSDocument. Should we rename these methods --> review and migrate FTL's.
Actions
2 Comments
Boris Kraft
It is probable relevant to note that Magnolia uses the Dublin Core Meta Data standard. This should be kept. Optimally it should be possible to use different meta data sets like IPTC or EXIF for images; maybe using mixins to allow that? For an overview of (some) meta data standards, see http://en.wikipedia.org/wiki/Metadata_standards
Eric Hechinger
We are tacking this into account. We will at least support the Dublin Core Meta Data standard that is in fact no more the case as the specification was updated in 2012.
A new user story was created https://magnolia.atlassian.net/browse/BL-145 and also a new concept page Concept - DAM Dublin Core MetaData.