Methods of performing basic and essential tasks are explained with reference to system naming conventions. Common tasks that ERA administrators might be asked to perform are explained in step-by-step instructions, and examples are given throughout.

1.1. Notation and Fonts for this Document

This document uses the following standard notation types and fonts in the following contexts:

Plain Sans-Serif Font - The general text of this document.

Italic Fixed-Width Font – Standard form of text that needs to be entered into the system by the administrator.

<Italic Fixed-Width Font in Angle Brackets> - Everything, including the angle brackets should be replaced with a variable value. This is often used in conjunction with the italic fixed-width font.

Plain Fixed-Width Font – Example of text that the administrator might enter into the system.

Bold Sans-Serif Font - A statement to which particular attention should be paid, or a reference to another section of this document. In the case of reference to another document, the full reference to the section will be given in the form Section Number: Section Title.

Italic Sans-Serif Font - An inline example or reference to the system.

1.2. Location of Resources

ERA

http://www.era.lib.ed.ac.uk/

ERA Administration Area

http://www.era.lib.ed.ac.uk/admin/

1.3. Logging in

On attempting to perform any action in ERA which requires authentication you will be prompted to log in. Enter your email address and your password and hit Log In.

2. Communities and Collections

Communities and Collections in ERA are used to create a shallow hierarchy within which the university's research will be categorised. A community maps directly, in most cases, onto a single recognisable academic unit such as the School name. For example, the School of Informatics has its own community entitled Informatics. The community may only contain collections, and a collection maps to any internal sub-units of the community. This could include working groups, institutes or centres. For example, the Informatics community contains Centre for Intelligent Systems and their Applications, Department of Artificial Intelligence and Institute for Adaptive and Neural Computation.

Naturally, this relationship of communities and collections to academic units does not always hold. It is up to the administrator to use discretion when allocating communities and collections. As a further example of where this has been that case, we present the community: Scottish Natural Heritage which is being hosted in ERA on behalf of that organisation. This contains the collection Scottish Natural Heritage Commissioned Reports which represents a sub-section of their working area which we are curating for them.

2.1. Community Configuration

2.1.1. Creating Communities

In the admin area of ERA, select Communities/Collections from the menu on the left. You will be taken to a page entitled Edit Communities and Collections. Press the button at the top of the page, which is labelled Create Community…. You will be taken to a page with a number of fields to be filled in.

To find out more about the fields that can be filled in, see the section 2.1.3: Community Properties.

2.1.2. Editing Communities

In the admin area of ERA, select Communities/Collections from the menu on the left. You will be taken to a page entitled Edit Communities and Collections. Communities are the headings in the list, and appear in grey rows. Find the Community that you would like to edit, and press the Edit button which appears to the right of it. You will be taken to a page with a number of fields to be filled in.

To find out more about the fields that can be filled in, see the section 2.1.3: Community Properties.

2.1.3. Community Properties

Below we detail the contents that you should be able to enter into each of the fields in the Community:

Name: This should be the name of the Community as per the naming conventions in the section 2.1.4: Community Naming Conventions.

Short Description: This should be a very short description of the Community, ideally not exceeding 80 characters.

Introductory Text: This should be a longer introduction to the Community. Contents might include a description of the sort of material contained in the Community, the history of the school to which it belongs, a description of the sorts of research that the school does. HTML is permitted in this field, and at a very minimum all individual paragraphs should be started with and ended with . For example:

This is my introductory paragraph

This is my second introductory paragraph

Please ensure that your HTML is valid and that it works.

Copyright Text: This section should be left blank as licences on each item of content cover all copyright issues.

Side Bar Text: This section should be left blank.

Logo: A logo for the Community may be uploaded if desired. This logo should be relevant to the title of the Community: it may be a school logo, or one made specifically to represent the Community within ERA.

2.1.4. Community Naming Conventions

The Community name should take the following form:

<school to which the Community belongs> (<special designation>)

For example, the School of Biological Sciences in the College of Science and Engineering should simply be called:

Biological Sciences

If the Community has a special designation, this should be declared in brackets after the name of the school. For example, if the Community is to contain theses and dissertations the name would be:

Biological Sciences (Theses and Dissertations)

For more information regarding special designations for Communities see the section 2.3: Special Designations.

2.2. Collection Configuration

2.2.1. Creating Collections

In the admin area of ERA, select Communities/Collections from the menu on the left. You will be taken to a page entitled Edit Communities and Collections. Find the Community to which you would like to add a Collection and press Create Collection on the right. You will be taken to a page with a number of fields to be filled in.

To find out more about the fields that can be filled in, see the section 2.2.3: Collection Properties.

2.2.2. Editing Collections

In the admin area of ERA, select Communities/Collections from the menu on the left. You will be taken to a page entitled Edit Communities and Collections. In the list which appears, Collections are subheadings, and appear in white bars. There are often several Collections within Communities. Find the Collection that you would like to edit, and press the Edit button which appears to the right of it. You will be taken to a page with a number of fields to be filled in.

To find out more about the fields that can be filled in, see the section 2.2.3: Collection Properties.

2.2.3. Collection Properties

Below we detail the contents that you should be able to enter into each of the fields in the Collection:

Name: This should be the name of the Collection as per the naming conventions in the section 2.2.4: Collection Naming Conventions.

Short Description: This section should be left blank.

Introductory Text: This should be a long-ish introduction to the Collection. Contents might include a description of the sort of material contained in the Collection, the history of the working/research group to which it belongs and a description of the sorts of research that the group does. HTML is permitted in this field, and at a very minimum all individual paragraphs should be started with and ended with . For example:

This is my introductory paragraph

This is my second introductory paragraph

