#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