Citation Language Style plugin bug: Issue year should have precedence over article publication year

OJS 3.1.x or 3.2.x

@asmecher , @NateWr

As an “old-fashioned” scientific librarian and former scientist, I have learned and am still of the opinion that the year in a citation is always the publication year of the volume/issue, if the journal is packaged into issues (if not, then it is the publication year of the article).

In this sense, the code in CitationStyleLanguagePlugin.inc.php (lines 355-365 for the stable_3_1_2 branch and lines 357-374 for the master branch) has the wrong logic - it should be the other way round: Issue publication year should get precedence over the article publication year.

We have a case of journal that created an issue in 2019 (correctly as planned), but added articles in early 2020. The citation by the CSL plugins shows 2020 as publication year, but it should be 2019. They don’t want to re-date the publication date of the articles to 2019.

There is not a way to submit an issue in GitHub - pkp/citationStyleLanguage: An OJS 3 plugin to generate an article citation in any CSL citation style using citeproc-php. , that’s why I posted here.

1 Like

Hi @mpbraendle,

I don’t agree but I’m hoping to hearing more opinions from our community. In most cases the publication date of an article is set automatically when an issue is published. The editor can override this date with their own, but we generally discourage this practice except in cases where continuous publishing is done. In those cases, the article publishing date is the more relevant.

I think this is where the problem is. If the article was published in 2020 and you want to indicate that this was the published date, then it’s my view that the date in the citation and the metadata should match. I checked the CSL specifications and it is not clear on this point:

issued
date the item was issued/published

But my reading of this is that the intention is to indicate when it was published. See https://docs.citationstyles.org/en/stable/specification.html#date-variables.

Yes, but if a journal has volumes/issues, the item is the issue, not the article. Citations then reference the publication year of the issue, not the article. This is general practice.

1 Like

It’s mostly about findability: If one doesn’t have a DOI, one has to go the general way: Find the journal first, then go to year, then volume, then issue, then page or article title. Year must match with volume/issue - otherwise, there is a mistake in the citation. That’s the established way of locating articles over decades, if not centuries.

I know even of journals that have issues that span several years. The citation then contains ({yearstart}-{yearend}), not the year of when the article was published. This I know because we had established a library system module already in 2000 with which we tracked more than 2000 e-journals and 100’000s of issues over the years.

I have modified the CSL plugin now for our needs.

There is an additional setting in the Plugin Settings that allows to choose whether issue metadata or article publication date shall have precedence.
This supports backcompatibility of the original algorithm.
Code: In the case of precedence of issue metadata, issued->date-parts instead of issued->raw must be used to pass to the CSL processor. This is more flexible, since it doesn’t require the month and day in the date.

If there is interest, I can share the code. There are en_US, de_DE, fr_FR and it_IT locales for the extended settings, others must be added.

3 Likes

Hi @mpbraendle,
I couldn’t find time to add my opinion until today and I am very happy to see that you modified the plugin: I am interested in your code since I am looking for a similar solution.

Hi @NateWr,
In Italy the citation year is important for scientific evaluation and accounting, and the correct year is always the one declared by the issue. The typical case where this is different from the actual publication year are a couple:

  • for online first (eg: article published in 2020 but formally issued in 2021)
  • for late publications (eg: it can be frequent to see an issue from 2020 being actually published in 2021)

@mpbraendle

Please can you share your code with me

It’s a little difficult - as I see on Github, PKP’s code base already moved further, while my code is based on the 3.3 branch. I will see what I can do.

@Pieter_Rall @piero_tasso

These would be my changes for the 3.3.0 branch (in addition, I added the WU H&M wirtschaftsuniversitat-wien-handel-und-marketing , which was a requirement by one of our journals):

Locales were only updated for en_US, de_DE, fr_FR, it_IT

@NateWr, @asmecher Can you do something with this? Please inspect the changes and tell me if they are worth a pull request.

2 Likes

Hi all,

Is there a downside to just ensuring that the article publication date is accurate, rather than adding a new option and conditional code to cause the behaviour to be ambiguous? If you’re following a normal OJS workflow, the article publication date should be set at the time the issue is published, thus the two should normally be the same. Maybe there’s a use of the workflow here that’s unexpectedly setting the article publication date differently?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

My problem is when issues run late or when articles are published online early. The automatic publication date is the accurate date, changing the date would be making it inaccurate. Changing the publication date of articles that were published online early is wrong and would show that someone’s article was published a year later than it actually was. Are there other ways to handle early and late publications without manipulating the real publication date?

Hopefully, in the future, online journals will drop the idea of having volumes and issues as they don’t seem to be very useful anymore.

Best Regards
Pieter Rall

I can confirm what Pieter said - sometimes journals have a planned schedule for volume and issue numbering for a given year - if the issue runs late because of a late article, it may be published early next year, but have the metadata of the previous year.

Citation practice referencing journal issues is still coming from the long-established (several centuries) print system, and I’m afraid that this will stay for a long while even when the e-era opens up new possibilities. Being myself in an Editorial Board of a scientific society journal, I observe that we are still in the thinking of “issues” (mostly because a print version is produced monthly and there is a very tight schedule because of the printer, delivery etc.). There were discussions of having a more blog-like publishing of some content, but as long this journal is not e-only, that will be difficult and require a change of organisation. Out of around a dozen journals that are on the OJS platform of our university, only two have a sequential publishing of articles not bound to issues.

Hi all,

In my opinion OJS needs to provide unambiguous data to the citeproc-php library it uses to generate citations, and it’s up to citeproc-php and the CSL files to format a citation from there. Adding a setting at the journal level to have OJS give it data in different modes is not something I’d add to the distribution; it assumes that a consistent decision can be made at the journal level, and opens the door to lots of fine-grained work-arounds that become very difficult to maintain (and grow the settings UIs unmanageably).

I’d suggest looking to resolve this at the citeproc-php/CSL level. There are related discussions e.g. here (thanks @ewhanson):

…and there are several kinds of dates that can be provided to the CSL templates already:

https://docs.citationstyles.org/en/stable/specification.html#date-variables

Note in particular available-date vs. issued vs. original-date. Currently the Citation Style Language for OJS.

Currently the latest revision’s publication date is provided to the issued CSL variable, and the first revision’s publication date is provided to original-date. The available-date variable is not currently provided to citeproc-php.

Maybe we could find a good general-purpose proposal for the use of the CSL date variables, and any deviations from that could be managed by adjusting the CSL templates? (I haven’t checked the major CSL formats’ use of these various date fields, but that would be informative too.)

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like