Issue 1 of the Collection Extensions blog
Collection Extensions is an effort to create a consistent and flexible approach for grouping items in Hyrax repositories. Implementation sprints are beginning Aug 7, 2017 (sign-up).
...
Use Cases
What is your use case for collecting together works? The Collection Extensions Requirements Working Group identified several use cases.
...
- assign Collection Managers (groups or users) who can edit collections other users have created, including adding to and removing works from a collection, modifying collection metadata, and deleting collections
- assign Collection Creators (groups or users) who can create and manage their own collections
Footnotes:
1 Based on use cases identified so far, it is expected that the number of collection types will be less than 5. If you have a use case requiring more, please let me know. A large number of collection types has an impact on UI design.
2 The only use case identified for required membership is Admin Sets. Let me know if you have a use case for more than one collection type in a system requiring membership (i.e., all works must be a member of collection type Admin Set AND all works must be a member of collection type A).
3 The Advanced configurations are not expected to be part of the original sprint. More information on these will be included in a later blog post.
Basic Configuration Process
The process for defining and configuring a collection type is quite simple.
Step 1: Add a configuration type by assigning a name and clicking Add (mockup)
Step 2: Define configurations (mockup)
Example Configurations - User Collections and Exhibits
...
| Current User Collection features (for reference) | User Collections for a self-deposit site | User Collections in a staff curated site | Exhibit |
|---|---|---|---|
|
|
|
|
For a self-deposit site, there may be only one collection type defined, that is, the User Collections for a self-deposit site.
...
NOTE: Your site may define User Collections and Exhibits different than what is presented here.
...
FAQ
| Table of Contents | ||||
|---|---|---|---|---|
|
What about Admin Sets?
Admin Sets can be viewed as a collection type. For the initial implementation, the code controlling and managing Admin Sets will remain the same. Sites cannot change the configuration of Admin Sets. The configuration is defined by the code implementing the behaviors of Admin Sets. Effectively, the configuration is...
| Admin Sets (effective) configuration |
|---|
Basic:
Advanced:
|
UI changes
Since these configurations and the grouping functionality is consistent with the concept of Collections, the UI is being adjusted to show Admin Sets to users as though they were implemented as just another collection type. The UI adjustments include...
...
- Changes at this level to Admin Sets would require migration for existing sites.
- There is a lot of work required to create the extended functionality for collections. We don't want to add more if we can avoid it.
- We want to be sure that the collection extensions are solidly in place before requiring sites to migrate to Admin Sets as a collection type.
- All this is designed to minimize churn for those already moving toward production with Hyrax using the current definition of Admin Sets.
...
What happens when a configuration is changed and collections of that type already exist?
| Less Restrictive (from Not-Allowed to Allowed) | More Restrictive (from Allowed to Not-Allowed) | |||
|---|---|---|---|---|
| Easy approach... | Moderate approach... | Difficult approach... | ||
| NESTABLE | No impact | Warning that any collections already nested will remain nested. | Warning that includes a count of the number of collections impacted. | Warning + count + page to help with reconciliation. |
| MULTIPLE MEMBERSHIP | No impact | Warning that any works already in collections of this type may continue to belong to multiple collections. | Warning that includes a count of the number of collections impacted. | Warning + count + page to help with reconciliation. |
| DISCOVERY | Requires action to make existing collections discoverable | Warning that collections already marked PUBLIC will remain discoverable. | Warning that includes a count of the number of collections impacted. | Warning + count + page to help with reconciliation. |
| REQUIRE MEMBERSHIP | No impact | Warning that works already created may not be in a collection of this type. | Warning that includes a count of the number of works impacted. | Warning + count + page to help with reconciliation. |
| SHARING | No impact | Warning that works already created may have sharing privileges assigned. | Warning that includes a count of the number of works impacted. | Warning + count + page to help with reconciliation. |
| WORKFLOW | No impact to existing works.New works will be assigned a workflow. | No impact for existing works. New works will not have a workflow assigned by collections of this type. | ||
I would expect that these might change during development, but would stabilize by the time the system goes into production. The easy approach may be sufficient.
NOTE: Changes to Workflow and Visibility do not have an impact. They are used as templates when a work is created. After that point, they do not control any aspect of the work. The changes will only effect new works created after the change.
...
This is the first of several blog posts intended to raise awareness of the implementation effort to expand the functionality of collections. Please don't hesitate to ask questions and get clarifications. That will allow for better communication and solidify the design.
...