Difference between revisions of "SUNScholar/Operational Guide"

From Libopedia
Jump to navigation Jump to search
Line 53: Line 53:
 
*Student masters and doctorates
 
*Student masters and doctorates
 
*Researcher publications
 
*Researcher publications
The collections above should satisfy the needs of the "dumb" harvesters who expect everything to be in one location.
+
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 were standardisation with the application of metadata per item. So we are going to have to have more "eyeballs" to assist with mapping items and doing metadata quality control.

Revision as of 00:36, 21 June 2015

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.

Common DSpace Operational Considerations

  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

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

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.

Ram-2.png

  • 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"

Ram-1.png

"Work-In-Progress"

Ram-3.png

Subject

To do.

The wisdom of experience

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

Harvesters

The main issue was and still is, are 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 were standardisation with the application of metadata per item. So we are going to have to have more "eyeballs" to assist with mapping items and doing metadata quality control.