Please ensure that your HTML is valid and that it works.

Copyright Text: This section should be left blank as licences on each item of content cover all copyright issues.

Side Bar Text: This section should be left blank.

License: This section should be left blank

Provenance: This section should be left blank

Logo: A logo for the Collection may be uploaded if desired. This logo should be relevant to the title of the Community: it may be a school logo, or one made specifically to represent the Community within ERA. Note, also, that if you wish the Collection to have the same logo associated with it as its parent Community it is necessary to upload the logo again.

There are additional options at the bottom of the Edit Collection page. The options available here are detailed in the sections: 2.4: Configuring Workflow Steps, 2.5: Configuring Item Templates and 6: Authorisation Administration.

2.2.4. Collection Naming Conventions

The Collection name should take the following form:

<working/research group to which the Collection belongs> (<special designation>)

For example, the Institute for Stem Cell Research (ISCR), in the School of Biological Sciences should simply be called:

Institute for Stem Cell Research (ISCR)

If the Collection has a special designation, this should be declared in brackets after the name of the working/research group. In addition, if the Community to which the Collection belongs has a special designation this should also be declared in the brackets. For example, if the Collection belongs to the Biological Sciences (Theses and Dissertations) Community, the name would be:

Institute for Stem Cell Research (ISCR) (Theses and Dissertations)

If the Collection is a catch-all for items which do not fall into any other working/research group’s Collection, and belongs to, for example, the School of Law, it should have the name:

Law (General)

For more information regarding special designations for Collections see the section 2.6: Special Designations.

2.3. Special Designations

The following are the standard special designations that may be applied to Communities and Collections:

None: A Community or Collection with no purpose beyond that of belonging to the school or working/research group does not need any special designation declared in its name

Theses and Dissertations: A Community or Collection which will contain only PhD Theses or Masters Dissertations

General: A Collection (not Community) which is not covered by any particular working/research group or contains miscellaneous information. A catch-all for all the particular Community’s non-categorised output.

2.4. Configuring Workflow Steps

There are three workflow steps available for each Collection. To insert workflow groups see the section 2.2.2: Editing Collections to find out how to see the Collection options, then select Create next to the workflow step number for which you wish to make a group, or Edit if you wish to edit the contents of a group which already exists.

When creating the groups, you should adhere to the group naming conventions laid out in the section 3.2: Group Naming Conventions. Instructions on creating groups are available in the section 3.1: Creating User Groups.

The remainder of this section deals with the workflows you will need for different sorts of Collections.

2.4.1. Theses or Dissertations

If your Collection is specially designated as a Thesis and Dissertations Collection then it is necessary to apply the workflow configuration detailed in the section 4.1: Configuring the Workflow.

2.4.2. Other Research Material

If your Collection is not specially designated then it is necessary to apply the workflow configuration detailed in the section 5.1: Configuring the Workflow.

2.5. Configuring Item Templates

An Item Template allows the Collection to apply any number of default values to a submission at the point at which it is created. When the user selects Start New Submission the values from the item template are automatically added to the new submission and displayed to the user.

To apply an item template, in the admin area select Communities/Collections from the menu on the left. Find the Collection to which you would like to add or edit the item template and click Edit. Near the bottom of the Edit Collection page to which you are taken click Edit next to Item template. You may now apply settings as per the following sections.

2.5.1. Theses and Dissertations

If your Collection is specially designated as a Thesis and Dissertations Collection, an item template is required. For details of the contents of this template see the section 4.5: Item Template.

2.5.2. Other Research Material

There are currently no requirements to set up an Item Template for Collections that do not have specific designations.

3. User Groups

The following guidelines will help ensure that user groups within ERA can be easily identified and thus more easily administered.

There are three different types of user group:

1) Workflow Groups

2) Supervisor Groups

3) Submitter Groups

Type (1) comprises of all groups that contain users who will work on post-submission workflow stages, type (2) comprises all groups that contain users who will supervise submitters, and type (3) comprises all groups that contain users which can submit items to given collections. Therefore, if a user is to be allowed to submit to a collection they should be added to that collection's submitter group; if a user is to supervise a submitter they should be added to that submitters supervisor group; if a user is to perform one of the post-submission workflow procedures they should be added to the relevant step of that collection's workflow group.

This section details how to create groups, add users to them, remove them and have them conform to the ERA naming conventions.

3.1. Creating User Groups

In the ERA Admin area select Groups from the menu on the left; this will give you a list of all the current user groups that exist. Click on Create New Group to get to the group creation screen. First change the name of the group as per the section 3.2: Group Naming Conventions and hit Update Name. Once the group has been renamed click on Add EPerson to Group; this gives you a list of all the email addresses of EPeople on the system. Select as many EPeople as you require to be added to the group; to select multiple email addresses hold down <Ctrl> on your keyboard while clicking on the list. Once you have chosen all of the people that you wish to add to the group click on Add EPerson.

The group has now been created with all of the selected EPeople.

3.2. Adding Users to User Groups

In the ERA Admin area select Groups from the menu on the left; this will give you a list of all the current user groups that exist. Find the group that you wish to add a user to and select Edit from the line on which you find the group. Click on Add EPerson to Group; this gives you a list of all the email addresses of EPeople on the system. Select as many EPeople as you require to be added to the group; to select multiple email addresses hold down <Ctrl> on your keyboard while clicking on the list. Once you have chosen all of the people that you wish to add to the group click on Add EPerson.

The group has now been created with all of the additional EPeople.

3.3. Removing Users from User Groups

In the ERA Admin area select Groups from the menu on the left; this will give you a list of all the current user groups that exist. Find the group that you wish to remove a user from and select Edit from the line on which you find the group. Click on Remove next to each user that you wish to remove from the group.

