ojs-to-ops.md

OJS to OPS

Naming conventions

Name of the Application: Open Preprint Server (OPS) / Preprint Server (PPS)

pkp-lib	OMP	OJS	OPS
Site	Site	Site	Site
Context	Press	Journal	Server
Submission	Monograph	Article	Preprint
Representation	Publication format	Galley	Galley(?)

Do we use Categories or Series instead of Sections in OPS? Both mentioned in the docs.

These need to be decided fairly fast, because I will start using them right away.

Questions

1. Regarding payments, I am choosing to remove everything at this point. If some kind of APC model is needed, it can be added later. Most of the payment stuff deals with subscriptions and embargoes, which are not needed.

2. With DOI related code I think that the short term goal is to copy the OJS code and modify it to work with OPS. The long term goal is to move more pubid code to the shared library, enable DOI registration in OMP as well and have a shared pubid / DOI plugins for all applications with minimal app specific code. This however is a large project that should not be resolved within this project.

3. In DOIs one central question is also that do we allow authors to attach DOIs to their preprints. Some OPS users may not want this since it will cost them.

4. A general remark is that many things that are app specific in OJS would look very much the same in OPS as well. This of course introduces the question if that code should be moved to the shared library, although it can not be used with OMP.

5. Important question that has not been discussed: do we need the OJS externalReview functionality, or are all reviews done with 3rd party tools and in public? Based on the documentation I've seen and the discussions we have had, I presume that we do not need it, but thinking especially what SCIELO thinks?

