SUNScholar/Operational Guide

BACK TO DSPACE CUSTOMISATION

BACK TO OPERATIONAL CAPACITY BUILDING

Introduction

This wiki page attempts to present some advice about the operational management of a research archive using DSpace software.

Community/Collection Hierarchy

In DSpace there are two "containers", namely communities and collections. Communities are containers for collections. Collections are containers for items.

Items are individual submissions of research outputs such as articles, book chapters, data sets etc.. and each item has a unique digital object identifier (DOI).

Items also have metadata associated with them that help to create machine and human readable indexes.

What type of hierarchy is best?

This depends on the purpose of the archive, is it general or specifically subject based?

General

At Stellenbosch University library we have a general research based archive, therefore we decided to use the existing institutional organisational structure as the basis for our hierarchy.

1. Faculties are designated as the top level communities.
2. Departments are collections contained by the top level faculty communities.

• Research that does not fit easily into either of the above, is stored in a top level "University Collections" community. There are normally research groups that collaborate across several disciplines. Beneath top level "University Collections" community we created collections for these cross-discipline research groups.
• In addition, under the top level "University Collections" community we created a "Work-In-Progress" (WIP) community. Beneath this community we created collections for items that are pending review and then movement or mapping to other collections. For example submission and review of our student thesis and dissertations are a collection under our top level "University Collections" community.

"University Collections"

"Work-In-Progress"

Subject

To do.

The wisdom of experience

In the beginning the hierarchy seemed adequate, then issues started to appear.

Issue 1 - Harvesters

The main issue was and still is... the harvesters from other web sites. Some harvesters are "smart" and can create harvesting filters using the metadata available and others are "dumb", they simply want to a harvest a single collection. Unfortunately we have to cater to the dumbest harvesters, so a possible project for us is to create "main" collections for the following under the "University Collections: top level community:

• Student masters and doctorates
• Researcher publications

The collections above should satisfy the needs of the "dumb" harvesters who expect everything to be in one location. This naturally very negatively impacts the easy browse facility in DSpace, so the idea is to map items from the "main" collections to suitable destination collections. This could be an automated process if there was confidence in the standardisation and quality of the metadata per item. Unfortunately this is not always the case, so we are going to have to have more "eyeballs" to assist with mapping items and doing metadata quality control.

Issue 2 - Lower the barrier for item submissions (Easy to submit!)

Our well constructed and detail collections hierarchy is great for the librarians to source items quickly BUT it is a nightmare for users to navigate when using the default DSpace submission system.

In addition the researchers expect the library to manage and organise items in the repository as it is basically information management and the researchers quite rightly expect the library to perform these functions on their behalf and not have to be burdened with long tedious electronic forms during submissions that have many metadata fields to complete.

A possible solution to this problem involves several actions, namely:

1. Greatly simplify the hierarchy as mentioned above in the "harvesters" discussion and then map items to the relevant collections.
2. Create very simple submission forms for the "main" collections to facilitate quick easy submissions for researchers and students.
3. Solict the assistance of many more "eyeballs" to do the above mapping and to capture the required metadata after the simple quick submissions mentioned above.

Conclusion

Together the actions mentioned above should solve both of the main issues, if we can get the "eyeballs" to help.

Common DSpace Operational Competencies

1. Webometrics
2. Harvesters
3. Metadata
4. Copyright and Open Access
5. Collection Templates
6. Community Management
7. Custom Workflows
8. Moving Items
9. Mapping Items
10. Item and Collection Permissions
11. Harvest Remote Collections (OAI Consumer)
12. User Management