Use Case 1: Agencies and Sub-agencies

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

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 

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

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.