ESciDoc OAI PMH Provider And DC Transformation

Implementation

• see https://www.escidoc.org/JSPWiki/en/OaiPmh
• https://www.escidoc.org/JSPWiki/en/InfrastructureOaiPmhConfiguration
• official protocol specification see http://www.openarchives.org/OAI/openarchivesprotocol.html
• OAI-DC transformation works on mandatory metadata record, XSLT configurable for the content-model

Requirement

• the persistent identifier of the resource shall be included in the metadata record served with OAI-PMH

Background information

• Persistent identifier of a resource assigned in the eSciDoc repository can not be included in the native escidoc metadata record due to the following reasons:
  • there is no clear separation of control who may modify/change the PID of the resource and at what point of time
  • even if we provide an e.g. application URL to always deal with latest versions of the resource the problem above will persist

Issues

• OAI-DC transformation can not include the PID of the resource/resource version in dc:identifier as it only works for metadata record
• in general related not only to the OAI-DC transformation, but as well to the metadata offered with the record (in any metadata profile)
• according OAI-PMH specification:

"Note that the identifier described here is not that of a resource. The nature of a resource identifier is outside the scope of the OAI-PMH. To facilitate access to the resource associated with harvested metadata, repositories should use an element in metadata records to establish a linkage between the record (and the identifier of its item) and the identifier (URL, URN, DOI, etc.) of the associated resource. The mandatory Dublin Core format provides the identifier element that should be used for this purpose."

Discussion

• These would mean that the OAI-PMH recommends to have URI/URL or other PID of the resource as part of the metadata
• that is against escidoc concept as escidoc resources may have various metadata records therefore, PID of the resource (being URI or URL or Handle or any string) is stored within the resource properties

• whatever metadata profiles are offered via OAI-PMH these should be transformed before written to the eSciDoc OAI-PMH cache (?)

• currently, it is possible to relate the XSLT to DC transformation in the content model for one metadata record - this works for one single mandatory metadata record

• escidoc has a concept of minimum one mandatory metadata record
  • can there be several mandatory metadata records?
  • XSLT reference in the ContentModel shall be allowed for any metadata record that is associated with the resource
  • XSLT transformation should be done at the time of writing the resource to the OAI-PMH cache
  • XSLT transformation shall work not only for the OAI-PMH transformation i.e. envisioned OAI-ORE service may make use of it as well ?)
  • what about allowing several transformations in the Content-model related to the service for which these transformations are actually useful (e.g. element content-model:resources) ?
    • Example: Resource R1 has MDRec1 and MDRec2
      • repository user decides to offer OAI-PMH for both MDRec1, MDRec2 and additionally OAI-DC
      • repository user decides to register the following "service-specific-transformations": Item ->OAI_MDREC1, Item->OAI_MDREC2, Item->OAI-DC
      • in other case repository user may decide to register only 1 "service-specific-transformaton" : Item->OAI-DC where he merges information he needs from both records into single OAI-DC record in custom manner and is able to provide the PID of the item as DC identifier

Open Archives Initiative Dublin Core

Extensible Stylesheet Language Transformations

Open Archives Initiative Protocol for Metadata Harvesting

Enhanced Scientific Documentation

Persistent Identifer or Identification

Uniform Resource Locator

Uniform Resource Name

Digital Object Identifier

Uniform Resource Identifier

Dublin Core

Open Archives Initiative Object Reuse and Exchange

Open Archives Initiative