Feature Inventory Grid

Table of Contents

Model Terminology

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

Project Base

software stack on which each project is based Sufia 4.1.0 Hydra 6.1.0

User Roles

roles

more info

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.

Click to see summary table of roles and abilities...

This is an example of the roles and abilities that could be created in support of a configured workflow.

Abilities ↓	site admin	collection admin	depositor	metadataEntry	editor	delegate/proxy	reviewer	publisher	viewer	guest
SITE: create groups of users	√	√
SITE: assign user to a group	√	√
SITE: assign site wide user roles (e.g. site admin)	√
SITE: specify Work types supported on the site (e.g. book, journal article, presentation, video, etc.)	√
SITE: specify core metadata fields used for all Work types	√
SITE: specify default metadata fields used for each supported Work type	√
SITE: select default workflows available for use in Collections	√
COLLECTION: set metadata for a collection	√	√
COLLECTION: assign users\|groups roles for a collection	√	√
COLLECTION: specify Collection specific metadata fields (default: none)	√	√
COLLECTION: select Work types allowed in the Collection (must choose at least one)	√	√
COLLECTION: specify Work type specific metadata fields (default: fields specified by site admin)	√	√
COLLECTION: select workflow to use when creating works in a Collection	√	√
COLLECTION: create Works in a collection	√	√	√			√ (on behalf)	√	√
COLLECTION: add(existing)/remove Works in a collection	√	√		√		√ (on behalf)	√	√
COLLECTION: set/modify metadata in Works in a collection	√	√		√	√	√ (on behalf)	√	√
COLLECTION: view list of Works in a collection	√	√	√	√	√	√ (on behalf)	√	√
COLLECTION: upload files to Works in a collection	√	√	√			√ (on behalf)	√	√
COLLECTION: approve work for publication	√	√					√	√
COLLECTION: release a work (i.e., mark as complete and follow visibility settings for the work)	√	√						√
WORK: view all completed works even if visibility=private (i.e., sharing read access for a Work)	√	√					√	√	√
WORK: permanently delete Works I created prior to release	√	√	√			√ (on behalf)	√	√
WORK: permanently delete Works after release	√	√						√
WORK: view all published works only if visibility=public	√	√	√	√	√	√	√	√	√	√

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

more info

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

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

more info

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

more info

A depositor can...

add Works to the Collection
set metadata for Works they deposit
view works they deposit

Set at level: COLLECTION

YES

NO

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

more info

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

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

more info

An editor can...

modify metadata for all Works in the Collection
view all Works in the Collection

Set at level: COLLECTION

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

more info

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

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

more info

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

N/A

+1

guest

more info

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

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

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 NO

Metadata

define Descriptive Metadata fields

+1

common for all Work types

more info

The core metadata that is collected for all Work types (e.g. book, journal article, image, etc.). Typically this includes, title, creator, contributor, abstract, keyword, rights, publisher, date created, etc.)

YES

Work types: Book, Journal Article, Image, etc.

sufia: metadata fields are hardcoded

Avalon - Audio and Video only

+3

specific to a Work type

more info

Metadata fields that are applicable only for a specific Work type.

Examples:

Book - number of pages, number of chapters, etc.

Video - length (hh:mm:ss), animation (true|false), etc.

NO

YES

Work types: Book, Journal Article, Image, etc.

sufia: this will likely flow in via merger with Worthwhile (and Curate?)

+2

specific to a Collection

more info

Metadata fields that are applicable for a specific Collection. This includes fields unique to a particular collection and can be almost anything.

NO

Avalon - minimal collection level info.

+3

sections of metadata grouped intelligently

more info

This functionality would allow metadata to be presented to the user with related metadata fields close to each other. For example, group all fields related to the creator, another group related to publication, another for Work type specific metadata, etc. The purpose of this is to aid the user in specifying values for metadata fields.

NO

YES

render sections of metadata only if needed (ex. book section only if doc type is book)

Hull has a generic metadata template as a default but has customised, grouped and tabbed pages for some content types. More are being developed as time allows.

file interrogation for Technical Metadata fields

more info

File interrogation is used to automatically fill in technical metadata describing characteristics of the file.

filename

+3

mimetype

more info

This was originally listed as format which may have different interpretations. Mimetype is a well established concept with one interpretation.

YES

sufia: uses FITS for file interrogation; not sure which of the following metadata FITS will extract

Curate: uses FITS for file interrogation

Avalon: Uses Media Info to extract (only format is stored)

+1 file size YES

