Requirements - Admin Sets vs. Display Sets vs. User Collections

Table of Contents

Error rendering macro 'toc' : For input string: " 4 "

Terminology

Admin Sets

An administrative grouping of items that an administrative unit is ultimately responsible for managing. The set itself helps to manage the items within it. Toward this end, an admin set can have...

- an Admin Policy Object (APO), which serves as a template for visibility settings that is applied when works are created in the Admin Set
- a Workflow which allows for assigning users roles and actions controlling the creation and editing of works within the Admin Set

NOTE: A default Admin Set exists beginning in Sufia 7.3 which holds all works not created within a specific Admin Set. A default workflow is defined that allows the depositor to complete the creation of a work in a single step.

Display Sets

An intellectual grouping of items primarily oriented toward display of content to end users. As such, they have organizational features like nesting, hierarchical browsing, discoverability, and membership in multiple Display Sets. Additionally, there are tools that aid in the creation and management of resources (e.g. other Display Sets and Works) within the Display Sets.

NOTE: There is a wide variety of Use Cases for Display Sets in Hydra that want to be addressed by Display Sets that have competing requirements. As such, the implementation of Display Sets will have a configuration that allows for certain features to be 'turned off'.

User Collections

An intellectual grouping of items, primarily used by individual users to create groups of items or favorites. At this point, users can control visibility of collections such that they can be discoverable through search.

QUESTION: Is there a site wide configuration that disables the user's ability to set visibility for user collections?

Participants

Impact on Admin Set Access

When participants are added to an Admin Set, access to the admin set will be assigned as follows.

Managers - edit_access for the Admin Set - able to set admin set metadata

Depositors - no access levels assigned

Viewers - no access levels assigned

Impact on ability to add works to an Admin Set

When a user is creating/editing a work, the Relationships tab has a selection list admin sets to which a user can add. Participants that can add to an Admin Set are.

Managers - can add to the admin set

Depositors - can add to the admin set

Viewers - can NOT add to the admin set

Impact on Work Access

Participant access is assigned when a new work is saved. When creating/editing a work, the Relationships tab has a selection list that will list all admin sets for which the current user is a Manager or Depositor.

Based on the Admin Set selected on the Relationships tab when creating a NEW work, access to the work will be assigned as follows.

Managers - edit_access for all works created in the Admin Set

Depositors - no access levels assigned

Viewers - read_access for all works created in the Admin Set

Once a work is created and access is assigned, the Admin Set's participants have no more bearing on the work. That is, if the participants are changed in the Admin Set, any existing works remain unchanged. Any new works will get access assigned based on the new participants for the Admin Set.

Also, if you edit a work and changed it's Admin Set, the membership of the work will be set to the new Admin Set, but the access assignments will remain unchanged.

Requirements Comparison

NOTE: This comparison chart shows 3 types of groupings. There is a proposal to expand User Collections to implement Display Sets. Since some apps already have User Collections, they are given their own column in the comparison chart. See the Use Case for implementing User Collections as Display Sets later in this document to see how they can continue to exist as currently defined, optionally allowing sites to expand the functionality available for user created collections.

