With so much work on Admin Sets now (autumn 2016), it's worth documenting the current understanding of how "nested collections" ought to work. This document attempts to explain in functional terms what the needs are. Note that Admin Sets are not based on PCDM.

Use Case 1: Agencies and Sub-agencies

The top-level collection is an agency (a data provider). Some of these agencies have sub-agencies, so the nested collection is the sub-agency. 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 or querying the top-level agency, a user should be able to see all works in the top-level agency and all 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?

 

---

 

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?
• The document shows a resource (item) belonging to multiple Collections.  Is that a critical requirement?  That conflicts with the current implementation of admin 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)