UKCoRR Responds to RCUK’s Revised Policy on Open Access

As members will be aware over the past couple of weeks we have been collating feedback and comments from you all on the RCUK’s revised policy on open access. Many, many thanks to those members and Committee whom have contributed to the drafting of UKCoRR’s response – which I can confirm has just been submitted to their communications officer.  In the spirit of the openness that underlies everything UKCoRR does – the text of the communication follows.  Naturally we’ll share with you any and all response the Committee receives.
—-
UKCoRR, on behalf of its membership, wishes to respond to the RCUK’s proposed policy on access to research outputs, given that it is an area that directly impacts on the activities of our 250+ members across the UK’s research establishments.

At the outset, UKCoRR would like to commend the RCUK for a very clear, positive and explicit statement. In particular the restriction of support for embargoes longer than 6 months post-publication (12 for AHRC and ESRC funded work). UKCoRR are also delighted to note the tone of the policy in favouring more Open Access friendly journals and publishers for RCUK funded research outputs.

There are, however, several issues, concerns and clarifications that our membership would like us to flag up for your attention and consideration.

Definition of Open Access
UKCoRR would query the definition of Open Access to scholarly publications as digital journal articles. “The Research Councils define Open Access to mean unrestricted, on-line access to peer reviewed and published scholarly research papers.” [p2] and likewise your classification of books or monographs as “grey’ literature” [p3]. There are many other types of authoritative research output besides pdfs of journal articles, especially in arts and humanities research. It is our belief that the OA movement needs to lobby for access to all research outputs, and that there is a need to ensure that RCUK’s policy does not exclude this significant portion of the scholarly literature. The contents of our members’ Open Access repositories clearly demonstrate the richness, value and readership of such scholarly works.

Creative Commons
The CC licence is a potentially contentious issue [p2] and one that UKCoRR believes may create more problems than it solves.

The current model of Green OA (i.e. self-archiving in an IR) as opposed to Gold (i.e. author-institution pays), is predicated on a pragmatic negotiation of copyright with academic publishers and, along with high profile initiatives like SHERPA RoMEO, has encouraged growth of the number of RoMEO green journals which allow self archiving, and therefore in the potential number of OA papers that can be self-archived in repositories. UKCoRR is concerned that the new policy will potentially impact on this strategy, and on repositories which will have to assert CC-BY on relevant papers after a maximum embargo period of 6 months.

It is not clear what effect the policy may have on journals defined as ‘green’ by SHERPA RoMEO and on the application of embargoes. Journals may choose to become RCUK-compliant, to remain RoMEO green but not compliant, or to reject green and compliance altogether with individual publishers’ policy likely to be informed by the potential loss of revenue resulting from a universal 6 month embargo and by the extent to which other funders will follow RCUK’s lead on CC-BY.

HE institutions are increasingly adopting policies on OA and self-archiving in their repositories and UKCoRR has some concerns that the policy should more explicitly consider implications to this Green route to Open Access

Limitation on Publication Destination
While UKCoRR acknowledges the value of this part of the policy, we note that it is likely to cause anxiety among academic stakeholders unless backed up by clear support mechanisms. If our members’ author stakeholders are made to feel more constrained on their choice of where to publish [p3] it could generate an adverse perception and consequent resistance towards the implementation of Open Access policies within their organisation; already an issue that many of our members encounter in the course of their work. However, we look forward with interest to the impact this may have on those publishers who to date have been reluctant to embrace more Open Access compliant author copyright licence agreements.

Impact on Publisher Policy
The policy would require a significant change in many publishers’ policies, and would limit the choice of journals to those that are recognised as compliant. Sources of funding for Open Access compliance will therefore become a more pressing issue across many institutions, where few currently have resources set aside to cope with such moves [p5]. We would encourage RCUK to be more proactive in ensuring that all researchers, especially PIs, and research administrators are made fully aware that this is part of the indirect costs allocated within the grant application and award. Clarity on RCUK’s stance in this regard would be especially welcomed by our membership.

