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

Output – SNEEP – Demonstration EPrints Repository for testing social networking plugins

Title: Demonstration EPrints Repository for testing the SNEEP social networking plugins

Date Released: November 2007

URI for Output: http://sneep.ulcc.ac.uk/eprints/

Summary of contents: The demo repository has three purposes:

• To provide a default, generic, vanilla Eprints install to test out SNEEP install scripts.
• To demonstrate how the SNEEP components work with EPrints.
• To provide a download for SNEEP plugins.

The repository demonstrates the four SNEEP plugins that add the facility for comments, bookmarks, tags and notes.

Additional information:

Comments: I created SNEEP demo repository account for myself to test the repository and plugins. I successfully added tags, comments and notes to the ‘Aurora Leigh’ test item at http://sneep.ulcc.ac.uk/eprints/3/. The bookmarks feature returned an error. The functionality was straightforward and quick to use.

Project – FAR

Federated Access to Repositories

Project Name: Federated Access to Repositories

Programme Name: Digital Repositories programme

Strand: Interoperability Demonstrators

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/interoperabilitydemos/far.aspx

Project URI:https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/WebHome

Start Date:01/11/2007

End Date:31/07/2008

Governance: Integrated Information Environment Committee (JIIE)

Contact Name and Role: John Paschoud, Project Manager

Brief project description: A workshop at the OAI5 conference in April 2007 identified a need for improved attribute managed federated access to repositories, and produced a set of requirements. The Federated Access to Repositories (FAR);project would take up this list, and use it to: Create recommendations for attributes to describe authorisation to repositories; where appropriate,;these recommendations will be passed to relevant standards groups Develop extensions to the repository software (EPrints and DSpace) so that it can be used with; Shibboleth and meet these requirements (building on earlier work where this exists) ;Test existing work integrating Shibboleth and Fedora and recommend to developers what will be;needed to meet these requirements ;Install demonstration repositories to show how this can work in practice Feed the modifications and full documentation into the appropriate repository software development process to ensure maintenance through future releases of Eprints and Shibboleth Develop procedures to consider ways of extending federated access management to new functionality introduced into the repository software products following the conclusion of the project A demonstrator of the software will be produced as well as a final version.

Name of Trawler: Mahendra Mahey

Output:

Output – SNEEP – Social Networking Plugins for Eprints

Title: SNEEP Eprints repository plugins

Date Released: 29th May 2008

URI for Output: http://sneep.ulcc.ac.uk/eprints/view/subjects/modules.html

Summary of contents: The SNEEP plugins add ‘key’ Web 2.0 features to the EPrints repository software. They were developed in response to recommendations by Franklin and van Harmelen that institutional repositories can be made more accessible for learning and teaching through the use of Web 2.0 technologies.

There are four plugins available to add the facility for comments, bookmarks, tags and notes which are also available as a suite.

Additional information: Requires EPrints 3.x version. A “very manual install” process is required for the beta release. An install script may exist in the future.

Comments: I created SNEEP demo repository account for myself to test the plugins. I successfully added tags, comments and notes to the ‘Aurora Leigh’ test item at http://sneep.ulcc.ac.uk/eprints/3/. The bookmarks feature returned an error. The functionality was straightforward and quick to use.

Benefits: Web 2.0 functionality may increase motivation for deposit. RSS and Atom may help embedding.

Roles: RSS and Atom may increase the availability of info for collation and be used to increase visibility.

Output – RIOJA – Overlay Journal software products

Title: RIOJA Project Software Products

Page: web page with related files

Summary of contents: the page points to downloads for ‘modified software packages to start journals based on existing repositories, and to start new API-enabled ePrints-based repositories.’

The software is a modified version of OJS journal system (2.1.1). Modifications include:
‘ * Quick validated submission of papers using existing repository IDs
* Keyword-based matching system to speed assignment of referees and editors
* Continuous publication, using links to accepted versions of the paper hosted on the repository.
* Removal of parts not needed in an overlay journal (print publication, etc) ‘