Requirement	Description	Admin Sets	Display Sets ¹	User Collections	Comments
Multiple membership	A resource ² in a set ³ can also be a member of any other set of the same type.	X	√	√
Nestable	A set can have another set of the same type as a member.	X	√	X	This purely top-down (e.g. A - B - C). Circular membership (e.g. A - B - C - A) is NOT allowed.
Hierarchical Browse	Browse from top most sets to member sets?	X	√	X
Branded Landing Page	Provides the ability to customize a landing page for each set.	X	√	X	Minimal branding customization: logo - possibly multiple logos for joint ventures description - including basic html that can have links
Discovery	Sets and member resources can be discovered through regular app wide search.	Optional	√	Optional	AdminSets - In Hyrax, Admin Sets are by default enabled and discoverable. They can be disabled and thus made not discoverable. User Collections - The creator of the collection can set the visibility of a user collection to public in which case it will be discoverable. Can the app be configured to disable a users ability to set a collection to public? <Comment from newmanld - see my comment below. I think the owner/creator of a display set will at times need to make the set temporarily private (while under construction) or limited to institution only.>
Search within Set	Search results are limited to resources in a set and any of its member sets	Optional	√	Optional	AdminSets - Admin Sets are faceted and allow for search within. User Collections - Are user collections faceted?
Add Existing Resource	Any resource that is discoverable and accessible by (at least some) viewers of the repository can be selected to be a member.	MOVE	√	√	AdminSets - A resource can belong to one and only one Admin Set. And there is a default Admin Set to which all unaffiliated resources are assigned. So adding an existing resource is really a move from one Admin Set to another in all cases.
Resource Creation	A single resource can be created directly in a set.	√	√	√
Batch Upload	Multiple resources can be created directly in a set via batch upload process.	√	√	√	Need to verify for Admin Sets and User Collections
Ability Controls	Assign users as managers, depositors, and viewers of the set.	√	√	X
Workflow Control	A workflow can be configured for a set. Any resource created directly in a set will be assigned that workflow.	√	~	X	~ Display Sets - A Display Set can be configured to be associated with an Admin Set. When a work is created directly within the Display Set, it will also be assigned membership in the associated Admin Set. The Admin Set defines the workflow that will control the Display Set's work. Rules controlling the association of a Display Set to an Admin Set: Association of a Display Set to and Admin Set is optional. A site that does not need workflow or APO control does not need an associated Admin Set. A site that does not want to create works directly in a Display Set does not need an associated Admin Set. Adding a work to the associated Admin Set only happens when a work is created directly in the Display Set. If a work is added to a second Display Set, there is no change to the Admin Set membership of that work. If an existing work is added to its first Display Set, there is no change to the Admin Set membership of that work.
APO Control	An Admin Policy Object (APO) can be configured for a set. Any resources added to a set have their visibility controlled by that APO.	√	√	X	~ Display Sets - A Display Set can be configured to be associated with an Admin Set. When a work is created directly within the Display Set, it will also be assigned membership in the associated Admin Set. The Admin Set defines the APO that will control the Display Set's work. (See Rules controlling the association of Display set to an Admin Set in the previous Workflow Control requirement.) Need to confirm, but I believe that APOs for Admin Sets serve more as a template where the visibility characteristics are copied to the resource. At that point, editing the resource can change its visibility. It is no longer controlled by the APO. A change to the APO will not effect the resource.
Custom Metadata	Additional metadata fields can be configured for a set. The fields are included in any resource in a given set.	X	√	X	Display Sets - This requirement is NOT targeted for the first implementation of Display Sets. But was identified as potentially useful functionality for Display Sets that can be added at a later date.

1 Display Set requirements are being developed by the Display Sets Working Group. They are not implemented at this time.

² The term resource is a generic term that may refer to a work, a set, or both.

³ The term set is a generic term for Admin Set, Display Set, or User Collection.

Concepts that may need clarification

Adding a Resource Directly in a Set

How it works now

Currently in Curation Concerns/Sufia, works can be created in the following ways...

Works → New Work
Dashboard → My Dashboard → Create Work
Works → Batch Create

Works can be assigned to an Admin Set via...

→ New Work → Relationships (tab) → select from Add as member of administration set
→ Edit Work → Relationships (tab) → select from Add as member of administration set
→ Batch Uploads → Relationships (tab) → select from Add as member of administration set

Works can be added to a User Collection via...

→ New Work → Relationships (tab) → select from Add as member of collection
→ Edit Work → Relationships (tab) → select from Add as member of collection
→ Batch Uploads → Relationships (tab) → select from Add as member of collection
→ My Works → check box beside one or more works → Add to Collection → select User Collection → Update Collection

Proposed new functionality

The concept of adding directly to a set sort of exists when the user selects an Admin Set or User Collection from the Relationships (tab) while creating the work via New Work. It is envisioned that two new actions will be created that provide a direct way to create a work directly in a set.

set show page → New Work Member → goes to New Work form and auto-fills the set on the Relationships (tab) which cannot be changed during the creation process
Dashboard → My Sets → action menu: New Work Member → goes to New Work form and auto-fills the set on the Relationships (tab) which cannot be changed during the creation process

