SWORD Setup for Deposits from OPS to OJS

talknshare · January 26, 2021, 11:26pm

OJS 3.2.0.3 and OPS 3.2.1.2

I have the sword server plugin installed in the OJS, and sword plugin in multiple OPS installations. I need help with creating a deposit point via the sword server plugin in the OJS installation, so that the articles in the OPS can be deposited by the OPS managers.

I am not able to figure out where to find the information needed in the OPS server plugin to create the deposit point, such as: Name, Deposit point URL, Username, Password, and API Key. I have browsed the SWORD Course page, but couldn’t find any specific information regarding how to use the OJS Sword Server plugin to generate the information previously stated to create a deposit point. Please help!

asmecher · January 27, 2021, 5:24pm

Hi @talknshare,

What version of each of the plugins are you using?

Can you describe your workflow a little more? Are the Managers generally going to be depositing in the same journal, or is there a variety of places the preprints might go? Will the managers be manually depositing them in the journal, or would the deposit ideally be triggered by some workflow step?

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · January 27, 2021, 6:23pm

Hi @asmecher,

In the OJS (3.2.0.3), I have the swordserver gateway plugin (0.0.0.1) installed. In the OPS (3.2.1.2), I have the sword generic plugin (1.0.4.1) installed.

I would like our affiliated associations who are using the OPS to organize and prepare their preprints, be able to selectively deposit articles via SWORD protocol to our OJS journal as new submissions for review. This way, we would be able to eliminate the step where the individual authors would have to create new accounts and submit their manuscripts. Most importantly, we want only the OPS managers to be able to manually select the articles to deposit in our journal.

I hope that I’ve provided enough information here. And I’m probably making this sound more complicated than it is, but still haven’t figured out how to create a deposit point using the sword server plugin. Thank you for responding so quickly, and I appreciate your help.

talknshare · February 9, 2021, 7:13pm

Hi @asmecher,

I wanted to know if this functionality is something that the overall OPS community would benefit from if the OPS to OJS transfer is implemented. I have recently noticed that the preprint archives such as bioRxiv and MedRxiv have the ability to transfer the manuscript/metadata to various partner journals. I found this snippet in the FAQ section of medRxiv, “medRxiv can save authors time in submitting papers to journals by transmitting their manuscript files and metadata directly from medRxiv. This means authors do not have to spend time re-loading manuscript files and re-entering author information at the journal.” (Advancing the sharing of research results for the health sciences).
It will be incredible if the OPS can also allow direct transfers to OJS journals.

Best,
@talknshare

asmecher · February 9, 2021, 7:20pm

Hi @talknshare,

That’s definitely our goal with the SWORD server and client plugins for OJS and OPS – but I need to revisit them to make sure they’re shipshape. Please watch for an update here in the next couple of weeks. I’m happy that you’re interested in using this in practice, as it’ll give me real-world feedback while checking out the functionality; often we have to guess at user needs.

One of the biggest challenges will be helping authors understand how to tell the OPS install where to find the OJS install (i.e. authors will currently need to know what the SWORD URL is). If you have suggestions on an author-friendly workflow for this, please describe it here.

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · February 10, 2021, 8:14pm

Hi @asmecher,

I’ll be waiting to read the update! We will be more than happy to share our experience and feedback regarding the implementation of the functionality, and if it bodes well with multiple installations and our workflow. I cannot divulge too much about us in a public forum, but I will be glad to talk privately with the team if you need any specifics.

One of the main questions that we get asked repeatedly (and intuitively?!) by our affiliates, who are trying out the OPS installations, is if they now are able to directly submit the preprints papers to our OJS journal. This in itself makes the case to have the SWORD available for OPS; and therefore, creating a direct pipeline for the OJS journals, allowing them to proliferate and promote open-access publishing.

As for the deposit points, the preprint server managers must be able to communicate directly with the journal administrators, coordinate that information and manually enter it in the OPS.

