Page History
...
OAI 2.0 is a Java implementation of an OAI-PMH data provider interface (originally developed by Lyncode) that uses XOAI, an OAI-PMH Java Library.
Why OAI 2.0?
Projects like OpenAIRE, Driver have have specific metadata requirements (to the published content through the OAI-PMH interface). As the OAI-PMH protocol doesn't establish any frame to these specifics, OAI 2.0 can, in a simple way, have more than one instance of an OAI interface (feature provided by the XOAI core library) so one could define an interface for each project. That is the main purpose, although, OAI 2.0 allows much more than that.
...
To implement an OAI interface from the XOAI core library, one just need to implement the datasource interface.
OAI 2.0
OAI 2.0 is a separate webapp which is a complete substitute for the old "oai" deployed as a part of the DSpace server (backend) webapp. OAI 2.0 has a configurable data source, by default it will not query the DSpace SQL database at the time of the OAI-PMH request. Instead, it keeps the required metadata in its Solr index (currently in a separate "oai" Solr core) and serves it from there. It's also possible to set OAI 2.0 to only use the database for querying purposes if necessary, but this decreases performance significantly. Furthermore, it caches the requests, so doing the same query repeatedly is very fast. In addition to that it also compiles DSpace items to make uncached responses much faster.
Details about OAI 2.0 internals can be found here.
| Info |
|---|
As of DSpace 6, the The OAI 2.0 Server only uses Solr for its indexing. The previous capability to use Database indexing has been removed. |
...
Configuration
Basic Configuration
Configuration File: |
|
|---|---|
| Property: |
storage| oai.enabled |
Example Value: |
storage = solr
|
| Information Note: |
This allows to choose the OAI data source between solr and database
Property:
| Allows you to enable or disable the OAI module/endpoint | |
| Property: | oai.path |
Example Value: |
|
| Information Note: | Allows you to specify the path where the OAI module will be deployed. This path is relative to the dspace.server.url. So, for example, if "dspace.server.url=http://localhost:8080/server", then by default the OAI module is available at http://localhost:8080/server/oai/ |
Property: |
|
Example Value: |
|
Information Note: | This allows to choose the OAI data source between solr and database. ONLY "solr" is supported at this time. |
Property: |
|
Example Value: |
|
| |
Informational Note: | Solr Server location |
Property: |
|
Example Value: |
|
Informational Note: | OAI persistent identifier prefix. Format - oai:PREFIX:HANDLE |
Property: |
|
Example Value: |
|
Informational Note: | Configuration directory, used by XOAI (core library |
). Contains xoai.xml, metadata format XSLTs and transformer XSLTs. | |
Property: |
|
Example Value: |
|
Informational Note: | Whether to enable the OAI cache. Default is true (for better performance). |
Property: |
|
Example Value: |
|
Informational Note: | Directory to store runtime generated files (for caching purposes). |
Advanced Configuration
OAI 2.0 allows you to configure following advanced options:
...
| Code Block |
|---|
<Format id="[IDENTIFIER]"> <Prefix>[PREFIX]</Prefix> <XSLT>metadataFormats/[XSLT]</XSLT> <Namespace>[NAMESPACE]</Namespace> <SchemaLocation>[SCHEMA_LOCATION]</SchemaLocation> </Format> |
where:
Parameter | Description |
|---|---|
IDENTIFIER | The identifier used within context configurations to reference this specific format, must be unique within all Metadata Formats available. |
PREFIX | The prefix used in OAI interface (metadataPrefix=PREFIX). |
XSLT | The name of the XSLT file within [dspace]/config/crosswalks/oai/metadataFormats directory |
NAMESPACE | XML Default Namespace of the created Schema |
SCHEMA_LOCATION | URI Location of the XSD of the created Schema |
NOTE: Changes in [dspace]/config/crosswalks/oai/xoai.xml requires reloading/restarting the servlet container.
...
If you need to add/remove metadata fields, you're changing the output format. Therefore it is recommended to create a new metadata format as a copy of the one you want to modify. This way the old format will remain available along with the new one and any upgrades to the original format during DSpace upgrades will not overwrite your customizations. If you need the format to have the same name as the original format (e.g. the default oai_dc format), you can create a new context in xoai.xsl containing your modified format with the original name, which will be available as /oai/context-name.
...
However, in order to be exposed DSpace items must be compliant with Driver/OpenAIRE guide-lines.
Driver Compliance
DRIVER Guidelines for Repository Managers and Administrators on how to expose digital scientific resources using OAI-PMH and Dublin Core Metadata, creating interoperability by homogenizing the repository output. The OAI-PMH driver set is based on DRIVER Guidelines 2.0.
This set is used to expose items of the repository that are available for open access. It’s not necessary for all the items of the repository to be available for open access.
...
As DRIVER guidelines use Dublin Core, all the needed items are already registered in DSpace. You just need to configure the deposit process.
OpenAIRE compliance
| Info |
|---|
For OpenAIRE v4 compliance, see OpenAIRE4 Guidelines Compliancy |
The OpenAIRE The OpenAIRE Guidelines 2.0 provide 0 provide the OpenAIRE compatibility to repositories and aggregators. By 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. For developers of repository platforms, the Guidelines provide guidance to add supportive functionalities for authors of EC-funded research in future versions.
...
There is a very useful validator for OAI interfaces available at http://validator.oaipmh.com, we urge you to use this validator to confirm your OAI interface is in fact usable.
Frequently asked questions and issues
TODO fill out based on notes from the March DCAT call: DCAT Meeting March 2016
Overview
Content Tools