Challenges of selecting Display Set on Relationships tab

list of Display Sets can be very long (e.g. > 400, > 1000)
some sites use filter of Display Sets to make this list smaller
FLAG as usability problem and punt to UI working group

"Primay" relationship between a Display Set and member works

NOTE: This is still under discussion.

How a work gets a "primary" relationship with a Display Set? In all cases, the user establishing the "primary" relationship must have edit access to the work.

create the work directly in the Display Set
add a work to its first Display Set
when removed from its primary Display Set, the user is asked whether they want to make another Display Set primary
possible others

If a "primary" relationship exists between a Display Set and some of the member works in the Display Set, then for those works...

ability controls are applied (e.g. managers, depositors, viewers)
APO templates are copied to works created directly in the Display Set
workflow applies to works created directly in the Display Set
work cannot be deleted as long as it has a "primary" relationship with a Display Set
removing a work with a "primary" relationship with a Display Set removes the "primary" relationship

The reason for adding the "primary" relationship concept is to allow one Display set to control abilities, workflow, and APO control.

Outstanding Questions:

How does this interact with Admin Sets, especially given that the implementation always puts new works in the default admin set if one isn't specified?

Configuring Display Sets

Global Configurations

The global Display Set configurations effect all Display Sets.

	Values	Can be overridden for specific set?	Comments
multiple membership within type	OFF \| ON	Can turn OFF, but not ON
nestable	OFF \| ON	Can turn OFF, but not ON
browsable	OFF \| ON	NO
discoverable	OFF \| ON	Can turn OFF, but not ON	This controls whether the Display Set itself is visible and discoverable. It does not effect the works in the Display Set. See APO controls for visibility and discoverability of the works in a Display Set.
branded landing page	OFF \| ON	NO	Seems like a core feature, so perhaps this configuration is not needed.
ability controls	OFF \| ON	NO
creators	Select users \| groups	NO	selected users/groups can create new sets of this type AND serve as default manager
managers can...	edit display set metadata set participants set release and visibility gets edit_access for works created in this Display set add works to set remove works from set (limited by edit_access)	Can make more restrictive, but not less	specific users/groups that fills each ability role is defined per set
depositors can...	add works to set remove works from set (limited by edit_access)	NO	specific users/groups that fills each ability role is defined per set
viewers can...	gets edit_access for works created in this Display set	NO	specific users/groups that fills each ability role is defined per set
workflow controls	OFF \| ON	Can turn OFF, but not ON	workflow is identified per set
APO controls	OFF \| ON	Can turn OFF, but not ON	When a work is created within the Display Set, the APO for the Display Set is copied to the work.

Use Cases - how they look under this implementation

Reference: Use Cases for Display Sets in Hydra

Use Case 1: Agencies and Sub-agencies

The global Display Set configurations effect all Display Sets.

	Global Configuration	Comments
multiple membership	OFF
nestable	ON
browsable	ON
branded landing page	ON
ability controls	ON
creators	group: SiteAdmins
managers can...	see global configs
depositors can...	see global configs
viewers can...	see global configs
workflow controls	N/A	It is ok that this work will not be done in the first pass.
APO controls	ON	visibility/discoverability is defined per set

NOTE: Agency and Sub-Agency are Display Sets.

Actions relating to Display Sets:

As a SiteAdmin, I create an Agency and assign at least one user as manager of the Agency.
As a SiteAdmin, I create Sub-Agencies as members of Agencies and assign at least one user as manager of each Sub-Agency.
As manager of an Agency|Sub-Agency, I set Agency|Sub-Agency metadata (title, description with links, logo, additional metadata - e.g. acronym, contact_email, contact_phone, location, homepage_url) and assign users/groups to be depositors and viewers.
As depositor, I create a Work directly in a Sub-Agency starting from the Sub-Agency show page.
As public user (not logged in), I want to browse from homepage listing all Agencies to a specific Agency to Sub-Agency to Work.
As public user (not logged in), I want to see a landing page for Agencies/Sub-Agencies with title, description, logo, and additional metadata.

Use Case 2: DSpace communities and collections

NOTE: Communities and collections are Display Sets.