But I think the most efficient way to organize the deposit points & URL information, is if PKP can create a database or a consortium where the OJS journals can automatically register their deposit points & other information from the sword server plugin itself. Then the administrator of the OPS installation with the sword client plugin can select which OJS journals in the PKP sword database are visible as an option for the authors or the managers to send the preprints. This workflow will allow OPS to offer the authors/managers a wide catalog of OJS and other compatible journals, and the journals will be able to advertise themselves as well.

Another issue I wanted to convey is since our journal uses different sections, categories, and metadata options, will it be required to synchronize these options between OPS & OJS for a smooth transfer?

To share my vision regarding the author-friendly workflow, in our case, the managers of affiliate OPS installations will educate the preprint authors that the option to transfer their article to the OJS directly from their OPS dashboard exists. I have drawn an example author dashboard (picture below) with the submission tab for “Submit to a Journal” in the sidebar. I think it is quite self-explanatory and simple to use. I would add, that if the author wants to request a journal to be available, there is a link to “Request a Journal” where the authors can fill a form out for the OPS administrator.

Sword deposit for authors

Another issue is to not let the authors submit the same preprint to more than one journal. So if they had already submitted a preprint to one journal on the list, that preprint should be grayed out for the authors. But allow the preprint server managers to reset that preprint and be able to submit it to another journal on the list of journals.

I hope my comments are helpful, and I am very excited about the OPS-OJS sword integration in the near future! Please reach out anytime.

Best,
@talknshare

asmecher · February 23, 2021, 2:01am

Hi @talknshare,

FYI, I’ve just dusted off the two SWORD plugins (GitHub - pkp/swordServer: OJS Plugin Providing SWORD Endpoints and GitHub - pkp/sword: Allow Journal Managers and (optionally) Authors to deposit articles via the SWORD protocol) and gotten them basically working with OJS and OPS 3.3.0. Are you interested in working with that level of the code, or are you committed to 3.2.x?

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · February 26, 2021, 2:51am

Hi @asmecher,

We would love to work on the sword implementation given that it’s our top priority, but we are committed to 3.2.x OJS/OPS installations at the moment. For the past couple of months, we have been corralling all of our affiliated organizations into adopting the OPS 3.2.x preprint servers, giving their staff a virtual (screen-shared) orientation to our OPS installations, and more are lining up quickly. It will be really hard for us to upgrade the installations from 3.2 to 3.3 in the middle of all this.

We still get a lot of questions regarding the OPS’s ability to “automatically transfer” the preprints to our journals. So I can 100% vouch that this is the right direction for the OPS to grow. I tested the OPS 3.3.0.3 and it is definitely not production-ready; there are a lot of unexpected errors and the code is incomplete in certain places.

A critique I received from the affiliates was that there is no “Submission” stage under the Workflow tab of submission, just the Production stage. The authors being able to submit a galley before moderation is logically flawed. They suggested having a submission file secured and not be replaced by a galley file. Also, each version of the revised file should be individually visible and accessible for review by the managers.

Another issue is of the “Chain of Custody” if that makes sense in the context of the moderators working with the authors. The communications (back and forth) between the managers, moderators, and authors must be a permanent record and disabled to be erased on a later date. This originates from the concerns that if the moderators are a hired help (Ph.D. students or professors), and if there is an unfortunate incident in the future, the OPS managers must be able to have all the comms in the legal sense.

I will keep you updated with more meaningful information regarding the OPS/OJS integration as we try to get all of it ready by the end of this month! Please keep me updated with the development of the sword. We are desperately waiting!

Best,
@talknshare

asmecher · February 26, 2021, 10:15pm

Hi @talknshare,

Could you provide a bit more information about where the upgrade to 3.3.0 didn’t work? Error messages, etc? We’re preparing another batch of builds and would like to include anything relevant, but we haven’t seen anything majorly wrong with that line of releases thus far in our own testing.

As for SWORD support, I’ve just built a round of preliminary releases of the SWORD and SWORD Server plugins for 3.2.x and 3.3.x…

For 3.2.x:

