Answered Questions

• Originals and copies can be moved and named independently of each other. But they always retain the (hidden?) link.
• You can edit an original (does not automatically create a copy).

Purpose

The goal is to implement the ability to find assets and uses of assets as described in this UX specification: Digital asset management

This paper is focussed on the data structures necessary to achieve this and the strategies for finding the references, it does not cover the user interface.

Explicit Goals:

• With an Asset 
  • Find an "Original" that it was derived from.
  • Find any "Copies" that were derived from it.
  • Find any "Uses" of the asset in another repository workspace, typically the website workspace.
  • Quickly find number of "Uses" of an asset so that it can be displayed in a column in list and tree views.

Some Use Cases: Working Scenarios for working with assets

Tracking uses/master/variant

Original / Copy

From a data modeling perspective, originals and copies have a one-to-many relationship. The most straightforward storage of the relationship is a foreign key on each copy. Therefore, every mgnl:asset node has an optional property "originalIdentifier" of type WEAKREFERENCE which stores the identifier of the asset that it was copied from.

We use a WEAKREFERENCE instead of a REFERENCE as it could be that a user wants to activate a copy but not its original to a public instance. (A REFERENCE would throw an error in this case because referential integrity would be broken, its referenced item would not be present.)

To find the original of a node, simply follow its originalIdentifier reference.
To find any copies of a node, search the dam workspace for all nodes which have the target nodes identifier as their originalIdentifier reference. 

Uses

A "use" of an asset is any instance where that asset is used in another workspace, typically on a page or component in the website workspace. So a use is not another node in the dam workspace.

An asset has a one-to-many relationship with its uses. Each use stores the identifier of the asset. Unfortunately, there is not currently a specific property name for where the use stores the identifier.
To find the uses of an asset, search all properties of all nodes of the website (or potentially other workspace) workspace for the assets identifier. 

Number of uses (Computed / Dependent / Cached Property)

In the UX mockups, in the list and tree views we see the number of uses of an asset. This might be slow to generate dynamically. A solution would be to store the number of uses of an asset on the asset node. The danger is that this could get out of sync with the actual uses. It is redundant data - just a "view" on the reference count. Is there a mechanism in JCR to store this kind of dependant, or computed property? If there is no built in way - we  have to implement that such a value gets updated on an asset whenever the asset is added or removed from a component or page in the website workspace.

Questions

Should the originalIdentifier be optional, or should it be mandatory and just be empty on nodes with no original? There could be search performance advantages for one of the approaches.

The search for uses of an asset could be slow. The identifiers of the uses (a reverse reference) of an asset could also be "cached" on a subnode of the asset. I think we don't need to do this in the original implementation- but it could be an optimization if we find performance is unacceptable.