The global Display Set configurations effect all Display Sets.

	Global Configuration	Comments
multiple membership	OFF
nestable	ON
browsable	ON
branded landing page	ON
ability controls	ON
creators	group: SiteAdmins
managers can...	see global configs
depositors can...	see global configs
viewers can...	see global configs
workflow controls	N/A	It is ok that this work will not be done in the first pass.
APO controls	ON	visibility/discoverability is defined per set

Actions Related to Display Sets:

As a SiteAdmin, I can create a community and assign at least one user as manager of the community.
As a SiteAdmin, I can create sub-communities and collections as members of a community.
As a SiteAdmin, I can assign a manager to a sub-community or collection.
As a community or sub-community manager, I can assign users as managers to my community, sub-communities, and collections.
As a community manager, I can not assign user roles to my parent community.
As a collection manager I can assign users as managers to my collection.
Role(s) assigned to a user in a community are assumed in sub-communities and collections, including workflow.
Workflows assigned to a sub-community or collection override default workflows assigned to a parent community or the site. It is understood that this work may be in a later phase.
As a community, sub-community, or collection manager, I set community|collection metadata (title, description with links, logo, additional metadata - e.g. acronym, contact_email, contact_phone, location, homepage_url) and assign users/groups to be depositors and viewers
As a depositor, I create a Work directly in a collection.
As public user (not logged in), I want to browse from homepage listing all communities to a sub-community, to a specific collection to Works.
As public user (not logged in), I want to see a landing page for communities, sub-communities, and collections with title, description, logo, and additional metadata.

Note: Depending on the implementation approach of workflows through admin sets, the ability to assume a default workflow from a parent community may be difficult. This may be an item for further discussion.

Use Case 3: Nested Collections

The use case of nested collection is the same as DSpace sub collections.

Use Case 4: Curated Exhibits

The use case of curated display sets is generally one in which the creator wants to gather works from the repository and feature them in a very accessible, visual, exhibit-like way. The creator should be able to name the set, provide an introductory, orienting description of the set, and ideally provide a custom banner or other visual decoration to help brand the set.

Ideally, when a visitor is viewing a curated exhibit display set, there is a set-specific search box and the facet sidebar is constrained to items in the display set (at the same time, the visitor should also be able to easily return to the repository-wide search and facets). A configuration option that enables the set manager to hide the facet sidebar (it would still show up on the search results page) works well in Spotlight and might be worth considering here (makes for a more focused, visual experience).

	Global Configuration	Comments
multiple membership	ON	Very important for exhibits. A common goal of exhibit creators is to bring together items from multiple collections, and multiple exhibits are likely to want to contain the same items.
nestable	OFF	Doesn't seem too critical to me, but there might secondary use cases that would benefit from being able to turn this ability ON.
browsable	ON	A defining feature of Curated Exhibits. It might not hurt to have the ability to turn it OFF, just to cover unusual use cases.
branded landing page	ON	Again, a defining feature of an exhibit. Being able to turn it OFF would allow more flexibility, but I'm not sure a curated display set without a branded landing page shouldn't actually be another kind of display set.
ability controls	ON
creators	any logged in user
managers can...	see global configs
depositors can...	see global configs
viewers can...	see global configs	Assumes an exhibit display set can include works with various levels of visibility; the viewer would see works that viewer is allowed to view based on that viewer's privileges (i.e., a public viewer would not see exhibit display set items with visibility = institution-only, but an authenticated user of that institution would. both types of users would see all items with visibility = open access).
workflow controls	N/A
APO controls	OFF	Depends on how we view exhibit display sets. I like the idea of them being completely read-only sets, so no work metadata editing or APO control changes would be done through the display set. But this probably needs more discussion to assess the pros and cons.

Actions Related to Exhibit Display Sets:

As a logged in user, I can create an exhibit display set to feature works from throughout the repository.
As the creator of an exhibit display set, I can add managers (who can edit set metadata as well as add and remove works from it) and depositors (who can add and delete works but not edit set metadata) to help me curate the display set.
As a creator of an exhibit display set, I can set the visibility of the display to public when I decide it is ready to be discoverable. I and any co-managers/depositors should be able to develop the display set over time before it becomes discoverable.

