Competing Interests plugin for OJS3

Community Showcase
1

Hi all,

I am pleased to announce that at Ubiquity Press we have released an open source plugin to add a competing interest statement to the submission.

Competing interests plugin for submission form/journal section admin (ubiquitypress / ojs-plugin-competing-interests · GitLab).

Gathering competing interests from authors on submission is best practice (it is one of the Committee on Publication Ethics’ core practices), particularly in medical journals (see WAME guidelines) - this can be done as a section in the text file, but it is easier to ensure it is present if it is a required submission field - it also highlights any competing interests to the editors, and opens up options for exporting alongside other article metadata (e.g. to indexes).

This plugin has three parts:

  • adding a text box to the submission form, in section ‘3. Enter Metadata’, allowing for a Competing Interests statement about the submission to be added.
  • adding a check-box to the journal section admin page, allowing for the Competing Interests text field to be made optional or mandatory, on a section-by-section basis. By default it is set to mandatory.
  • adding a text field to the submission metadata editing form, in the admin dashboard. When editing the metadata of a completed submission, in the ‘publication’ tab, a text field displaying the Competing Interest text and allowing for editing, is present.

This brings the functionality of the Competing Interests statement to a very similar level to the article Abstract, with the ‘Do not require Abstracts’ check-box, etc.

We are always happy to accept suggestions / bugfixes / improvement / translations!

Thanks

1 Like
2

Hi @FrancescoDeVirgilio,

Excellent work!

Just reviewing the codebase, it looks like OJS 2.x had support for a “competing interests” field that could be entered for each author of a submission. That data, where already entered, is still preserved in OJS 3.x after the upgrade process – but there is no longer a field for its entry, and it is no longer displayed. How do you feel about keeping this with the author, per previous releases, instead of making it per-submission? Did you work with the OJS 2.x competing interests field?

Regards,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher,
thanks for your suggestion. Since we are introducing this functionality straight in OJS3 (not migrating it from the previous implementation for OJS2) we never really thought about this.

Let me have a chat with @UP_PFord and @sm2020 and I will get back to you on how feasible this is.

Thanks!

1 Like
5

Hi @asmecher,
We’ve had a discussion about whether the CI statement in our plugin should be author-level or submission-level, and we think that for our use-case it’s best to keep them at submission-level. We definitely do recognise that there is utility in author-level CI statements however, it’s just that this plugin may only end up serving a subset of users, which is fine. Our reasons for submission-level CI statements are:

  • Both authors and editors have expressed to us in large numbers that more concise submission forms are preferable. Entering/repeating CI statements for large author lists can be a real time-drain, and managing them after submission equally so.
  • A single CI statement can be rendered onto an article page in a more readable way than multiple ones. For us, we consider the information too important to get accidentally buried in multiple sections. In practise we find that often the majority of authors will not have anything to declare, but one or two might, and this situation is more concisely expressed in a single piece of text, instead of, say, eight individual statements with seven declaring nothing and one having an important declaration to make.
  • To our knowledge, single submission-level CI statements tend to be more commonplace, and we export metadata to indexes such as crossref, where the systems are set up to accept submission-level statements more readily. Both in the exporting of metadata from OJS (often in externally defined formats) and the importing to indexes, we expect a submission-level CI statement to fit this much more easily than author-level ones, which we suspect will be less supported.

We do understand, however, that in general it is preferable to keep things in line with previous releases, rather than take a slightly different direction. We are happy to continue this discussion, if there is any interest.

With best regards,
Peter Ford (PM, Ubiquity Press)

6

Hi @UP_PFord,

We generally try to align our data model choices with JATS as a well-considered standard; have you seen Conflict-of-interest (COI) statements - JATS4R? It leans towards associating COI statements with authors (even though it does permit less specific mappings than 1:1). This makes sense to me at a logical level – a statement at the submission level does not have a clear “actor”, while a statement at the author level does.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi @asmecher,

This is new information to me, thanks for providing this! It’s encouraging to hear that our concerns about exporting to crossref can likely be put to rest.

However, I don’t know that this changes our use-case for the single CI statements, namely the ability to clearly render multiple statements into a readable entity on the article landing page, and expedient handling of information in the submission forms and submission admin pages. It’s very common for us to have over author lists numbering 10 or more, even 20-40 in some cases.

We already serve our customers with this, and we have heard frequently that this is a positive feature for them, over other, more cumbersome, systems they’ve used elsewhere. I can’t deny there’s a lot of utility in CI statements concretely linked to individual contributors, but for us the main goal is to have a clear, readable declaration, whose accuracy hasn’t suffered from editor fatigue(!). We can’t see a way to make this happen with author-level CI statements at the moment. Do you have any ideas?

Thanks for your help on this,
Peter Ford (PM, Ubiquity Press)

8

Hello @UP_PFord,

Thank you for this plugin.

