The "%c" DOI token appears not to be implemented (OMP)

[asmecher]

See https://forum.pkp.sfu.ca/t/chapter-doi-urns-in-omp-3-1-1/55164 for a description.

In Setup, it's possible to write a pattern for DOIs to use, including variables in the pattern that are replaced with values from the submission data. The setup form allowing this pattern to be entered describes a "%c" token to be replaced with the chapter data; apparently this is not being replaced.

[ajnyga]

This seems to be working ok in master branch. I mean the chapter variable is used there. However, the pattern mentioned in the description is %p.%m.c%c for chapters. Currently the c before %c is missing.

The pr below adds that missing c and removes an s before %s that is not mentioned in the %p.%m.%f.%s pattern. Let me know if you would like to change the pattern description instead.

It also fixes the reassign DOIs error for OMP.

Thirdly it adds a new possible pattern component %b to the pkp-lib and ui-library. This component is for the publicationId which can then be used for DOI versioning which I will most likely need in PPS.

omp: pkp/omp#730
ui: pkp/ui-library#52
lib: #5304

@NateWr and @asmecher a central question here:
Would it be possible that in the publications table we would have both publicationId and versionNumber. The versionNumber would always start from 1 and would be unique in the context of a single submission. It would look better in DOIs and also in the UI. So instead of a link like 2019-11-19 (4524) leading to /article/view/2453/version/4524 you could have 2019-11-19 (1) leading to /article/view/2453/version/1 and the DOI in PPS could be 10.1234/server1.preprint2453.v1

Of course the publicationId will technically work and DOIs should not be human readable, but I am pretty sure this will be requested for URL's fairly soon after 3.2 is released.

(I think there is a similar "problem" if we will have chapter landing pages. I mean you will have URL's leading to "chapter 343" which will probably bother editors. But there it is more complicated while the chapters might change their places in the TOC - the URL can not change accordingly if there are DOIs attached. Or it could, be the DOIs involved would have to be updated in the process. Not impossible, but a lot of work for a visual thing.)

[NateWr]

I'm hesitant to introduce a versionNumber property because it will get complicated down the line. People will want this versionNumber to reflect the published versions, but it is possible to unpublish a version and in the future it may be possible to delete one, and the number will fall out of sync.

I also think, in cases where there is some kind of pre-production publishing, it may look odd to have a version number like 3 for the first "published" version.

I would rather address the version identity problem with a focus on publication types and summaries.

The URL problem is a harder one to address. We are encountering similar hiccups around permanent galley URLs. I really think that to solve this we should move to a URL derived from the names of the objects or some other technique.

Take the chapter landing page example. Even if we used something like a chapterNumber that started with the first chapter and counted up, we'd still have odd URLs because the first chapters are often prefixes and front matter. So the URL to chapter 1 would be /chapter/3.

I would rather see URLs that looked like the following:

• /article/view/253/pdf <-- pdf derived from galley label: "PDF"
• /article/view/253/version/292/pdf
• /book/view/253/chapter/introduction-to-semantics
• /book/view/253/version/292/chapter/introduction-to-semantics

With such URLs we'd gain some SEO advantages. We'd also get consistent URLs for the latest version of things (unless the titles changed). And in cases where a URL path fails we can fall back gracefully to the latest article/book landing page and the user can quickly find what they need.

[ajnyga]

yeah, I can see how that would introduce a lot of potential problems. The idea with chapters is a good one.

I do think that deleting a version is not a big problem. If a number is missing, it gives a clear signal that a version has been removed.

For preproduction publishing happening inside OJS, I think it would make sense that the final published article would show those versions as well as earlier versions of the article. If those earlier versions would have some other content type (like preprint) then that would of course be shown as well. So version 1 was a preprint, version 2 post-review and version 3 is the final published article.

But that question is really not the main topic, I really need the publicationId to be consider in the pubId functionality in order to get DOI versioning to work :) Tests passed all except one. Probably a glitch?

[NateWr]

I restarted the failed test.

[ajnyga]

Thanks! Is that something I could do myself?

[NateWr]

I don't think so.

[ajnyga]

the tests completed, thanks!