What to write in Public Galley Identifier and Public URL identifier during publication of articles and issue in OJS 3.x

Software Support
1

I am using OJS 3.x. What should I write in Public Galley Identifier and Public URL identifier when I upload the articles and full issue of our journal. Kindly advise

2

Hi @sulaman,

Those are optional fields, so you donā€™t need to put anything there. If you want to change the articleā€™s identifier in the URL into something more meaningful than a number, you can enter it here. (It must be unique and shouldnā€™t be strictly numeric.)

Regards,
Alec Smecher
Public Knowledge Project Team

3

Thank you @asmecher. I wish to know what various options are available to fill in this field of Public URL identifier. Though optional yet I am interested in learning about it. Would be obliged if you may kindly guide.

1 Like
4

Hi @sulaman,

Itā€™s used as described above ā€“ if you want to have something other than a numeric identifier in the articleā€™s URLs.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Thank you @asmecher. I wonder if I can get any examples of non-numeric identifier. I am sorry for being new to this all and asking too many questions.

1 Like
6

Hi @sulaman,

You can use whatever you think is logical for your journal. For example, you could combine the authorā€™s last name and the year, e.g. smecher2017.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
7

Many thanks @asmecher. What is the example of public URL identifier?

8

Hi @sulaman,

smecher2017 is an example I gave above.

Regards,
Alec Smecher
Public Knowledge Project Team

9

Thank you @asmecher. Does that mean that Public URL identifier and Public galley identifier is the same thing?

Sorry, I am a bit confused. I believed that Public URL identifier should be in the format of a URL.

10

Hi @sulaman,

These fields allow you to enter an identifer thatā€™s used within a URL. They are supported for article URLs, galley URLs, etc., and when entered they replace the numeric identifier that would normally form part of the URL.

Regards,
Alec Smecher
Public Knowledge Project Team

11

Thank you so much @asmecher for your kind support always. I am looking forward to hear from you regarding my query about plugin for integrating OJS with iThenticate.

Regards. Sulaman

12

@asmecher - why cannot the public identifiers be numeric any more? I have used the system of VOLUMENUMBER.ISSUENUMBER (e.g 22.1) in the previous versions of OJS for PIs of issues and these have been transferred to the new version of OJS without problems. But when I try to add the public identifier for an issue in the same format now (23.1), I get an error message (ā€œThe public identifier ā€˜23.1ā€™ must not be a numberā€).
If these formats could be used before, why cannot they be now? This breaks the system of including issue numbers in the URLs and Iā€™m not happy about it at all.

Ivo

13

Hi @ivovolt,

OJSā€™s own automatically-generated identifiers are numeric, and thereā€™s the potential for the two to collide (i.e. OJS assigns 1234 automatically when thereā€™s already a 1234 that was manually assigned). Weā€™ve generally recommended that editors not use numeric IDs when manually assigning them in order to avoid this situation, but have only recently added a check to make sure of it.

It sounds like youā€™re using decimal notation, which is technically numeric, but which OJS will never automatically assign (itā€™ll only assign integers). If you like, you can relax the check by changing calls to is_numeric to ctype_digit inā€¦

  • lib/pkp/controllers/tab/pubIds/form/PKPPublicIdentifiersForm.inc.php
  • controllers/grid/issues/form/IssueGalleyForm.inc.php

This will still prevent manually-assigned IDs like 1234 but will allow numeric but non-positive-integer data like -123, 123.4, etc. Those wonā€™t collide with OJSā€™s automatic IDs.

If youā€™re able to verify that this works as expected, please confirm here and Iā€™ll commit the change for a future release.

Regards,
Alec Smecher
Public Knowledge Project Team

14

Thank you, @asmecher - this worked!

15

Hi @ivovolt,

Committed, thanks:

Regards,
Alec Smecher
Public Knowledge Project Team

16

Hi @asmecher !

Many thanks for help!
As you noticed, this solution works only with format like this 23.1

but Is it possible to combine OJS automatically generation of identifiers like 1234 and manually assignment of positive natural numbers 1234 ā€¦ (at the same time two ways are available) ?

To avoid duplicates OJS may just report an error when ID is already assigned to another material (as it happens with DOIs)ā€¦

If it is possible, what should be changed in the code and in which files?

17

Hi @OSU,

Iā€™d strongly recommend against trying to use all-numeric IDs in public URL identifiers. The check that currently prevents this is intentional. If you want to remove that check, you can, but youā€™ll likely run into weird ambiguities down the line.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
18

Thank you!

in that case we will refrain from thisā€¦

With regards.

19

Thanks for pointing this out - we recently had a problem with the native XML upload though. A prospective editor used strictly numeric public IDs and the upload went through, but - unsurprisingly - caused conflicts with existing articles in our journal installation (the existing articles were no longer reachable). Could a check for the XML upload be added as well (editors can unintentionally wreak havoc on multi journal installations this way)? Defining the ID as string in the .xsd for import is not enough, because strings can consist of all-numeric characters too.

20

Hi @ojs_univie,

Any chance youā€™d be willing to take a crack at adding this constraint? Because the id element is used in several cases, we canā€™t add a blanket restriction on numeric values ā€“ only for type="public". At a glance, this will require a co-occurrence constraint. I wrote the XSD files defining the native import/export XML format, but havenā€™t worked with it since then and am a little rusty.

Regards,
Alec Smecher
Public Knowledge Project Team