We are using a multi-lingual website , but one text in English language is enough for this section. So, I changed multilingual=false in the tpl file. Now the data will not save in the database.

How can I save and display in English only?

Best,
Ali

9

Hi @alirezaaa,

I have queried our technical team about your situation. They informed me that in addition to the change in the tpl file, it is also necessary to change the following variables in CompetingInterests.inc.php:

$schema->properties->competingInterests->multilingual = false;

and

'isMultilingual' => false,

These changes, in addition to the .tpl one, should result in success. If this does not work, please don’t hesitate to get back in touch.

Thanks,
Pete (PM, Ubiquity Press)

10

Hi @UP_PFord,

Thank you for your response. I edited the code as you suggested, but is not working. I checked the database and the new values are not saved in DB.

I think the below code in metadataExecute function in CompetingInterestsPlugin.inc.php should also be changed. but I could not figure it out.

foreach ($competingInterests as $locale => $value) {
            $competingInterestsDao->replaceCompetingInterests($pubId, $locale, $value);
        }

I changed the code to:

$competingInterestsDao->replaceCompetingInterests($pubId, "en_US", $competingInterests);

This time the data is saved in database but is not shown and updated correctly.

Could you help us on this issue please?

Best,
Ali

11

Hi @UP_PFord,

Sorry, haven’t seen this post earlier but if it makes any difference, to make this more readable, there may be 2 settings - the first one that contains a boolean whether there are conflicts of interests to declare and the other one that contains a text of the statement if the first one is true. I think that that may be enough for most cases. In this scenario only those authors, who have a conflict of interest may be explicitly mentioned, for others, a common statement may be used (that author should agree on).

Also, I want to mention that it’s not a rare case when an electronic medical journal explicitly publishes a declaration/statement of each author, e.g.: https://www.cochranelibrary.com/cdsr/doi/10.1002/14651858.CD006239.pub2/information#CD006239-sec1-0015

12

Hi @alirezaaa,

The technical team have the following instructions for you:

  • Remove $locale from replaceCompetingInterests in CompetingInterestsDAO.inc.php

     function replaceCompetingInterests($pubId, $competingInterests) {
          $updateArr = [
          			  'publication_id' => $pubId,
                        'setting_name' => 'competingInterests',
                        'setting_value'  => $competingInterests
                       ];
          $keys = ['publication_id', 'setting_name'];
  		$result = $this->replace('publication_settings',$updateArr, $keys);
  		return $result;
  	}

  • Replace this code:

      foreach ($competingInterests as $locale => $value) {
              $competingInterestsDao->replaceCompetingInterests($pubId, $locale, $value);
          }

(with this:)

$competingInterestsDao->replaceCompetingInterests($pubId, $competingInterests);

  • And finally remove these lines from CompetingInterestsPlugin.inc.php:

      if (!$competingInterests) {
                  $competingInterests = 'array($locale => null)';
              }

If there are any further issues, let us know.

13

Hi @UP_PFord,

Problem solved. Thank you for your support.

Best,
Ali

15

@UP_PFord , does your team plan on submitting this to the Plugin Gallery?

16

Hi @ctgraham - yes, we do plan on submitting this to the Plugin Gallery. Unfortunately, I don’t have a timeline for this yet, because we’re in the middle of a large internal transition project. Do you have a requirement for this? If so, we can take that into account, and produce an estimate on when this’ll be submitted to the Gallery.

Thanks

17

Hi, @UP_PFord , we have no hard requirement here. But, we do have a publishing partner who would be interested in using the plugin, and our policy is to only support plugins which have been included in the plugin gallery. So, we are needing to give them a “soft no” for now.

18

Hi @ctgraham, I’ve discussed this with our project leader and we need to prioritise our resources on our current transition operations for the immediate term, as we’re on a tight internal schedule. I’m reluctant to give a concrete estimate on when we’ll have the plugins in the gallery, just due to the potential flex in our project, but I would tentatively say that we will start considering work of this nature towards the end of this calendar year (according to current estimates).

Would you be able to say a little more about the reasoning behind your policy (of only using plugins from the gallery)? It’d be really helpful for us to learn the motivating factors, particularly if they’re shared by other members of the community.

19

In our model for supporting OJS publication and hosting at scale, we do not allow individual clients or partners to modify the OJS codebase or to add plugins on their own. Rather, we provide an standard installation of OJS with a fixed set of plugins available to be enabled to customize the OJS experience.

We are depending on the active submission and external review of plugins within the Plugin Gallery to assure:

  • There is a plugin developer who is committed enough to see the plugin certified against various versions of PKP software
  • There is a level of trust on behalf of the broader community for the security and function of the plugin

With that commitment and trust expressed through the submission and review process of the plugin gallery, we’re willing to support the plugins listed there for our clients and partners.

1 Like
20

Thanks for sharing this - it’s really helpful. We’ll feed this into our thinking, and plan our timeline accordingly.