DSpaceDirect Overview & General Planning Recommendations
The checklist below identifies the recommended tasks that you may wish to address before you upload 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. A step-by-step "how to" guide to walk you through each task will be available soon.
Planning Your Repository
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.
- The Repository Service Project Planning Check list - A series of planning checklists that offer sets of key questions for planning an institutional repository.
- Other resources - There are several other planning resources that may be of use listed on the DSpace Resources page.
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 our DSpace user registry. This list can be browsed based on various criteria – like country or type of institution (academic, research center, museum, etc.). Once you click on the institution's name you can see more detail about the repository, including a link that you can follow to visit the repository.
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 work to 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 policies about taking down any content 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 is the audience?
Setting up Communities and Collections
Before you upload your 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 DSpaceDirect calls "Communities" and "Collections". Communities and Collections are the names of the hierarchical structure that can be used to easily navigate. Some example structures:
- Department / Research Group / Item
- Department / Item Type /Item
- Faculty /School / …
Communities can be further divided into Sub-Communites and within each Community or Sub-Community you can create various Collections, which are groupings of related content. Content "Items", which includes 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 optionally assigning different access and reviewer roles (for different Collections). More information on Access and Reviewer Roles can be found below.
The hierarchical structure can be changed and content can be moved, but it is a good idea to think about how best to organize your DSpaceDirect repository and reflecting on all the possible content you may want to add before you begin creating Communities and Collections.
Items and the Submission Process
Before you begin to upload content you will need to understand what is included in a DSpaceDirect "Item".
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:
- Metadata: Metadata fields describe the Item (i.e. author, title, date).
- 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.
- 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.
Overview of the submission process:
- Chose a Collection to submit your content to.
- 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").
- Enter metadata that describes the Item (e.g. title, author, abstract, citation, date of publication).
- 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.
- Review your submission - If something is not correct you can correct it before submitting.
- Agree to the deposit license and complete the submission - A copy of the (digitally signed) license is deposited with the Item.
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.
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 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 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.
- 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.
- 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.
- 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).
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.
Establishing Standard Use of Metadata
Before you begin to upload content you should understand what metadata is available in DSpaceDirect, decide whether you need to make any immediate modifications and 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 will need to notify DuraSpace to ensure those metadata fields are also updated in the Item submission forms and elsewhere. Depending on the complexity of the changes this may require purchasing extra support hours.
Metadata is information that describes a particular piece of content. In DSpaceDirect metadata is used 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:
Descriptive metadata - Information that describes the attributes of an object, such the title, author, or publication date.
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.
The default metadata schema 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:
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, you will need to notify DuraSpace 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 extra support hours.
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.