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

Browser not supported