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.
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.
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.
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.
A grouping of existing works into an exhibit oriented toward display of content to end users.
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.
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.
|Admin Sets (Visibility Policy Enforcement)||User Collections|
|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|
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|
- Only one collection type can be configured to control visibility.
- A change to the settings in the collection will cause all works in this collection to have their visibility updated.
- Visibility settings in the work are LOCKED and cannot be changed from the work.
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||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.
Click here to see additional features usage by collection type...
The following list shows features that are available to all collection types. They are not configured. The marks in this section show expected usage of these features.
|Admin Sets (Visibility Policy Enforcement)||User Collections||Exhibits||General Nested||Comments|
Other features that are not configured
|Hierarchical Browse||Browse from top most sets to member sets?||N/A||N/A||?||N/A||√|
|Branded Landing Page||Provides the ability to customize a landing page for each set.||N/A||N/A||N/A||√||√|
Minimal branding customization:
- logo - possibly multiple logos for joint ventures
- description - including basic html that can have links
|Search within Set - public search||Search results are limited to resources in a set and any of its member sets||√||N/A||N/A||√||√|
AdminSets - Admin Sets are faceted and allow for search within.
User Collections - Are user collections faceted?
|Search within Set - dashboard||Search on My Works and results are limited to resources in a set and any of its member sets||√||√||√||√||√|
|Add Existing Resource||Any resource that is discoverable and accessible by (at least some) viewers of the repository can be selected to be a member. ||MOVE||MOVE||√||√||√|
AdminSets - A resource can belong to one and only one Admin Set. And there is a default Admin Set to which all unaffiliated resources are assigned. So adding an existing resource is really a move from one Admin Set to another in all cases.
|Resource Creation||A single resource can be created directly in a set.||√||√||√||√||√|
|Batch Upload||Multiple resources can be created directly in a set via batch upload process.||√||√||√||√||√||Need to verify for Admin Sets and User Collections|