Files/OpenAIRE Compliance Plug-in

From EPrints Documentation
Revision as of 10:09, 1 June 2012 by Tmb (talk | contribs)
Jump to: navigation, search

This EPrints extension is designed to help the administrators of repositories that contain outputs from EU FP7 funded projects to achieve compliance with the OpenAIRE Guidelines version 1.1 (http://www.openaire.eu/index.php?option=com_content&view=article&id=207).

In summary, these guidelines state that the outputs from FP7 projects must be made avaiable for harvesting via OAI-PMH using a defined set specification. In addition these outputs should meet certain standards in their metadata as defined in the guidelines document.

What this add-on does and doesn't do

This add-on will

  • Add new metadata fields for EU FP7 specific elements
  • Map the default EPrints data types to their DRIVER equivalents (see http://www.driver-support.eu/documents/DRIVER_Guidelines_v2_Final_2008-11-13.pdf, page 69)
  • Create a new custom set within the OAI-PMH output of the repository called EC_fundedresources and containing all resources that are flagged as being outputs of FP7 projects
  • Add required metadata to the OAI-PMH output
  • Check if any files have an embargo date specified (and are restricted access) and alter the rights field in OAI-PMH output to reflect this

This add-on will not

  • Check whether items flagged as outputs of FP7 projects have a Project ID specified in the correct format before including them in the EC_fundedresources set
  • Check whether items flagged as outputs of FP7 projects have full text available before including them in the EC_fundedresources set
  • Check whether items flagged as outputs of FP7 projects have all required metadata set (e.g. DC.rights)

This is due to the fact that EPrints custom sets can only currently filter on a single metadata value (in this case we're using the flag that states that the resource is form an FP7 funded project).

Installation (EPrints 3.1+)

Download the latest tarball to your local repository directory (eg. /opt/eprints3/archives/ARCHIVEID/)

Extract files:

tar xzvf eprints-openaire.xx.tgz

Update database

Add the new metadata fields to your database:

cd [eprints_root]/bin
./epadmin update_database_structure ARCHIVEID --verbose

Getting started

To activate the OpenAIRE compliance features you will need to make some changes to your repository setup.

In file cfg/cfg.d/eprint_fields_automatic.pl add the following lines:

# Map Eprints type to DRIVER type
 my %type_map = (
 "article" => "info:eu-repo/semantics/article",
 "book_section" => "info:eu-repo/semantics/bookPart",
 "monograph" => "info:eu-repo/semantics/book",
 "conference_item" => "info:eu-repo/semantics/conferenceObject",
 "book" => "info:eu-repo/semantics/book",
 "patent" => "info:eu-repo/semantics/patent"
);

my $mapped_type = (exists $type_map{$type}) ? $type_map{$type} : "info:eu-repo/semantics/other";
$eprint->set_value("fp7_type", $mapped_type)

In file cfg/workflows/eprint/default.xml add the following lines before the closing </workflow> tag:

<stage name="fp7">
 <component type="Field::Multi">
  <title>Details for FP7 project outputs</title>
  <field ref="fp7_project"/>
  <field ref="fp7_project_id"/>
  <field ref="access_rights"/>
 </component>
</stage>

And add the following line to the <flow> element (near the start of the file) to place the new FP7 stage where you feelit will be most appropriate for your workflow:

<stage ref="fp7"/>

e.g.:

<flow>
 <stage ref="type"/>
 <stage ref="files"/>
 <stage ref="core"/>
 <stage ref="subjects"/>
 <stage ref="fp7"/>
</flow>

Restart apache to ensure that all the changes are applied.

ADDENDUM - install notes for EPrints 3.3

-----Original Message-----
From: Timothy Miles-Board
Sent: 01 June 2012 10:53
To: Rob Ingram
Subject: OpenAIRE Compliance Plug-in http://files.eprints.org/649/

Hi Rob,

FYI

I've just installed your plugin on an EPrints 3.3 repository.

The OAI code has changed in 3.3 so it doesn't work out of the box.

$c->{oai}->{v2}->{output_plugins}->{oai_dc} = "OAI_DC_Ext";

The OAI code no longer looks at the output_plugins setting to determine 
which plugin to use for each metadataPrefix. Each individual export 
plugin can now advertise support for a metadataPrefix so given a 
metadataPrefix request, the OAI code just asks the plugin subsystem for 
a plugin that says it supports that metadataPrefix.

So in order to get the OAI_DC_Ext used instead of the default OAI_DC I 
needed to add the following config settings (eg. to z_oai.pl):

# don't use Export::OAI_DC for oai_dc metadataPrefix...
$c->{plugins}->{"Export::OAI_DC"}->{params}->{metadataPrefix} = undef;
# ...use Export::OAI_DC_Ext instead
$c->{plugins}->{"Export::OAI_DC_Ext"}->{params}->{metadataPrefix} =  "oai_dc";

Regards,

Tim

--
Timothy Miles-Board
EPrints Services