Child pages
  • Feature Inventory Grid
Skip to end of metadata
Go to start of metadata

Table of Contents


Model Terminology

TermDefinitionComments
CollectionCan 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.
WorkCan hold...
  • hasMember - 0..m Works
  • hasFile - 0..m Files
  • Descriptive Metadata
 
FileCan 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

Sufia1

OregonDigital

UCSD DAMS

Curate

Worthwhile

Avalon

 

Hydra @ Hull

Another Project Name Here


Comments

Project Base
 software stack on which each project is basedSufia 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  Roles site admincollection admindepositormetadataEntryeditordelegate/proxyreviewerpublisherviewerguest
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

LIMITEDLIMITEDYESYES YESYES 

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 YESLIMITED YESLIMITED 

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

YESYESNOYES YESLIMITED 

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  YES N/AN/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  YES YESYES 

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

NOYESNONO N/AYES 

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)

YESYESYESYES YESN/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

YESYESYESYES YESYES  
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 editorsYES  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
+2site admin applies to entire siteYESYESYESYES YESYES  
 collection admin applies to a specific Collection     YES   
+2all 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.)

YESYESYESYES YESYES 

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.
NONONOYES  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.

NONONONO NONO 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.

NONONONO NOYES 

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 YESYES YESYES 

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) 

+1file size      YES  
+1file create date     NO   
+1file last modified dateYES    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 NONO Sufia: FITS will do this, but embedded metadata can be awful, so we disable it in ScholarSphere
+2titleYES  NO NONO Sufia: FITS will do this, but embedded metadata can be awful, so we disable it in ScholarSphere
+3publication dateNO  NO  NO sufia: FITS can extract last modified date of file, but that's the closest it provides
+3languageYES  NO NONO 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.

YESYESYESNO  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
+2multiple controlled vocabularies

LIMITED