3.4. Removing User Groups

In the ERA Admin area select Groups from the menu on the left; this will give you a list of all the current user groups that exist. Find the group that you wish to remove and click Delete on the line on which you find it.

Note: Administrators are, by their very nature, capable of performing many potentially damaging operations within the system, and great care should be exercised when logged in as an administrator and performing hazardous operations. Changes cannot be undone.

3.2. Group Naming Conventions

All group names (with the exception of the Administrator and Anonymous groups, which should never be renamed) must follow the naming conventions laid out here.

3.2.1. Workflow Groups

These groups contain users whose role is to receive the submitted items at a specified stage of the workflow. The name of these groups should be of the form:

WF(<workflow step>): <Collection wf group belongs to>

For example:

WF(3): Institute of Cell and Molecular Biology (ICMB)

This is the workflow group dealing with the third workflow step for the Institute of Cell and Molecular Biology Collection.

WF(2): Accounting and Business Method (Theses and Dissertations)

This is the workflow group dealing with the third workflow step for the Accounting and Business Method (Theses and Dissertations) Collection.

3.2.2. Supervisor Groups

These groups contain supervisors and advisors for one specific supervision order over a single thesis. The name of these groups should be of the form:

SU: <email address of student being supervised>

For example:

SU: a.n.other@ed.ac.uk

Supervising group for the item being authored by the person with the email address: a.n.other@ed.ac.uk

3.2.3. Submitter Groups

These groups contain the users who may submit to a particular Collection in ERA. The name of these groups should be of the form:

IN: <Collection group can submit to>

For example:

IN: Accounting and Business Method (Theses and Dissertations)

This would contain PhD and Masters Students submitting to the Accounting and Business Method (Theses and Dissertations) Collection.

IN: Institute of Cell and Molecular Biology (ICMB)

This would contain academics working for the Institute of Cell and Molecular Biology who are submitting content to ERA.

4. Theses and Dissertations

4.1. Configuring the Workflow

If your Collection is specially designated as a Thesis and Dissertations Collection, the following workflow configuration is required:

Workflow Step 1 Group: This group should contain the workflow administrators who work in the College Office and will take delivery of theses. For details of the duties of this group see the section “Duties of Workflow Groups”.

Workflow Step 2 Group: This group should contain one of the following configurations:

Empty: If online marking is not desired, this workflow step should be left empty. There is no need to place a group here.
Examiners: The internal and external examiners who will be responsible for marking the thesis, performing the viva and recommending corrections should be members of this group.

Workflow Step 3 Group: This group should contain the Collections librarians who will be responsible for ensuring the quality of the metadata and performing the final checks before the thesis reaches the archive.

For details of the duties of these groups see the section 4.2: Duties of the Workflow Groups.

4.1.1. The Future Workflow

The theses and dissertation workflow is due to change in line with upcoming university policy. The workflow will, in the fullness of time, be migrated to the following form:

Workflow Step 1 Group: This group will contain the binder department whose responsibility it will be to produce the relevant number of bound copies of the thesis (in liaison with the student).

Workflow Step 2 Group: This group should contain the Collections librarians who will be responsible for ensuring the quality of the metadata and performing the final checks before the thesis reaches the archive.

Workflow Step 3 Group: This group should contain the ERA administrators who will ensure that any restrictions have been correctly applied and that the thesis is in a fit archival state.

For more information regarding the future workflow see Appendix B.

4.2. Duties of the Workflow Groups

Each of the workflow groups performs a specific function in the ingest of submitted items into ERA. In this section we detail the duties of each workflow group.

4.2.1 Step One: College Office

The College Office for the relevant department of the submitter is responsible for ensuring that all of the criteria for E-Thesis submission have been met before allowing the submission to continue. The checks that need to be performed are as follows:

Has the Intention to Submit form been completed and handed in?
Has the relevant licence been attributed to the item? For more information on this see the section 4.4: Licensing and Restrictions.
Are all the required files within the item?
Is the correct Institution; College; School field set? For more information on this see the section 4.3: Publisher Naming Conventions
Is the submitter allowed to submit a thesis or dissertation to this Collection?

If all of the above criteria are considered to be met by the relevant College Office then the item may be accepted to move on to the next workflow stage.

4.2.2. Step Two: None

This workflow step is currently left empty, although it can be filled later with a group who require the facilities: edit metadata, reject, approve for submission.

4.2.3 Step Three: Library

The Library is responsible for ensuring that the item meets the minimum requirements to enter into the archive. The following tasks or checks need to me done before approving the submission:

The author's name should be in a standard format.
The classifications may be given for any of the subject classification fields if deemed necessary.
The relevant restrictions, if necessary, are applied before the item reaches the archive. For more information on this see the section 4.4: Licensing and Restrictions.
The metadata is exported in MARC21 format for the library catalogue (This feature is not yet enabled).

Once these tasks have been performed, the item can be accepted into the archive.

4.3. Publisher Naming Conventions

The Publisher in the context of a thesis or dissertation is considered to be the school in which the student was based during the work. This is of the form:

University of Edinburgh. <College>. <School>.

For example, if the student performed the work within some unit of the School of Informatics, the standard publisher name would read:

University of Edinburgh. College of Science and Engineering. School of Informatics.

4.4. Licensing and Restrictions

4.4.1. Description of Licences and Restrictions

There are three licences that are simultaneously agreed to when submitting a thesis or dissertation:

1. Deposit Licence: This gives ERA the rights it requires to accept the submission, such as a non-exclusive licence to publish the work and to preserve it in whatever manner necessary; a confirmation that the work does not infringe copyright; and confirmation that the University is not obliged to take legal action in the event of breach of copyright or other intellectual property rights.

