Feature Inventory Grid

Table of Contents

1 Model Terminology
2 Features / Requirements
- 2.1 Project Base
- 2.2 User Roles
- 2.3 Metadata
- 2.4 Works
- 2.5 Files
- 2.6 Access Control
- 2.7 Workflow
- 2.8 Branding
- 2.9 Reporting / Notification
- 2.10 Export Utility
3 Example Workflows
- 3.1 Depositing
- 3.2 Modifying Works
- 3.3 Changing Access Controls
- 3.4 Viewing
- 3.5 Administration
4 Example External Controlled Vocabularies
- 4.1 External Controlled Vocabularies
5 Example Reports & Notifications
- 5.1 Reporting (dashboard)
- 5.2 Notifications (email)
6 Potential Definitions of Workflows

Model Terminology

Term	Definition	Comments

Term	Definition	Comments
Collection	Can hold... hasMember - 0..m Collections hasMember - 0..m Works hasFile - 0..m Files Descriptive Metadata	Files attached to collections are used for thumbnails, collection documentation, etc.
Work	Can hold... hasMember - 0..m Works hasFile - 0..m Files Descriptive Metadata
File	Can hold... 1 attached file Technical Metadata
Descriptive Metadata	information describing a Collection or Work	Preference for using commonly-used ontologies (e.g. Dublin Core, SKOS, FOAF) with custom ontologies used only for the portion of the metadata that cannot be described in one of the commonly-used ontologies.
Technical Metadata	technical details about an attached file	e.g. format/content type, size, checksum, create/modify dates, runtime/codec, etc.

Reference: Hydra Works Application Profile

Features / Requirements

What you can do?

Add a column for your project and indicate whether your project implements the feature / requirement.
Add a row for each feature / requirement not already on the list.
Update the Desired counter by one to indicate it is a high priority your project and you would like to see this feature added to Sufia.

Desired	Description	Sufia¹	OregonDigital	UCSD DAMS	Curate	Worthwhile	Avalon	Hydra @ Hull	Another Project Name Here	Comments

Desired	Description	Sufia¹	OregonDigital	UCSD DAMS	Curate	Avalon	Hydra @ Hull	Comments
Project Base
	software stack on which each project is based	Sufia 4.1.0					Hydra 6.1.0
