The DSpaceDirect KnowledgeBase is a living document - your feedback is welcome. Please send your suggestions for improvements to dspacedirect@lyrasis.org.

DSpaceDirect Overview & General Planning Recommendations

The checklist below identifies the recommended tasks that you may wish to address before you begin uploading your content into your DSpaceDirect repository. It is intended to explain basic DSpaceDirect terminology and functionality in order to assist you in the planning of your repository implementation. This information essentially explains DSpaceDirect's capabilities and how it could be useful. 

 

Planning Your Repository 

Planning resources

Before you upload your content into your DSpaceDirect repository, we highly recommend you spend some time thinking about some key questions to further flesh out the plans for your repository (if you haven't done so yet). There are some excellent repository planning resources that can help you with this process, and while they were written a while ago, much of the content is still very useful.

  • Creating an Institutional Repository: LEADIRS Workbook - Describes the major steps and decisions for designing and building an institutional repository. Written originally for a series of workshops in the UK, the workbook contains advice, sample documents, tools, and reference materials.
  • SPARC Institutional Repository Checklist and Resource Guide, published by the Scholarly Publishing and Academic Resources Coalition

You may also find it helpful to see how others are using the DSpace open source software. You can find a listing of the the known public DSpace repositories on the DSpace user registry. This list can be browsed based on various criteria, for example country or type of institution (academic, research center, museum, etc.). Some institutions have included links that you can follow to visit their repository.  

Key Outcomes

 During your local planning process, you should work towards coming to a general plan/agreement at your institution on the following:

  • Identify the vision/purpose and initial goals for your repository.
  • Identify the team who will support the repository along with each person's responsibilities. For example, you should decide who at your institution will be involved with uploading content, reviewing submissions, answering local questions, etc.
  • Develop a clear service model for your repository and conduct a needs assessment. Identify what local services you will provide to your repository users, and whether any fees will be associated with those services, etc.
  • Identify the primary users of your repository and/or the individuals who will most likely be creating the content.
  • Identify what type(s) of content you will accept.
  • Identify a pilot or early adopter program. It may be easiest to start with a few highly energetic departments or groups as "early adopters" and enhance your local repository policies/procedures from that experience.
  • Determine how you would like to organize your content – by school, department, subject, etc. You need not decide this all initially (as you can move things around), but it makes it easier to have a good plan in place early on.
  • Reflect on your institution's legal/copyright policy and determine the implication for your repository content. For example, do you feel the need to review content (for possible copyright concerns) as it comes into the repository?  Or possibly develop local takedown policies if a copyright complaint is submitted to the institution?
  • Develop a plan for marketing/promoting your repository - communications, events, etc.  For example, how do you want to advertise your repository to your campus/institution? Who are your target audience(s)?

Setting up Communities and Collections

Before beginning to upload content, you will need to establish an organizational structure for your DSpaceDirect repository. To do this you may wish to use your institution's basic organizational structure (college, department, research center, laboratory, etc.) and create what the DSpace software calls "Communities" and "Collections". Communities and Collections provide hierarchy and structure to your repository. Some example structures:  

  1. Department / Research Group / Item
  2. Organization / Sub-organization / Item Type / Item
  3. Faculty / School / Item Type / Item
  4. Topic / Sub-topic / Item

Communities can be further divided into Sub-Communities. Within each Community or Sub-Community you can create various Collections, which are groupings of related content and can also be sub-divided with Sub-Collections. Content "Items", the metadata and a file or group of files, can only be deposited under a Collection.

Communities and Collections are not the only way to browse or locate content in your DSpaceDirect repository: your users will also be able to search or browse by author, titles, subjects, and issue date.  But Communities and Collections are an important aspect of structuring your content and can be used to optionally assign different access and reviewer roles for different Collections.  More information on Access and Reviewer Roles can be found below.


Items and the Submission Process 

Before beginning to upload content, you will need to understand what is included in a DSpace "Item."

Items

Items are a combination of metadata and corresponding file/s (it is possible to have metadata-only Items). 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. Enter metadata that describes the Item (e.g. title, author, Item type, abstract, citation, date of publication). Metadata can be extremely minimal for an Item, only a title, type, and issue date, or you can choose to add additional information if you have it.
  3. Upload file/s & provide Item access conditions (such as open access, setting an embargo, choosing whether or not to make an Item discoverable, etc. More information about these options is available elsewhere in this KnowledgeBase).
  4. Review your submission - If something is not correct, you can correct it before submitting.
  5. Agree to the deposit license and complete the submission - A copy of the (digitally signed) license is deposited with the Item.

Tips for consideration

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, anonymous users (that is, anyone not logged into your repository) can view, browse and download content. However, in order to submit or edit Items, users must have a User Account established. There are various options available for users to create accounts*; when an account is created, 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 as 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. 

*Lyrasis Hosting discourages the self-registration option, as this has led to repositories being overrun by spambot accounts. If you choose to allow this option, we will enable reCAPTCHA and recommend only allowing known email domains (such as an email domain associated with your institution). 

Setting up User Groups

User Groups allow you to 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 wish to create a group for all faculty from the same department. You could name the group "Computer Science Faculty and 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 them in both groups they will inherit both sets of privileges.

Tips for consideration:

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, DSpace 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.)
  • Submitter: 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 a Collection, edit a Collection's 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 a review workflow 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 of 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 library's 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, as well as accept or reject them. If they reject a submission they can provide a reason that 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 they cannot reject submissions.