YES NO NONO sufia: will use QA for controlled vocabularies but currently has pre-QA code
+2forms use auto-suggest from controlled vocabulariesYESYES NO NONO  
+2multiple values from a controlled vocabulary in the same fieldYESYES NO NONO  
+1hierarchical controlled vocabulariesNOLIMITED NO NONO OregonDigital allows for (e.g. GeoNames Features hierarchy, but hierarchies are on a case by case basis; no generalized SKOS support.
+1internally defined controlled vocabulariesNOLIMITED (no editor) NO LIMITEDNO system for defining controlled vocabularies hierarchies and values
+2use external controlled vocabulariesNOYES NO NONO see Example External Controlled Vocabularies
+1disambiguationNOYES NO NONO  
+2ability of user to write-in a value if not in the controlled vocabularyYESLIMITED N/A N/AN/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 NONO NONO 

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.
YESYESYESYES     
+2

multiple part Works

 more info
  • A Work can have multiple files associated with it.
  • A Work can have sub-Works.
NOYESYESYES YESLIMITED 

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 YESYES LIMITEDYES 

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 NONO NONO  
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
+2text (e.g., txt, docx, pdf, etc.)YESYESYESYES NOYES 

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.

+1video (e.g., mp#, qt, avi, etc.)YESYESYESYES YESYES 

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

Curate: no streaming or custom players

+2audio (e.g., mp3, aif, wav, etc.)YESYESYESYES YESYES 

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

Curate: no streaming or custom players

+1images (e.g., jpg, png, gif, etc.)YESYESYESYES NOYES Curate: no IIIF
+2datasetsYES YESYES NOYES 

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  YES NOYES Curate: Theses supported in Curate; temporarily turned off at Cincinnati; theses have different metadata than article or document.
file delivery
+2downloadYESYESYESYES NOYES 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.
+2view in browserYES YESYES  YES 

Curate: where format is understood by browser

Hull: likewise.

+2streaming audioNO LIMITEDNO YESNO Handoff to external streaming server (tied to IP address)
+2streaming videoNO LIMITEDNO YESNO 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.

YESYESYESYES NOYES 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.

NONOYESYES LIMITEDNO 

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.

YESNONOLIMITED NONO 

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
      ReviewerEditorDepositorDelegateViewerLogged-in
      User
      Guest
      Descriptive Metadata
      for Public Collection
      XXXXXXPublishedPublishedPublished
      Descriptive Metadata
      for Public Work
      XXXX

      Published or
      Own the Work

      Published or
      Own the Work

      PublishedPublishedPublished
      Contents of File
      for Public Work
      XXXX

      Published or
      they deposited

      Published or
      they deposited

      PublishedPublishedPublished

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

YESYESYESYES YESYES sufia: public
+2
    • private

       more info
      Can view...Site
      Admin
      Collection
      Admin
      ReviewerEditorDepositorDelegateViewerLogged-in
      User
      Guest
      Descriptive Metadata
      for Private Collection
      XXXXXXPublishedNoNo
      Descriptive Metadata
      for Private Work
      XXXX

      Own the Work

      Own the Work

      NoNoNo
      Contents of File
      for Private Work
      XXXX

      Own the Work

      Own the Work

      NoNoNo

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

       

       

YESYESYESYES YESYES 

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
      ReviewerEditorDepositorDelegateViewerLogged-in
      User
      Guest
      Descriptive Metadata
      for Private Collection
      XXXXXXPublished

      single-use link
      for 24 hours

      No
      Descriptive Metadata
      for Private Work
      XXXX

      Own the Work

      Own the Work

      Published

      single-use link
      for 24 hours

      No
      Contents of File
      for Private Work
      XXXX

      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.

LIMITEDNONONO 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
      ReviewerEditorDepositorDelegateViewerLogged-in
      User
      Guest
      Descriptive Metadata
      for Private Collection
      XXXXXXXXX
      Descriptive Metadata
      for Private Work
      XXXX

      X

      X

      XXX
      Contents of File
      for Private Work
      XXXX

      Own the Work

      Own the Work

      PublishedNoNo

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

LIMITEDNOYESNO LIMITEDNO 

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
      ReviewerEditorDepositorDelegateViewerLogged-in
      User
      Guest
      Descriptive Metadata
      for Private Collection
      XXXXXXPublishedN/AN/A
      Descriptive Metadata
      for Private Work
      XXXX

      X

      X

      XXX
      Contents of File
      for Private Work
      XXXX

      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.

NONONONO NONO 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 NONO NOYES  
+1
    • unpublished

       more info

      considered complete, and continues to be hidden from lists presented to viewers and guests

NO NONO YESYES 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 NONO YESYES  
 MODIFIER: published modifiers         
+3
    • embargo - delayed release

       more info

      considered complete, but will be marked published on a specified date

NO YESYES NONO 

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 YESNO NONO 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 LIMITEDNO NOYES 

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

YESNONOYES LIMITEDNO 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

YESNONOYES NONO 

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

NONONONO LIMITEDYES 

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)
+1stock workflowsNOYESNONO YESYES  
+1admin user defined workflowsNONONONO NONO  
Branding
System hierarchy
 2 level hierarchyYESYESYESNO 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.

+2Flexible nested hierarchyNOYESYESNO NOYES 

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
+2site wide single brandYESYESYESYES YESYES main landing page has Cornell brand
+1multiple brandingNOYESNONO NONO 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
+2dashboardLIMITED NONO NO  See Example Reports & Notifications
+3emailNO LIMITEDNO 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
+0export metadataYESYESYESNO 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

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

 

NOTES:

1 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.

 

DesiredWorkflowSufiaOregon DigitalHydra at HullProject 2 NameComments
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
+1upload a single file (no Work specified)YES   Upload file; Create File instance and Work instance; Associate File with Work
+2replace a single fileYES   Upload file; Update File instance
+1batch add multiple files into an existing WorkYES   Upload files; Create File instance for each; Associate each File with existing Work
+1batch 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
+1batch 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
+1add/edit metadata for a single WorkYES YES  
+1batch add/edit metadata for multiple WorksLIMITED NO 

descriptive metadata can be set in batch

Hull: no, but looking to add this very soon (weeks not months)

Changing Access Controls
+1publish a single WorkLIMITED YES sufia: any document marked public can be considered published
+1retract a single WorkLIMITED YES sufia: for a public document, mark it private
+1delete a single WorkYES 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.
+1batch publish multiple Works     
+1batch retract multiple Works     
+1batch delete multiple Works     
+1suppress a single WorkLIMITED YES sufia: make a public item private
+1batch suppress multiple Works     
+2embargo a single Work    in worthwhile
+1batch embargo multiple Works     
+1lease (temporary publish) a single Work     
+1batch lease multiple Works     
Viewing
+1view metadata in search resultsYES YES  
+1view Work (file and metadata)YES YES  
+1download fileYES YES  
+1export metadataYES NO in 3 or 4 formats, end-note, zoterra, mendeley
+1export files & metadata to external datastoreNO NO  
Administration
+2add/edit usersLIMITED 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.

+2assign user site-wide rolesLIMITED   sufia: admin only through code by being a member of a group
+1assign users roles in a Collection     
 assign users roles for a Work     
+1add/edit collections / sub-collectionsNO  YES  
+1add/edit metadata fields for a Work typeLIMITED   

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

 

DesiredContentSufiaOregon DigitalProject 2 NameComments
External Controlled Vocabularies
+1Geolocation    

Example Reports & Notifications

 

DesiredContentSufiaOregon DigitalProject 2 NameComments
Reporting (dashboard)
+2Site wide counts    
+1Count of all sub-entities starting at a given level    
+2Count for a specific collection    
+2Count of Works in a particular state by site/entity/collection    
Notifications (email)
+1Work pending your approval NO   
+1Summary of all Works pending an action by you NO   
+1Summary 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

     

     

 

 


 

 

  • No labels