Comments on High Priority Use Cases

It might seem that Use Case 2 (Master Thesis) and Use Case 4 (ETDs) are similar however the former would probably be more dependent on an administrative set than the latter.

Like Indiana, we will continue to keep OPAC and library-managed content on a separate system (Virgo), but there are many parallels in these "IR" use cases for user-managed collections that could be applied to librarian-managed collections. Ideally, I would like to progress Virgo and Libra so that they are implemented with the same code base and differ only by configuration.

Comments on Key Questions

Who can create an admin set?

If an administrative set is a type of collection (assuming prior thoughts on this still applies), then it wouldn't be unreasonable to assume that anyone with permission to create a collection would be able to create an administrative set. In practice, though, there might be reasons why an institution would want to limit this ability. For that reason, the current session should be checked to determine whether the associated user and/or group(s) are authorized to create administrative sets.

Can a general user specify an admin set to deposit into?

See below.

Can a user choose "no admin set"?

See below.

If a particular admin set is chosen who approves it?

See below.

Should Curate be able to work without using admin sets at all?

Yes.

What roles need to exist for use in admin sets?

To support the ability for a given user or group to be a participant in zero or more administrative sets and to make allowances for future enhancements:

Creator capabilities [NOTE 1]

- Create an administrative set

Owner capabilities

- Modify metadata for the administrative set
- Modify presentation of the administrative set [NOTE 2]
- Hide the administrative set [NOTE 3]
- Un-hide the administrative set
- Delete the administrative set [NOTE 4]
- ...plus all Editor capabilities

Editor capabilities

- Add a new work to be owned by the administrative set [NOTE 5]
- Include a reference to an existing work in the administrative set [NOTE 6]
- Hide administrative set works/collections
- Un-hide administrative set works/collections
- Create collections in the administrative set
- Remove collections from the administrative set
- Add a work/reference to a collection
- Remove a work/reference from a collection
- Remove a reference to a work from the administrative set
- Remove a work submitted to the administrative set [NOTE 7]
- Remove a work owned by the administrative set
- Delete a work owned by the administrative set
- ...plus all Reviewer capabilities

Reviewer capabilities

- Approve a submission to the administrative set
- Reject a submission to the administrative set
- ...plus all Member capabilities

Member capabilities

- View hidden (unreleased) works
- Comment on hidden (unreleased) works
- ...plus all Contributor capabilities

Contributor capabilities [NOTE 8]

- Submit a work for inclusion in the administrative set
- Modify a submission to the administrative set
- Withdraw a submission to the administrative set
- ...plus all general user capabilities

[NOTE 1] The ability to create administrative sets would be unrelated the role of owner of any specific administrative set.

[NOTE 2] Potential future capability to allow the administrative set owner to have some control over how the works/collections are presented.

[NOTE 3] To allow the owner to take the set "offline" while changes are being made

[NOTE 4] Whether "deletion" means actual purging from the repository would be subject to site policy configuration.

[NOTE 5] The "current" owner would be set to the internal user/group defined as the owner of the administrative set.

[NOTE 6] Like a symbolic link, the reference would be an item controlled within the administrative set but the referenced work would not be.

[NOTE 7] Removing a submitted work would result in the "original" owner becoming the "current" owner.

[NOTE 8] Allows for the possibility that non-members of the group could submit works for inclusion in the administrative set.

How granular should those roles/permissions be?

Higher granularity would make it possible for institutions to specify the capabilities associated with each role according to their specific situations,

Can admin sets hold other admin sets?

If an administrative set is a collection, and collections can contain collections, then it would follow that administrative sets could hold administrative sets. However, there are a lot of details regarding how to handle permissions within such a hierarchy and this would have to be designed with some care. I would say that (a) the implementation should not preclude the possibility but (b) it should not actually be implemented until we know that this is a capability that is definitely needed.

Is there a hierarchy of collections?

If the question is whether there should be a default "root" collection which would own all items not otherwise in a collection, then I'm not sure whether this would be necessary (unless there is something in the underlying implementation that would make this a useful strategy).

Do we need administrative units?

I'm not sure what this means in this context. I think that an administrative set would be associated with one or more roles (Owner, Editor, Reviewer, Contributor) and that each of those role would be associated with zero or more users and/or groups.

Can an admin set be ordered?

Yes, but that seems like a capability that would be useful for collections in general.

Can an item belong to more than one admin set?

Probably not – conceptually a work would have only one "owner" at a time.

Browser not supported