Requirements - Display Sets
Table of Contents
NOTE: The term Display Sets is being replaced with the generic term Collection.
Milestones
| Priority | Requirement | Description | Use Case | Comments |
|---|---|---|---|---|
Milestone 1 core -- critical core concepts representing the minimal functional requirements | ||||
| Critical | Nestable | A Display Set can have another Display Set as a member. | 1: Agencies/Sub-agencies 2: Communities and collections 3: Nested Collection | Is this purely top-down (e.g. A - B - C), or can there be circular membership (e.g. A - B - C - A)? Decision: Purely top-down Can Display Sets have members that are Display Sets and works at the same time? Decision: Leave flexible to avoid being pre-scriptive; potential implementation of configuration to allow a site to specify |
| Critical | Multiple membership | A work in a Display Set can also be a member of any other Display Set. | 2: Communities and collections 4: Curated Exhibit | |
| Critical | Add Existing Works | Select any work that is discoverable and accessible by (at least some) viewers of the repository to be part of a display set | 4: Curated Exhibit | Will the relationship be isMember or a link to existing works, more like an alias? Decision: implementation detail TBA Select via Dashboard → My Works → checkboxes → Add to Display Set (or Add to Collection) |
| Critical | Global Configuration - creators group, nestable, allow_multiple_membership | Configuration controls global characteristics about Display Sets. At the minimum, this includes:
| 1: Agencies/Sub-agencies | Effects all Display Sets |
Milestone 1 UI -- search and discovery extensions | ||||
| High | Basic Landing Page - Branding | A landing page with custom branding per Display Set | Minimal Set of branding customization:
| |
| High | Discovery | Display Sets and member works can be discovered through regular app wide search. | Allow for visibility setting of private such that the Display Set is not discoverable while it is private. The work visibility is controlled by that work. | |
| Moderate | Search within Display Set (basic) | Search results are limited to work in a Display Set | 1: Agencies/Sub-agencies | Would be nice for those migrating from DSpace. Departments love this. Would the search results include sub-Display Sets? YES eventually - see Search within Display Set (extended) |
Global Configuration (extensions) - discoverable | Configuration controls global characteristics about Display Sets including:
| 1: Agencies/Sub-agencies | Should the configuration be: discover display set | discover works in display set | discover all | |
Milestone 2 core -- moderately complex core features | ||||
| High | Direct Work Creation | A single work can be created directly in a Display Set. | 1: Agencies/Sub-agencies | Adds a New Work button to the Display Set landing page that is visible to D |
| High | Participants | Allow creator/manager to set participants (e.g. Managers, Depositors, Viewers). | See Sufia wiki documentation on Understanding Admin Sets Participants
Questions:
| |
Global Configuration (extensions) - allow_participants | Configuration controls global characteristics about Display Sets including:
| 1: Agencies/Sub-agencies | If false, the participants tab is not shown for Edit Display Set | |
Milestone 2 UI -- more extensive UI extensions | ||||
| High (comes as part of nested display set) | Hierarchical Browse | Browse from top most Display Sets to member Display Sets? | 1: Agencies/Sub-agencies | Do we define top-most to be any Display Set without a parent or is there a default parent? Decision: Make the decision during implementation. Has UI implications. Metadata field has Display Set field which can be used to get to all members. Decision: This is an implementation detail of the use of is_member_of property in a way consistent with hydra::work is_member_of hydra::works::collection. Has UI implications. Example: Browse from Display Set to its members. Browse from member work/set to parent Display Set. Would it help to mention facets and pivoting here? That is, there would be a facet for top level display sets. If a display set has another display set as a member, the member display set shows up in the first browse limited by the top level facet. I believe this is called using a pivot field with hierarchical faceting in Blacklight?https://github.com/projectblacklight/blacklight/blob/1640c0cb4b1bd54c00c6ea647083e617dbb600d5/lib/generators/blacklight/templates/catalog_controller.rb#L78 (comment by newmanld) Decision: There will be a facet from a Display Set to its members. Need more information on pivoting. |
| Moderate | Search within Display Set (extended) | Search results are limited to work in a Display Set AND any of its member Display Sets | 1: Agencies/Sub-agencies | Adding on deep search of nested display sets. |
Moderate | Work - Link to All Locations | On the show page for a work, it lists all Display Sets and other collectors (i.e. Admin Sets, User Collections) where the work also lives AND that the user has access to view. | 4: Curated Exhibit | Links to other locations will not be displayed if config.show_other_collections == false |
Global Configuration (extensions) - browsable, show_other_collections | Configuration controls global characteristics about Display Sets including:
| 1: Agencies/Sub-agencies | ||
Milestone 3 - lower priority features (will review all remaining requirements before proceeding) | ||||
| Low | Display Set Types | Configure characteristics that define a display set type (e.g. User Collection, Curated Exhibit, Nested Collections, etc.) | This will allow sites to have display sets with different characteristics in the same repository. For example, a site may want to allow any user to create User Collection types, but only certain users can create Curated Exhibit types. The configurations may have discoverable=false for User Collections and discoverable=true for Curated Exhibits. Site admins can configure and name the various types allowed for their site. Global configurations will effect all Display Sets. Display Set type configurations can make the global configurations more restrictive, but cannot make them more permissive. For example, if the global configuration has browsable==false, then the configuration for a display set type cannot set browsable=true. The Display Set Type is selected when the Display Set is created. Questions:
| |
| Low | Custom Metadata | Additional metadata fields are included in any work in a given Display Set. And/Or order is determined by the Display Set. | IR | Do we want to implement this on the first pass? Decision: Implement in a second pass of implementation. There may be substantial architectural changes required. What happens to those fields if the work is removed from the Display Set that added the fields? Are the custom fields of one Display Set shown in other Display Sets? Are custom fields stored in the work? IR: working id field Available in Spotlight now. Definitely used. |
Customizable Facets | A custom set of facets that are shown on the landing page for the Display Set. | Requested by Steve Van Tuyl for Oregon Digital project. | ||
| Low | Batch Upload | Multiple works can be created directly in a Display Set via batch upload process. | 2: Communities and collections | Is this functionality working in base Sufia now? |
| Low | Administrative Notifications | Notify Managers and site Admins of empty Display Sets | Notify Display Set admins when the Display Set becomes empty. This facilitates cleanup of empty Display Sets. | |
Milestone 4 - Complex with significant overlap with Admin Sets | ||||
Workflow Control | Any work created directly in a Display Set will be assigned the configured workflow. | 2: Communities and collections | What happens if the work is placed in a second Display Set with conflicting workflow controls? | |
APO Control | An Admin Policy Object (APO) can be configured for a Display Set. Any works added to the Display Set have their visibility controlled by the APO. | 2: Communities and collections | Need to confirm, but I believe that APOs for Admin Sets serve more as a template where the visibility characteristics are copied to the work. At that point, editing the work can change its visibility. It is no longer controlled by the APO. A change to the APO will not effect the work. | |
Associated Admin Set | A work created in a given Display Set is automatically added to the mirrored Admin Set. Workflows and permissions of the Admin Set are applied to the new work. | This is assigned at creation time. If the work is added as a member of other Display Sets or is moved to another Display Set or removed from all Display Sets, it continues to be a member of the Admin Set until the work is manually moved to another Admin Set or deleted. | ||
Use Cases Milestone Requirements
For each use case, what milestone would need to be completed before you could make a viable implementation? The milestones will be completed in order.
| Use Case | Milestones Required | Additional Milestones Desired | Comments |
|---|---|---|---|
| Agencies & Sub-agencies | 1 core+ui | 2 ui | It would also be nice to have Milestone 3 Display Set Types, but not required. |
| DSpace Communities & Collections | |||
| Nested Collections | 1 core+ui 2 core+ui | ||
| Curated Exhibits | 1 core+ui | 2 core+ui 3 | One or two features from each of 2 core+ui and 3 would be minor enhancements for the Curated Exhibits use case. |
| User Collections | N/A | N/A | User Collections exist now and will be the base code for Display Sets. |