iThenticate integration improvement #33
Replies: 7 comments 9 replies
-
|
The key thing to keep in mind is allowing Editors to select which submissions/files should be sent to verification, so that they have control in terms of how much this will cost at the end of the month/year. |
Beta Was this translation helpful? Give feedback.
-
Perhaps a series of filters?!
[NEW RULESET] I think it's also important to:
|
||||||||||||
Beta Was this translation helpful? Give feedback.
-
|
Looks good to me! Minor point, but would sending after copyediting be a real use case? By this point there will have been a lot of investment into the submission (reviewers, editors, copyeditors), so wouldn't editors want to know if it had problems well before it was copyedited? Copyediting may also hide the fact that the author has plagiarised content if changed the text. = Perhaps options to send at In your suggestion, how would the option to manually send files work? It sounds like some journals would prefer this to be an option, and then other journals do not want this to be available (mainly due to the files being auto-sent). |
Beta Was this translation helpful? Give feedback.
-
|
Ah, those are just some generic ideas from my developer perspective :)
I think not! But when in doubt, I prefer to forward the decision to the end-user (in fact, having less customizations makes the code easier to write).
For the manual selection, having some control of which files have been sent is required (retrieving the validation result would be just an additional feature to justify the plugin usage). Does it make sense to send some types of files automatically and optionally send others? If yes, then the manual selection can work together with the automated one (the condition to skip the interface would be: at least 1 file not submitted to iThenticate). |
Beta Was this translation helpful? Give feedback.
-
|
Does this discussion have the scope to include adding the iThenticate results back into OJS so that editors can very easily have the reports provided to them? |
Beta Was this translation helpful? Give feedback.
-
|
@touhidurabir I'd like to see the file sending integrated with the editorial decisions. So instead of automating this based on file Component, the editor can select the files when recording an editorial decision. For example, the journal may configure Article Text to be sent by default. Then, when sending the article from Submission to Review, the editor will be presented with a form to select the files to sent. All Article Text files will be selected by default, but can deselected if desired. This will give control to the editor to not send files. For example, if the submitting author has selected the wrong file Component or has uploaded a file twice. Or maybe this submission is an editorial or review or otherwise unique and they don't want to pay to send it to iThenticate. Also, the iThenticate plugin could add a new editorial decision that appeared in the Submission stage just for sending the files. There is more discussion of this suggestion at #4 (comment). |
Beta Was this translation helpful? Give feedback.
-
|
Could the settings for the automated sending of files still be by Component? The use case we have is:
*I can see the cost advantage to this, but some journals do substantial desk assessments prior to the review stage, often involving multiple people. Only being informed of significant similarity issues when a submission goes into Review does mean that this will be potentially wasted time. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I should have clarified that I think this in addition to the automated sending at the point of submission. Journals could opt for one or the other. (I am wary of automation as the only option, because in my experience we always run into problems automating things to everyone's needs. A manual option is necessary to accommodate all the different editorial practices.) |
Beta Was this translation helpful? Give feedback.
-
|
Makes complete sense! If a manual option is being added then rather than trying to incorporate different stages of the workflow into the settings - e.g so some journals can manually send during the Submission stage, others when in Review stage - then is it worth adding a button/tab to the submission page that would simply be present throughout all these stages? This would mean that a) the editor can pick and choose when to use it with complete flexibility of the workflow and b) presumably this makes the plugin simpler as it doesn't have to account for when to make the function available. When the 'manual send' button is clicked, it brings up the list of files for the editor to choose from (as you suggest above). I'm visualising the plugin settings as having two primary options
The journal could have either or both enabled. |
Beta Was this translation helpful? Give feedback.
-
|
I can imagine two options that interact to get the desired effect:
When in automated mode, the selected file types (eg - Article Text) are sent automatically. When in manual mode, those files will be selected by default in the form. |
Beta Was this translation helpful? Give feedback.
-
|
I like this proposal a lot, @NateWr. |
Beta Was this translation helpful? Give feedback.
-
|
Just throwing this out there: are you all aware that iThenticate recently upgraded to v2? https://www.crossref.org/blog/similarity-check-whats-new-with-ithenticate-v2/ Does this upgrade impact this plugin in any way? |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't impact the plugin at the moment; the v1 API is still supported for now and I don't see concrete plans yet to decommission it. Upgrading to v2 is on our radar, but we haven't prioritized it yet; one challenge is that the 3rd-party v1 API library we use (https://github.com/bsobbe/iThenticate) doesn't seem to be actively developed anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Quick update, if only to log for my own reference, but we've just had a case where an author uploaded a zip file of their article/research data when completing the submission process. The zip file contained 2300+ txt files, which were unpacked by iThenticate and scanned and thus charged a very high cost for. We need to find a process that allows the journal to encourage authors to provide their data with the submission but not incur such costs (limiting by component would do this). |
Beta Was this translation helpful? Give feedback.
-
|
@twakeford, I've asked @touhidurabir (who is working on iThenticate improvements) to hard-code an exclusion of uploads for |
Beta Was this translation helpful? Give feedback.
-
|
Another comment to add a little new context (for us anyway) is that we have a journal that is heavily video based, so the submission components often include mp4 files, which can get quite large. We've found that submissions with particularly large files (recent example 296MB) fail on the final stage of the submission process. We've done some digging around and found that it seems to be the attempt to send the files to iThenticate that causes the fail. Being able to set the plugin so that only specific components are sent should allow a journal to get around this, as they won't want them sent to iThenticate anyway. |
Beta Was this translation helpful? Give feedback.
-
Current Implementation
Right now when an author submit a new submission, if the
pkp/plagiarismplugin installed, enabled and configured, it will automatically sent all the associated files to theiThenticateservice for the checking plagiarism .Problem
A lot of time not all the files are required to sent to
iThenticatefor plagiarism checking but only few selected files . But right now plugins sent every single file for plagiarism checking which is costly. Also not all submission may not require plagiarism checking based on section/series association or may be not right away .Possible Improvements
Option 1
Keep the automatic process but have a journal/press/preprint wide option to toggle the automatic behaviour . In that case an editorial decision phase can be introduced to run the plagiarism verification via
iThenticateservice manually when the editor/manager want to initiate based on the state of automatic state . More control can be introduced by allowing editor selecting which files can be sent for verification. Similar implementation discussed at #4 .Option 2
Keep the automatic process but have the
iThenticateoptions available for each of Article Component . As a result at the end of submission, files associated with enabled component will be sent for verification process . Similar implementation discussed at#26 .
Option 3
Keep the automatic process and add have the
iThenticateoptions available for each of section/series. As a result at the end of submission, only those submissions that have associated section/series have this enable will be sent to verification process . Similar implementation discussed at #12 .Possible Implementation
A combination of
Option 1andOption 3can be considered as a generalised solution which will have impact at both the automatic and editorial decision behaviour and at the same time at submission level . A similar idea was proposed at #4 (comment). It may be possible to integrate theOption 2also but that may introduce too much options/settings which can lead the editors/managers to greater confusion.Beta Was this translation helpful? Give feedback.
All reactions