OpenAIRE: Making your repository OpenAIRE compliant: Guidelines and notes


Published on

Tutorials/short videos about making your repository OpenAIRE compliant. (Jan. 2012 - January is OpenAIRE compliance month.)

Published in: Technology, Health & Medicine
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OpenAIRE: Making your repository OpenAIRE compliant: Guidelines and notes

  1. 1. To Make your repository OpenAIRE compliant you need to implement the OpenAIRE Guidelines. 1
  2. 2. 1. OpenAIRE supports the Commission’s open access policy by developing an infrastructure for repository networks and a European helpdesk system to support researchers in depositing their research publications. 2. To make possible this infrastructure, OpenAIRE developed simple metadata specifications for repositories – The OpenAIRE guidelines. 3. The purpose of OpenAIRE Guidelines is to make FP7/ERC publications visible. To achieve this and allow central harvesting of FP7/ERC publications, repositories must comply with some minimum technical requirements, and after complying to the OpenAIRE guidelines, the repositories will become the single entry point for researchers that need to deposit publications. 2
  3. 3. 1. The OpenAIRE Guidelines provides orientation for repository managers to define and implement their local data management policies in compliance with the Open Access demands of the European Commission. 2. Furthermore they will comply with the technical requirements of the OpenAIRE infrastructure that is being established to support and monitor the implementation of the FP7 OA pilot. 3. By implementing these Guidelines repository managers are facilitating the authors who deposit their publications in the repository, in complying with the EC Open Access requirements. 3
  4. 4. 1. The OpenAIRE guidelines were presented in July 2010 and the current version (1.1) was published in November 2010. 2. The OpenAIRE guidelines are supplementary and built on top of the DRIVER Guidelines. For OpenAIRE compliance purposes, all the aspects of the DRIVER Guidelines are valid, with the some exceptions that you can find it in the document. 4
  5. 5. 1. The OAI-PMH protocol states that the Repositories may organize items into sets. Set is a standard component of the OAI-PMH and are used to filter specific parts of a repository. This slide shows the preferred setName and setSpec that can be used to create the OpenAIRE set. 2. For harvesting of records relevant to OpenAIRE, the use of a specific set (OpenAIRE Set) at the local repository is mandatory. 3. EC_fundedresources is the OpenAIRE set. The specific content of the 'ec_fundedresources' set is to be determined at the local repository, but All the resources that will be harvested must be outcomes from research projects funded by the EC, and are peer-reviewed. 5
  6. 6. 1. The use of oai_dc is based on the usage by DRIVER, as expressed in the DRIVER Guidelines 2.0. 2. In three cases the use of the DC elements is specific to OpenAIRE, opposed to a more general use in DRIVER. 3. These elements are: projectID, access_rights and embargoEndDate. 4. projectID, access_rights are mandatoty elements, and embargoEndDate is recommended. 6
  7. 7. 1. projectID is needed to connect project information to the publication in the OpenAIRE information space. It equals to the Grant Agreement number as found in all documentation/correspondence between the EC and the researcher/coordinator. The projectID equals the Grant Agreement number, and is defined by the namespace info:eu-repo/grantAgreement/EC/FP7. 2. The namespace defines the grant agreement number from the funder (EC) and funder program (FP7). 3. The project information itself (project period, acronym, funding area etc.) will be ingested into the OpenAIRE information space by other means. 7
  8. 8. 1. accessRights will define the type of access to the publication. 8
  9. 9. 1. When the value of accessRights is “embargoedAccess” embargoEndDate will define the date of the embargo period. 2. This is a Recommended element when accessRights = info:eu- repo/semantics/embargoedAccess 9
  10. 10. Visit 10