#2 Collection Permissions

Owned by Bill Branan
Jun 16, 2017

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