Access to Data Outputs
The final paragraph in section 8 says “The underlying research materials do not necessarily have to be made Open Access” [p6]. While UKCoRR understands that mandating open data publication is out of the scope of this policy, we would welcome an approach that encourages this. There is an opportunity here to get more open data for use and reuse by the research community while respecting the normal provisos about commercial sensitivity, patient confidentiality etc.

Compliance Mechanisms
Our membership would also be interested in knowing more about how the “mechanisms to help ensure compliance” will operate [p6]. Given the time scales and workloads already placed upon our members, greater clarity in this regard and at the earliest opportunity will make such mechanisms more practicable for us to implement.

OA Fields and ROS
Given the timing of this, we would also query the lack of proper OA fields built in to the recently launched Research Outcomes System (ROS). There are fields for SHERPA/RoMEO data and preprint/postprint, but nothing to clarify if an OA version actually exists. While we are aware of discussions ongoing with the JISC that UKCoRR has also been party to, we would welcome this being highlighted in the policy.

Final Comments
Overall, as strong advocates of the cultural, economic and intellectual benefits of Open Access to the UK’s unique research outputs UKCoRR keenly supports this bold policy.

We welcome any opportunity to enter into a dialogue with the RCUK as to how this could be cascaded, both to our membership and our academic stakeholders.

Using Google Analytics Statistics within DSpace

Thank you to Claire Knowles of Edinburgh University who provides this overview of how they have been able to display statistics from Google Analytics in DSpace.
—-
In 2009 Edinburgh University Digital Library adopted Google Analytics (GA) to track usage statistics within the DSpace Repositories it supports on behalf of the Scottish Digital Library Consortium (SDLC).  The GA statistics have proven much more reliable than the existing plugins available for DSpace previously with which we experienced lost statistics and inflated pageviews resulting from robots.

Unfortunately the GA statistics for sites being tracked are only viewable via the GA dashboard for which users require a Google account and managed permissions.  This limits the visibility of statistics to a few people at each institution.   Prompted by the presentation given by Graham Triggs (then working for BioMed Central) at the Open Repositories Conference 2010, we decided to write some code to make the Google Analytics statistics visible to all users of the DSpace installations.

The work has been broken into phases:

1. Capture of downloads in DSpace by Google Analytics. 

The basic GA tracking code within DSpace is unable to capture the number of file downloads as these are not links within pages.  To address this we added code to the two downloads on the item page to enable these download actions to be measured.  This captured all downloads within Dspace but not those users coming directly from search engines to the download file.  To capture these statistics we decided to reroute all users back through the item page. This means that they now have two clicks instead of one to reach the download but it enables us to capture these statistics and also raises the visibility of the Repository to users.  To reduce the inconvenience to the users we moved the file downloads links on the item page from the bottom to the top so that they do not have to scroll down to find the download. 

2. Adding page views to each item page within DSpace

Secondly, we added the number of page views within the last year to the item page.  This was a proof of concept which showed that we could connect to the Google Analytics API and pull back statistics into DSpace.  We decided to only include the number of views for the past year to reduce any disparities between the the number of pageviews between older and new items.

3. Making statistics viewable within the DSpace web pages. 

We decided to make the GA statistics available at three levels: item, collection and repository as this provides most of the statistics which are requested by users.  Using the Query Explorer provided by Google we were able to test and refine our queries before starting development.  The pages were developed using the Google Analytics java API, jQuery and the Google Chart tools to draw graphs and maps.  

As we complete the rollout of Google Analytics to all the SDLC partners we are starting to look to what other statistics we would like to make available both from Google Analytics and also possible exposing statistical information about DSpace using Google’s chart tools. One statistic that would be of interest to researchers is collating and presenting download figures for authors (rather than by item/collection/community).

