KE Usage Statistics Guidelines Work group

Problem definition

The problem with statistics is that they are comparable within one system, but not across systems. This is caused by using different robot filters, and different interpretations. Especially in an environment where reputation is so important that jobs are at stake, the usage statistics measurements need to be reliable. Therefore transparent agreements need to be made to exchange usage statistics in an interoperable manner.

This workgroup is dedicated to work on Guidelines for the Exchange of Usage Statistics.

Scope

The scope of the working group is founded in the insitutional repository world. Yet they have to keep the environment in mind of traditional publishers and modern scientific communication via blogs.

Role

The role of the KE usage statistics working group will be an advisary group that brings in real expertise from the field, working proactively in in usage statistics projects already.

Results and deliverables

Members

Group: ke-usage-statistics-workgroup
Benoit Pauwels (benoit.pauwels) benoit dot pauwels at ulb dot ac dot be
Hans-Werner Hilse (hans-werner.hilse) hilse at sub dot uni-goettingen dot de
Jochen Schirrwagen (jochen.schirrwagen) jochen dot schirrwagen at uni-bielefeld dot de
Maurice Vanderfeesten (maurice) vanderfeesten at surf dot nl
Paul Needham (paul.needham) paul dot needham11 at btinternet dot com
Peter Verhaar (p.a.f.verhaar@library.leidenuniv.nl) p dot a dot f dot verhaar at library dot leidenuniv dot nl
Ross Macintyre (ross.macintyre) ross dot macintyre at manchester dot ac dot uk
Sune Karlsson (sune.karlsson) sune dot karlsson at oru dot se
Tobias Schaefer (tobias.schaefer) tobias dot schaefer at sub dot uni-goettingen dot de

Proposal for the creation of KE Usage Statistics Guidelines

The following is from the technical group at the KE Statistics meeting in Berlin.

what would be the measurable goal of the activity

An agreed set of "KE Usage Statistics guidelines ".Emphasize these are guidelines NOT standards! (Profile for using appropriate standards)

(what does 'agree' mean: representative of each project in each country has agreed, by putting the name of the projects on the guidlines under the section "Endorsement" )

what the results/benefits would be

Freely available guidelines

Standardisation of Usage Statistics Exchange, across current and futurre projects. This leads to Confidence , transparency, trust, reliability and interoperability.

who would be using the results, for what purpose ,

[*] = directly involved in this proposal.

Three MAIN groups:

• [*] Developers: for implementing the guidelines
• Repository administrators: providing usage data
• Analysts: work with the usage data
• Other Stakeholders, including:
  • End Users: guide to popularity,
  • Funders: they could demand adoption of these guidelines
  • Publishers
  • Etc.
  • [*] OpenAIRE: can adopt the guidelines, and propagate it to repositories. And to maintain the guidelines.

- what would the work to be done look like

• Communicate to all stakeholders in the world , this is IT! In the beginning, and in the end.
• Put online - hosted by SURF
• Editing activities
• Agreed version 1.0 interoperable guidelines: end of MAY 2010
  • "Agreed" => means: all the parties have the chance to contribute:
  • Endorsement: OpenAIRE (EU), SURFsure (SURF), PIRUS-2 (JISC), OA Statistik (DFG), RePEC ()
• Beta Implementation starting in june
• Reviewing in September.Results in agreed version 2.0 (stable)

what would be required to make it happen

• Writing of the guidelines
• Online environment
• 6days for the work (2d for each project)
• 2days overhead& coordination (Peter)

Little more planning:

• 1rst half of April: initial online document.
• 2nd half of April: online meeting (Agenda)
• 2nd meeting in 2nd half of MAY. After the meeting we have an agreed version 1.0
• Advocacy (conferences, etc.)
• Test Implementations between June and Sept. (at each project, internally, not accross projects, yet)
• Review in Sept. (Face to Face meeting in Sept. In the UK)

Ultimate interoperability test:

• Get one Base URL from each project , and test the interoperability , not setting up a service.!!!
• Resulting in an agreed version 2.0

who are the actors/parties that should take part

• SURFsure (SURF)PIRUS-2 (JISC)OAStatistik (DINI)RePEcNEEOOpenAIRE

in what way could Knowledge Exchange help further this activity

• Putting their stampFacilitate meetings
• Communication to all the stakeholders
• Act as an Organisational umbrella

would it happen without KE

• We wouldn't be here if it wasn't for KE
• Project instigation/inspiration
• We need to have a temporary "home" for this project,

an indication of timeline and resources required

Timelines are there - specific deliverable of each participating project

Resources:

• Resources are already assigned from the originating projects, PIRUS-2, OAStatistik, SURFsure.

Role of OpenAIRE:

• Host the Guidelines and Maintain it.
• need to review the guidelines, and perhaps need some extensions (e.g. FP7 project number)

Role of RePEc & NEEO providing consultancy/review & endorsement

Rol of KE: facilitates face-to-face meetings (What does that mean? Is it to FUND the meeting, so it does not take away project budgets?)

How will we communicate?

• Primarily by e-mail
• Conf. call via "Powwownow", Skype or another virtual meeting technology

Editing the guidelines

1. The wiki is used to generate the firs draftThis is being distributed to all the participants
2. They make their comments (with track changes ON)
3. They send it back to the coordinator
4. The coordinator is incorporating all the changes and is putting a new version online.
5. In the first conference call, we discuss the latest version of the guidelines
6. A final round of changes is made to get all the changes, and then we have version 1.0
7. We date stamp each wiki version (after each round)
8. We can put this proposal in the wiki