A brief outline of Kotahi features

Kotahi has been in the wings for a while. Now, however, we are moving ahead with some more accelerated development. In short-time the product has been extended in collaboration with eLife. We now also have the platform in production at eLife.

The following is a brief outline of the current state.

Importing content

Kotahi has an extensible import pipeline. Currently docx import goes a step further than most ingestion pipelines and converts the docx file into a kotahi compliant data structure (via xsweet) so the content can be displayed and edited in the browser (using wax 2). However we do also have use cases currently in testing for batch import of submissions via crossref, bioRxiv and Pubmed Apis, as well as via content from a google spreadsheet.

  • Extensible import pipeline
  • Currently supports the batch import of articles via bioRxiv and Pubmed APIs, Docx

Login

Kotahi supports any kind of login OAuth, integration with existing auth systems, or the standard account creation process. However we have made the ORCID login process the default.

  • Authentication and login with ORCID

Manuscript submission

Submission objects (article, preprint etc) can take the form of a URL (eg a link to a github repo for reviewing sofware, or a link to a Jupyter notebook, an existing preprint via DOI link etc). Submission objects can also be an attachment (eg PDF, EPUB, latex file) or content to be converted and edited within the system (eg docx).

Additional submission data is captured by author input into a submission form. This form is built by the admin. the building of the form is all done in the browser with our Form Builder (no need for a developer to do this).

Each field has validation options as well as the option to mark certain fields as required etc.

  • Submit manuscripts from a URL or upload a file.
  • All manuscript metadata is captured in a form using the Form Builder
  • Submission form builder accessed via a browser
  • Options to customise/parse specific object data e.g. DOI URL validation upon submission

Manuscript editing

If you have ingested a docx file then the ingested content (micropub, manuscript etc) can be viewed and edited within the system. When content is edited within the revision cycle separate versions of each submission step are maintained. This is also true for form data captured in the submission form.

  • Edit your manuscript in your browser using Wax 2, a premium word processor developed by Coko
  • Wax 2 and Form Builder support multiple versions of a submission (all revisions)

Manuscript handling

A lot here… Admin and Managing Editor / EiC etc share the same ‘god’ role – they have access to everything. Senior Editors, Handling Editors etc are assigned per submission. All folks access their submissions via the dashboard although there is also a view that shows all submissions (available only to those with managing editor etc perms).

  • Role-specific views and information accessed via the Dashboard
  • Managing Editor/Admin view accessed via the Manuscripts page; status, date modified, created by etc.
  • The Manuscripts page can be configured to include the following actions; view/edit metadata, edit/publish manuscripts and evaluations (reviews)

Triage

Kotahi supports ‘triaging’ via a number of tools. Essentially filtering by topic and labels combined with the ability to delete/reject submissions enables multiple types of triage process.

  • Filtering manuscripts view by status, ad hoc labels and/or topics
  • Deletion of submissions

Peer review

There are multiple types of peer review process supported. Various types of open and blind reviews. There is also the ability to assign individual reviewers OR multiple reviewers to conduct a shared/collaborative review.

  • Discreet vs shared reviews
  • Public vs anonymous reviews
  • Capture reviewer recommendations
  • Capture Editor decisions (accept/revise/reject)

Communication

Multiple tools to enable collaboration. Live chat, video calls, ‘presence’ indicators’ etc.

  • Synchronous and asynchronous chat
  • Chat directly with an Author or have a confidential discussion between editors
  • Launch a video chat
  • Built-in email notifications subsystem

Pre-production

  • Copyediting work can be done in Wax (Grammarly integration)

Publishing

This is more or less the export pipeline and it similarly extensible (as per import pipeline). Kotahi has a native publish interface but it can also be integrated with external services. You could, for example, publish instead to the forthcoming product – Flax.  Currently the following use cases are also built in for publishing to (registering) DOIs and metadata with Crossref, and publishing to a spreadsheet.

  • Publishing to Kotahi’s homepage
  • Registering DOIs via Crossref
  • Publishing to a spreadsheet
  • Extensible export (publishing) pipeline

Reports

  • Filter and view system-wide, manuscript and role-specific performance data

User management

  • Assign system wide role permissions
  • Assign manuscripts specific permissions

Forthcoming:

  • Text strings accessible for translation/modification
  • UI for config

Kotahi code is open source

New product announcement soon

At Cabbage Tree Labs we have been working on a new product called ‘Flax’. It is a new platform that any tool can publish to. For a long time Coko has been focused on building workflow tools for the content production and review process. Now we are extending the natural scope of the flow to the actual publishing of materials.

The framework is designed to be lightweight and extensible. Building workflow products is hard, and we have developed PubSweet to make this easier. However publishing front ends (call them repositories, libraries, collections, shops…whatever you like) aren’t so tricky AND they need to be highly customised per publisher. Consequently we have built a lightweight extensible framework that can handle any kind of content coming from any tool. The system can then be extended by a local development house (or by yourself if you are geeky) to include all your about pages, FAQ, policies etc…

The key features are:

  • content agnostic
  • lightweight and extensible
  • can handle one item or an entire repository/library of content

Regarding Coko products, we can integrate Flax with Editoria and Kotahi using GraphQL which means there is a live connection between the workflow and the publish end point. Consequently you can immediately publish, update, unpublish etc to Flax from Kotahi or Editoria.

However Flax is built to integrate with any tool. Consequently we have placed it in Cabbage tree Labs. The Labs are for projects that anyone building a publishing tool could leverage without using any other Coko products.

Anyways… announcement coming soon…