Configurations of Typical Collection Types

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

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:

  • 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

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.







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.



Feature

Description

Admin Sets
(Current Implementation)

Admin Sets (Visibility Policy Enforcement)

User Collections

Exhibits

General Nested

Comments

Feature

Description

Admin Sets
(Current Implementation)

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