Example Usage of Collections and Admin Sets
Basic Premises and Assumptions
- All works must belong to one and only one Admin Set. If the app does not create any, the default Admin Set will be used to hold all works.
- The requirements described for Display Sets will be be extending the current Collection implementation. Hence forth, Display Sets will be referred to as Collections.
- In the initial implementation there will be only one configuration for all collections, which means that apps can only use one type of collection (e.g. user collections OR curated exhibits)
- Later implementation will allow for types of collections, which means that apps can have multiple types of collections (e.g. user collections AND curated exhibits)
- Requirements - Display Sets (NOTE: This document uses the term Display Sets which is synonymous with Collections.)
Scholarsphere - self deposit IR with User Collections
Current Behavior
Scholarsphere currently supports User Collections which allow any user to organize works that they create. There is a single default Admin Set which holds all works in the repository.
New Behavior
End user interactions with Scholarspheres will not be effected by any of the proposed changes. The app could take advantage of some of the proposed enhancements. This will be controlled by the configuration that Scholarsphere chooses to use for collections.
Admin Sets:
- Using the default admin set.
- Workflow: The default admin set uses the default workflow which allows the user to create, save, and publish a work in a single step.
- APO: There are no special APO requirements.
- Participants: None set. Ownership of the work determines access to the work.
- User does NOT need to select an admin set.
Collection Configuration to implement current User Collection behaviors:
| Global Configuration | Comments | |
|---|---|---|
| multiple membership | ON | |
| nestable | OFF | NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections. |
| browsable | OFF | NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections. |
| branded landing page | OFF | NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections. |
| creators | any logged in user | |
| ability controls | OFF | manager, depositor, and viewer all set to CREATOR NOTE: Some sites might want to turn this ability ON. If is OFF to reflect current functioning of User Collections. |
DSpace Migrated Repository
Current Behavior
DSpace has Communities and Collections, where Communities can have member Communities and Collections. And Collections only can hold works.
- uses default admin set
- uses display sets for communities and collections
Simple app - uses default admin set; uses display sets for groupings and organization
App with multiple admin sets
- want to connect workflow to a specific group of users defined in hyrax or by identity management system
- want ability to select all users as depositors
- user chooses a worktype which drives the workflow
- user chooses a collection (aka display set) which drives the workflow
- would like the list of worktypes be limited based on an ability of the user
Sipity type work workflow process
An admin set
- one-to-one work in admin set
- display set between admin set and work
- primary display set or secondary display set
- used when multiple display sets are selected at create time
- user selects which display set is primary
- primary display set or secondary display set
- admin set can be associated with multiple display sets
- display set can be associated with one and only one admin set
- participants role at display set level
- one work can be part of multiple display sets
- workflow defined in admin set