Talk:Surrogate items

Faces,MPDL,FIZ

General concept

 * FACES uses the surrogate item to allow sharing of an album. A user will not add/remove items to an album but create-add/remove a surrogate item.
 * To illustrate the concept please see the figure below.
 * --MFranke 09:25, 11 August 2009 (UTC) Please clarify wording: collection, context, container. As the use of the concepts here is not clear, the whole concept is hardly understandable.



Contexts

 * We have 2 contexts:
 * The collection context: In that context a user can create a collection. A collection is a container. The user can create items with content and add it to his collection. FACES is collections, Diamonds is one too.
 * The Album Context: A user can create an album. If he has the rights to see an item of a collection he can create a surrogate item of that item to add it to his album.

Items

 * Items are normal escidoc items. They have their own metadata record and components. Only the creator of the items has rights on it.

Surrogate Items

 * Surrogate items are normal escidoc items. Their metadata record inherits the one of the original item (In case of FACES: emotion, age, etc.). New metadata can be added on these surrogate items such as: comment etc. Besides, a surrogate items holds in the content-model-specific-properties the escidoc identifier of the album it belongs to, and the escidoc identifier of the original item.
 * so a surrogate item has to be member of exactly one album? why can't the relation between surrogate item and album simply be one of container and member?--Robert 15:15, 9 April 2009 (UTC)
 * in fact it is a relation between a container and a member. As you noticed, the difference is that a surrogate item can belong to only 1 container (unlike classical items). The reason is that if users who collect their items in an album would like to have "album-specific" annotations, extensions to metadata, comments etc. In this case, original resource should be intact, however, by relating the surrogate item to its origin item, it is possible to infer all extensions and comments as related to the origin item. --Natasa 09:49, 3 June 2009 (UTC)
 * i still don't understand why the item couldn't be used like a regular item in other contexts, e.g. be related to other containers as well. it seems as if "surrogate" is less a property of an item than a way of using an item.--Robert 10:38, 3 June 2009 (UTC)
 * --MFranke 09:25, 11 August 2009 (UTC) I also do not understand this feature. Items in a container are defined by the struct-map that can also be used to form a search query on a container's items

Collection

 * Collection is a container created in Collection context.

Album

 * Album is a container created in Album context.

Use Cases

 * Creation of a collection: We have 2 users: User1 and User2. User1 creates a collection in the collection context (Collection1) and defines User2 as collaborator. User1 adds 3 items (Item1, Item2 and item123) to Collection1. Collection1 is still in state pending, nobody else (except User2) can see or edit the Collection1. He releases Collection1. From this point on, all other users can see Collection1 (not necessarily private content).


 * Managing an album: User2 creates an album (Album1) in Album Context. He wants to add to add Item1 of Collection1 to it. By clicking on "Add to Album1" the system creates a Surrogate item (SurrogateItem1) in Album context and adds it to Album1. If user clicks on "Remove picture from Album1" the system will simply delete the SurrogateItem1.
 * Browsing an album: To browse Album1,the system will search for all surrogate items with Album1 identifier (in md-record) with the appropriate browsing parameters (Number of results, page number, sorting parameters). The result list of surrogate items will enable the system to retrieve the original items from collection context.

User Management

 * In Collection Context:
 * A creator of a collection will have Depositor (to create/edit) and Moderator (to release) rights.
 * To access Faces items in the Collection Context with private content, a user will have "privileged-viewer" role on Collection context.
 * the Depositor policy will be changed to allow release as well, therefore the Moderator rights will not be necessary. --Natasa 13:48, 9 April 2009 (UTC)
 * A Collaborator will only have the collaborator rights on the collection.
 * At this point it is not required to have several collections in Faces context. Above only describes what is needed if users would like to have e.g. "Young Faces" collection in addition to the complete Faces collection.--Natasa 13:48, 9 April 2009 (UTC)
 * Diamonds is from my point of view a very soon candidate for a new collection in Collection Context, isn't it? --Bastien 14:17, 9 April 2009 (UTC)
 * Diamonds will be a collection in a separate Collection context (e.g. NIMS Collection Context)--Natasa 15:04, 9 April 2009 (UTC)
 * In album Context:
 * All users will have Depositor and Moderator rights.
 * See remark above on Depositor policy change--Natasa 13:48, 9 April 2009 (UTC)
 * Users will have collaborators-modifier rights for albums on which they collaborate.

Remarks

 * a user who can create Album in Album context or a user who can collaborate on Album in Album context should have privileged-viewer role on Collection context to be able to see "private" content in the Collection context.--Natasa 13:48, 9 April 2009 (UTC)
 * Is it possible to define it on collection level and not on context level? For further development, a user shouldn't be privileged viewer for the whole collection context. Diamonds users are not allowed to see FACES private content!--Bastien 14:13, 9 April 2009 (UTC)
 * not certain what is meant with collection level, but it is the complete Faces collection that belongs to a single context - thus it will be on context level. The Diamonds pictures will be in separate context. --Natasa 09:51, 3 June 2009 (UTC)

Timeline

 * the timeline has to be checked with the implementation from FIZ. If in meantime FIZ enables surrogate-item handling, then MPDL will use it, otherwise we will implement the concept given above.
 * Faces 3.5 timeline would start July-Aug 2009