Child pages
  • Requirements - Display Sets
Skip to end of metadata
Go to start of metadata

Table of Contents


Prerequisite...  Determine terminology that will be presented to the user.

Option 1: Stay with generic term Collection and extend 'User' Collections to include the Display Sets requirements. 

Option 2: Go with term Display Sets where User Collections become one type of Display Set.


Milestones

PriorityRequirementDescriptionUse CaseComments

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 resource in a Display Set can also be a member of any other Display Set.

2: Communities and collections
4: Curated Exhibit
 
Critical

Add Existing Resources

Select any resource 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 resources, 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:

  • who can create Display Sets:  group id
  • allow_nestable: true | false
  • alow_multiple_membership: true | false

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

 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:

  • logo - possibly multiple logos for joint ventures
  • public landing page vs. show page for display set management
  • description
    • basic html that can include links
  • how browse, search, facet from the Display Set landing page
High

Discovery

Display Sets and member resources 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 resource in a Display Set

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

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:

  • discoverable: true | false

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

Should the configuration be: discover display set | discover works in display set | discover all

Milestone 2 core -- moderately complex core features

 High

Direct Resource Creation

A single resource 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

  • add a Participants tab in Edit Display Set to specify participants
  • allow Managers and Depositors to select the Display Set on the Relationships tab for New/Edit forms
  • show New Work on landing page if user is Manager | Depositor
  • give users edit_access of the Display Set when added as a Manager participant
  • give Managers edit_access for any work created directly in the Display Set
  • give Viewers read_access for any work created directly in the Display Set

Questions:

  • What happens if the user also selects an Admin Set that has participants specified?  Will this be additive?  Seems like YES is the easiest approach.  There will always be an Admin Set assigned for New works, with the Default Admin Set assigned if none specified.

Global Configuration (extensions) - allow_participants

Configuration controls global characteristics about Display Sets including:

  • allow_participants:  true | false

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

 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
2: Communities and collections
3: Nested Collection

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 Linda Newman)  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 resource in a Display Set AND any of its member Display Sets

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

Adding on deep search of nested display sets.

Moderate

Landing Page - Link to All Locations

On the landing 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:

  • browsable: true | false
  • show_other_collections: true | false

1: Agencies/Sub-agencies
2: Communities and collections
3: Nested Collection

 

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:

  • Can the type be changed?  What impact does that have if the configurations are not compatible? 
  • What impact does it have if the type configurations are modified after display sets of that type have been created?
Low

Custom Metadata

Additional metadata fields are included in any resource in a given Display SetIR

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 resource 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 resource?

IR: working id field

Available in Spotlight now.  Definitely used.

 Low

Batch Upload

Multiple resources can be created directly in a Display Set via batch upload process.2: Communities and collectionsIs 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 resource created directly in a Display Set will be assigned the configured workflow. 2: Communities and collections

What happens if the resource 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 resources added to the Display Set have their visibility controlled by the APO. 2: Communities and collectionsNeed 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.
 

Associated Admin Set

A resource 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 resource.  This is assigned at creation time.  If the resource 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 resource 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 CaseMilestones
Required
Additional
Milestones
Desired
Comments
Agencies & Sub-agencies

1 core+ui
2 core

2 uiIt would also be nice to have Milestone 3 Display Set Types, but not required.
DSpace Communities & Collections


Nested Collections1 core+ui
2 core+ui


Curated Exhibits1 core+ui2 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 CollectionsN/AN/AUser Collections exist now and will be the base code for Display Sets.
  • No labels

2 Comments

  1. Regarding options 1 and 2 at the top of the page.  I think 'display set' contrasts with 'administrative set' to convey our intentions within the PCDM framework.  But in the UX interface, I think submitters (non-administrators), both for discovery and creation but especially for discovery, will find the term 'Collection' a much better term.  So +1 to Option 1.

    I think a submitter of content  - for example in a self-submission IR - would understand the term 'collections' better than 'display sets' - and also would understand 'Workflow/Permissions' better than 'administrative sets'.

  2. Adding in comments that I left earlier in Slack:

    I'd think that Hierarchical Browse and Search within Display Set (Extended) are necessary for effective nested collections. Agree that they are more complex to tackle, not sure about deferring them to Milestone 4.