Output – RIOJA – Journal Repository APIs

Title: RIOJA Journal-Repository APIs

Page: web page with related files

Summary of contents:
The page contains an introduction to and details about the xml APIs developed by RIOJA.
The APIs cover:
” Repository APIs

  • getRepositoryInfo: Get information about the repository
  • validateAuthor: Author validation
  • getMetadata: Metadata exchange
  • setStatus: Journal status change notification
  • getStatus: Get journal status from repository
  • getTrackbacks: Get repository trackbacks
  • getStatistics: Get repository statistics
  • getCurrentPaperInfo: Get current state of paper

Journal APIs

  • getJournalInfo: Get information about the journal
  • getStatus: Get submission status within the journal
  • submit: Submit to journal from repository “

The final section is of note:

  • Author managed papers are assumed by these APIs.
  • ‘Why not just use OAI?
  1. OAI is designed for metadata harvesting not as an immediate-reponse API to be used interactively. For RIOJA journals need to be able to get metadata dynamically during the submission process; OAI allows “wait” responses which require re-querying at a later time.
  2. RIOJA allows for extraction of information before a paper is public on a repository (e.g. for integrated submission) before it would be available by OAI
  3. RIOJA needs to track paper versions carefully. OAI does not include detailed paper version information.
    There should be a well-defined format for titles and abstracts with text formatting and equations so that they can display the same way on the journal and repository without further editing; OAI is very flexible but very vague.
  4. RIOJA requires several other functions apart from extracting Metadata ‘

This rationale is also laid out in the final report page 9.http://eprints.ucl.ac.uk/12562/1/12562.pdf
This section also details similarities between some of RIOJA’s desired functionality and that subsequently developed in SWORD.

Comments:

As commented on the software – the API’s currently require custom versions – if this functionality doesn’t make it into a core release using/ supporting these API’s is unlikely to be sustainable.

The case to replace an accepted api has to be very strong.

Looking at these reasons OAI-PMH is deemed unsuitable:

  1. no1 – In can see the case for this but given the model of overlay journal that the project has chosen (simlutaneous deposit to repository and for overlay publication). Although I’m not convinced this is the only possible workflow – this reason in itself is probably sufficient to examine alternative apis.
  2. no.2  – this seems to be more to do with repository configuration than OAI-PMH as such. There is no reason that a repository can’t be configured for secure OAI-PMH metadata harvesting. Again a lot is predicated on a particular workflow.
  3. no.3 – this is just plain wrong – versioning information is a question that relates to bibliographic metadata, OAI-PMH is a harvesting protocol. You can put whatever information you want into OAI-PMH. The observation is true for the simple dublin core metadata (oai_dc) that you must include with  a oai-pmh compliant repository – but this does not prevent you adding any other sets of information. It’s like saying you need an alternative to roads because your car needs lpg not petrol. It is certainly true that the information you get from most existing repositories (via OAI-PMH) does not support the needs of the an overlay journal but this, in itself, is not a reason to replace OAI-PMH.
  4. no4 – impossible to comment.

I’m not suggesting that there isn’t a need to use something other than OAI-PMH for an overlay journal, but, aside from the first point (which could be significant enough in itself, but is predicated on a particular workflow) the summary arguments for implementing an entirely new api interface are are weak. In the Final Report possible overlap with SWORD (which developed independently while the project was running) is noted. It doesn’t examine SRW/SRU interfaces.

I’d suggest this is a good example of an infrastructure encountering the limits of accepted protocols but also of a development setting itself up for long term problems by effectively requiring 3rd party support for custom api’s [though, please note: this is not a comment on the effectiveness of these APIs for their purpose as a pilot/ proof of concept service]

Date Released: 2008

URI for Output: http://cosmologist.info/xml/APIs.html

Advertisements
%d bloggers like this: