Category: Uncategorized

https://www.booksprints.net/2020/06/18/webinar-on-rapid-collaborative-book-production/

notes for a possible article

Networkflows – a framework for the Evolution of Publishing Workflows

The idea – to define evolutionary stages of Publishing Workflows. Suggested starting 5 are :

 

1. Paper
2. Paper-like digital (digitalised paper)
3. Non-linear digital
4. Concurrent
5. Enlightened collaboration

• Define workflow

Stage 1 Paper

• The past – paper and stamps

Stage 2 Post Paper Digital (paper-like)

• Current state of Publishing workflows
  • Don’t restrain to only journals if possible – more applicable if we keep it wide eg books, micropubs, journal articles, manuscripts of all kinds
  • Current workflows based on post-→digital paper (paper=MS Word, email = envelope+stamp)
  • Operate on the object then send to the next person
  • Linear
  • Each stage gated (one operator per stage)
  • Like a conveyor belt – uni-directional
  • Going ’backwards’ is difficult
  • Difficult to account for the non-linear or ad-hod
  • Control of edits via ‘who holds the doc’ + track changes
  • Many softwares for (eg) managing journals are called workflow systems but really they are for tracking progress and storage. Tracking is also good to use here as it is related to paper

Stage 3 Non-linear (also paper-like?) …The Pizza Model (needs better analogy…maybe car assembly?)

• Moving Publishing into the network – stage 1 (the pizza table)
  • It is the second stage of digital evolution for publishing
    • Paper → post-paper (1st stage digital) → the network
      • There will be plenty of published theory on the above
      • The pizza theory – a round table, not a conveyor belt
      • Many people can improve the pizza
      • The folks pass the pizza around in any direction
      • Still gated
      • Non-linear, or at least partially linear
      • Actions determined on an ad-hoc basis
      • The pizza can go back and forwards in the flow easily
      • All actors can see what is going on with the pizza

Stage 4 Concurrent collaboration

• Moving Publishing into the network – stage 2 (concurrent collaboration)
  • Needs a good analogy (shared surface?)
  • The third stage of the digital evolution for publishing
  • People can operate at any time, or on any part of the object
  • Communication is in real time, reflecting more of a conversation
  • Decisions made through conversation
  • Accountability via tools that enable ‘breadcrumbs’ and rollbacks

Stage 5 – enlightened collaboration

• Authorship starts to dissolve
• Roles become fluid
• Facilitation becomes the most important tool
  • Eg Book Sprints
• Facilitation maintains trust
• Everyone has the mandate to change the object
• Flattened hierarchy
• Comment on diversity
• Accountability comes via conversation and group relationships

Some more stuff to come on Kotahi…most of this, and more, will re-emerge on the Coko blog in edited form…but….just to say… Kotahi is designed to be a community project.

We started the process with community (Collabra Psychology folks, then the Organisation for Human Brain Mapping folks)…. co-designing the system with them…

The intention is to continue in this manner. We have the Orgnaisation for Human Brain mapping committing to this project along with Amnet Systems. If you would like to join and contribute to the effort then give me a yell – adam@coko.foundation

So…. what special features are there in Kotahi?

Well…first of all, not all of this is yet built but much of it is. So I’m just going to outline what we are building whether it will be in the 1.0 release or later.

Live Chat

Live chat for talking in realtime. So, you might ask, how come this doesn’t exist in publishing systems to date? Because, I would argue, most systems are built with the concept of post-paper digital workflows. MS Word, or similar ‘offline’ storage medium, is used together with email to emulate (literally) paper and stamps. The Scholarly Communications sector has not escaped the paper paradigm. Live chat is a child of the network. It is time, IMHO, we start embracing the network in how we work.

Video Chat

Same as above. Except – if text becomes too burdensome then dial up your collaborator and talk to them directly.

Article (concurrent) editing

Edit the article right in the system with annotations, comments, semantic tagging etc etc…edit the article concurrently if necessary (similar to google docs). All achieved using the Wax 2 editor.. why editors are so integral to this kind of system is beyond these posts… I’ve written about this elsewhere, but in short…the problem Scholarly Comms is very text heavy and we lack a robust, sophisticated, fast and extensible framework for building web based word processors that use annotated  html compliant data structures for their content storage format. Wax 2 is exactly this and why we built an editor (wax 1) and then rebuilt it (wax 2)… 1.0 of wax 2 out very soon… an editor is not just an editor… there is so much more to it…but more on this later

Push button to PDF

Yes… using the very latest typesetting technology you can go from “annotated html compliant data structures ” (as per above) to very good looking PDF…. attached is a very simple example of pagedjs in action

scientific-math-paper

pagedjs is a state of the art, standards (W3C) compliant, typesetting engine that converts html to PDF using CSS to control the style and layout. How do we know so much about this? Because we built it. For more info on this and wax see https://www.cabbagetreelabs.org/

Push button to JATS

