search

elifesciences / elife-crossref-feed

code to support uploading info to crossref on PAW articles
1 stars 1 forks source link

Stop publishing Component DOIs #140

Closed Melissa37 closed 4 years ago

Melissa37 commented 5 years ago

See https://github.com/elifesciences/XML-mapping/issues/87

gnott commented 5 years ago

I think in issue https://github.com/elifesciences/XML-mapping/issues/87, we had some discussion about not publishing component DOI.

The decision (I think) was it is ok to continue publishing them if they are in the XML file. In that case, there is no code change to do, they will just be omitted from the Crossref deposit when no longer present in the XML.

If you prefer to stop publishing them completely, even if they are present, then we could consider adding a new value to the config file whether to deposit components or not.

@Melissa37 do you have any additional thoughts about the component DOI values at Crossref?

Melissa37 commented 5 years ago

The decision (I think) was it is ok to continue publishing them if they are in the XML file. In that case, there is no code change to do, they will just be omitted from the Crossref deposit when no longer present in the XML.

That is fine by me and the most sensible approach. But I think a code change will be required as the decision letter and author response will look like they still have component DOIs but they will now be proper DOIs. Their suffix will be different, so that could be the hook to differentiate them? Does that make sense?

However, as we want the Crossref tool to be extensible to other publishers who might use component DOIs, I wonder whether as an initial step we could just change the code so if there is a DOI in a <sub-article> <front-stub> this is not treated like a component DOI but like a main DOI that is a peer review materials DOI? This is not fool proof for other publishers, but will allow eLife to recognise our new peer review material DOIs and allow other publishers using the code to publish component DOIs in the main article xml.

WDYT?

M

gnott commented 5 years ago

I was not thinking that far ahead. Please do you have an example of what a non-component-doi for the sub-articles would be?

I cannot remember the difference between a component DOI and a regular DOI, except that a component is associated with an article or the parent DOI. They all work the same - unique, and redirect to a URL. You probably know more about why a "real" DOI would be applicable to a peer-review that is included in the article XML itself, and why it can not / should not be a component DOI?

Melissa37 commented 5 years ago

I was not thinking that far ahead. Please do you have an example of what a non-component-doi for the sub-articles would be?

From looking at the tagging in the XML you cannot tell the difference between a component and a full/normal DOI.

eLife will have a different suffix that you can use to determine it's a peer review materials DOI and it will be in the sub-articles...

".DL" and ".AR" (instead of ".001" etc)

gnott commented 5 years ago

Thanks @Melissa37! I think it might be better for us to add some configuration options about whether to deposit component DOIs, and/or to specify which components to deposit as having component DOIs. Ultimately, eLife will migrate to not depositing any component DOIs, or at least we exclude <sub-article> component DOIs from being deposited.

Melissa37 commented 5 years ago

Sure, shall we talk about the configuration on our call today?

M

Melissa37 commented 5 years ago

This is waiting on @thewilkybarkid to remove the dependency of Digest having component DOI. Once that's done we can close this ticket (this week hopefully!)

gnott commented 5 years ago

@Melissa37, when the component DOIs are removed, do the peer review DOI formats also change at that time?

I am wondering about when to deploy the change (in https://github.com/elifesciences/elife-crossref-xml-generation/pull/74) where decision letter and author response component DOIs are no longer deposited as components.

Must the deployment of that change be timed with the XML switch over, or is it ok to deploy it any time now?

thewilkybarkid commented 5 years ago

Unassigned myself as https://github.com/elifesciences/api-raml/pull/239 is done, it just needs implementing.

Melissa37 commented 5 years ago

@thewilkybarkid is this waiting for @giorgiosironi to come back before it is merged/implemented?

thewilkybarkid commented 5 years ago

Either @lsh-0 or @gnott to implement the change (not sure where the change needed is; it'll then be back to me).

gnott commented 5 years ago

I would like to nominate @lsh-0 to take a look please. I think lax needs to support v3 articles, and then the absence of a component DOI will be valid.

lsh-0 commented 5 years ago

(forgot to reply) cheers, @gnott , implementation details are happening in this ticket: https://github.com/elifesciences/issues/issues/5019

Melissa37 commented 5 years ago

@gnott I'll leave this with me until Exeter have implemented it.

@FAtherden-eLife can you update the kitchen sink: no component DOIs DL/AR DOI change and file naming changes of sub-article assets.

fred-atherden commented 5 years ago

@Melissa37, PR - https://github.com/elifesciences/XML-mapping/pull/96

Melissa37 commented 5 years ago

@gnott Exeter plan to put this live on Monday 18th Nov

gnott commented 5 years ago

Thanks for the note @Melissa37, it is good timing.

My memory and assessment of this issue is the removal of component DOIs will not break anything. they will currently be deposited as component DOIs, but we are in a position to start depositing the ones on peer reviews as peer reviews in the next week or so.

Those that were originally deposited as component DOIs are switched over to peer review assets at Crossref when we redeposit the peer review metadata.

Melissa37 commented 4 years ago

I think this is done and can be closed now @gnott ?

gnott commented 4 years ago

Yes indeed, can be closed because it is done as of 12 days ago. I will close it now, thanks @Melissa37.