Refine "Public URL Identifier" availability and behaviour

[jmacgreg]

Problem(s):

1. What we now call "Public URL Identifiers" aren't identifiers, at least in the same sense as DOIs - they are custom URL slugs.
2. creating a tab at the same level/importance of galleys, metadata, references, etc., called "Identifiers" with only this item in it by default can be misleading - folks may not understand that this is a custom URL slug and not eg. a field to configure a DOI.
3. Having this option so prominently displayed, and by default enabled, will likely result in far more folks throwing stuff in here without understanding why they should or shouldn't.
4. conflating these custom URL slugs with DOIs (by adding DOIs as a field to this page) will just further complicate matters.

Proposed Solutions:

1. rename "Public URL Identifer" to "Public URL Slug".
2. disable this tab by default - add an option somewhere in Journal setup to enable Public URL Slugs, and only display the tab if this option has been enabled, or if DOIs or URNs have been enabled. This tab shouldn't be available and usable by default.

[jmacgreg]

Note: this isn't a bug per se, but more of a potential for confusion. Time depending, if this has to wait to a later release, that's fine - but it should be reviewed at some point. @AhemNason also says that a small note attached to the field describing its intended use would also be fine.

[NateWr]

I'm totally behind this, but it's my understanding that this field is in use as a kind of pub id -- sometimes referencing a submission's ID in other systems or something like that. I'd love to separate these out.

At the moment, the URL slug is stored in a setting called pub-id::publisher-id and this is used in methods like getBestId(). It is also in use by galleys, issues and issue galleys -- anywhere pub ids are in play.

So I'm definitely up for changing this but I just want to double-check that we're not mushing data together here in a way that doesn't match its actual use. This is always a danger when changing the underlying meaning of a field.

Another approach would be to keep pub-id::publisher-id in place, but make it opt in like the DOI or other pub ids. Then to copy any existing values over to a new field like urlPath, and use that instead. This would keep the value in both places and let people disambiguate going forward.

I'm also happy to just get rid of it if we think it's not being used or shouldn't be used.

[AhemNason]

Honestly, I think the biggest issue is that it’s called a “public id” If it were called a “publisher id” and had some copy about what a publisher ID might look like, I’m ok putting it there.. “public URL identifier” doesn’t really describe what this is either.

…

On Mon, Jan 27, 2020 at 6:44 AM Nate Wright ***@***.***> wrote: I'm totally behind this, but it's my understanding that this field is in use as a kind of pub id -- sometimes referencing a submission's ID in other systems or something like that. I'd love to separate these out. At the moment, the URL slug is stored in a setting called pub-id::publisher-id and this is used in methods like getBestId(). It is also in use by galleys, issues and issue galleys -- anywhere pub ids are in play. So I'm definitely up for changing this but I just want to double-check that we're not mushing data together here in a way that doesn't match its actual use. This is always a danger when changing the underlying meaning of a field. Another approach would be to keep pub-id::publisher-id in place, but make it opt in like the DOI or other pub ids. Then to copy any existing values over to a new field like urlPath, and use that instead. This would keep the value in both places and let people disambiguate going forward. I'm also happy to just get rid of it if we think it's not being used or *shouldn't* be used. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5430?email_source=notifications&email_token=AAD3DVH7T7YHL6RZVRHKGNTQ73CLLA5CNFSM4KLIGBA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ7G5QQ#issuecomment-578711234>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD3DVBPRYZFINB5SRS7TCLQ73CLLANCNFSM4KLIGBAQ> .

[NateWr]

some copy about what a publisher ID might look like

To my knowledge, there is no such guidance. It's an extra pub id with no specific intended purpose, that we also use for the URL though we have never said as much to editors.

[NateWr]

Coming back to this (and cc'ing @asmecher). I think we'll need a decision on this soon to get it resolved for 3.2. A brief recap:

Currently a pub-id::publisher-url is available for submissions, galleys and issues. This is described as a pub id and grouped with other pub ids, such as DOIs. However, it is not a recognized pub id and is not treated as such with depositing services. We only use it for the URL slug, but individual journals may attach their own IDs and we don't know how the field is used.

I can see two options:

1. We keep it as-is but move it out of the Identifiers form in publications and into the Issue Entry form, and rename it URL Path. The field for galleys and issues will stay in place for now.

2. We leave it in Identifiers but make it an optional setting (maybe a pid plugin). At the same time, we create a new urlPath property and copy any existing pub-id::publisher-url values into it. And add a URL Path field to the Issue Entry form. The field for galleys and issues will stay in play through the optional setting.

Both options address the confusion for the end user. However, Option 1 leaves the ambiguity in the data structure and we'll probably need to resolve this some day.

[asmecher]

I have a suspicion that we'll be asked for both versioned and non-versioned URL slugs, and versioned and non-versioned publisher IDs. Option 2) gives us non-versioned URL slugs only, and versioned publisher IDs only (correct?). But the two are at least clear and disambiguated, so we can add more options later if need be. Of the two options, I support the second.

[NateWr]

Option 2) gives us non-versioned URL slugs only, and versioned publisher IDs only (correct?).

I think the urlPath could be versioned as well. I was thinking that urlPath would be assigned to the Publication -- in part just because there's no place in the UI at the moment for it to be assigned to the Submission.

I'll plan to work on Option 2 unless James or Mike having anything they want to add.

[jmacgreg]

Option 2 sounds fine to me!

[AhemNason]

I agree with James!

…

On Tue, Feb 4, 2020 at 11:20 AM JB MacGregor ***@***.***> wrote: Option 2 sounds fine to me! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5430?email_source=notifications&email_token=AAD3DVFEMQZRG7R2BZPKNJ3RBGBUVA5CNFSM4KLIGBA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKYAB6A#issuecomment-581959928>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD3DVEPSUR5ANKMN64WT5DRBGBUVANCNFSM4KLIGBAQ> .

[NateWr]

PRs:
#5519
pkp/ojs#2626
pkp/omp#765

Publisher ID is now enabled as metadata under Settings > Workflow > Submission > Metadata.

It appears alongside other metadata.

And a new field has been added for urlPath.

The following tooltip gives some guidance. @AhemNason can you please give me a 👍 or 👎 on this tooltip, particularly its usage in PubMed? (That's the only place I could find the publisher ID used).

Similar steps have been taken with the pub-id::publisher-ids for galleys, issues and issue galleys. When no pub id (DOI/URN) or publisher id is activated, the Identifiers tab will not appear. When upgrading to 3.2, any pub-id::publisher-ids are copied over to the urlPath so existing URLs continue to work.

In OMP, this has been implemented for publication formats but not chapters or submission files. Chapters do not have URLs yet so I left the urlPath out. Submission files do, and it probably makes sense to use a urlPath for these, too. But I opted not to in the end because submission files are much harder to separate out between OJS/OMP, and submission files do not have URLs in OJS. In this case, I took the path of least resistance on the assumption that url paths for files are probably not widely used and that there's a good chance we may separate out publication format files from submission files at some point down the line.

This required a bit more heavy-handed changes than I expected. I'm a bit nervous about this going in so late before 3.2's release. I'd appreciate any time that anyone has to check how the new URL Paths work.

@asmecher The new url_path columns in the db tables are all VARCHAR(32). Should we make this longer or change the type?

[NateWr]

I've merged this in but there are still two things I'd like to hear back on.

1. @AhemNason can you please give me a +1 or -1 on this tooltip for publisher ID?

2. @asmecher The new url_path columns in the db tables are all VARCHAR(32). Should we make this longer or change the type?

[AhemNason]

+1 for sure.

…

On Thu, 20 Feb 2020 at 11:43, Nate Wright ***@***.***> wrote: I've merged this in but there are still two things I'd like to hear back on. 1. @AhemNason <https://github.com/AhemNason> can you please give me a +1 or -1 on this tooltip for publisher ID? <https://user-images.githubusercontent.com/2306629/74674981-70624500-51aa-11ea-9c79-260b95615ec1.png> 1. @asmecher <https://github.com/asmecher> The new url_path columns in the db tables are all VARCHAR(32). Should we make this longer or change the type? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5430?email_source=notifications&email_token=AAD3DVEX2IKZZZHX2S3ZSNLRD2QJFA5CNFSM4KLIGBA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMO2EPY#issuecomment-589144639>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD3DVDJX2WJEXLMLIBBYGTRD2QJFANCNFSM4KLIGBAQ> .

[asmecher]

I haven't heard of a need to go beyond 32 characters, but it is an arbitrary limit and I wouldn't object to e.g. doubling it. (We used to have occasional issues with MySQL's max key length getting hit in certain tables -- that's one potential downside to increasing column lengths on indexed columns. But I don't think we're at risk of that in this case.)

[NateWr]

Thanks!

[fgnievinski]

Hi. I just wanted to confirm if the following field description remains valid:

"A unique ID provided by the publisher. It will be used in the publication's URL path instead of the id when present."
https://github.com/pkp/ojs/blob/main/schemas/galley.json#L46

I was with the impression that for fresh installs, urlPath would be totally split from publisher IDs. Only after upgrades that any pub-id::publisher-ids would be copied over to the urlPath, so existing URLs continue to work.

[NateWr]

Good catch @fgnievinski! This is out of date. Now the urlPath represents the URL. I've updated the description in the commits above.