Configurations of Typical Collection Types
Table of Contents
Typical Collection Types
The effort to extend and consolidate the concept of collecting works revealed the need to have multiple types of collections in order to meet the broad set of use cases. Based on existing code and identified use cases, the following were identified as typical collection types.
Admin Sets
An administrative grouping of works that an administrative unit is ultimately responsible for managing. The set itself helps to manage the items within it. There are multiple use cases that Admin Sets are attempting to fulfill. This document shows how to implement existing Admin Set functionality as a collection type and a different configuration of Admin Sets with a goal of using them as a policy enforcer for visibility.
Current Implementation
Because works can belong to one-and-only-one Admin Set, it is being used as a template for new works to assign workflow and initial visibility settings. These serve as templates and once applied to a work are no longer controlled by the Admin Set.
NOTE: To address the need for a default workflow which is currently filled by the requirement that a work MUST belong to an AdminSet which may be the default AdminSet with a default workflow, the system configuration could have a default workflow. It is also worth noting that some sites prefer to assign the workflow based on work type instead of membership in an AdminSet or other collection. We may want to revisit workflow assignment.
Visibility Policy Enforcement
An alternate view of Admin Sets is as a controller of the visibility of works that are restricted by an external policy from a publisher, content owner, or other agency. In this case, workflows are not assigned by the Admin Set and visibility is tightly controlled such that any changes to the visibility policy in the Admin Set will also change visibility of all works in the Admin Set.
User Collections
An intellectual grouping of works, primarily used by individual users to create groups of items or favorites. How these are configured will depend on the application. Two examples are shown. To see what kinds of choices might be made, we will look at the Discovery configuration.
User Collections for a self-deposit site
In this case, general users who self-register for the system are providing all the content. They are building collections that may have value to the public. These user collections are discoverable by the public.
User Collections in a staff curated site
In this case, the content that is discoverable by the public are Exhibit type collections. Staff curate the content that go into exhibits. User Collections in this site are used by staff to organize work they are responsible for in what ever way makes their work easier. These personal collections are not exhibits for public view and are not discoverable.
Exhibits
A grouping of existing works into an exhibit oriented toward display of content to end users.
General Nested
Provide the ability to nest collections for the purpose of organizing content. Several use cases fall into this category and have significant overlap of requirements. These include DSpace migrated content (i.e. Community → Collection), organization unit based collections (e.g. University → School → Department, Agency → Sub-agency, etc.), and general nesting for organizing materials.
Configuration Comparison
NOTE: The configurations specified here are the typical configurations that would be used for each type of collection. A site can configure each type as needed for their application. A site can also configure custom types that beyond those listed. A site can create and configure one or more collection types as needed for their use cases.
1 To demonstrate how sites may define a type differently, User Collections are defined from the perspective of a site that is serving general users for self-deposit (matches current implementation) and a site that is facilitating staff responsible for curating exhibits.
Configuration | Description | Admin Sets (Current Implementation) | Admin Sets (Visibility Policy Enforcement) | User Collections (self-deposit site)1 | User Collections (staff curated site)1 | Exhibits | General Nested | Comments |
---|---|---|---|---|---|---|---|---|
General Settings (√=ON | X=OFF) | ||||||||
Nestable | Allow collections to be nested (a collection can contain other collections of this type) | X | X | X | √ | X | √ | This purely top-down (e.g. A → B → C). Circular membership (e.g. A → B → C → A) is NOT allowed. |
Multiple membership | Allow a work to belong to multiple collections of this type | X | X | √ | √ | √ | √ | |
Require membership | A work must belong to at least one collection of this type | √ | X | X | X | X | X | |
Discovery | Allow collections to be discoverable | √ | X | √ | X | √ | √ | |
Sharing | Allow users to assign collection managers, depositors, and viewers for collections they manage. | √ | √ | √ | √ | √ | √ | |
Workflow | Allow collections of this type to assign workflow to a new work | √ | X | X | X | X | √ | NOTE: If multiple collections of any type could set the workflow, then the user must select one as the primary collection. |
Visibility | Allow collections of this type to assign initial visibility settings to a new work | √ | X | X | X | X | √ | NOTE: If multiple collections of any type could set the visibility, then the user must select one as the primary collection. |
Control Visibility | Visibility of works in this collection are controlled by the settings in the collection | X | √ | X | X | X | X | NOTE:
|
Participants - assign users and groups - typically assigned to... | ||||||||
Managers | Managers can edit all collections of this type, including adding to and removing works from a collection, modifying collection metadata, and deleting collections. | site admins | site admins | site admins | site admins | site admins | site admins | |
Creators | Creators can create and manage their own collections of this type. | site admins | site admins | Any User | Any User | privileged users | privileged users |
Frequently Asked Questions
Are any of the collection types going to be predefined and delivered with Hyrax out of the box?
Admin Sets will be a collection type that is delivered out of the box. By default, it will follow the configuration in the column Admin Sets (Current Implementation). The name is shifting slightly to be Administrative Collections. Sites will be able to override some of the configurations (e.g. Discovery, Sharing, Participants → Managers, Creators), but others will not allow changes (e.g. Nesting, Multiple Membership, Required Membership, Workflow, Visibility).
Why do Admin Sets still require membership?
This decision was made to limit the impact to existing Hyrax applications and the considerable design work that has been done around Admin Sets.
I don't want users to select Admin Sets. How can I do that?
Many sites do not surface Admin Sets to users and are only using the default Admin Set with a single workflow that applies to all works. You will be able to continue to use Admin Sets in this way.
Can my site have more than one collection type?
Yes. You can define as many collection types as you need. It is anticipated that sites will only need a few collection types (e.g. 1-5). If you have a use case that needs significantly more, we'd be interested in hearing about it.
Do I have to use the names of the collection types shown in the table?
No. You can name your collection types what ever is appropriate for your site. You cannot have two collection types with the same name.
Can I define User Collections differently than that shown?
Yes. You can define all types as appropriate for your site. The configurations shown are typical based on known use cases, but you can see even from the table that there are two interpretations of User Collections shown.