#2 Collection Permissions

Owned by Bill Branan
Jun 16, 2017
2 min read

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