Sword server plugin for OJS: https://github.com/pkp/swordServer/releases/download/v1_0_1-0/swordServer-v1_0_1-0.tar.gz
Sword client plugin for OJS and OMP: https://github.com/pkp/sword/releases/download/v1_0_5-0/sword-v1_0_5-0.tar.gz

For 3.3.x:

SWORD server plugin for OJS: https://github.com/pkp/swordServer/releases/download/v1_1_0-0/swordServer-v1_1_0-0.tar.gz
SWORD client plugin for OJS and OMP: https://github.com/pkp/sword/releases/download/v1_0_6-0/sword-v1_0_6-0.tar.gz

These are somewhat experimental so I haven’t put them in the Plugin Gallery yet; to install them you’ll need to upload the right version into your “Install a New Plugin” tool (when you’re logged in as an administrator). (If you’d like to install these using git/github for ease of updating, I can write a few quick instructions for that.)

You should fairly quickly be able to get these going with your OJS and OMP installations, but I think you’ll quickly find that there are some areas for improvement in guiding authors along – your contributions back to the plugins are very welcome, and I’ll be happy to work with you on this to some extent!

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · March 4, 2021, 2:11am

Hi @asmecher,

I was able to download and install the Sword server plugin in OJS 3.2.x, and Sword client plugin in OPS 3.2.x. Now we are back to my first post of the thread: how do I actually get these plugins running? are there any instructions on how to create a deposit point, etc?

Thanks,
@talknshare

asmecher · March 4, 2021, 3:12am

Hi @talknshare,

I’d start with a “manager only” deposit point – it’s easiest to experiment with.

On the target system (OJS)…

Make sure you have an api_key_secret configured in config.inc.php. Make up anything you like, but make sure it’s “long enough” (I forget the exact bit length that’s required for the JWT tool we use, but mash the keyboard).
In some account’s user profile, generate an API key. This is the account that will receive the submissions.

On the source system (OPS)…

Create a new deposit point and give it the API key you generated before.
For the deposit point URL, use e.g.: http://url-to-ojs-here/index.php/journal-path-here/gateway/plugin/swordServer/servicedocument
Because you’re using an API key, keep the username and password blank.
You can deposit content using the access point from the import/export area.

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · March 5, 2021, 9:27pm

Hi @asmecher,

I followed your instructions to a tee, but still encountered the “Service Document Unreachable” error when I tried to deposit a published submission.

sd unreachable

sword deposit failed

I made the api_key_secret to be over 600 characters long. I kept the username and password fields blank. And as you can see in the screenshots, I encountered this error in the import/export area. Please let me know what could be causing the service document URL to be unreachable. I really appreciate your help!

Best,
@talknshare

asmecher · March 5, 2021, 9:36pm

Hi @talknshare,

What do you get when you visit the service document URL with the browser?

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · March 5, 2021, 9:40pm

It says, “You are not authorized to make this request”.

asmecher · March 5, 2021, 10:03pm

Hi @talknshare,

Good, that’s the right URL and the server plugin appears to be working. Do you see anything in your PHP error log when you try the client plugin?

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · March 5, 2021, 10:38pm

Hi @asmecher,

PHP error log for the OPS has the following lines repeating several times when I edit or create a deposit point in the “Sword Settings” tab:

PHP Warning: Declaration of SwordSettingsForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in OPS_URL/plugins/generic/sword/SwordSettingsForm.inc.php on line 57

PHP Warning: Declaration of SwordSettingsForm::execute() should be compatible with Form::execute(…$functionArgs) in OPS_URL/plugins/generic/sword/SwordSettingsForm.inc.php on line 66

PHP Warning: Declaration of SwordDepositPointForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in OPS_URL/plugins/generic/sword/controllers/grid/form/SwordDepositPointForm.inc.php on line 93

PHP Warning: Declaration of SwordDepositPointForm::readInputData($request) should be compatible with Form::readInputData() in OPS_URL/plugins/generic/sword/controllers/grid/form/SwordDepositPointForm.inc.php on line 77

PHP Warning: Declaration of SwordDepositPointForm::execute() should be compatible with Form::execute(…$functionArgs) in OPS_URL/plugins/generic/sword/controllers/grid/form/SwordDepositPointForm.inc.php on line 107

PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; SWORDAPPClient has a deprecated constructor in OPS_URL/plugins/generic/sword/libs/swordappv2/swordappclient.php on line 12

PHP Deprecated: Array and string offset access syntax with curly braces is deprecated in OPS_URL/plugins/generic/sword/libs/swordappv2/utils.php on line 60

Best,
@talknshare

talknshare · March 6, 2021, 10:15pm

Hi @asmecher,

I noticed something very unusual with the APIs in the OJS 3.2.0.3 installation. All users of the journal have the same API, and when I tried to generate a new API key for a user, it doesn’t. If you know what’s up with that, please let me know. It could very well be the reason why the OPS sword client is unable to connect to the OJS server.

Thanks,
@talknshare

asmecher · March 8, 2021, 7:08pm

Hi @talknshare,

The JWT tool we use generates “blank” API keys when the api_key_secret isn’t set; maybe something about your config file is not allowing it to be read properly? Try something simple and shorter than 600 characters to see if that causes API key generation to behave better.

Regards,
Alec Smecher
Public Knowledge Project Team

talknshare · March 8, 2021, 9:05pm

Hi @asmecher,

I changed the API key secret to 44 characters in the config file and generated a new key. But now all users have this same new API key. And now it won’t generate another new key.

; The unique secret used for encoding and decoding API keys
api_key_secret = “slaIEUI4EpDo1xzemLsAZVuE4eY7og4scDViZkN4d9p”

When I insert the address below in the browser: http://OJS_website.com/index.php/journalpath/api/v1/issues?apiToken=copypasted_from_profile

It gives me this error message:
{“error”:“user.authorization.accessDenied”,“errorMessage”:"##user.authorization.accessDenied##"}

Is there anything in the config file that could potentially affect the JWT tool? Should I be looking someplace else to check if the JWT tool is working properly?

Thanks,
@talknshare

asmecher · March 8, 2021, 9:18pm

Hi @talknshare,

Hmm, I’m not sure why the JWT library is unhappy, but I’d suggest checking here:

github.com

pkp/pkp-lib/blob/stable-3_2_1/classes/user/form/APIProfileForm.inc.php#L66


		$secret = Config::getVar('security', 'api_key_secret', '');
		if ($secret === '') {
			$notificationManager = new NotificationManager();
			$notificationManager->createTrivialNotification(
				$user->getId(), NOTIFICATION_TYPE_WARNING, array(
					'contents' => __('user.apiKey.secretRequired'),
			));
		} elseif ($user->getData('apiKey')) {
			$templateMgr = TemplateManager::getManager($request);
			$templateMgr->assign(array(
				'apiKey' => JWT::encode($user->getData('apiKey'), $secret, 'HS256'),
			));
		}
		return parent::fetch($request, $template, $display);
	}

	/**
	 * @copydoc Form::execute()
	 */
	function execute(...$functionArgs) {
		$request = Application::get()->getRequest();

(This is where, in the lib/pkp submodule, the API key gets generated when you save the profile form.)

You could try experimenting with this outside of the OJS environment – JWT is the third-party \Firebase\JWT\JWT library.

The user profile’s apiKey property is generated here, when the form is instructed to generate a new one:

github.com

pkp/pkp-lib/blob/stable-3_2_1/classes/user/form/APIProfileForm.inc.php#L91



		// remove api key if exists
		if (!$apiKeyEnabled) {
			$user->setData('apiKeyEnabled', null);
		}

		// generate api key
		if ($apiKeyEnabled && !is_null($this->getData('generateApiKey'))) {
			$secret = Config::getVar('security', 'api_key_secret', '');
			if ($secret) {
				$user->setData('apiKey', sha1(time()));
			}
		}

		parent::execute(...$functionArgs);
	}
}

This is the user-specific secret that is used to generate the JWT; varying any detail of either this property, or the api_key_secret in config.inc.php, should result in a different API key being displayed on the form.

Regards,
Alec Smecher
Public Knowledge Project Team