The software retains OJS’ OAI functionality. As it stands the software can be used with the Arxiv repository or any modified ePrints installation (a modified version of ePrints 3 is also available for download).

Sample journals based on the software is linked: http://arxivjournal.org/ . Of the journals on this page the first two are linked explicitly to the project – cosmology continous and cosmology issued. Cosmology continous has a current issue (from July 2008) none of the other pages associated with these journals have any content. The other four journals seem to be experimental only either having no content or being labelled for developers and requiring a login.

There are a number of outstanding bugs noted.

Comments:
A model of software development that relies upon releasing modified versions of software both for data provider and overlay journal is probably going to struggle to be sustained and adopted.
From what I can tell RIOJA has demonstrated the concept of an overlay journal in this field well but unless their work makes it into core releases of the software they’re adopting (an issue not discussed here) their work will remain as proof of concept.

The issues encountered in this software development are relevant to any infrastructure project developing or heavily moddifying software.

Date Released: 2008

URI for Output: http://arxivjournal.org/rioja/

Project – ROAD

Project Name: Robot-generated Open Access Data

Programme Name: Repositories and Preservation Programme

Strand: Tools and Innovation

JISC Project URI:http://www.jisc.ac.uk/whatwedo/programmes/reppres/tools/road

Project URI: http://www.inf.aber.ac.uk/projects/road/

Start Date:01 June 2007

End Date: 31 June 2009

Governance: Repositories and preservation advisory group, Integrated Information Environment Committee (JIIE)

Contact Name and Role: Stuart Lewis, Project Manager

Brief project description:

The aim of the two year JISC funded project (start date June 2007) is to investigate the use of current open-source digital repository software to enable the automatic curation of robot-generated experimental data and metadata.

The intention is to demonstrate the feasibility of using current open-source digital repository software for management of data acquired directly from automatic integrated laboratory equipment, specifically the Robot Scientist created at UWA.

It is expected that the project will also contribute to research on the sharing of experimental data as well as providing a case study for similar scientific installations in other institutions and for other scientific domains. The vision for data repositories in Digital Repositories Roadmap: looking forward has an information environment in which raw research data is made available on an open access basis. This vision includes the idea of direct linking between laboratory equipment and a departmental or institutional repository. The link with the Robot Scientist constitutes a sophisticated demonstration of this vision.

Development work and testing will focus on three open source repository systems: DSpace, Fedora and EPrints.

Name of Trawler: Mahendra Mahey

Output:  No outputs are available at present. The plan suggests the following:
Reports
• A report detailing the ability of different repository platforms to ingest and store the requisite data in a suitable fashion
• Quarterly project reports giving updates on the progress of the project.
• Final report detailing the investigations undertaken, the software written, and the evaluation performed.
Software (specific to chosen repository platform)
• A suitable data repository to hold the data from the Robot Scientist
• Software to perform the ingest of large amounts of data into the chosen repository platform
• Suitable interfaces to allow people and machines to easily download the data help within the repository

Output – SOURCE – Screencast and Summary of Bulk Migration Tool

Title: Screencast and Summary of Bulk Migration Tool

Date Released: 31st July 2007

URI for Output: http://www.bbk.ac.uk/lib/life/source/alpha/BulkMigrationTool_AlphaRelease.html and http://www.source.bbk.ac.uk/reports/SummaryToScreencast_BulkMigrationTool_Alpha (PDF document)

Summary of contents: A screencast and summary document that demonstrate the use of the alpha release bulk migration tool to migrate content from one repository (Equella) into two other repositories (two Harvest Road Hive repositories).

Additonal information:

Comments: lack of audio on the screencast limits it’s usefulness.

Output – SOURCE – Screencast for Proof of Concept Demonstrator

Title: Screencast for Proof-of-Concept Demonstrator

Date Released: 6th April 2007

URI for Output: http://www.bbk.ac.uk/lib/life/source/demonstrator/Screecast_ProofOfConceptDemonstrator_SOURCE.html