How? Well, we have an extensible editor… next is to add functionality that will enable us to identify regions in an article, add metadata from the submission form, and export to JATS. Its possible in theory, hard in practice. It is our next item to tackle. But it is doable…i mean, we built track changes into the editor (you never want to do this…twice)… we can figure this one out….

Form Builder

What? A form builder? how exciting!… well..actually it is pretty cool…. Kotahi has a built-in form builder for generating your submission questions..what does that mean? It means you can build your own submission forms, using custom submission questions and interface elements (check boxes, text boxes etc) with custom validations. You can also mark which items are necessary to answer and which are optional. Finally, Kotahi stores all this stuff in the DB explicitly marked so you can then call this up when exporting (eg to JATS)… its pretty useful.

…

much more too… but enough for now…

Following on from the first post…https://www.adamhyde.net/kotahi-can-do-waaaaaat/ … some more thoughts for a post to Coko later on.

So… thinking about how to represent how one platform can encapsulate three workflow… i remember this post from a design session Dan, Alison and I did…

Rethinking Workflow

In this process we drew up the ‘high level’ architecture and mapped the flow of (what is now) Kotahi for a typical journal article. Some pics from that post and session here:

So…this is actually a nice way to show how preprints, micropubs and journal articles can fit within the same system…so here goes…pulling out the trusty drawing book…first image is a birds eye view of the Kotahi platform showing all of the related ‘pages’…

The spaces are connected through links. Only folks with the right permissions can see the links / can access certain spaces. The authors, for example, don’t get a link to the control panel…below is a description of each of the above spaces with a few notes…

1. login
   Where everyone logs in. At this stage Kotahi supports ORCID login only.
2. Dash
   All folks logging in go to their dashboard. Linked from the dashboard is also a profile page (not shown) which is populated with info from ORCID plus some user contributed data. The dash shows only those items (articles/objects/manuscripts) you have a relationship to.
3. Submission
   The submission page containing all the metadata added by the author. Linked to this is (not shown) the actual article if it has been added via MS word (converted into HTML and loaded in the Wax Editor). If the article is a link or a attached asset then that information is attached / linked to on this submission page.
4. Control Panel
   This is where the editors manage the workflow of the paper. Managing Editors can assign Senior and Handling Editors. Reviews are read here. Decisions are made here.
5. Assign Reviewers
   Where the editors assign reviewers.
6. Review
   Where reviewers create and submit reviews.

OK…so… you now see the ‘work’ spaces… what is the ‘flow’ (geddit…’work-flow’) associated with each of the usecases (journals, micropubs, preprints)….

Ok… Journals….the Journal workflow more or less looks like this:

1. Author – submits article
2. Managing Editor – checks. Rejects if necessary, or sends on to be processed.
3. Managing Editor – assigns Senor Editor
4. Senor Editor – assigns Handling Editor
5. Handling Editor – assigns reviewers
6. Reviewers – accept / decline
7. Reviewers – write reviews, make recommendations
8. Handling Editor – makes decision to a) revise (goto 9) b) reject c) publish (goto 12)
9. (review) Handling Editor – writes decision to authors
10. (review) Author – revises manuscript and resubmits
11. (review) Handling Editor – may assign reviewers (goto 5) or publish
12. publish

Sure, any journal may deviate from this. Its a general case. One thing to try not to get caught up on is the naming of roles. For example, the micropubs folks we have worked with might have a Science Officer … but, as we shall see in the next workflow breakdown, that role does more or less the same as a second, consultative, Senior Editor.

Ok… so, the above list of steps flows through the spaces as so….(this looks sooo ugly, will find a nicer way for the coko post)….

Ok…so, you can (in ugly detail) see how the flow, flows (so to speak) across the workspaces…the color each numbers relating to roles as per the key..

oke…so…what does a micropub look like? maybe something like this (assuming the article goes through one review cycle):