6. (Do we need LOCKSS/CLOCKSS for OPS? edit: no we do not, mentioned in John's doc.)

7. Regarding dublinCoreMeta, googleScholar and a possible Open Graph -plugin, I suggest that we merge all three plugins and create a application independent plugin with a separate repository. We could call it Landing Page Metadata Plugin and it should be enabled by default. A possible project for a Sprint?

8. Galleys or some other type of representation? We have translated "galley" to "published file" in the Finnish translation, so for us it would make sense that we talk about galleys in OPS as well. However, I have understood that for native speakers the meaning of galley is not that simple?

Roadmap

The general roadmap which I am envisioning is below. Probably it will not be so clean, meaning that I need to edit some things before hand and also afterwards.

1. Database changes, renaming, registry, schemas, dbscripts, api, install, default settings, test db with some prefilled values,

2. Frontend -> create a simple listing functionality and the ability to show single published preprints. Remove all unnecessary frontend code.

3. Submission listings -> submission listings view for preprints in the backend.

4. Roles and users -> user management, role management, custom roles needed for preprints ("super author"), roles not needed in OPS.

5. Submit a preprint workflow -> simple submission functionality, metadata form for preprints, ability to upload representation files, ability to publish the preprint from step 5 if screening ok,

6. Submission stage for preprints -> submission stage management (author/editor views)

7. Settings -> site management, context management

8. Extended browse and search in frontend

9. DOIs

10. plugins, tasks, mail templates, statistics,

The Delete list

/api/v1/

Remove totally

_payments

issues

Review and edit content

_submissions

site

submissions

/classes/

Remove totally

controllers

issue

mail (if no app specific mail template needed?)

payment

subscription

tasks (if no app specific new ones needed)

user (only includes subscription related code)

Review and edit content

components

core

handler

install

journal -> server

log

notification

notification/NotificationManager.inc.php (includes books for review specific language?)

oai

plugins (short term goal to have DOI functionality in OPS by modifying OJS code)

search

security (most things can be removed)

services

statistics

submission

template

workflow

Candidate for moving to pkp-lib

i18n/AppLocale.inc.php

plugins (long term goal to move pubId stuff to pkp-lib and share for OJS, OMP and OPS)

/dbscripts/

Remove totally

xml/upgrade

Review and edit content

xml

docs (remove most)

/js/

Remove totally

controllers/tab/

controllers/grid/issues/

Review and edit content

load.js

pkp.min.js

/locale/

Remove all keys and start from scratch with en_US (we need a native speaker to go through all translations I create)

/pages/

Remove totally

about

authorDashboard (empty class, why needed?)

information (I think this should be removed from OJS as well and move the existing content to navigationMenu custom content)

issues

manageIssues

manager (just payments stuff)

payment

payments

reviewer

Review and edit content

article -> preprint

catalog (main method for browsing content in OPS)

gateway

index

management (possibly everything can be deleted)

oai

search

sitemap

submission

user (most things can be removed, concerns mostly payments)

workflow

/plugins/

Remove totally

auth (remove all for now)

blocks (remove all for now)

gateways

generic/announcementFeed

generic/customBlockManager (for now)

generic/driver

generic/dublinCoreMeta (for now)

generic/externalFeed

generic/googleAnalytics

generic/htmlArticleGalley

generic/lensGalley

generic/orcidProfile

generic/browse

generic/pdfJsViewer

generic/googleScholar (for now)

generic/OpenAIRE

generic/recommendByAuthor

generic/recommendBySimilarity

generic/staticPages

generic/translator (for now)

generic/webfeed

importexport/datacite

importexport/doaj

importexport/medra

importexport/native

importexport/pubmed

importexport/sample

importexport/users

metadata/mods34

metadata/openurl10

oaiMetadataFormats/marc

oaiMetadataFormats/marcxml

oaiMetadataFormats/rfc1807

paymethod

pubIds/urn

reports (for now)

Review and edit content

generic/acron

generic/citationStyleLanguage

generic/tinymce

generic/usageEvent

generic/usageStats

importexport/crossref

metadata/dc11

oaiMetadataFormats/dc

pubIds/doi

themes/default (maybe the theming team could prepare an advanced preprints server theme that would be available later this year?)

/registry/

• Review and edit content

/schemas/

• Review and edit content

/styles/

• Review and edit content

/templates/

Remove totally

controllers/grid/issueGalleys

controllers/grid/issues

controllers/grid/subscriptions

controllers/grid/users/reviewer

controllers/modals/submissionMetadata

controllers/tab/issueEntry/form/

frontend (all issues and payment related can be removed)

gateway

manageIssues

payments

reviewer/review/

Review and edit content

admin

common

controllers/pubIds

controllers/grid/submissions

controllers/grid/settings/sections

controllers/tab/authorDashboard/

controllers/tab/pubIds/form/

controllers/tab/workflow/

frontend/ (all issues and payment related can be removed)

images

management

submission (possibly just remove)

/tests/

• review content, remove most

/tools/

• review content, remove most

Here's SciELO's take on some of the questions:

1. Regarding payments, I am choosing to remove everything at this point. If some kind of APC model is needed, it can be added later. Most of the payment stuff deals with subscriptions and embargoes, which are not needed.

Agreed. According to Alec, this can be added later on so no problem in removing it completely at this moment.

2. With DOI related code I think that the short term goal is to copy the OJS code and modify it to work with OPS. The long term goal is to move more pubid code to the shared library, enable DOI registration in OMP as well and have a shared pubid / DOI plugins for all applications with minimal app specific code. This however is a large project that should not be resolved within this project.

Please keep in mind that the existing CrossRef plugin requires an ISSN number, which Preprint do not that. It would need to be slightly adjusted for those who wish to use CrossRef as DOI provider (as is SciELO's case).

5. Important question that has not been discussed: do we need the OJS externalReview functionality, or are all reviews done with 3rd party tools and in public? Based on the documentation I've seen and the discussions we have had, I presume that we do not need it, but thinking especially what SCIELO thinks?

We won't be needing external Review. The only bit of "review" that will happen is for the initial screening that some papers will have to go through. Specifically those that were not pre-approved, but sometimes even those might need to go through some screening. I don't think that would require the whole externalReview module (ie: selecting, inviting, filling out a review form). Perhaps the existing "Editorial Discussion" functionality might work. externalReview is too much/too involving for what we need.

8. Galleys or some other type of representation? We have translated "galley" to "published file" in the Finnish translation, so for us it would make sense that we talk about galleys in OPS as well. However, I have understood that for native speakers the meaning of galley is not that simple?

If SciELO has any saying on this, we prefer "published file" over "galley".