NOTE: In this context, the use of the term collection does not imply User Collections as implemented in Sufia. Collection is used in it's generic form as a grouping of items. The complete definition of Display Sets is TBA.

Use Case 1: Agencies and Sub-agencies

(Submitted by Lynette Rayle)

The top-level collection is an agency (a data provider). Some of these agencies have sub-agencies which is a collection that is a member of the agency collection. Both agencies and sub-agencies can hold works. The layering here is useful in terms of navigation: a user should be able to view top-level agencies together and be able to drill down into sub-agencies. Additionally, a search for everything in an agency will return works in the agency and all sub-agencies under that agency.

Requirements

Both top-level agencies and sub-agencies may contain works.
A work may not belong to multiple agencies or sub-agencies.
When viewing a top-level agency, a user should see all works in the top-level agency and a list of sub-agencies.
When querying the top-level agency, the result set should include matching works in the top-level agency and works in sub-agencies.

Questions

How many layers of nesting are needed?
Do top-level agencies want to assert any controls (perhaps related to visibility, access controls, embargo) over sub-agencies?
If a top-level agency says "all of my works don't get released until 2019" and child admin set says "all of my works are immediately released," and I add a work to a sub-agency, when does it get released?
If a top-level agency says "I use 1-step workflow", should a sub-agency be beholden to its parent, or should it be able to assert a 2-step or 0-step workflow?

University of Michigan: We do not have a use case for agencies and sub agencies.

Use Case 2: DSpace communities and collections

(Submitted by Aaron Collier)

Data currently stored in DSpace will be migrated to a compatible structure in CC or Sufia.

DSpace nested structure:

communities are top level
communities can have sub-communities
communities and sub-communities can have collections
collections can have resources

User interactions related to nesting:

Internal user sees list of communities and drills down through sub-communities to a collection and views an existing resource or adds a resource to the collection.
External user sees list of communities and drills down through sub-communities to a collection and views a resource to the collection.

Features

Reference: Required Feature Matrix (compiled by DSpace/Hydra Interest Group)

Of interest to this discussion:

Mediated Deposit
Admin sets + Hierarchical display of admin sets

Reference: Collection Specs for Hydra Community

This document describes nesting requirements and other assumptions for behavior within a Hydra app for supporting a DSpace type structure.

Questions

Questions from the Collection Specs for Hydra Community document.

DSpace allows for Communities to have Sub-Communities. The document proposes a simplified structure with only top level communities that can have collections. Is this sufficient?
- University of Michigan: No, we have a use case where sub communities are required to serve our University archives
The document shows a resource (item) belonging to multiple Collections. Is that a critical requirement? That conflicts with the current implementation of admin sets.
- University of Michigan: Yes, this is a critical requirement, Items must be able to appear in multiple collections [as achieved in DSpace via the mapping function].

University of Michigan: Restrict access to items in communities or sub communities by IP [e.g. for a specific building] or user groups like current faculty, students, and staff
University of Michigan: The default setting for communities and collections can be edited by admin. (Is this handled by Admin Sets?)
University of Michigan: Batch upload into Display Sets?

Implementations requiring multiple level of communities:

Cornell University Library → Albert R. Mann Library → Agriculture and Life Sciences Publications → Journal Price Study Core Agricultural and Biological Journals (Cornell University)
CSUN ScholarWorks → CSUN Centers and Institutes → Bookstein Institute → Tax Development Journal (California State University Northridge)

Use Case 3: Nested Collection

(Submitted by Linda Newman)

A content submitter/depositor with several hundred items has created a parent collection - the "Global Marine Biodiversity Archive". This is a self-submitted user set of nested collections grouped by subject. Within that top-level collection, they have eight (more to come) sub-collections. At least one collection "Crinoidea from Jamaica" has a sub-sub collection, "Crinoid Habitat, Discovery Bay" as well as works that are direct members of "Crinoidea from Jamaica."

Of interest to this use case:

Hierarchical display/browse as well as searchability/discovery at each collection level, of all sub-collections and works below that level.

Comment from Linda: This is a case of a user collection that requires nesting. I am not sure that user collections and display sets need to be different entities in the UX. ND/Ruth: There might be some permissioning/UI stuff which would need to be built in but I agree that functionally these are essentially the same.

University of Michigan: We do not have sub-collections within collections. This would be a useful option to have (and captures some/all of the functionality requested in Use Case 1?) but is not a requirement for us.

University of Notre Dame: This reflects our current LibraryCollections functionality (developed summer 2016) fairly well. We create the collections ahead of time by creating top-level first and each layer of nesting afterward (we can always add sub-collections later). We then deposit or update objects and assign them to one or many sub-collections (as appropriate by grouping...mostly they just go in one). In the public interface, you can search within any collection or subcollection. In theory you can nest ours infinitely, but it's rarely reasonable. We do not have a way to manage these collections from within the user interface, mostly because of the development time involved, everyone who manages these collections can use the batch ingester.

We'll need to be able to have this same functionality after migration. More on our LibraryCollections here.

Use Case 4: Curated Exhibit

(Submitted by Hannah Frost)

A curator has selected fifty items from ten collections (admin sets) in the repository to be presented for discovery and access as an "exhibit" highlighting key resources in a multi-disciplinary field of study. This content and curators of the exhibit may evolve over time as repository source items accumulate, so multiple users may be permitted to add/remove items to keep the exhibit current.

Key points:

Any repository resource that is discoverable and accessible by (at least some) viewers of the repository can be selected to be part of a display set
An item in a display set can be linked back to its "home" in the repository - original discovery context is not lost
- Can also be linked to its place in other display sets
The owner of the display set is a shared and transferable role
The ability to curate the exhibit (manage the display set) can be based on display set-level group permissions, and is not tied to an organizational structure imposed by a system outside of the repository (ie, faculty in English and faculty in Computer Science can curate the same exhibit)

Use Case 5: User Collections

(Submitted by Caroline Cole, Jeremy Friesen)

If Display Sets and their extended functionality replaces User Collections, then there still needs to be an ability for sites to have the equivalent of User Collections using Display Sets.

Browser not supported