Getting Started Checklist

Items and the Submission Process 

Before you begin to upload content you will need to understand what is included in a DSpaceDirect "Item".

Items

In DSpaceDirect an Item is a combination of metadata and corresponding file/s (it is possible to have metadata only Items, however). All Items include:

1. Metadata: Metadata fields describe the Item (i.e. author, title, date).
2. Bundles: Bundles are the group of files in an Item. For example, there are separate file Bundles for the raw uploaded files, a copy of the license that was agreed to during submission and the extracted text from the original file(s) for indexing purposes.
3. Bitstreams: Each file uploaded into DSpaceDirect or created by DSpaceDirect is considered a bitstream. A bitstream refers to the fact that a file is simply a stream of ‘bits’ (0s and 1s) held on a storage medium such as a disk.

Submission

Overview of the submission process:

1. Chose a Collection to submit your content to.
2. Answer some initial questions ("The Item has more than one title, e.g. a translated title", "The Item has been published or publicly distributed before").
3. Enter metadata that describes the Item (e.g. title, author, abstract, citation, date of publication).
4. Upload file/s & optionally set an embargo. The embargo option allows submitter to specify a period of time during which the Item will not be visible to anyone except administrators. After that period of time passes, the Item will automatically become publicly visible.
   
5. Review your submission - If something is not correct you can correct it before submitting.
6. Agree to the deposit license and complete the submission - A copy of the (digitally signed) license is deposited with the Item.

Key Outcomes

Understanding the submission process provides an opportunity for you to build consensus at your institution about how to standardize content submissions to your repository. For example, there may be some metadata fields that you decide not to use because they are not meaningful and/or because skipping them will expedite the submission process. You may also want to consider developing some policies around Item submissions – for example – a policy around the appropriate use of the embargo feature and perhaps set limits on the duration of embargoes.

User Accounts and User Groups

In order to give people submission privileges or edit rights you will need to set up User Accounts and User Groups.

Setting up User Accounts

Assuming that your DSpaceDirect repository is open, anyone can view, browse and download content without needing a User Account (these are referred to as anonymous users). However, in order to submit or edit Items users must have a User Account established. Through the DSpaceDirect account set up process you already identified what type of authentication scheme you wanted to use (DSpaceDirect offers one or more of the following options: user self-registration (default), LDAP, Shibboleth, IP-Address-Based). If you chose the default user self-registration, anyone can register with your DSpaceDirect instance using their email address. An email is automatically sent to verify the email address and to complete the registration process. Once they have completed the registration process, by default, new users only have the same rights an anonymous user (they are only able to browse, view and download public content). To modify User Account authorization rights you can use the administrator's Access Control options. 

Setting up User Groups

By establishing User Groups you can manage authorization/access rights for individuals who need the same privileges by placing them into logical Groups. This makes it easier to modify privileges and establish reviewer workflow submission roles. For example you may want to create a User Group for the faculty from different departments – like a Group called ‘Computer Science Staff’ and add all relevant users to that Group. Those users will then inherit the privileges associated with that Group. Users can be a member of multiple User Groups. For example an individual may work for two different departments. By putting him/her in both groups they will inherit both sets of privileges.

Key Outcomes

DSpaceDirect provides a flexible way to manage and group users to suit your institutional structure and workflow. If you haven't done so already, think about the logical groupings of individuals and decide what Groups you may want to establish to facilitate the submission process as well as the content review process. You can always create new User Groups or modify User Groups and their authorization rights as you learn more and as local needs change.

Access and Reviewer Roles

To support your local repository workflow and ensure quality control over your repository content, DSpaceDirect provides different types of access and reviewer roles. With the exception of Administrator, the access and reviewer roles are all set at the Collection level. The Administrator role can be set at either the Community or Collection level.     

Access Roles

Access roles determine what rights individual users or User Groups have for each Collection. When establishing or editing a Collection you can specify any or all of the following access roles to suit your local workflow:

• Read access: Provides rights to browse, view and/or download any Item or Bitstream in the Collection. The default setting allows read access to any user, regardless of whether they have a User Account or are an anonymous user. It is worth noting that if you choose to restrict read access, these changes are NOT retroactive. In other words, those new restrictions are only automatically applied to future items added to the repository. Existing Items in the system will still be viewable by those who had read access at the time of their addition (However, if needed, you can edit each existing Item to change their read access restrictions.)
  
• Submitters: Provides rights to individuals or User Groups to submit new Items to the Collection.
• Administrator: Provides rights to individuals or User Groups to submit Items to the Collection, edit the Collection metadata, edit Item metadata after submission (for Items in this Collection), and "link" existing Items to this Collection from other Collections.
  • As noted above, the Administrator role can also be applied to a specific Community. The Community Administrator role provides rights to individuals or User Groups to edit that Community's metadata, create/edit Sub-Communities or Collections under that Community, submit Items to any Collection under that Community, edit Item metadata after submission (for Items within any Collection under that Community), and "link" existing Items to any Collection under that Community.

Reviewer Roles

Reviewer roles determine what individual users or User Groups are in charge of reviewing new Items submitted to a Collection. Here are a few examples of how review process can help ensure quality control over your repository content:

• The head of research wants to review all submissions from his department in order to ensure the content is of a suitable standard. If the submission is incomplete or not up to standard, the head or research can reject the submission providing a reason to the content submitter.
• The repository administrator wants to ensure that the submission is in the correct Collection and there are no copyright issues. If there is any issues, the repository manager can modify as appropriate.
• A cataloger is assigned to perform a final check on submitted Items to make sure that the metadata meets the standards and if not, the cataloger can modify the metadata before the content is made public.
• Because the reviewer process is optional, Collections can be established without any requirement for a reviewer. When no reviewers exist for a Collection, any newly submitted Items are archived in the repository immediately after the submitter completes the submission. When reviewers exist for a Collection, an email notification is sent to those reviewers whenever a new Item is submitted. That Item is held in a private queue until all review steps are completed.

When establishing or editing a Collection you can specify any, all or none of the following reviewer roles to suit your local workflow.  It is important to note that each of these roles actually constitute a "step" (or stage) in the review process.

1. Accept/Reject Step: Individuals or User Groups responsible for this step can accept or reject incoming submissions, but they are not able to edit the submission's metadata.
   
2. Accept/Reject/Edit Metadata Step: Individuals or User Groups responsible for this step can edit the metadata of incoming submissions, and then accept or reject them. If they reject a submission they can provide a reason which will be emailed to the submitter.
   
3. Edit Metadata Step: Individuals or User Groups responsible for this step can edit the metadata of incoming submissions, but cannot reject submissions.
   

The reviews happen in the order indicated above. Each user or User Group assigned to a reviewer role will receive email notification automatically when it's their turn to review. If a role is assigned to more than one user or a User Group only one person needs to review and approve before it moves to the next step. On each Collection you can individually decide which of these review steps to enable. They are always processed in the same order, but you can choose to enable zero, one, two or all three of the steps (steps which are not enabled are skipped over).

Key Outcomes

DSpaceDirect provides a flexible reviewer process that can be customized to suit your institution's repository workflow. If you haven't done so already, think about the controls you need to establish and who will play a role in reviewing submissions before content Items are made public. You will need to balance the need for accurate, high quality content with duration and complexity of your review process – but you can always modify the review roles as your learn more and as the needs change.