We have encountered problems separating the item, collection and community statistics within DSpace as all of their urls are formatted in the same way, we therefore have to query DSpace data to do this and cannot distinguish them using the statistics data alone.  If the requested item, file, collection or community is not available in DSpace an error page is returned, these were being recorded in the same way as successful page which has led to invalid items being listed in the statistics top ten tables.  To prevent this error pages are now recorded as an error event within Google Analytics.

These changes have given us much greater understanding of how our repository is being used with the majority of users coming directly from Google.  The URLrewrite change led to a double of our download statistics as we now capture users who previously went straight to the download.

Thanks to: Scottish Digital Library Consortium, Stuart Wood and Gareth Johnson of University of Leicester for information on the URLrewrite, Graham Triggs formerly of BioMed Central and now Sympletic.

The code to enable GA stats within DSpace is freely available from github: https://github.com/seesmith/Dspace-googleanalytics

You can view our collection and item statistic changes at http://www.era.lib.ed.ac.uk

Using Google Analytics Statistics within DSpace

Thank you to Claire Knowles of Edinburgh University who provides this overview of how they have been able to display statistics from Google Analytics in DSpace.
—-
In 2009 Edinburgh University Digital Library adopted Google Analytics (GA) to track usage statistics within the DSpace Repositories it supports on behalf of the Scottish Digital Library Consortium (SDLC).  The GA statistics have proven much more reliable than the existing plugins available for DSpace previously with which we experienced lost statistics and inflated pageviews resulting from robots.

Unfortunately the GA statistics for sites being tracked are only viewable via the GA dashboard for which users require a Google account and managed permissions.  This limits the visibility of statistics to a few people at each institution.   Prompted by the presentation given by Graham Triggs (then working for BioMed Central) at the Open Repositories Conference 2010, we decided to write some code to make the Google Analytics statistics visible to all users of the DSpace installations.

The work has been broken into phases:

1. Capture of downloads in DSpace by Google Analytics. 

The basic GA tracking code within DSpace is unable to capture the number of file downloads as these are not links within pages.  To address this we added code to the two downloads on the item page to enable these download actions to be measured.  This captured all downloads within Dspace but not those users coming directly from search engines to the download file.  To capture these statistics we decided to reroute all users back through the item page. This means that they now have two clicks instead of one to reach the download but it enables us to capture these statistics and also raises the visibility of the Repository to users.  To reduce the inconvenience to the users we moved the file downloads links on the item page from the bottom to the top so that they do not have to scroll down to find the download. 

2. Adding page views to each item page within DSpace

Secondly, we added the number of page views within the last year to the item page.  This was a proof of concept which showed that we could connect to the Google Analytics API and pull back statistics into DSpace.  We decided to only include the number of views for the past year to reduce any disparities between the the number of pageviews between older and new items.

3. Making statistics viewable within the DSpace web pages. 

We decided to make the GA statistics available at three levels: item, collection and repository as this provides most of the statistics which are requested by users.  Using the Query Explorer provided by Google we were able to test and refine our queries before starting development.  The pages were developed using the Google Analytics java API, jQuery and the Google Chart tools to draw graphs and maps.  

As we complete the rollout of Google Analytics to all the SDLC partners we are starting to look to what other statistics we would like to make available both from Google Analytics and also possible exposing statistical information about DSpace using Google’s chart tools. One statistic that would be of interest to researchers is collating and presenting download figures for authors (rather than by item/collection/community).

We have encountered problems separating the item, collection and community statistics within DSpace as all of their urls are formatted in the same way, we therefore have to query DSpace data to do this and cannot distinguish them using the statistics data alone.  If the requested item, file, collection or community is not available in DSpace an error page is returned, these were being recorded in the same way as successful page which has led to invalid items being listed in the statistics top ten tables.  To prevent this error pages are now recorded as an error event within Google Analytics.

These changes have given us much greater understanding of how our repository is being used with the majority of users coming directly from Google.  The URLrewrite change led to a double of our download statistics as we now capture users who previously went straight to the download.

