Samvera Community Wiki
#2 Collection Permissions
Group: Lynette Ryle (facilitator), Mathew Barnett, Jeremy Friesen (timekeeper), David Trujillo, Ryan Wick, Mark Bussey (notetaker)
Collections
Columbia Uses
Some collections are transient, temporary batches durning processing
Become part of larger public collections when processing is complete
Alberta
600 Collections in their Hydra repo
Collections can be nested
Various levels of management and visibility requirements
Notre Dame
Collections disabled at this point
Currently using a controlled vocabulary and metadata - can facet of 'collection'
Looking at enabling admin sets
UCSD
Scoping end-user requirements now
Oregon Digital + Sufia 6 based IR
Sets (metadata on item)
Archival collections (metadata on item)
WUSTL (goldenseal - DCE)
User Collections - anyone can create, can contain any item the user has visibility to, can be shared or private
Administrative Collections - Admins can create, works can only belong to one admin collection, can be shared or private
See straw dog at User Collections, Admin Sets, Display Sets
Summarized Requirements
1) Collapse Display sets and User Sets into a single class until specific differentiators occur, possibly add controllable visibility and facet-ability setting to User Sets
Function | User Sets | Admin Sets | Comments (User Sets code exists in Curation Concerns, Admin Sets code exists in Goldenseal) |
|---|---|---|---|
Who can create | Any logged in user | Admin? = true | Existing behavior of curation_concerns |
Can be nested in other User Sets | Yes | No | Need to check current curation_concern behavior for nesting |
Can be nested in other Admin Sets | No | No | Some use cases might like nested Admin Sets - Mark B. asks if we need to represent the top of the hierarchy, but can we just represent the end nodes of the tree? |
Members inherit visibility of parent | No | User is prompted whether to propagate changes on the Admin Set (parent) to members of the set | Need to check current curation_concern behavior for propagating changes - this is probably missing |
Members inherit access grants to parent | No | User is prompted whether to propagate changes on the Admin Set (parent) to members of the set | Need to check current curation_concern behavior for propagating changes - this is probably missing |
Members can belong to multiple User Sets | Yes | Yes |
|
Members can belong to multiple Admin Sets | No | No |
|
Members can be ordered | Yes | No |
|
Sets can contain multiple references to the same work | Yes | No | need to check User Set behavior in Curation Concerns |
Members must belong to an Admin Set | Yes* | Yes* There's probably a default admin set, but it may be totally invisible from an end-user standpoint |
|
Members must belong to a User Set | No | No |
|
|
|
|
|
|
|
|
|
Deferred for future discussion
Default metadata values - could be addressed by metadata template
Default rights, access, etc - could be addressed by object config templates
Faceting requirements, especially hierarchical faceting
Flattening nested collections - overridable default method - depth first, breadth first, ordered, unordered?
Applying "rules" vs. "changes" to hierarchically arranged works - do we try to derive at runtime or apply at
Inheritance of rights when a new object is created in a particular admin collection
Inheritance (or not) of rights when an object is moved between admin collections
Optionally constraining depth of hierarchy
Display of hierarchy context - breadcrumb, full context, near neighbors (parents, siblings, children) ???
Next Steps
Resolve outstanding feature questions (Yellow)
Refactor goldenseal Admin Sets into curation_concerns