Version page omits metadata

[diegoabadan]

When we register a DOI  of a preprint with Crossref, the link points to the address of the registered version  (e.g. https://preprints.scielo.org/index.php/scielo/preprint/view/2758/version/2914 ) instead of the preprint link typically displayed by OPS (eg, https://preprints.scielo.org/index.php/scielo/preprint/view/2758)

The problem is that this version-specific page doesn't display the metadata (eg, Dublin Core and pertaining to Google Scholar) in its source code.

What I expected: to see the metadata, at least when I'm in the current version.

Possible solution: when accessing the specific link of a version, this being the most recent version, redirect to the main address of the publication, as we are used to accessing it by browsing through OPS.

Alternatively, insert the metadata on the current version page.

My fear is that disclosing a publication address that does not have this metadata is harming indexing / visibility.

Tested on OPS 3.3.0-6, but probably occurs on OJS as well.

[NateWr]

@ajnyga do you remember any specific decisions made here? My sense is that the URL deposited to Crossref should be the landing page, without a version, but I think you'll know better than me on this.

[ajnyga]

OPS DOI plugin supports versioning according to the Crossref guidelines so the links point to a specific version: https://www.crossref.org/documentation/content-registration/content-types-intro/posted-content-includes-preprints/

We could probably change the code so that the link to the latest version would always be the shorter one /view/2758 but have to make sure that once new versions are added the plugin handles the update of the old version DOIs correctly.

Or, we could do what Diego suggests above and make sure that the latest version page also shows the metadata.

This should not be an OJS issue since there is no DOI versioning there.

[NateWr]

That's great, thanks @ajnyga. Yeah, so if that's correct (each deposit is for its own version), then we should add the metadata to the version page.

[diegoabadan]

Not all preprint servers adopt a DOI per version. Scielo, for example, adopts only one DOI per preprint, which must always point to the current version.

@alexxxmendonca maybe you wanted to complement or even correct me?

Since these two scenarios are common, it is perhaps important that OPS supports both.

[alexxxmendonca]

@diegoabadan you are right and I don't have anything else to add.

[ajnyga]

The OPS DOI plugin supports both cases. All depends on the suffix settings. If the suffix containts the version variable, then DOI versioning happens.

However, the Crossref DOI registration plugin presumes that preprint DOIs have versioning according to the Crossref posted content registration guide linked above:

Each version should be assigned a new DOI, and associate the versions via a relationship with type isVersionOf - learn more about structural metadata and declaring relationship types

It is simple enough to change how the Crossref plugin works, but I would like to hear from Crossref first before doing any changes.

[NateWr]

I'm struggling to understand our options here. @ajnyga can you write a short list of changes that we need to make or discuss requirements with Crosssref? As far as I can tell, there are three issues: whether or not to show metadata on article landing pages, where a DOI should link to when a single DOI is used for all versions, and how to handle DOIs-per-version.

[ajnyga]

First of all we need to check from Crossref if they do accept single DOIs for all versions of a preprint. Their website states that they do not, but maybe they have a different policy after all.

If we choose to add metadata to all versions then we need to know how for example Google Scholar will handle this. Do they expect metadata for all versions or only for the latest version.

I am inclined to think that a solution where we always show metadata for the latest version is the best approach and would probably cover most cases and would seem logical for services like google. We could make sure that in the Crossref plugin the registered url for the latest version is not the direct link to the latest version, but to the main landing page.

[NateWr]

We could make sure that in the Crossref plugin the registered url for the latest version is not the direct link to the latest version, but to the main landing page.

I think that this would probably be the opposite of what is expected for any preprint server using a separate DOI for each version.

Maybe it would be enough to add the appropriate version metadata to each version's page. When a new version is created, will the Crossref plugin automatically update the DOI metadata with the new version URL?

[ajnyga]

I think that this would probably be the opposite of what is expected for any preprint server using a separate DOI for each version.

This should not be a problem. Let's say we have three versions published. DOI1 is pointing to version 1, DOI2 is pointing to version 2 and DOI3 is pointing to the main landing page which shows version 3. We still have three distinct DOIs pointing to three distinct url's. If a fourth version is created then we have DOI4 pointing to the main landing page and DOI3 starts to point directly to version 3 url.

[NateWr]

If a fourth version is created then we have DOI4 pointing to the main landing page and DOI3 starts to point directly to version 3 url.

I guess the question is when and how is this information updated with the DOI agency? With each new version, we deposit a new DOI with new metadata. But my understanding is that we do not go back and modify the metadata of existing DOIs. Are you proposing that all DOIs are redeposited with every new version? Or is this already done?

[ajnyga]

It is updated when DOI4 is registered. The plugin will reregister DOIs for all publications within a submission. DOI1 and DOI2 will stay the same, but DOI3 will receive and update on the url it is pointing to. The registered DOIs are then tied together with isVersionOf relations.

An example XML with three versions for the same preprint was checked and accepted by Crossref back in Feb 2020, but we can of course discuss again, using an example outputs, if what we suggest would work for them.

[ajnyga]

See https://github.com/pkp/crossref-ops/blob/main/filter/PreprintCrossrefXmlFilter.inc.php#L67-L79

[NateWr]

That's great. If it already works that way, then that's the best solution, IMO.

[ajnyga]

Ok, I will edit the code and prepare two XML outputs for Crossref. Output 1 with three versions and then output 2 with four versions and they can check if it works like they think it should.

This means that when the DOI of the latest version will point to the main url in OJS and it will display the Google Scholar meta as it should. This will not fix the GS output for other version pages though.

[ajnyga]

OPS: pkp/crossref-ops#9

I noticed that the current OPS DOI plugin probably does not support versioning anymore. This is something that Crossref asks in their documentation and it was supported in the old OPS DOI plugin.

The Crossref plugin for OPS supports the versioning of DOIs and now with these changes the URL for the current publication DOI is the default landing page URL which should resolve the problem here.

I also edited the plugin so that if versioning of DOIs is not enabled, meaning that all versions have the same DOI, then the plugin will only register the current version / publication. BUT, as mentioned above, this is not the way Crossref asks preprint servers to work with preprint DOIs.

[alexxxmendonca]

This is something that Crossref asks in their documentation and it was supported in the old OPS DOI plugin.

BUT, as mentioned above, this is not the way Crossref asks preprint servers to work with preprint DOIs.

The Crossref Preprint Advisory Group (for which I'm part of) is re-discussing that, actually.

This is taken from the most recent meeting notes:

Crossref should not mandate an approach to versioning: one DOI for all versions vs one DOI for each version. Both have advantages and disadvantages, and metadata capturing versions needs to be applicable to both cases.

So we might see an update in their recommendations sometime soon.

[ajnyga]

ok, good to know. This work should support both cases now.

(that is in the Crossref plugin, the DOI code in current OPS main branch does not have versioning)