Thanks to: Scottish Digital Library Consortium, Stuart Wood and Gareth Johnson of University of Leicester for information on the URLrewrite, Graham Triggs formerly of BioMed Central and now Sympletic.

The code to enable GA stats within DSpace is freely available from github: https://github.com/seesmith/Dspace-googleanalytics

You can view our collection and item statistic changes at http://www.era.lib.ed.ac.uk

Using Google Analytics Statistics within DSpace

Thank you to Claire Knowles of Edinburgh University who provides this overview of how they have been able to display statistics from Google Analytics in DSpace.
—-
In 2009 Edinburgh University Digital Library adopted Google Analytics (GA) to track usage statistics within the DSpace Repositories it supports on behalf of the Scottish Digital Library Consortium (SDLC).  The GA statistics have proven much more reliable than the existing plugins available for DSpace previously with which we experienced lost statistics and inflated pageviews resulting from robots.

Unfortunately the GA statistics for sites being tracked are only viewable via the GA dashboard for which users require a Google account and managed permissions.  This limits the visibility of statistics to a few people at each institution.   Prompted by the presentation given by Graham Triggs (then working for BioMed Central) at the Open Repositories Conference 2010, we decided to write some code to make the Google Analytics statistics visible to all users of the DSpace installations.

The work has been broken into phases:

1. Capture of downloads in DSpace by Google Analytics. 

The basic GA tracking code within DSpace is unable to capture the number of file downloads as these are not links within pages.  To address this we added code to the two downloads on the item page to enable these download actions to be measured.  This captured all downloads within Dspace but not those users coming directly from search engines to the download file.  To capture these statistics we decided to reroute all users back through the item page. This means that they now have two clicks instead of one to reach the download but it enables us to capture these statistics and also raises the visibility of the Repository to users.  To reduce the inconvenience to the users we moved the file downloads links on the item page from the bottom to the top so that they do not have to scroll down to find the download. 

2. Adding page views to each item page within DSpace

Secondly, we added the number of page views within the last year to the item page.  This was a proof of concept which showed that we could connect to the Google Analytics API and pull back statistics into DSpace.  We decided to only include the number of views for the past year to reduce any disparities between the the number of pageviews between older and new items.

3. Making statistics viewable within the DSpace web pages. 

We decided to make the GA statistics available at three levels: item, collection and repository as this provides most of the statistics which are requested by users.  Using the Query Explorer provided by Google we were able to test and refine our queries before starting development.  The pages were developed using the Google Analytics java API, jQuery and the Google Chart tools to draw graphs and maps.  

As we complete the rollout of Google Analytics to all the SDLC partners we are starting to look to what other statistics we would like to make available both from Google Analytics and also possible exposing statistical information about DSpace using Google’s chart tools. One statistic that would be of interest to researchers is collating and presenting download figures for authors (rather than by item/collection/community).

We have encountered problems separating the item, collection and community statistics within DSpace as all of their urls are formatted in the same way, we therefore have to query DSpace data to do this and cannot distinguish them using the statistics data alone.  If the requested item, file, collection or community is not available in DSpace an error page is returned, these were being recorded in the same way as successful page which has led to invalid items being listed in the statistics top ten tables.  To prevent this error pages are now recorded as an error event within Google Analytics.

These changes have given us much greater understanding of how our repository is being used with the majority of users coming directly from Google.  The URLrewrite change led to a double of our download statistics as we now capture users who previously went straight to the download.

Thanks to: Scottish Digital Library Consortium, Stuart Wood and Gareth Johnson of University of Leicester for information on the URLrewrite, Graham Triggs formerly of BioMed Central and now Sympletic.

The code to enable GA stats within DSpace is freely available from github: https://github.com/seesmith/Dspace-googleanalytics

You can view our collection and item statistic changes at http://www.era.lib.ed.ac.uk