MCR-3320 publication date of host should be preferred in orcid export if present

[chemicus]

Link to jira.

[chemicus]

As a follow up to MCR-3319 I suggest, that mods:dateIssued[@keydate='yes'] always be preferred and that the dateIssued of a host is preferred over the dateIssued of an article. This is relevant especially for journal articles that have been published electronically and later be included in an issue. The relevant publication date in such cases should be the issue date rather than the date of the article.

[fluetze]

Using descendant::mods:relatedItem[@type='host'] may also catch unwanted paths we currently plan for use like
mods:relatedItem[@type='original']/mods:relatedItem[@type='host']
or other versions etc, depending on the order of related items in the mods:mods.

This order always prefers the dateIssued in the host.
I understand your point, but I think the date that is "closest" to the publication itself should be used, and that means prefering the mods:mods/mods:dateIssued if present.

Maybe this needs

• discussion
• more clarity on when the keyDate attribute must be used
• or a configurable path, which I think should be possible in xslv3

[chemicus]

I agree with the first recommendation and refined the xpath to exclude non-host-type relatedItems.

I still think that the host-date is more appropriate in most cases, but the fact, that there is discussion about this indicates that the selection of the appropriate publication date can not be done generically, hence it belongs into the application specific part (mcr2work.xsl) which is meant to be implemented individually by every application. We can of course implement a sane default in this file, or we could leave the template empty to enforce the individual implementation. I'm not sure, which is best?

[fluetze]

descendant::mods:relatedItem[@type='host'][not(ancestor::mods:relatedItem[not(@type='host')]
is hard to read, but is ok for me.

I still think the date "closest" to the publication level should win. What about defining the priority as follows:

• If there is a keyDate=yes in the publication, use that date
• Otherwise, if there is a keyDate=yes in the host, use that date
• Otherwise, use the dateIssued in the publication
• Otherwise, use the dateIssued in the host

I do not want to / can't decide this, what about other reviewers?

[chemicus]

I still think the date "closest" to the publication level should win. What about defining the priority as follows:

• If there is a keyDate=yes in the publication, use that date
• Otherwise, if there is a keyDate=yes in the host, use that date
• Otherwise, use the dateIssued in the publication
• Otherwise, use the dateIssued in the host

I don't really care about the default order, since now this can be configured by overwriting mcr2work.xsl (rather than mcr2work_generic.xsl). I have now changed the order accordingly.