1. Author – submits article
2. Managing Editor – checks. Rejects if necessary, or sends on to be processed.
3. Managing – assigns Handling Editor
4. Handling Editor – assigns reviewer
5. Reviewer – accepts / declines
6. Reviewer – write reviews, make recommendations
7. Handling Editor – makes decision to revise (goto 8) or publish (goto 10
8. (review) Handling Editor – writes decision to authors
9. (review) Author – revises manuscript and resubmits
10. publish

Mapped onto the spaces…

And lastly preprints might look like this…

1. Author – submits article
2. Managing – assigns Handling Editor
3. Handling Editor – checks
4. Handling Editor – makes decision to reject or publish
5. publish

And mapped out…

That is the gist of it. As you can see, each usecase can fit into this one system. Of course, the above outlines do not capture every role name or flow – but these are just examples… the point is, any workflow like the above can fit into the Kotahi system…. next posts deal with special features and an examination of the role (so to speak) of permissions in such a system.

So, this is in part a bit of a brain dump as I intend to write something along the lines of this post for the Coko site.

Kotahi is the forthcoming publishing platform that we have now in a 1.0 alpha release. Kotahi is, by the way, a Maori word meaning ‘unity’ and we asked local iwi in northland (NZ) if we could use the name and they were happy for us to do so.

Coko has wanted a journal system for a long time. We started developing one in collaboration with the Collabra Psychology journal. But we were pretty understaffed to take it on and we needed folks on Editoria. That, and the fact that Hindawi had started their wonderful Phenom platform for journals meant we didn’t feel such a need to follow the project through at that time. eLife had also started Libero which was another journal system built on PubSweet. So why bother when so many good folks were on top of the problem? So we paused the effort.

So..why restart recently? Well, eLife have gone through a reshuffle and they aren’t focusing so much on Libero right now. That, plus Hindawi have a beautiful system (Phenom) but it has a lot of Hindawi business logic built in. If you want to use Phenom then you need to dig a lot of that code out. Not out of the question if you have the resources and certainly worth checking out if you do have the resources…but it feels like there is a gap now in the market for a modern, easily deployable, system.

That is why we restarted Kotahi. We already had a lot of stuff done so getting it across the line was an easy call to make. We had a little surplus too that we could spend on it, as we have no funding to build Kotahi. Not many funders are interested in supporting journal systems. So, we just decided to get on with it.

We have, as it happens, benefited alot from the wisdom accrued since we paused the dev. We have in the meantime built a micropublications system that is in production for the micropublication.org project. And also, we have seen inside many other workflows in a hands-on manner. My work with Workflow Sprints (a one day facilitated event to improve a publishers workflow) has allowed me to be a very privileged witness to many many workflows and use cases from journals, to preprints, micropublications, content aggregation, collaborative authoring of non-linear narratives, open access book production, OER textbook production and more…

From those sessions I have come to believe that there is very little difference in many of these workflows. There is, to speak directly, very little difference between a micropublications workflow, a journal workflow, and a preprint workflow.

I made a little slideshow about this here

The main point are the following slides showing a very lightweight breakdown of the three types of workflow..starting with Journals…the following is a very high birds-eye view of a typical journal workflow.

There is a gap between revise and publish that is covered by production. However, many journals currently have this managed by external vendors so in a way it is ‘outside’ a typical workflow. However, Kotahi will address this…more on this later…for now micropubs…

If you look at the difference in *workflow* between a journal and a micropub there isn’t much to speak of. Given that there is no strict category for what  a micropub actually is, from my experience talking to, and working with, micropubs folks, the point they are eager on is that (from a workflow perspective) the process is ‘lighter’. The article might have a reviewer, or handling staff might know enough just to pass the content straight through. A revision might take place but since the articles are smaller than journal articles, the revision is mostly something of a ‘touch up’ rather than a radical revision. If they do review something it is done fast and with minimal reviewers. Maybe one for most cases.

So the main difference really is the ‘slightly lighter’ version of the same workflow Journals have… this may be hard for some micropubs people to stomach because, from my experience, they might see what they do as a radical departure from journals – possibly they may see micropubs as a necessary radical intervention and re-think because journals are too slow, leave important data on the cutting room floor, and manuscript publishing doesn’t account for the interesting (and long) journey of related findings researchers make along the way to a full manuscript for journals…

But, lets face it…. there is a difference between a ‘rethink’ of what kinds of things are worth publishing and the workflow associated with the publishing. Micropubs are a radical rethink of the former, but not yet on the later. That means, for all intents and purposes, we can consider journal workflows and micropub workflows to be more or less the same. That should actually be exciting for micropubs folks rather than deflating as it means you could very easily sit the two side by side in the same publishing channel … cross linking micropubs to manuscripts etc… achieving the progressive publishing, step by step to a full manuscript, that is part of the micropub movements narrative.

That is not to say I am defending the idea of manuscripts as a means of communicating research 🙂 I’m not… I’m relating usecases I see in the world right now and their associated workflows.

One last point about micropubs…unlike preprints and journals, the publishable content doesn’t look like a typical journal manuscript. The content, in fact, could be anything…it could be a gitlab repo, or a link to a jupyter/binder instance, or a link to stenci.la reproducible docs, or an abstract, or an image with some explanation… this is probably where micropubs deviate further from journals and preprints. The difference is in the content type, not really the workflow…so if you design a system that can work with ‘smaller’ articles, or different shaped articles, or even just with links to external resources as a publishable asset….well…then you have something…

So…what of preprints… well they aren’t that much different either. Basically, reviewing falls off the cliff…but not completely…. preprints have checks…some are automated, some are manual, before the stuff is pushed through. So, the process really is the same but ‘lighter’ again…

You can argue with me about this 🙂 I’d welcome it. But I don’t see the difference. As I say in the above slide deck, the difference in workflows between these 3 workflow is minimal, but configurable.

What I mean by that, is that it is easy to build a system that encapsulates any of these 3 workflows within the same system. It is also pretty simple to build a system that can deal with different content types, be they links, journal articles, abstracts-only or whatever…that isn’t so hard…One platform, if designed well, can do all 3 use cases.

That is what we have done with Kotathi.

If you would like to know more… email me. We are doing demos soon and also putting out the word for folks to join the effort.