User Roles
roles Uses can be assigned roles that control what they can see and do on the site. Security Question: Who can see the list of users? This has implications on role assignment. If user list is public, role assignment can be performed by selecting from a list of users. If not, the user ID has to be known by the person making the assignment. This is an example of the roles and abilities that could be created in support of a configured workflow. Assumes a more granular set of abilities beyond READ\|EDIT access. Currently, access is associated with the Work. And if you have EDIT access to a work, you can perform all CRUD. If you have READ access, you can view only.
+4	site admin The site admin user is a highly trusted user with privileges to do anything on the entire site, potentially including but not limited to... create groups of users assign user to a group assign user roles specify Work types supported on the site (e.g. book, journal article, presentation, video, etc.) specify core metadata fields used for all Work types specify default metadata fields used for each supported Work type select default workflows available for use in Collections perform actions of all other roles in all Collections Set at level: SITE	limited	limited	yes	Yes	Yes	Yes	sufia: see status of async jobs, admin stats page, edit some content blocks, add featured works/researchers worthwhile : admin dashboard (I think) - ask Justin OregonDigital: Manage roles, ip groups, bulk import, metadata. Curate: can do anything any user can do in the gui, with any content Avalon: can do anything to content or collection Hull: can do anything to content or collection but cannot see material under development in a depositor's private space ("the protoqueue"). Uniquely, an adminstrator can actually do a complete delete (lesser users' "delete" buttons move the object to a protected space available only to admins, who can potentially restore or delete the object).
+3	collection admin The collection admin user is a highly trusted user with privileges to do anything in a specific collection, potentially including but not limited to... set Collection metadata create groups of users assign users to a group assign collection admin, depositor, delegate, reviewer, and viewer roles to users/groups specify Collection specific metadata fields (default: none) select Work types allowed in the Collection (must choose at least one) specify Work type specific metadata fields (default: fields specified by site admin) select workflows available in the Collection (default: all) perform actions of all other roles in the Collection Set at level: COLLECTION (default - user creating the Collection)	LIMITED		yes	Limited	Yes	Limited	sufia: same as Curate Curate – What is called a collection today in Curate is a user generated list – the creator of the list is the administrator and can add or remove items from the collection. Anything discover-able can be added to the collection. Removing items from the collection does not remove the items from the repository. Membership in the collection does not confer additional or different rights to works and files.
+2	depositor A depositor can... add Works to the Collection set metadata for Works they deposit view works they deposit Set at level: COLLECTION	yes	yes	no	Yes	Yes	Limited	sufia: everyone as long as they log in OregonDigital: "archivist" role can ingest via form. Avalon: depositor rights are assigned at the collection level Hull: All material going into the repository proper is mediated by the Library "Content and Acceess Team" (previously our cataloguers). Depositors put their material into a QA queue for approval/checking by CAT before publication.
+1	delegate/proxy A delegate can... add Works to a Collection on behalf of another user set metadata for Works they deposit view Works they deposit Set at level: COLLECTION	Yes			Yes	N/A	N/A	Curate: A depositor can designate delegate(s) (proxies). Their delegate(s) can submit new works on the depositor's behalf, with the depository recognized as the owner of the work. As currently implemented, delegate(s) can also edit or delete any of the depositor's existing works.
+1	editor An editor can... modify metadata for all Works in the Collection view all Works in the Collection Set at level: COLLECTION	Yes			Yes	Yes	Yes	Curate: An owner of a work can designate another user as an editor or that particular work. The editor can edit metadata and add files to that work. Avalon: Editor rights, assigned at the collection level Hull: this role is fulfilled by the Content and Access Team repository-wide.
+2	reviewer A reviewer can... modify metadata for all Works in the Collection view all Works in the Collection publish, retract, delete, suppress, embargo, lease any Work Set at level: COLLECTION	no	yes	no	No	N/A	Yes	worthwhile & curate : have mediated deposit Curate: no mediated deposit enforced by application. Avalon: NA Hull: this is the role fulfilled by the Content and Access team.
+1	viewer A viewer can... view all published Works in a Collection even if the Collection is private (set at COLLECTION level) view all published Works in public Collections (set at SITE level) Set at level: COLLECTION Set at level: SITE (default - all logged in users)	yes	yes	yes	Yes	Yes	N/A
+1	guest A guest is anyone not logged into the system. A guest can... view public, published Works in public Collections Set at level: N/A	yes	yes	yes	Yes	Yes	Yes
groups
	group of depositors					Yes		group of users who can deposit in a specific Collection Avalon: For this, editors and reviewers -- Since is not a Self deposit IR, depository, editors, reviewers is based on collection. Content is not owned by individuals, but belong to collections and units.
	group of proxies					N/A		group of users who can serve as delegate/proxy of another user
	group of editors	Yes			Yes	Yes		group of users who can edit a specific Work or Works in a specific Collection Curate: A depositor can create a group that includes themselves and other users. By default the creator of the group is the administrator/owner of the group, but they can assign this role to a different member of the group. The depositor of a work can assign a group to that work, with the result that the members of the group are editors of the work.
	group of reviewers					Yes		group of users who can publish/retract a specific Work or Works in a specific Collection
	group of viewers					Yes		group of users who can view a specific Work or Works in a specific Collection
roles apply to
+2	site admin applies to entire site	Yes	yes	yes	Yes	Yes	Yes
	collection admin applies to a specific Collection					Yes
+2	all other roles can apply to a specific Collection				No	Yes		Cincinnati (Curate): We have a request to be able to apply roles to a collection, allowing rights to cascade to works within the collection. But our implementation allows an individual work to be members of multiple collections; this may be the territory of admin sets, where a work should only be a member of one admin set.
	all other roles can apply to a specific Work

Feature Inventory Grid

Model Terminology

Features / Requirements

Project Base

User Roles

roles

groups

roles apply to