Telstar

6.7.3 RefWorks Account structure

6.7.3.1 Assumptions

• There is a requirement for multiple users to manage course related references for a single course
• References will be exported to a RIS file before being incorporated into structured content.
• References will also be exposed via RefShare to allow updates and additions to references during the presentation of a course within the course ‘Resources’ page within the VLE
• References can also be imported into the course from RIS or RefWorks XML files, but for simplicity this route is omitted from the models
• There will be an overlap between those references incorporated in structured content and those included in the Resources page, and that it is desirable for these to be managed in a similar way

6.7.3.2 Limitations

RefWorks does not support any graduated security model. There is a single username/password for an account, and anyone with this username/password has full permissions within the account. In order to have multiple users contributing to and managing references within the account, they have to share this single username/password.

6.7.3.3 Model 1 – Single RefWorks database, multiple users

Advantages

• A single Reference record can be used across multiple courses, and when details of the Reference need amending, this could be done in a single place
• Single RefWorks account to create and administer

Issues

• If access to the single RefWorks database were to be given to all possible contributors (i.e. every member of each course team) then potentially hundreds (thousands?) of users sharing a single username and password and the ability to update all records (whether used in their course or not), and the risk of errors being made is large.
• If access to the single RefWorks database is restricted to a smaller, core, team (e.g. Learning and Teaching Librarians) the work required to keep this up to date falls on a small number of people, and course teams do not have direct access

6.7.3.4 Model 2 – One RefWorks database per course

Advantages

• Only small numbers of people need access to any particular RefWorks database
• Course teams could have direct access

Disadvantages

• Multiple copies of each Reference need to be maintained. For References used on many courses this could lead to a very large overhead (if the details of the reference were to change)
• Hundreds of RefWorks databases to manage (account creation and of user names and passwords, account deletion)

6.7.3.5 Model 3 – One RefWorks database per course plus a Library database for common resources

Advantages

• Resources common across multiple courses are managed in a single place (the RefWorks Library Account)
• Only small numbers of people need access to any particular RefWorks database
• Course teams could have direct access

Disadvantages

• Hundreds of RefWorks databases to manage (account creation and of user names and passwords, account deletion)
• Library Resources continue to be seen as separate to Course specific resources
• Still potential for References to be duplicated across courses, and so lack of central management – except for those in the RefWorks Library account

6.7.3.6 Other Models

While models 2 and 3 assume one RefWorks database for each course, it would be possible to group courses together and so reduce the number of RefWorks databases that need managing (e.g. have a RefWorks database that manages references a small group of courses, or all courses within a specific subject area). Taking this approach could mean striking a balance between the advantages and disadvantages of the models outlined above. An example could be that a single RefWorks could be used for all courses across a faculty, and this central account could be managed on behalf of the faculty by the library.

6.7.3.7 Discussion

Essentially the lack of a granular permissions model in RefWorks forces a choice between the ability to distribute responsibility for building course reference lists and the ease with which the references can be managed.

Model 1 would only work if you assigned a small team to the job of managing the database, Quality Assuring the references, and building reference lists for courses (although obviously what went on those lists would be informed by the Course Teams).

Model 2 is more practical, as working at a course level would mean only a small number of people working in the same RefWorks at any time. Model 2 does not have the benefit of sharing common references across multiple courses, however interviews with course authors and library staff suggest that the majority of resources are not repeated over multiple courses, except perhaps very general resources.

Model 3 is a variation on Model 2 to allow for those resources which are repeated over multiple courses to be managed more efficiently. However, it creates a split between the ‘Library’ references, and the ‘Course’ references which is not necessarily desirable.

It should be noted that there are further variations around these models that could be adopted where seen as practical. For example a RefWorks account for a programme or faculty; or having multiple accounts per course.

6.7.3.8  Recommendations

1. Courses should adopt a model that best fits their requirements.
2. The best compromise that will suit the majority of courses is Model 2 with a RefWorks account dedicated to a course.
3. Variations on Model 2 which user a single RefWorks database for a faculty or programme may be appropriate where a small central team can be identified to manage all the references (e.g. library staff)
4. Central lists of resources could be created by the library that could be easily added to a course specific account.
5. Future work should investigate the possibility of enabling Model 1 by enabling a more sophisticated security model over RefWorks or alternative central databases.