DSpace as a replacement for OJS

[Peter]

Hi,

We are currently working on updating our OJS instance to the newest version. It introduces many changes, but still, due to limitations related mainly to handling languages (and some of our journals publish in more than 10 languages), we struggle with introducing the new version.

We also maintain DSpace, and considering OJS limitations one option is to abandon the latter one altogether in favor of DSpace. These two systems obviously differ in terms of managing the editorial process, but DSpace is very flexible about metadata and their languages, and ver. 7 has also improved in terms of maintaining journals. DSpace lacks tools for exporting metadata to Crossref/DOAJ for example, but these can be entered manually (we don't publish thousands of articles every year). It also lacks submission/review stage functionality similar to what OJS offers, but it could be replaced with emailing/cloud sharing. Priority would be to publish in line with modern standards, which includes exchanging metadata. 

I was wondering, has any member of this group made such a switch from one system to another, and if so, how does it affect their journals in terms of content indexing or conforming to standards required by indexing services? What are advantages/disadvantages apart from obvious limitations of DSpace mentioned above? My experience shows that editors/authors/reviewers are not willing to use all those options for discussions/exchanging files that OJS provides, and ultimately oftentimes we end up using email. DSpace on the other hand focuses on content publishing but is more universal, suitable for journals, books, etc. Having both these systems on board currently, simplifying the infrastructure by moving to only one of them seems appealing too.

Thanks for any thought/suggestions, Peter

[José Carvalho]

Hi Peter,

I know both systems very well and I would not use DSpace for journal management, mainly if you have already a OJS instance. 

First, you should investigate better the problem you identify regarding the limitations about OJS handling many languages. It is actually very versatile regarding this aspect and don't know what is the problem, you may describe better the limitation. 

Then, OJS includes by default a big set of features and plugins to improve the journal integration with other services (DOI, Preservation, DOAJ, ...), and more important, it includes standard workflows to support an editorial activity based on good practices. One example, you can't reproduce on DSpace, is the review process where you first ask if the reviewer is available, if he responds yes, so it can start the review. The review process itself includes some instructions for reviewers, comments for the author and/or editor, can use evaluation forms. Additionally,  when you select a reviewer, it must have that role and you know if it has other active reviews, the area of specialty, ... 

Finally, it allows the editorial team to access each work and understand all the steps that have been done, all the emails that have been sent, ... 

Some journals don't use the workflow of OJS... it's a bad practice, and maybe they need some initial training and support to allow the use of the workflow.

Regarding the indexing requisites, you usually need some pages (which you can't add by default on DSpace) to explicitly show the editorial board, policies, ... Also, some services may request access to check the review process. 

In terms of indexing in search portals, they are very similar, and both have OAI-PMH, so I don't see limitations in this context. 

OJS had a recent change from versions 2.x to version 3.x which is similar to what is happening now with DSpace 6.x to 7.x in the way that the change technically all the system to use more recent technologies.

This is my opinion and others are welcome to share their experiences. 

Regards,

José Carvalho

[Peter]

Hi José,

Thank you for your valuable comments.

The languages issue with the OJS (I am now testing one of the latest versions of the software) is quite serious for us: Some of our journals accept manuscripts in more than 10 languages, which means, above others, that:

1. With the English and Polish OJS UI languages on, I have no way out-of-the-box to present metadata in original language of the work if it is different from the UI;

2. Accepting/publishing in so many languages requires enabling them all in OJS, which results in additional fields (following the above example, more than 10 per field) showing up in different form fields, which is not user friendly approach. And obviously I would like to put metadata in Language A, B, … in a field intended for Language A, B, … so that they are correctly interpreted by independent services (metadata XML often includes descriptor of a language).

Additionally:

3. Some plugins, e.g., Citation Style Language, present metadata in a UI language rather than in original language (not to mention the plugin cannot show up an article number, an article element widely used nowadays and generally not supported by the OJS as far as I'm concerned).

4. I am not able to distinguish publication dates of the original version vs. digitalized one which may affect indexing.

5. Recent versions of the OJS had introduced many changes to the roles system, e.g., journal editors have now access to many technical settings previously (OJS 2) reserved for journal managers; from our perspective this is problematic and hinders managing of the journals.

For us, OJS oftentimes means limitations to our journals, and actually preventing from following the best practices (see above). Editorial workflow doesn't need specialized software to follow best practices. DSpace seems to reduce some of the restrictions mentioned above, allowing for indexing of the content also in line with the modern protocols, with more flexibility against, e.g., the issues reported above related to the metadata languages.

Maybe this discussion will continue and be helpful for others.

Thanks, Peter