+1 file create date NO

+1 file last modified date YES NO

md5

checksum

file interrogation of embedded Descriptive Metadata

more info

All metadata in this section is extracted from embedded metadata.

NOTE: Embedded metadata is not consistently entered, may not be updated when file content changes, metadata field names may vary, and value formatting may vary (e.g. capitalization, spacing, dash and underscore usage, etc.). There should be an option to disable this.

+2

author

YES

NO

Sufia: FITS will do this, but embedded metadata can be awful, so we disable it in ScholarSphere

+2 title YES NO NO NO Sufia: FITS will do this, but embedded metadata can be awful, so we disable it in ScholarSphere

+3 publication date NO NO NO sufia: FITS can extract last modified date of file, but that's the closest it provides

+3 language YES NO NO NO Sufia: FITS will do this, but embedded metadata can be awful, so we disable it in ScholarSphere

advanced file interrogation for Descriptive Metadata

+2

full text extraction

more info

Use a tool (e.g. Apache Tika) to perform full text extraction from PDF, TXT, DOC, PPT files.

See the full list of file formats and how they are parsed by Tika for more information.

YES

NO

YES

can we do auto-tagging based on extracted full text
OregonDigital: Text extraction doesn't do OCR (yet) - pulls from PDF and used for blacklight/viewer search.

keyword auto-tagging

more info

Use a tool (e.g. Kea) combined with a controlled vocabulary to perform auto-tagging of keywords. Prefer options for keyword ranking, such as, frequency with boosting for appearance of the keyword in title, abstract, headings, etc.

controlled vocabularies

+2

multiple controlled vocabularies

LIMITED

YES

NO

sufia: will use QA for controlled vocabularies but currently has pre-QA code

+2 forms use auto-suggest from controlled vocabularies YES YES NO NO NO

+2 multiple values from a controlled vocabulary in the same field YES YES NO NO NO