2. User Licence: This gives visitors to the site the rights that they need in order to obtain reasonable, free access to the work. This is a Creative Commons Attribution-NonCommercial-ShareAlike 1.0 licence (http://creativecommons.org/licenses/by-nc-sa/1.0/).

3. Restriction Licence: A request by the author to restrict the licence from all but ERA administrators (only for the purpose of preservation and long term storage).

See Appendix A for copies of the licences.

There are 6 kinds of restriction setting available for theses and dissertations. This restriction level defines how the licences detailed above will be applied at submission:

1. No Restriction: The thesis or dissertation is publicly available

2. Domain Restricted 1 Year: The thesis or dissertation may not be viewed by non-affiliates of the University of Edinburgh for a period of one year. After this it reverts to (1).

3. Domain Restricted 2 Years: The thesis or dissertation may not be viewed by non-affiliates of the University of Edinburgh for a period of two years. After this it reverts to (1).

4. Restricted 1 Year: The thesis or dissertation may not be viewed by anyone other than the submitter and supervisors for a period of one year. After this it reverts to (1).

5. Restricted 2 Years: The thesis or dissertation may not be viewed by anyone other than the submitter and supervisors for a period of two years. After this it reverts to (1).

6. Total Restriction: The thesis or dissertation is exempt from the Freedom of Information Act and may not be viewed by anyone other than the author and supervisors for an indefinite period. It will never be publicly available unless specifically requested by the author at a later date.

4.4.2. Structure of the Licence

The licence takes the form:

Licence header
Time dependent information if necessary
Permanent Licence
Temporary Licence if required
Site Licence

Below is an example of what you may encounter when opening the licence file:

License granted by Andrew Other (a.n.other@ed.ac.uk) on 2004-06-16T14:44:58Z (GMT):

This header information lets you know who agreed to the licence, their email address, and when they agreed.

=========================================================

Time Dependencies on this Licence

=========================================================

The “Permanent Licence” contained within this file is limited in scope for 2 years. Until 30th March 2006 the licence applies only to users who exist within the ed.ac.uk domain

For all users outside ed.ac.uk the “Temporary Licence” contained within this file applies.

=========================================================

The next section is then the time dependency header. This let you know if there are any restrictions in this licence that expire after a certain timeframe. These are restrictions (2), (3), (4) and (5) in the section 4.4.1: Description of Licences and Restrictions. If this header is present you will have to apply one of those restrictions (more information on this further down); if not then the licence is either a permanent restriction or publicly available. In general most licences will be publicly available.

If the item does not have a time dependency header then the next section will read:

=========================================================

| Use Licence |

=========================================================

This is followed by the text of the standard user licence as per Appendix A. Each section of the licence is separated from the other sections by a horizontal line thus:

=========================================================

If the item does have a time dependency then the rest of this part of the licence is split into two parts: a permanent licence and a temporary licence. The permanent licence section defines the licence after the period that the time dependency header covers, and is denoted thus:

=========================================================

| Permanent Licence |

=========================================================

The temporary licence section defines the licence during the period that the time dependency header defines, and is denoted thus:

=========================================================

| Temporary Licence |

=========================================================

The licence then always terminates with the deposit licence irrespective of the content that is provided before. The deposit licence is denoted thus (it is still currently referred to as a site licence but this term is deprecated):

=========================================================

| Site Licence |

=========================================================

4.5. Item Template

To set up an item template follow the instructions in 2.5: Configuring Item Templates to set up the template and use the values as described below:

Select publisher from the pull-down list underneath the columns Elements and Qualifier, then enter the Value as per the section 4.3: Publisher Naming Conventions. In the box under the column Language you should enter letters: en. Press Add, and the default value for the publisher will be added to the item template.

If you make a mistake with this it is necessary to press Remove and to start entering the publisher details again from scratch.

4.6. Configuring Supervision Orders

Supervision Orders are managed in the ERA Administration area. Select Supervisors from the menu on the left and you are presented with three options:

Add a Supervision Order
View Current Supervision Orders
Clean Supervision Order Database

The sections below detail how to deal with common supervision order tasks.

Note: The option to Clean Supervision Order Database should be used once in a while just to perform basic maintenance operations on the database. It is completely automatic and takes a very short time to execute. Simply click the Clean Supervision Order Database button once in a while.

4.6.1. Viewing Current Supervision Orders

Select View Current Supervision Orders and you are presented with a list of all supervision orders currently in effect. From this page you can modify the policies for the supervision order (See the section 6.2: Supervisor Groups) or remove the supervision order (See the section 4.6.3: Removing Supervision Orders).

The details you have on this page allow you to see the name of the group doing the supervising, the author of the item being supervised and the title of that item.

You may also add a supervision order from this page as per the section 4.6.2: Adding Supervision Orders.

4.6.2. Adding Supervision Orders

Select Add a Supervision Order from either the main supervision order page or the Current Supervision Orders page.

To set a supervision order you need to define the group to do the supervising and the item in the workspace to be supervised. In addition, this page gives you the option to set a default set of policies for the supervising group to have over the item. For more information on the policies see the section 6.2: Supervisor Groups.

Select the desired group from the pull down list of groups on this page. The group should be named as per the naming conventions in 3.2.2: Supervisor Groups. Next select the WorkSpace to be Supervised. This means clicking on the round select button on the right of the item in the listing you can see on this page.

Note: the ID that is in the left hand column of the item listing is the database id for the workspace item, and is there for the reference of system administrators.

Once you have chosen the group and the workspace item to be connected you may also select a default policy from the Initial Policy Setting pull down box. For more information on the nature of these policies see the section 6.2.1: Default Supervisor Policies.

Once happy with your selection click on Submit Supervision Order and your settings will be applied, and you will be returned to the supervision order main page.

4.6.3. Removing Supervision Orders

Go to the View Current Supervision Orders page and select Remove from the supervision order that to wish to remove. You will be asked to confirm the removal of the order, upon confirmation of which it will be removed from the system.

4.6.4. Customising Supervision Order Policies

Go to the View Current Supervision Orders page and select Policies for the supervision order for which you would like to customise the policies. You will be taken to the Policies for Item page. From here you may customise the policies for the particular item.

In order to set policies for the supervisor group you should select, for example, Add New Policy for the item or any of its component parts, then select the supervisor group that you are wanting to configure from the given list of groups. You can then select the Action that you want to perform and hit Save Policy.

For more details on policy administration see the section 6.4: General Policy Administration.

5. Other Research Material

5.1. Configuring the Workflow

Each of the workflow groups performs a specific function in the ingest of submitted items into ERA. In this section we detail the duties of each workflow group

If your Collection is not specially designated (see section 2.3: Special Designations for more information), the following workflow configuration is required:

Workflow Step 1 Group: This group should be left blank.

Workflow Step 2 Group: This group should contain a school secretary or local school administrator who can verify the validity and authenticity of submissions.

Workflow Step 3 Group: This group should contain librarians who will be responsible for ensuring the quality of the metadata and performing the final checks before the item reaches the archive.

For details of the duties of these groups see the section 5.2: Duties of the Workflow Groups.

Note: The set up in this section is dependent on the desires of the collection administrators. Specific workflow setups for collections within ERA are detailed in Appendix C.

5.2. Duties of the Workflow Groups

Each of the workflow groups performs a specific function in the ingest of submitted items into ERA. In this section we detail the duties of each workflow group.

5.2.1 Step One: None

This workflow step is currently left empty, although it can be filled later with a group who require the facilities: reject, approve for submission.

5.2.2. Step Two: School Administrator

The School Administrator for the relevant department of the submitter is responsible for ensuring that all of the criteria for allowing submission of a piece of research material have been met before allowing the submission to continue. The checks that need to be performed are as follows:

Is the submitter a member of the department to which they are submitting?
Does the submitter have copyright permission from any publishing body to self-archive the item in the Edinburgh Research Archive?
Is the item coherent and complete?
Is the item appropriate content for the School’s section of the Edinburgh Research Archive?

If all of the above criteria are considered to be met by the relevant School Administrator then the item may be accepted to move on to the next workflow stage.

5.2.3 Step Three: Library

The Library is responsible for ensuring that the item meets the minimal requirements to enter the archive. The following tasks or checks need to me done before approving the submission:

The author's name should be in a standard format.
The metadata must be of sufficient quality, as judged by the cataloguer.

Once these tasks have been performed, the item can be accepted into the archive.

6. Authorisation Administration

To administer the system authorisations, go to the ERA admin area and select Authorization from the menu on the left. This provides you with four options:

1. Manage a Community's Policies

2. Manage Collection's Policies

3. Manage An Item's Policies

4. Advanced/Item Wildcard Policy Admin Tool

The following sections use one of these options to configure the authorisations required by the system.

6.1. Submitter Groups

Submitter groups are groups of individuals who are permitted to submit to a given collection. Each collection should have exactly one submitter group associated with it, and all authorised users should be added to that group.

In the Authorisation Administration section of the ERA admin area select Manage Collection's Policies. You are presented with a list of all the Collections in the system. Select the Collection that you wish to configure the submitter group policies for and then click Edit Policies. You are now presented with a list of all the current policies associated with that Collection.

Click Add New at the top of the page and you are presented with a list of all the groups on the system. Select the group that you wish to set up a policy for. It should be possible to locate the group easily as it will be named as per the section 3.2.3: Submitter Groups.

Underneath the list of all the user groups, go to the Action: pull-down menu, choose ADD then click Save Policy. This returns you to the policy listing for the Collection and you should see a new line which has the new policy detailed.

6.2. Supervisor Groups

6.2.1. Default Supervisor Policies

In general the polices for your supervisor groups are pre-defined at the point of creation of the Supervision Order. See the section 4.6: Configuring Supervision Orders for more information. This section then details the default policies that are defined when creating supervision orders.

There are three default policy types that can be applied when a supervision order is created:

1. None - The supervision order is created but the supervising group is not given any policies regarding the item to be supervised. This usually indicates that the administrator has decided to manually set policies for this supervision order.

2. Observer - The supervising group is given READ access to the item (but not to any bundles or bitstreams that already exist). Any new bundles or bitstreams inherit the supervision group's policy to permit READ operations.

3. Editor - The supervising group is given ADD, WRITE, and READ access to the item (but not any bundles or bitstreams that already exist). Any new bundles or bitstreams inherit the supervising groups's policy to permit ADD, WRITE and READ operations.

6.2.2. Changing Supervisor Policies

In the ERA Admin area select Supervisors from the menu on the left then click View Current Supervision Orders. This shows you a list of all of the supervision orders currently set. On the left of the supervision order whose policy you wish to modify click on Policies, and you will be taken to the policy set for the item.

From this page you may add new policies as per the section Authorisation Administration: General Policy Administration.

6.3. Workflow Groups

The policies for workflow groups are automatically managed by the system when the group is set up as a workflow group. The policies this group has are dependent on the position in the workflow that they occupy.

6.4. General Policy Administration

In the ERA Admin area select Authorization from the menu on the left. This gives you access to the four policy administration areas.

6.4.1. Authorisation Actions

The following authorisation actions are available:

READ

Give users the permission to view metadata associated with an entity within the system. For example, item metadata or community metadata

WRITE

Give users the permission to add or edit metadata associated with an item

Gives users the permission to add sub-entities to the entity. For example, to add items to a collection or to add bitstreams to an item.

REMOVE

Gives users the permission to remove sub entities from an entity. For example, items from a collection of bitstreams from an item.

DEFUALT_BITSTREAM_READ

Gives users the permissions to view and item's bitstreams

DEFAULT_ITEM_READ

Gives users the permissions to view an item's metadata

WORKFLOW_STEP_1

Give the group the permissions required to be part of a standard workflow step 1

WORKFLOW_STEP_2

Give the group the permissions required to be part of a standard workflow step 2

WORKFLOW_STEP_3

Give the group the permissions required to be part of a standard workflow step 3

WORKFLOW_ABORT

Give the group the permissions required to abort the workflow process for any given item.

OBSOLETE (DELETE)

This permission is deprecated and should not be used.

6.4.2. Community, Collection or Item Policies

Click Manage a Communitiy's Policies, Manage a Collection's Policies or Manage an Item's Policies, then choose the community or collection that you want to configure, or enter the handle or ID of the item that you want to work with. You will be provided with a list of the current policies associated with that system entity.

The relevant parts of the policy are discussed briefly here:

The database id of the policy. There is no need to worry about this number - it will manage itself

Action

The action that the policy deals with. See the section 6.4.1: Authorisation Actions for more details.

EPerson

The EPerson to whom the policy applies. No policies should be applied to a single EPerson, so this field should always be blank.

Group

The group of EPersons to whom the policy applies.

To set a new policy hit Add New, to edit an existing policy hit Edit on the relevant policy line, and to remove a polity hit Delete on the relevant policy line.

When adding a new policy you need to select the group to which the policy will apply for the community, collection or item, and the action that the policy deal with (see 6.4.1 Authorisation Actions for more information). When editing a policy you can use exactly the same procedures as for adding a policy, but the values in the form will be pre-populated.

Note: If editing a policy, do not hit cancel unless you wish to remove the policy from the object. Instead use save policy without changing any details.

6.4.3. Advanced/Item Wildcard Policy Admin Tool

This tool allows you to set policies on items and their bitstreams for specific collections. Select Advanced/Item Wildcard Policy Admin Tool from the Authorization page to use this tool.

First select the collection to whose items or bitstreams you wish to apply policies. Next you need to choose the level at which you wish to apply the policies from the Content Type field. Choose either item or bitstream to effect all items or all bitstreams respectively. Third, choose the group to whom the policy will be granted, and then finally the action that will be granted to the group for the items or bitstreams in the given collection.

To add this new policy then you hit Add Policy at the bottom of the page. If, instead, you are wishing to remove a certain type of policy that may or may not exist in the system you can use Clear Policies and any matching policies will be cleared. This should be used with extreme caution as no indication as to the actions performed will be fed back to the administrator.

7. Common Tasks and Troubleshooting

7.1. New User Wants to Submit to a Collection

A user contacts the administrator when they have registered for an ERA account and have attempted to submit an item for the first time. At this stage they are presented with an error message announcing that they do not have permission to submit to any Collections and should contact the ERA administrator.

Once the user has contacted the administrator the following procedure must be followed:

Verify that the Collection exists. If it does not, verify that it could exist and create it as per the sections 2.1.1: Creating Communities and 2.2.1: Creating Collections.

Verify that the user is who they say they are, and should be given permission to submit to that Collection. Do this by contacting the School office and verifying that the user can be allowed to submit.

Find if a submitter group has already been created for the Collection. It will have a name of the form:

IN: <Collection to be submitted to>

Otherwise it will need to be created as per the section 3.1: Creating User Groups.

Add the user’s account to the user group for the Collection as per the section 3.2: Adding Users to User Groups.

Give the submitter group ADD permissions to the desired Collection. See the section 6: Authorisation Administration for more information.

The user will now be able to submit items to the Collection.

7.2. Submitted Item Contains Incorrect File

Note: changing files in the archive introduces some inconsistency in the persistence of the data. For this reason changing files in items should be done only when absolutely necessary. Ideally it should be done only immediately after an item has been submitted to the archive, when it is clear that an error has occurred. Otherwise the old file should either be kept in the archive and the new file uploaded alongside it, or a new item should be created containing the correct files

A user has submitted an item which contains the wrong file. There are three possibilities for the current situation of the item:

1. It is in the workflow, in stages 1 or 2

2. It is in the workflow, in stage 3

3. It is in the archive

If it is in the workflow stages 1 or 2 then the item should be rejected, and the user may correct the error in their workspace. If the item has made it to workflow 3 then refer to the section 7.4: Rejecting submissions from workflow step 3. The remainder of this section deals with the case where the item has already passed through the workflow and is in the archive.

Instruct the user to send you the file that should be in the archive, and to provide the information on the file which needs to be removed.

Go to the ERA Administration area and select Items from the menu on the left. You will be given the option to enter a Handle or an Internal ID. For more information on handles see the section Glossary: Handle.

Enter the Handle or the Internal ID of the item you wish to modify (most likely you will want to obtain the handle by browsing for the item in the archive), and click Find.

From this Edit Item page you can change the properties of items in the archive. Scroll to the bottom and you will find a section entitled Bitstreams which contains all the files associated with the item.

Remove the metadata associated with the file to be removed. These are the fields format.mimetype and format.extent. Be sure to select the correct entries as there may be more than one of each of these fields if there are multiple files.

Find the file that you want to remove in the list of files and select Remove. The file will be immediately removed.

Add the new file by selecting Add Bitstream. You will be taken to a page entitled Upload Bitstream, where you click on Choose to select a file on your machine to upload. Once you have chosen a file click Upload.

Add the metadata for the file you have just uploaded by selecting from the pull-down menu at the bottom of the metadata listing:

format.extent: enter into the box next to it the size in bytes of the file.
format.mimetype: enter the international standard mime-type for the file format. The mime-type is a code that helps define what sort of file we have. For example, text/plain is plain text and application/msword is a Microsoft Word document. For more information on mime-types refer to specific documentation from standards bodies.

You need to click on Add after you enter each metadata element.

Once you have finished click on Update at the bottom of the page.

7.3. An Item has been submitted to the Wrong Collection

Note: If an item has been submitted to the wrong collection, it is possible that the user's permissions are not set correctly, and this should be looked at in parallel to resolving the issue addressed here.

If an item has been submitted to the wrong collection it could be in one of three states:

1. In workflow steps 1 or 2

2. In workflow step 3

3. In the archive

If (1) the item should simply be rejected back to the user's workspace. If (2) look at the sub-section 7.4: Rejecting submission from workflow step 3. The remainder of this section deals with the case where the item is already in the archive.

This solution requires a degree of technical capability, and should not be attempted without some familiarity with the Linux operation system. If in doubt please contact the systems administrator for help.

Obtain the system ID of the item that has been wrongly submitted:

Obtain the handle ID by browsing for the item in the archive
In the administrative area, in the section Items, enter the Handle where indicated and click Find.
At the top of the Edit Item page you will see the field Item internal ID. You should note this number down for later use. We will refer to it as <item id>

Obtain the system ID of the collection that you wish to move the item to

In the administration area, select Communities/Collections from the menu on the left.
Find the collection that you wish to move the item to.
Note down the DB ID, which is indicated in brackets after the collection name. We will refer to it as <new collection id>

Log into agrona.lib.ed.ac.uk as the dspace user. If you don't know how to do this please contact the system administrator.
Start a session with the database with: psql dspace
Modify the database to move the item from one collection to another with the following SQL:

UPDATE collection2item SET collection_id = <new collection id> WHERE item_id = <item id>

Re-index the database for the changes to take effect in the search facilities by going to /u01/dspace/bin on agrona and executing the command:

./index-all

7.4. Rejecting submissions from workflow step 3

Since the workflow step 3 options do not include a Reject facility it is necessary to go to the admin area to solve this problem.

Go to the ERA admin area and select Workflow from the menu on the left
Find the item that has been submitted to the wrong collection and hit Abort. This returns it to the user for re-submission to the correct collection.
Email the user notifying them that their submission has been returned to them.

Glossary

Handle

A form of persistent identifier which ERA uses to provide permanent locators to its content over time. This is a service provided for free by a third party (CNRI). Handles for items in ERA can be see on the item metadata page in the form http://hdl.handle.net/handle/1842/xxx.

Appendix A: Licences

A1. Site Licence

EDINBURGH RESEARCH ARCHIVE - DEPOSIT AGREEMENT

COVERED WORK

I would like to deposit my material in the University of Edinburgh ePrints Service - Edinburgh Research Archive (ERA). Research referred to below as "Work" is covered by this agreement and when I deposit my Work in the future, whether personally or through an assistant or other agent, I agree to the following:

NON-EXCLUSIVE RIGHTS

Rights granted to ERA through this agreement are entirely non-exclusive. I am free to publish the Work in its present version or future versions elsewhere. I agree that ERA may, without changing content, translate the Work to any medium or format for the purpose of secure storage.

DEPOSIT IN ERA

I understand that work deposited in ERA will be accessible to a wide variety of people and institutions - including automated agents - via the World Wide Web.

I understand that once the Work is deposited, a citation to the Work will always remain visible, although the author retains the right to update the Work. Removal of the item can be made after discussion with ERA administrators.

I AGREE AS FOLLOWS:

- That I have the authority of the authors to make this agreement, and to hereby give ERA the right to make available the Work in the way described above.

- That I have exercised reasonable care to ensure that the Work is original, and does not to the best of my knowledge infringe upon anyone's copyright.

A2. Use Licence

Attribution-NonCommercial-ShareAlike 1.0

You are free:

- to copy, distribute, display, and perform the work

- to make derivative works

Under the following conditions:

-Attribution.

You must give the original author credit.

-Noncommercial.

You may not use this work for commercial purposes.

-Share Alike.

If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the author.

Your fair use and other rights are in no way affected by the above.

********************************************************************************

URL (human-readable summary):

http://creativecommons.org/licenses/by-nc-sa/1.0/

URL (legal code):

http://creativecommons.org/licenses/by-nc-sa/1.0/legalcode

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

A3. Restrict Licence

I request that no access of any kind be permitted to this item. No access means that no-one, not even the author, will have access to this item excepting ERA administrators for the purposes of long term storage and preservation only.

The University of Edinburgh is under no obligation to contact me about changing the period of restriction.

Appendix B: Workflow Documentation

Theses management at the University of Edinburgh:

Incorporating electronic theses

Version 1- 5.11.04

Circulation- Internal

Author: Dr Theo Andrew

This paper proposes a viable approach for the adoption of a University-wide electronic thesis deposit system which will supplement the existing system of print management. The proposal here is built upon research findings from the JISC-funded Theses Alive pilot project. This paper will be of interest to:

Those responsible for the management of print theses at EUL (Special Collections and cataloguing staff).

Senatus Postgraduate Studies Committee

Senior managers responsible for the Digital Library Division at EUL

Printing and binding staff at EUL

Background

The JISC-funded Theses Alive! project was initiated in Oct 2002 and is due to end in Oct 2004. The projects aims and objectives were to investigate the procedures and processes required in setting up an institutional electronic theses programme, and to develop tools for the digital management of electronic theses and dissemination via the internet. The project was instrumental in developing and setting up the Edinburgh Research Archive (ERA), a digital institutional repository capable of capturing, storing, managing and disseminating all forms of digital research output produced by the university. ERA has been operational as a pilot project since June 2004 and is due to be formally launched as a digital library service in October.

Dual e-thesis/print thesis submission proposal

1. This paper describes a new system for theses management utilising the benefits networked computing can offer. As this proposal does not affect the established practice of thesis examination, a number of prior actions occur before the process described here. These prior actions include:

Intention to submit form,
submission of two soft-bound copies,
Thesis viva + corrections,
examiners check corrections + sign student off with faculty office.

2. We have identified two areas that need addressing before the student submits their thesis. Firstly, the students need to be aware of the electronic thesis submission process and have adequate support from the institution. Guidance should be provided from the relevant Faculty Office prior to final submission. This could take the form of literature provided by the library advising students of the process.

3. Secondly, permission will need to be sought for any third party copyright material included in the thesis. Practically speaking, only the authors know what material in their thesis requires copyright clearance. It is unrealistic for an institution to verify each thesis for breach of third party copyright, to seek permissions if necessary, all on top of the ancillary checks that need to take place. We suggest that authors should have the responsibility for this task as they are in the best position to do so. However, placing the onus on authors can be a huge burden without support. Therefore it may be necessary to provide training during the writing process to inform authors of copyright responsibilities. Such training could be incorporated into existing Thesis Workshops.

4. The electronic thesis deposit system described here starts when the student submits their e-thesis to ERA. This can occur via the internet, or by mediated deposit when hard to do so, e.g. physical restrictions or thesis problems. Once the thesis has been deposited the item is sent to the Workflow Step 1 task pool.

WF(1): Bindery staff

5. ERA automatically generates and sends email to the Bindery alerting staff to the new submitted thesis. Contained within the text is a URL which directs the staff to the Bindery task pool in ERA where the files can be downloaded (Fig.1.)

Figure 1: Email generated by ERA Workflow Step 1 informing Bindery staff of new submission

Figure 2: Workflow Step 1 task pool (arrow points to submitted item).

6. Bindery staff contact student via email to confirm the print run details, binding options/specifications and payment options.

7. Payment options will include the choice to pay over the internet using a credit/debit card, which is not currently available, via The University of Edinburgh's Electronic Receipting Application (http://www.finance.ed.ac.uk/ePayment/erafrontpage.htm). For those who do not wish to pay by credit/debit card then payment can be made at the Main Library site Bindery.

8. Once confirmed the Bindery will print/bind the thesis from the downloaded files in ERA, plus any requested additional copies. Once this is done then the e-thesis can be moved to the next stage of the workflow (as shown in Fig.3).

Figure 3: Workflow step 1 options

9. The primary print copy, along with copies of the abstract will then be sent to the relevant faculty office via internal mail, whilst the additional copies will be picked up by the student from the Main Library site. Any outstanding payments (i.e. non-credit card) can be made at this point.

Faculty Office

10. The student is required to go to the Faculty Office to sign the primary print copy of the thesis and to be checked off the graduation list. Also at this point any debts to the university are also checked, which could include the printing/binding costs incurred. With this administrative task completed the primary print copy is sent to the Main Library.

WF(2): Special Collections/Cataloguing

11. After the e-thesis is signed off from Workflow step 1 it is assigned to the Special Collections task pool. An email is automatically generated to the relevant staff which directs them to the task pool in ERA (Similar to Fig.1).

(b)

(a)

Figure 4: Workflow step 2 options. Edit metadata option (a) and approval option (b) highlighted.

12. Information input by the submitter forms the basis for the enhanced Dublin Core metadata record generated by ERA. As this is input from the student directly it needs to be checked and verified by the cataloguing staff. This can be easily done from the Workflow step 2 options (Fig.4.). Where appropriate, this record can be enhanced by

metadata editors, for example assigning Library of Congress Subject Headings for HSS theses. Depending on the metadata editor’s preferences this work can be carried out on either the e-thesis or the primary print copy as the workflow converges at this point (See flowchart). However, it is envisaged that any metadata enhancements would be recorded electronically in ERA.

13. Once the metadata records have been validated and enhanced, the item can be approved (Fig. 4b) and sent to the next ERA administrative workflow step.

14. Outside of the thesis submission critical path a number of additional tasks take place. This includes sending the abstract of the thesis to the ‘Index to Theses’ service. Unfortunately, this currently this cannot be done electronically.

15. It should be possible to automatically generate catalogue records from ERA via a Dublin Core to MARC21 cross-walk. These can be exported to the online catalogue, with links available between the two records.

WF(3): ERA Administration

16. The final step on the thesis submission critical path is the role of the ERA administrator, who will need to check that all restricted theses have correct deposit and use licences and also a valid FOIA exemption. Once these are checked the thesis can be accessioned into repository.

17. Essentially, as soon as the thesis has been cleared by the ERA administrator the item will be available online. It is likely that this will occur before the student’s graduation. To withhold the thesis until graduation will create an administrative burden and may have implications with the FOIA. We would recommend releasing the thesis as soon as it has cleared the ERA workflow.

18. Once the thesis is online metadata from ERA will be automatically harvested via the OAI-PMH by data aggregation services, which in the future could include the BL. Similarly web-indexing robots from Google and Microsoft automatically trawl the website for their browsing services.