Use Case 5: User Collections

The global Display Set configurations effect all Display Sets. The following defines settings that have User Collections operating as they do currently.

	Global Configuration	Comments
multiple membership	ON
nestable	OFF	NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections.
browsable	OFF	NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections.
branded landing page	OFF	NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections.
ability controls	OFF	manager, depositor, and viewer all set to CREATOR NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections.
creators	any logged in user
managers can...	see global configs
depositors can...	see global configs
viewers can...	see global configs
workflow controls	N/A	It is ok that this work will not be done in the first pass.
APO controls	ON	visibility/discoverability is defined per set NOTE: Some sites might want to turn this ability off, limiting the ability to make PUBLIC display sets to users with a particular role or in a particular group.

Actions Related to Display Sets:

As a logged in user, I can create a user collection to organize my works.
As a creator of a user collection, I can set the visibility of the collection to public such that it will be discoverable.

NOTE: The definition of what you can do with a user collection may be expanded to include some of the new Display Set functionality. For instance, there is no reason to not allow users to nest their collections.

Phase 2: Extended Functionality for Display Sets

(Not part of initial implementation.)

Display Set Types

Due to the fact that there are widely varying use cases for Display Sets, is it desirable to be able to define types of Display Sets. For example, a site may want to use Display Sets for curated exhibits which is limited to select staff AND use Display Sets for user collections which is open to all logged in users to allow them to organize their works. By having Display Set Types, each type can have its own configurations controlling available functionality and who can create each type.

Custom Metadata

This is metadata that would only be visible on the show page for a work when it is displayed in the context of the Display Set.

Questions:

What does it mean to view the show page for a work in the context of a Display Set?
Where would the custom metadata be stored? As part of the work, or as a separate object?
What happens to the metadata when the work is removed from the Display Set?

Administrative Support

Notify Display Set admins when the Display Set becomes empty. This facilitates cleanup of empty Display Sets.

Connecting a workflow to a Display Set

There are use cases for Display Sets that would like to include support for workflows. Associating workflows directly with a Display Set brings several challenges...

If a work is in more than one Display Set, which one defines the workflow for that work?
If a Display Set is nested in another Display Set, does the child set inherit the workflow and/or APO from the parent set?

Proposed solutions

Solution 1:

As part of the configuration for Display Sets, an association can be made with an Admin Set. The Admin Set will have a selected workflow and/or APO. The impact of making an association between a Display Set and an Admin Set will be...

- Adding a work to the associated Admin Set only happens when a work is created directly in the Display Set.
- If a work is moved from one Display Set to another, there is no changed to the Admin Set membership of that work.
- If a work is added to a second Display Set, there is no change to the Admin Set membership of that work.
- If an existing work is added to a Display Set, there is no change to the Admin Set membership of that work.

This is following a basic principle that if a work is already in an Admin Set, then that membership will not be effected by any action taken with regard to membership in Display Sets.

Challenges:

- It may be confusing to the end user if some of the management happens through the Admin Set UI and some through the Display Set UI. For example, to set users/groups that serve particular roles, you would have to edit the Admin Set. To set metadata, you would edit the Dispay Set.
- To have a different set of participants acting as managers, depositors, and viewers for each Display Set, there will have to be an Admin Set per Display Set.

Potential solution for both:

- Tightly couple the Display Set with an Admin Set. That is, every display set created also creates an Admin Set. The UI could hide this fact by having a Display Set UI that shows the workflow, APO, and participant configurations from the Admin Set in the Display Set edit UI.

Solution 2:

Display Sets can control a work with the following set of rules...

- One and only one Display Set can control a work.
- Other Display Sets can have the work as a member, but will not control the work.
- Control can be transferred to a different Display Set by moving a work from one Display Set to another.

The Display Set will have a selected workflow that controls any works that Display Set controls.

Challenges:

- What happens when a work is defined in an Admin Set with workflow A and in a Display Set with workflow B?

Solution 3:

A combination of the two.

QUESTION: When a completed work is edited, does it go back into the workflow? For DSpace, the retracted item has to be reentered from the start. It is desirable for the work to go back into the workflow.