Reviews happen in the order indicated above. Each user or User Group assigned to a reviewer role will receive an 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 that are not enabled are skipped over.

Tips for consideration:

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. We suggest starting with the simplest, fewest steps possible and adding onto them only if needed in order to keep your workflow sustainable.


Establishing Standard Use of Metadata

Before you begin to upload content you should understand what metadata is available out of the box in DSpaceDirect and decide whether you want to make any immediate modifications. You should also contemplate establishing any standard practices for metadata (e.g. author names always should include full names rather than nicknames – i.e., "David" and not Dave). Please note if you wish to add or remove metadata fields in DSpaceDirect, you may need to notify Lyrasis Hosting to ensure those metadata fields are also updated in the Item submission forms and elsewhere, if you want your Submitters to fill in that metadata during the submission process. Depending on the complexity of the changes this may require purchasing an enhanced metadata submission process package or additional support hours. Contact digitalservices@lyrasis.org if you have questions.

Metadata is information that describes a particular piece of content. Metadata is used in DSpace to describe different types of content or structures within the repository, including Communities, Collections, and Items. In addition there are two different types of metadata:

  1. Descriptive metadata - Information that describes the attributes of an object, such the title, author, or publication date. This metadata is typically manually created by users.

  2. Administrative metadata - Information that helps with the management of an object or describes the object's provenance. Examples include the location of the object or the name of the user who created the object and its descriptive metadata. This metadata is frequently system-generated.

The default metadata schema (or structure and pre-defined elements for a metadata set) in DSpaceDirect is Dublin Core. Dublin Core is made up of elements and qualifiers. There are 15 base elements, all of which can be refined through the use of qualifiers:

  1. Title

  2. Creator

  3. Subject

  4. Description

  5. Publisher

  6. Contributor

  7. Date

  8. Type

  9. Format

  10. Identifier

  11. Source

  12. Language

  13. Relation

  14. Coverage

  15. Rights

If the content you plan to put in your repository requires a different metadata schema, you can add new schemas. You may also edit existing schema elements, like modifying the name or descriptor of an element, deleting an element or adding new elements. Again, please note that if you wish to add or edit metadata schemas or fields in DSpaceDirect for the submission process, you will need to notify Lyrasis Hosting to ensure your changes are fully enabled in the Item submission forms or search results or similar. Depending on the complexity of the change, this may require purchasing an enhanced metadata submission package and/or additional support hours. Contact digitalservices@lyrasis.org for more information.

Tips:

Understanding metadata provides an opportunity for you to build consensus at your institution about how to standardize metadata to suit your content and your users. The sooner you determine how you will use metadata and communicate that to all your submitters, the less metadata editing will be required of your reviewers and/or the less clean up you will have later. 
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.