+1 hierarchical controlled vocabularies NO LIMITED NO NO NO OregonDigital allows for (e.g. GeoNames Features hierarchy, but hierarchies are on a case by case basis; no generalized SKOS support.

+1 internally defined controlled vocabularies NO LIMITED (no editor) NO LIMITED NO system for defining controlled vocabularies hierarchies and values

+2 use external controlled vocabularies NO YES NO NO NO see Example External Controlled Vocabularies

+1 disambiguation NO YES NO NO NO

+2

ability of user to write-in a value if not in the controlled vocabulary

YES

LIMITED

N/A

sufia: we like to say that Sufia provides "authority suggestion" rather than authority control

Curate: Not applicable as we have no controlled vocabularies.

versioning

+1

track versions of metadata change

more info

Provide the ability to store versions of metadata and the UI to allow viewing or restoring of previous versions.

LIMITED

NO

all fields tracked as a set with each save of metadata
Fedora : can use Fedora versioning to track versioning of metadata (this is how sufia works on top of Fedora 3, if you have enabled this in Fedora)

Works

work structure

+1

single part Works

more info

A Work can have one and only one file associated with it.
A Work does not have sub-Works.

YES

+2

multiple part Works

more info

A Work can have multiple files associated with it.
A Work can have sub-Works.

NO

YES

LIMITED

worthwhile - has this; coming soon to Sufia via Hydra Works
OregonDigital: "Complex assets" - utilized via RDF:List, will move to Hydra:Works when appropriate.

Hull: an object can have multiple files, but not sub-objects

related works

+3

link to related

more info

Provide a general ability to link a Work to another Work. In this case, the relationship between the two works is not identified.

NO

YES

LIMITED

YES

Curate: you can relate a work to other works in the repository; you can also add an external link.

Avalon: can add external link

Hull: via a metadata entry

link by metadata field

more info

A metadata field can be identified as a relationship to a Work and can be used to select a Work that fills that relationship. (Ex. Front Cover Image)

+1

link by relationship

more info

Use a controlled vocabulary to extend the general link to related functionality to include use of a controlled vocabulary to identify the type of relationship (Ex. errata)

NO

work types

more info

Identification of high level work types, as opposed to file format types, allows for metadata fields to be displayed specific to that type. For example, both a book and a journal article may have file format type application/pdf, but only the book will have number of chapters and only the journal article will have a link to the journal's Work.

various high level text types (e.g. book, page, article, thesis, etc.) YES Each of these controls what metadata is displayed for metadata 'specific to a Work type'

various high level video types (e.g. movie, presentation, webcast, video clip, etc.) LIMITED Hull: we identify these high-level differences but have not yet differentiated the displays

various high level audio types (e.g. music, podcast, audio clip, etc.) LIMITED Hull: as above

various high level image types (e.g. diagram, illustration, photograph, etc.) LIMITED Hull: as above

Files

file types

+2

text (e.g., txt, docx, pdf, etc.)

YES

NO

YES

Curate: we have 'article' and 'document' as separate work types, both intended for text, but with different metadata.

Hull: we support all these but encourage PDF wherever possible.

+1

video (e.g., mp#, qt, avi, etc.)

YES

sufia: no streaming
OregonDigital: No streaming
UCSD DAMS: External streaming server

Curate: no streaming or custom players

+2

audio (e.g., mp3, aif, wav, etc.)

YES

sufia: no streaming
OregonDigital: No streaming
UCSD DAMS: External streaming server

Curate: no streaming or custom players

+1 images (e.g., jpg, png, gif, etc.) YES YES YES YES NO YES Curate: no IIIF

+2

datasets

YES

NO

YES

Sufia: so much depends on what is assumed here. as with OregonDigital, any files may be uploaded, described, displayed, and downloaded

OregonDigital: They could go in as a file, but no explicit support.

theses

more info

Theses and dissertations are a special case of text file types. If Work types are implemented, then these will not need to be treated as a separate file type to have them use different metadata.

YES

NO

YES

Curate: Theses supported in Curate; temporarily turned off at Cincinnati; theses have different metadata than article or document.

file delivery

+2 download YES YES YES YES NO YES Sufia: whether the download or browser view action is triggered is determined by the interaction between the MIME type stored and sent by the server and what your browser supports.

+2

view in browser

YES

Curate: where format is understood by browser

Hull: likewise.

+2 streaming audio NO LIMITED NO YES NO Handoff to external streaming server (tied to IP address)

+2 streaming video NO LIMITED NO YES NO Handoff to external streaming server (tied to IP address)

file location

+1

within system repository (default)

more info

Sufia stores uploaded files in the Fedora Repository installed as part of the Sufia-Hydra stack.

YES

NO

YES

UCSD DAMS: DAMS Repository with Fedora 3 REST-API emulation

+2

external repository

more info

This supports the ability to store large datasets and other large files outside of the Fedora Repository. Perhaps Fedora's support of external datastreams could be leveraged for this functionality.

NO

YES

LIMITED

NO

Sufia: we're moving to Fedora 4 with a quickness partly in order to accommodate large files within the stack. there's no notion of external datastreams in Sufia.

UCSD DAMS: DAMS Repository supports multiple storage backends, including OpenStack

Curate: user can insert url for external file reference; no integration in GUI with Fedora external datastreams

Avalon: option to hand off master file after processing

versioning

+1

track changes to an attached file

more info

Provide the ability to store versions of an uploaded file and the UI to allow viewing or restoring of previous versions.

YES

NO

LIMITED

NO

each file tracked separately with each file replacement vs. all files of a Work tracked as a set with each file replacement

Curate: currently versioning files but not metadata. Fedora may give us metadata versioning, but this is not exposed to depositors via Hydra.

Access Control

Application of Policies

settable on: Collection, Work, File

policies inherit downward

more info

A sub-Work inherits the policies of the parent Work.
A Work inherits the policies of the parent Collection.
A sub-Collection inherits the policies of the parent Collection.
Any Work or Collection can override their parent to be more restrictive. (See most restrictive policy prevails)

most restrictive policy prevails

more info

If a child overrides the inherited policies AND the child's policy is more restrictive, then the child's policy prevails.

Inheritance Example:

If a Collection is marked public and a Work has no VISIBILITY FLAG property, it inherits the Collection's public mark.

Fail to Override Example:

If a Collection is marked private and a Work is marked public, it inherits the more restrictive Collection's private mark.

Override is Applied Example:

If a Collection is marked public and a Work is marked private, the more restrictive Work's private mark is used for that Work. The Collection remains public.

VISIBILITY FLAG

VALUES

+2

public

more info

Can view...	Site Admin	Collection Admin	Reviewer	Editor	Depositor	Delegate	Viewer	Logged-in User	Guest
Descriptive Metadata for Public Collection	X	X	X	X	X	X	Published	Published	Published
Descriptive Metadata for Public Work	X	X	X	X	Published or Own the Work	Published or Own the Work	Published	Published	Published
Contents of File for Public Work	X	X	X	X	Published or they deposited	Published or they deposited	Published	Published	Published

* Assume roles are set for the Public Collection or Public Work.

YES

sufia: public

+2

private

more info

Can view...	Site Admin	Collection Admin	Reviewer	Editor	Depositor	Delegate	Viewer	Logged-in User	Guest
Descriptive Metadata for Private Collection	X	X	X	X	X	X	Published	No	No
Descriptive Metadata for Private Work	X	X	X	X	Own the Work	Own the Work	No	No	No
Contents of File for Private Work	X	X	X	X	Own the Work	Own the Work	No	No	No

* Assume roles are set for the Public Collection or Public Work.

YES

require login and role of viewer for the Collection/Work/File to be discoverable through search and viewed
sufia: institutional access - logged in users
sufia: private - me only
OregonDigital: Can be restricted to IP ranges or specific users. GUI in progress for assigning groups to assets.

Curate: private to me, unless I have assigned delegates (proxies) or editors, in which case my delegates and editors can discover my private works.

Avalon: Private means to collection staff (people edit rights to collection)

Hull: all items under development to a depositor are private to them.

MODIFIER: private modifiers

+2

single use

more info

Can view...	Site Admin	Collection Admin	Reviewer	Editor	Depositor	Delegate	Viewer	Logged-in User	Guest
Descriptive Metadata for Private Collection	X	X	X	X	X	X	Published	single-use link for 24 hours	No
Descriptive Metadata for Private Work	X	X	X	X	Own the Work	Own the Work	Published	single-use link for 24 hours	No
Contents of File for Private Work	X	X	X	X	Own the Work	Own the Work	Published	single-use link for 24 hours	No

* Assume roles are set for the Public Collection or Public Work.

NOTE: This was originally described as semi-private where a group of users could be identified who could view only. This can be achieved for both Collection and Works by giving a user the Viewer role for the private Collection or Work.

LIMITED

NO

LIMITED

all users, who know the URL to the Collection/Work/File, can view it
sufia: private, but shared with group or a user (use ldap for groups) - mark who can see
sufia: single use links - link lasts 24 hrs
OregonDigital: We want single use links.

Avalon: Can keep undiscoverable/hidden but available via URL to users with the right to view it.

+1

searchable

more info

The searchable modifier allows metadata to show up in search results. Files remain private.

Can view...	Site Admin	Collection Admin	Reviewer	Editor	Depositor	Delegate	Viewer	Logged-in User	Guest
Descriptive Metadata for Private Collection	X	X	X	X	X	X	X	X	X
Descriptive Metadata for Private Work	X	X	X	X	X	X	X	X	X
Contents of File for Private Work	X	X	X	X	Own the Work	Own the Work	Published	No	No

* Assume roles are set for the Public Collection or Public Work.

LIMITED

NO

YES

NO

LIMITED

NO

Collection/Work/File metadata and full text is discoverable via public search, but the user cannot view the Collection/Work/File
hydra : access controls with discover permission (would like to see this added to sufia)
OregonDigital: If you can find the document in the catalog view, you can view its full document. This is on purpose.
Avalon: keep hidden but it's totally hidden (metadata and file)

Hull theoretically has this ability but we've never had a use case yet.

+1

limited access

more info

Limited use means the user can view or print the contents of a file, but only one page at a time.

Can view...	Site Admin	Collection Admin	Reviewer	Editor	Depositor	Delegate	Viewer	Logged-in User	Guest
Descriptive Metadata for Private Collection	X	X	X	X	X	X	Published	N/A	N/A
Descriptive Metadata for Private Work	X	X	X	X	X	X	X	X	X
Contents of File for Private Work	X	X	X	X	Own the Work	Own the Work	One page at a time	One page at a time	One page at a time

* Assume roles are set for the Public Collection or Public Work.

NO

can view/print one page at a time

STATUS FLAG

VALUES

+1

- in-process
  more info
  considered incomplete; hidden from lists presented to viewers and guests

NO

YES

+1

- unpublished
  more info
  considered complete, and continues to be hidden from lists presented to viewers and guests

NO

YES

OregonDigital: We have "reviewed" and "unreviewed" - when ingested it's unreviewed, when reviewed it's public.

+1

- published
  more info
  considered complete; in lists presented to viewers and guests based on public-private indicator

NO

YES

MODIFIER: published modifiers

+3

- embargo - delayed release
  more info
  considered complete, but will be marked published on a specified date

NO

YES

NO

Sufia: anticipate this coming in via merger from Worthwhile and/or Curate

worthwhile - does this; coming soon (1st & 2nd qtr next year) to Sufia

Hull: currently no, but coming.

+2

- lease - fair use
  more info
  considered complete, and will be published for a limited time period (e.g. 2 weeks); Use Case: text available for a class

NO

YES

NO

worthwhile - does this; perhaps coming soon (1st & 2nd qtr next year) to Sufia

MODIFIER: unpublished modifiers

+1

- suppressed
  more info
  strong marker that although this document & metadata are complete, the document cannot be made published until the suppression marker is removed; requires a note for the reason the document is suppressed

NO

LIMITED

NO

YES

UCSD DAMS: collection-level suppression

Hull: this is our "hidden" status - used in the event of copyright challenges etc.

Workflow

deposit method

+2

self-deposit

more info

user deposits for self only

YES

NO

YES

LIMITED

NO

Avalon: it depends on how you define this...Avalon has no sense of self, you can grant any user the right to deposit.

+3

proxy-deposit

more info

user deposit as a proxy, as though they are another user

YES

NO

YES

NO

Sufia: added in 4.1.0

Curate: term 'delegate' is used.

MODIFIER: on self/proxy-deposit

+3

- mediated-deposit
  more info
  reviewer must approve any deposits before they can be published

NO

LIMITED

YES

Avalon: You could set it up permissions as certain roles can deposit but not publish, but it's system wide for all collections.

workflows (see Example Workflows)

+1 stock workflows NO YES NO NO YES YES

+1 admin user defined workflows NO NO NO NO NO NO

Branding

System hierarchy

2 level hierarchy

YES

NO

YES

sufia: uses this model (kind of, but I'm not sure I understand this row – files can be organized into collections and discovered that way, but files need not belong to collections. files are first-class objects just like collections are)

Avalon: Units and Collections

- Organization / University

NO

highest level is the application

+1

- Collection

LIMITED

user defines 1 or more collections at any time (user must be logged in; users own collections they create)
OregonDigital: Collections are assets to be created by administrators.

Curate: a collection is a list and not an admin set (although at Cincinnati we need admin sets). A collection is itself collectible, and thus can be a member of a 'parent' collection, but we are not yet presenting that relationship-- when collections are listed, all collections appear in a flat list.

+2

Flexible nested hierarchy

NO

YES

NO

YES

Sufia: Coming Soon with Hydra Works. Each nested level is a Collection with a sub-Collection.

OregonDigital: We support this in the backend (if it's RDF we support it), but there's no UI for nesting.

Hull uses this primarily for internal structural organisation; we can also have nested display collections but it's rather crude as yet.

- Organization / University

highest level of system hierarchy (e.g. Cornell)

- Collection

second level of system hierarchy (e.g. CUL-Mann)

- any number of nested collections

third level of system hierarchy (e.g. Teeale); fourth level of system hierarchy (e.g. Gates Documents)

Branding strategies

+2 site wide single brand YES YES YES YES YES YES main landing page has Cornell brand

+1 multiple branding NO YES NO NO NO NO different brand allowed at each system level with lower levels inheriting brand from parent level if unspecified; not really sure how branding is implemented, so inheritance may be a manual process

Reporting / Notification

Delivery Mechanism

+2 dashboard LIMITED NO NO NO See Example Reports & Notifications

+3

email

NO

LIMITED

NO

LIMITED

Sufia: this is a documented need in ScholarSphere, so it could come to Sufia in the coming months

See Example Reports & Notifications
UCSD DAMS: email reporting in separate (Java) ingest webapp

Avalon: sends an email regarding status of batches importing and imported.

Export Utility

+0

export metadata

YES

NO

sufia: export in 3 formats - endnote, zotero, mendeley (and we have a rake task to spit it all out as RDF/XML)

OregonDigital: can download metadata as ntriples from object URI

+2 export files and metadata to external datastore NO NO NO NO NO OregonDigital: can export as BagIt bags

NOTES:

¹Sufia - This column indicates whether Sufia implements this feature out of the box.

Example Workflows

NOTE: See Potential Definitions of Workflows for full steps involved in each workflow.

Desired	Workflow	Sufia	Hydra at Hull	Comments
Depositing
	create a work		YES	Creates a Work instance with no Files Hull: this is the first stage in creating an object. A file or files is then uploaded and associated with the object.
	upload a single file into an existing Work			Upload file; Create File instance; Associate File with existing Work
+1	upload a single file (no Work specified)	YES		Upload file; Create File instance and Work instance; Associate File with Work
+2	replace a single file	YES		Upload file; Update File instance
+1	batch add multiple files into an existing Work	YES		Upload files; Create File instance for each; Associate each File with existing Work
+1	batch add multiple files to multiple Works (no Work specified)	YES		Upload files; Create File instance for each; Create Work instance for each; Associate each File with one new Work
+1	batch add multiple files to one Work (no Work specified)	YES		Upload files; Create File instance for each; Create one Work instance; Associate each File with the one new Work
Modifying Works
+1	add/edit metadata for a single Work	YES	YES
+1	batch add/edit metadata for multiple Works	LIMITED	NO	descriptive metadata can be set in batch Hull: no, but looking to add this very soon (weeks not months)
Changing Access Controls
+1	publish a single Work	LIMITED	YES	sufia: any document marked public can be considered published
+1	retract a single Work	LIMITED	YES	sufia: for a public document, mark it private
+1	delete a single Work	YES	LIMITED	Hull: if a cataloger deletes an object it actually goes into a hidden (admin only) state. Only an admin can truly delete an object.
+1	batch publish multiple Works
+1	batch retract multiple Works
+1	batch delete multiple Works
+1	suppress a single Work	LIMITED	YES	sufia: make a public item private
+1	batch suppress multiple Works
+2	embargo a single Work			in worthwhile
+1	batch embargo multiple Works
+1	lease (temporary publish) a single Work
+1	batch lease multiple Works
Viewing
+1	view metadata in search results	YES	YES
+1	view Work (file and metadata)	YES	YES
+1	download file	YES	YES
+1	export metadata	YES	NO	in 3 or 4 formats, end-note, zoterra, mendeley
+1	export files & metadata to external datastore	NO	NO
Administration
+2	add/edit users	LIMITED	LIMITED	sufia: all university logins are available out of box, self register Hull: all university logins are available for viewing restricted content; only admins can add depositors at present.
+2	assign user site-wide roles	LIMITED		sufia: admin only through code by being a member of a group
+1	assign users roles in a Collection
	assign users roles for a Work
+1	add/edit collections / sub-collections	NO	YES
+1	add/edit metadata fields for a Work type	LIMITED		e.g. set of fields for a Book, Journal Article, or Theses, etc. sufia: one set of metadata fields configured in code worthwhile: does have multiple types
	add/edit metadata fields for a file type			e.g. set of fields for a png, mp3, or doc, etc.

Example External Controlled Vocabularies

Desired	Content	Sufia	Oregon Digital	Project 2 Name	Comments
External Controlled Vocabularies
+1	Geolocation

Example Reports & Notifications

Desired	Content	Sufia
Reporting (dashboard)
+2	Site wide counts
+1	Count of all sub-entities starting at a given level
+2	Count for a specific collection
+2	Count of Works in a particular state by site/entity/collection
Notifications (email)
+1	Work pending your approval	NO
+1	Summary of all Works pending an action by you	NO
+1	Summary of all Works with actions pending	NO

Potential Definitions of Workflows

add a Work

login -> button to add-> 
             upload document -> 
             auto-process using file interogation -> 
             add/adjust metadata -> 
             publish

batch add multiple Works

login -> button to add files from a directory -> 
             auto-process using file interogation -> 
             update dashboard of ingest as documents complete -> 
             allow adding/adjusting metadata as files register as ingested -> 
             publish completed items (either batch or individually)

edit a Work

login -> list documents -> button to edit -> 
             add/adjust metadata -> 
             publish

retract a Work – does this make it private (unpublished) again or is it more complex?

login -> list documents -> button to retract -> autostep: change visibility from public to private

Feature Inventory Grid

Model Terminology

Features / Requirements

Project Base

User Roles

roles

groups

roles apply to

Metadata

define Descriptive Metadata fields

file interrogation for Technical Metadata fields

file interrogation of embedded Descriptive Metadata

advanced file interrogation for Descriptive Metadata

controlled vocabularies

versioning

Works

work structure

related works

work types

Files

file types

file delivery

file location

versioning

Access Control

Application of Policies

VISIBILITY FLAG

STATUS FLAG

Workflow

deposit method

workflows (see Example Workflows)

Branding

System hierarchy

Branding strategies

Reporting / Notification

Delivery Mechanism

Export Utility

Example Workflows

Depositing

Modifying Works

Changing Access Controls

Viewing

Administration

Example External Controlled Vocabularies

External Controlled Vocabularies

Example Reports & Notifications

Reporting (dashboard)

Notifications (email)

Potential Definitions of Workflows