Summary of contents: Audio and video screencast of the proof of concept SOURCE bulk migration tool. The screencast shows a java swing bulk migration application querying MIT hosted applications of Learning Edge and Intralibrary repositories. The repositories are queried and items found. A learning object is then migrated to a Harvest Road Hive repository using the tool and shown to be deposited.

Additonal information:

Comments:

Project – MetaTools

Project Name: Metatools

Programme Name: Repositories and Preservation Programme

Strand: Tools and Innovation

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/tools/metatools.aspx

Project URI: http://www.ahds.ac.uk/about/projects/metatools/

Start Date: 15 March 2007

End Date: 15 September 2008

Governance: Integrated Information Environment Committee (JIIE), Repositories and preservation advisory group

Contact Name and Role: Dr Malcolm Polfreman – (Project Manager)

Brief project description:

To develop a methodology for evaluating metadata creation tools. To Compare the quality of currently available metadata generation tools. To develop, test and disseminate prototype web services that integrate the best metadata generation tools and functionality.

Name of Trawler: Mahendra Mahey

Outputs
Project Outputs are not available as yet (though project was supposed to finish in September).

According to the project plan the outputs will be:

• Develop a methodology for evaluating metadata generation tools
• Compare the quality of currently available metadata generation tools
• Develop, test and disseminate prototype web services that integrate the best metadata generation tools and functionality.

Project – CURVE

Coventry University repository validation and enhancement

Short Project Name: CURVE

Brief project description:
“CURVE will aim over the course of 18 months to create a substantial body of research and learning outputs from across the institution and elsewhere by building on an established institutional repository. In particular we have the expertise to offer a considerable resource in the dance and product, automotive and transport design areas, as well as at the transition from FE to HE in health boundary.

The Coventry University Repository Virtual Environment is the bridge between the e-learning environment (CUOnline) and the information environment provided by the university’s Lanchester Library… CURVE’s main purpose is to be a major element in the university technology enhanced learning environment. CURVE is based on the Equella repository system developed by The Learning Edge.”

Outputs:

1. Final report http://cuba.coventry.ac.uk/curve/files/2008/10/curve_final_report.doc
2. Report on video accesses http://cuba.coventry.ac.uk/curve/files/2008/08/accesses-to-curve-videos.doc
3. Diagram showing integration with CUOnline http://cuba.coventry.ac.uk/curve/files/2008/08/cuonlinemay07.jpg
4. Draft report on transfering objects into a VLE http://cuba.coventry.ac.uk/curve/files/2008/08/transferring-content-from-a-vle-to-a-repository.doc
5. Mindmap of project http://cuba.coventry.ac.uk/curve/files/2008/08/curvediagram.jpg
6. Purpose and content strategy http://cuba.coventry.ac.uk/curve/files/2008/05/ir-content-policyv1.doc
7. CiPEL Learning Objects report http://cuba.coventry.ac.uk/curve/2007/11/14/cipel-learning-objects/
8. Learning Object Reuse strategy http://cuba.coventry.ac.uk/curve/files/2008/05/ur_reuse_strategy_v021.doc
9. InterProfessional eLearning Objects Presented Diagrammaticallyhttp://cuba.coventry.ac.uk/curve/files/2008/05/ur_ip_elo_diagrams_v02.doc
10. Internal Structure of Learning Objects and Reusability http://cuba.coventry.ac.uk/curve/files/2008/05/ur_internal_structure_of_learning_objects_and_reusability.doc

Programme Name: Repositories and Preservation Programme

Strand: Repositories start-up and enhancement projects

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/repositories_sue/curve.aspx
Project URI: http://cuba.coventry.ac.uk/curve/
Start Date: 2007-03-30

End Date: 2009-08-30

Governance: Repositories and preservation advisory group

Contact Name and Role: Prof David Morris, Lynn Clouder, Dr Caroline Ingram Project Director, Project Manager, Project Manager

Name of Trawler: John