[OJS] Evalute PIE-J best practice recommendations

[ctgraham]

NISO Presentation and Identification of E-Journals (PIE-J) provides best practice recommendations.

Some of these are relevant strictly to a publisher's implementation, but some are relevant to the journal publishing platform.

We should evaluate OJS's compliance with (or disagreement with) these recommendations that are platform related:

Retention of the original title and citation information is essential for users trying to access the original full text

• 2.1.1 Provide the full journal title in a prominent, clear, and consistent manner on every journal content page where it is possible to control the title presentation.
• 2.1.3 Associate articles, issues, volumes, and dates within the journal title under which they were originally published. Identify all content from a former title(s) under that journal title and not the current journal title.
• 2.1.4 Construct any "Cite as" feature to use the title, volume, issue, and date under which the content was originally published.
• 2.1.5 Ensure that all outputs by the publisher or provider use the journal title and other identifying citation information under which the content was originally published.

Users appreciate as full a journal title history as possible to show clear relationships such as previous or later titles

• 2.2.4 Provide a journal title history. Include the full journal title, publication date range, and ISSN for the current title and at last the immediately preceding and/or succeeding titles, as appropriate.

Accurate and complete presentation of the ISSN enables user access via linking services and facilitates library identification and management of e-journals

• 2.3.3 Show all ISSNs for a title and specify the format for each.

To preserve the history of a journal and the individuals who were involved in editing it, certain vital facts should always be included on the website and retained over time so that content can be interpreted in context.

• 2.5.1 Provide an "About the Journal" or "Journal Information" page that covers vital identifying facts including: editors and editorial board members, ISSN, publisher names (and places), sponsoring or responsible bodies, scope and purpose, publication frequencies, publication or copyright dates, masthead information, errata and retraction policies, and, if applicable, other pertinent information such as ethics guidelines and peer review status. Ensure that this information is retained for volumes over time.
• 2.5.2 Indicate clearly on a journal's website that a journal title history exists and provide appropriate links.

[asmecher]

@stranack and @NateWr -- very relevant for our OJS3.x front-end work.

[NateWr]

Sorry, I think I'll need more context. I don't really understand any of the specifications as written.

[ctgraham]

I would hesitate to call these specifications; rather, these are the recommendations from the NISO PIE-J standing committee, and are deliberately framed without particular technical implementation specification.

That said, Appendix A in the recommendation might be helpful for example-driven context.

In my mind, our core questions are:

• Are we providing a structure where journal content can be related to the original titles and ISSNs as title changes happen over time? (I think the answer is "no".)
• Are we providing a framework where journal managers can record and expose such title changes in a structured way? (I think the answer is "no".)
• Are we providing a framework where journal managers can record editorial board changes over time? (I think the answer is "not really"; we've instead opted for unstructured editorial lists)
• Are we providing a structure for recording what PIE-J refers to as "vital identifying facts"? (I think we've deliberately moved away from structuring many of these.)
• And ultimately, how should these recommendations shape our development?

[NateWr]

For title changes, I think the versioning feature will go a long way towards this. There's a lot to consider, but I'd like to see us work towards always-on versioning by default.

I'd like to see us continue to stay away from engineering specific data input for every piece of recommended data. I think if we added revision history to custom pages, and outlined the recommended data set in our editor-facing documentation, we could bridge the goals of supporting these recommendations while keeping the platform leaner and more flexible.

[ctgraham]

Isn't versioning targeted at the article level? These recommendations aim at the change of Journal Title and ISSN over time. For example, "The Journal of Horseless Carriages" becomes "The Journal of Automotive Technology" becomes "The Journal of Point-to-Point Transportation"; each title change results in one or more new ISSNs (depending on physical vs. electronic distribution).

[ctgraham]

We don't want to dive into a-field-for-everything hell, but it is equally problematic to have an industry best practice which enumerates "vital" elements, which we then leave up to the publisher to include in one large freetext field.... at least until we can have them enter it all in some semantically meaningful form.

[ajnyga]

Big thumbs up for supporting journal name history.

Ideally the old names/ISSNs should be available in metadata exports, I mean for example OAI-PMH, and maybe also in journal archive listings etc. One way of dealing with this would be to have a timestamp (startDate, endDate) based list of old names and perhaps a $journal->getHistoricName() function to fetch the journal name based on the issue publish date.

[ctgraham]

Comments from the PIE-J Standing Committee:

The PIE-J Standing Committee met and discussed the PIE-J related issue you asked about. We appreciate your reaching out to us in order to better understand and implement PIE-J. Here are our comments/suggestions regarding the conversation string on github:

• The Standing Committee agrees that you have identified the PIE-J recommendations that are most relevant to platform infrastructure
• We recommend OJS tell publishers it is better if they create separate pages for each former journal title, rather than relying on a versioning feature. We agree with the comment by ctgraham that versioning is targeted at the article level, not the journal level. We are not sure how the versioning feature affects public display, but we suspect that this is not the best way to handle former titles. A new title is not a new version of the old title.
• Most important is that for all article-level content, the journal title and ISSN as originally assigned must be apparent on the website. We feel the best, easiest, simplest way to do this is to have separate pages for each new title (with new ISSN).

I hope these comments are helpful. Please feel free to reach out again if we can help in any way.

[ajnyga]

I have to say I find the answer a bit problematic. I agree that it is a clear solution, but the journals that have this situation do want to have a continuing archive of their articles in one place. If that archive is split to several individual journals, it is hard to find.

I still support my suggested model above. It would enable to automatically create a journal "history page" which would explain the title changes and it would be easy to call the suggested function when showing the archive.

The situation where I would support creating several journals is when two independent journals have been combined. For example "Journal of skates" and "Journal of sticks" become the "Journal of ice hockey". I know a few cases at least in Finland.

[ctgraham]

My take is that the standing committee's recommendation to "create separate pages for each former journal title" is stuck in a mindset of static site management. It shouldn't be necessary for a journal manager to create static pages within OJS for each journal title, nor should the journal be split across multiple OJS journals to reflect the journal history. I also support building out journal history support within OJS, and the PIE-J recommendations give us good guidelines of what items should be important in recording that journal history (their "vital identifying facts").

[heike-r]

Nice to know this topic is already in discussion. To give you some input from the user (journal manager) perspective:

• We would welcome the possibility to keep the complete history of a journal 'under one roof'. It reflects the rich history some journals have. Our current OJS installation shows three times as many journals as we actually have, since we needed to set up a new journal every time one changed its name. It looks a bit overcrowded.
• Versioning as I understand it would not be a solution since, as the PIE-J Standing Committee pointed out, a new title is not a version of an old title. The old title is not changed, just discontinued.
• As a journal manager, I would not mind entering the historic data as a separate journal. It is not much work, I am familiar with the process and I am not doing it very often. But I want an option like 'add as subset to journal x' so the reader does not see it as separate journal. The compilation of the archive could go by publication date. The journal history displayed to the reader also does not necessarily have to show all historic meta data (ISSN, editor, publisher, ...), but they have to be searchable.

[ajnyga]

Hi @ctgraham,

One of our journals with 6 past names is asking about this feature. Do you have any plans to work on this in the near future?

[ctgraham]

Hi, @ajnyga . Pitt doesn't have specific plans for scheduling this work at present. I think the first step here is getting consensus on the PIE-J recommendations and then identifying if agreed-upon changes should be prioritized and staged, or if they should be implemented in one single release.

[ajnyga]

hi @ctgraham

Returning to this fairly old (but very important) issue.

I think the issue is very much connected to article versioning, but it is not probably considered there at least yet. However, I have a suggestion that would be a fairly easy way of fixing the problem with changing journal metadata (from the versioning thread):

What we could do actually is to add the journal name, ISSN and publisher name to the article metadata (submission_settings table). So that when you publish an article, you can fill those fields for all individual articles as well. And for new articles those could also be automatically filled based on the journal settings when the article is first published. This would solve the problem with back issues with different names and would enable OJS journals to change their names, ISSNs and publisher names > the article metadata in old articles would not be affected in any way.

What do you think? It will make metadata db table a bit larger, but gives a lot of flexibility. The current situation where the metadata does not reflect the changes in Journal names at all is very bad and should be high priority to fix imho.

[ctgraham]

Rather than replicate the journal name, ISSN, and publisher information into the article metadata as individual fields, it would be better to track on the name changes in an independent table, and then have the submission table link via foreign key to the row in the other table. I think the "big picture" of PIE-J is the assertion that this kind of publication history is important enough to have its own data representation.

That said, I concur that prioritization is needed here. Perhaps the next step is to schedule this against a specific release.

[ajnyga]

Sure, that is the other option. You could basically call for example $journal->getName() with a timestamp. With $journal->getName() you would get the current name and with $journal->getName('1980-02-02') you would get a name stored within that specific time frame.

[asmecher]

We currently stamp copyright and license information from the journal settings onto the article settings at the time the publishing action takes place; perhaps an approach like that could be useful? We would definitely need a mechanism to reset or modify these stamps -- there is a "reset" button for licensing information, but I suspect broadening the use of this kind of stamping would prove the current mechanism inadequate.

[ajnyga]

Yes, that is basically the other option I mentioned above. It is probably faster and maybe even more flexible, but @ctgraham preferred the other one.

Maybe we need more opinions on this: @jmacgreg, @NateWr, @stranack?

• Option 1: Journal name, ISSN and publisher name history stored in separate database table together with timespans that define when for example a specific name was used. This data is checked when showing article metadata (use article publish date to fetch for example the correct name). We can also easily list the journal name history on a separate public page (see 2.2.4 in the original issue).
• Option 2: Journal name, ISSN and publisher name are saved to submission_settings as article metadata. This needs to be supported in import/export functions, quicksubmit and the article metadata form. For new articles the fields are prefilled based on journal settings. Possibility to reset data.
• Option 3: both. We have a separate db table that saves the namey history, but we also stamp the metadata to submission_settings as article metadata. This would enable us to have a more eloquent way of resetting the data that you could use also with copyright and license information that also tends to have a "history".

Schedule: 3.2 is coming way too fast for this and in any case this involves work with settings forms which are currently under construction. So maybe we could target something like 3.2.1?

I am happy to work on this. This comes up constantly when I talk with library people, but also happy to hand this over to someone else.

[NateWr]

There is strong demand for tracking the history of changes to journal name, ISSN, publisher, and editorial team. I think we should add to that copyright notice and section policies. No doubt there are more I'm missing.

So, yes, I think we need a facility for storing past data that goes beyond stamping the published article with these details.

It will also be needed beyond just the journal_settings table. Extending our table pattern to object, object_settings and object_history might do the trick, as long as we don't produce any name collisions between object columns and object_settings. Alternatively, we could add a column updated, to object_settings tables, which stamped the date and was part of the primary ID. Or maybe the versioning work is a good basis for this. I'd leave those details to someone who has a better understanding of the performance trade-offs they would entail when pulling up the correct details for an article published on YYYY-MM-DD.

Either way, we can build history tracking in at a low level with the (new) SchemaDAO and define which properties of an object should track history in the schema.

[lpanebr]

I agree with @ctgraham that

[...] it would be better to track on the name changes in an independent table, [...]

The current stamping strategy mentioned by @asmecher makes retrieving the information easy but creates the problem (he also described) of updating things afterwards..

An important concept touched by @NateWr is that the need for tracking history goes much deeper, as the PIE-J recommendations aim to enable "content to be interpreted in context":

Source: https://groups.niso.org/apps/group_public/download.php/10368/rp-16-2013_pie-j.pdf

With this in mind one might start to realize the truth (there is no spoon*), that the solution is versioning every first-level Entity like articles, pages etc.

By taking this approach the system could always show the current version and each version would always have a stamped pointer to the independent table record related to that point in time. Stamping this is important so that Users are allowed to create back content correctly linked to their history.

* sorry I could't stop myself from throwing that Matrix pun: https://www.youtube.com/watch?v=uAXtO5dMqEI

[gerwinC]

It is nice to see that work is being done on the problem area of "journal title changes" and "complex history of a journal". We have several natural history journals for which this is important. Two aspects that may not have been discussed yet are the following:
(a) Sometimes a change of title was accompanied by the beginning of a new count "Volume 1", and so on.
(b) Sometimes the journal main title did not change, but "New Series" was added and the count began again with "Volume 1".
Hopefully (a) and (b) do not collide with the fact that names of issues must be unique.

[ctgraham]

@gerwinC , can you give an example of what you mean by:

the journal main title did not change, but "New Series" was added

?

I'm trying to picture how the "New Series" would be represented in the journal's metadata / citations / etc.

[gerwinC]

@ctgraham … here are some journals illustrating the New Series phenomenon. These examples are from the Biodiversity Heritage Library just because journals can be viewed quite easily there. (Our own OJS journals showing similar kinds of phenomena are not available online yet.)

In the BHL frontend, use the volumes pulldown (above the main frame) to see list of published volumes and their counting modes. The following examples are 19th century only, because this is BHL's main focus. Many examples from the 20th century do exist, but these normally cannot be viewed as easily.

https://www.biodiversitylibrary.org/item/23248
Annales de la Société Linnéenne de Lyon.
Volumes up to 1852 were identified by year only. Vol. „1“ of New Series ("Nouvelle Série") beginning 1853.

https://www.biodiversitylibrary.org/item/42347
Zeitschrift fur Allgemeine Erdkunde
First six volumes were numbered 1 through 6, then new series (in German „Neue Folge“) started with N.S. vol. 1 (1856).

https://www.biodiversitylibrary.org/item/20041
Annals of Philosophy
After 16 volumes, a New Series was started with vol. 1 (1821); in this example, the subtitle of the journal was abandoned while the main title remained unchanged (which can be regarded an irrelevant change).

[ajnyga]

This issue surfaced again in one of our journals. @ctgraham do you think we could meet maybe together with @NateWr and @asmecher and decide how to implement this to OJS?

Crossref needs to be contacted, because I think they are linking the journal name to an ISSN and that could create problems when registerin DOIs for backissues.

[mfelczak]

Adding @AhemNason and @ewhanson since they may have some additional input re: Crossref requirements here.

[ajnyga]

Seems that a journal title change should require a new ISSN: https://www.issn.org/understanding-the-issn/assignment-rules/issn-the-major-principles/. So the problem I mention above with Crossref should not be there.

Why do I have a feeling that this is probably not enforced always?

[heike-r]

From an editors point of view: theoretically, a title change requires a new ISSN. However, a journal would be disconnected from its entire history in indexing databases such as Web of Science or Scopus. It would start out as a 'new' journal or might even require a new application to be indexed and thus have no impact factor or metrics like it. A huge disadvantage any editor will try to avoid.

[ajnyga]

If de facto a lot of journals are changing their names without changing the ISSN, then this needs to solved with Crossref (and maybe others) first. Otherwise we end up with a code that attaches a historic journal name to the current ISSN and Crossre API will throw an error because they can not match the ISSN and the name.

I am not sure how they have arranged this. I mean, it could be that they can store multiple variants of the name to the db. But in this case, how to get those variants to the crossref db is unknown to me.

[lpanebr]

@ajnyga is right that title changes SHOULD require a new ISSN. There are, however, some situations prescribed in the ISSN manual that allow for title changes without changing the ISSN, as seen in section 2.4 below:

As a service provider for journal I can say that I have seen this happen a number of times.
I can also say that in the recent past (1 year) this seems to be no longer easy to achieve as I have witnessed denied requests for title changes without a change in the ISSN.

Despite that, the fact remains that there are journals that have changed their title without changing their ISSN. It's only logic to assume that this might happen again.

As for crossref throwing errors for title-issn pair differences, while it happens it is easily fixed just by editing the current journal title in the publisher-crossref database.
Furthermore, I have evidence that crossref does allow the different titles for the same ISSN as shown below for a journal that has changed title many years ago:



source: https://api.crossref.org/v1/works/10.1590/s0101-20612006000100002

source: https://api.crossref.org/v1/works/10.1590/fst.28219

With this, it is my understanding that crossref does not validate title-issn with the ISSN database, delegating that responsibility to the publishers themselves. Which IMO is the right call.
The indexing databases mentioned by @heike-r also do not validate this, as the above mentioned journal was and still is indexed in WoS, Scopus and Scielo.

In conclusion, I believe that OJS should not impose restrictions nor try to take upon itself to check and/or enforce journal's title-issn validation. It should just instead allow journal owners to create new title instances in the journal database with whatever associated title metadata they wish (title, ISSNs etc.). ONE restriction that I believe MUST be implemented is to flag which of the registered title instances is the active journal*, and use that for new submissions, while allowing backlog articles to be inserted using whichever title instance is needed. Then, journals would be able to host as many journal title changes as they NEED in their OJS installation, thus fulfilling the PIE-J recommendation to preserve ARTICLE's information in lieu of the publishing journal history.

[gerwinC]

The recent contributions to the discussion were very interesting for me. An important point that seems unresolved to me in the last discussed approach with additional title instances is what ajnyga remarked earlier (26 May 2017): "...the journals that have this situation do want to have a continuing archive of their articles in one place. If that archive is split to several individual journals, it is hard to find."

[AhemNason]

Hey everyone, at risk of opening a sarcophagus here, I wanted to add an example of where we continue to see an issue here.

Hosting just had a journal change its name and file path. They got a new ISSN. I needed to update all their DOIs with the new URLs. But because the metadata in those DOIs is determined (always) by the current title-level metadata, I had to:

1. update the filepath to the new one
2. put all the old title and issn information into the journal settings
3. deposit/update all the backissue DOIs so the new URLs would update
4. put the new title and issn information back in
5. deposit/update their most recent issue with the new metadata

I do understand we're at tension here where we want users to have control and be able to make corrections, but title and issn are key metadata and they should be locked into the record on publication the way licenses are. At the very least, title level metadata should be attached to the article record on publication and not tied to current journal settings.

I know we've talked a lot about storing "journal history" and the likelihood of that being useful, but in this case, I do think it's important.

[AhemNason]

Just a note here for @ewhanson who is writing "is this metadata stale" code into the DOI plugin. We definitely don't want users who changed their journal name or ISSN being prompted to update as a result.

[ajnyga]

In brief none of the metadata shown for an article for example in OAI-PMH should ever come from an OJS setting directly.

[NateWr]

Hi everyone, this issue has drifted from its original remit (PIE-J best practices) and come to focus primarily on the problem of how to reflect historical changes in journal-level metadata in article metadata. That's a problem worthy of its own issue as it will require some detailed discussions and specifications.

Bonus points for anyone who is willing to file a new issue with a detailed description of the problem and initial specifications that address the following:

1. What precise pieces of metadata need to be tracked at the article level which are not being tracked now? (ie - journal title and ISSN, what else?)
2. For each piece of metadata, when should this data be "stamped" in the article?
3. When this "stamped" data needs to be changed (due to a mistake or any other reason), should it require a special operation (like creating a new version) or can any editor edit it whenever they want?
4. How will the system know when changes to stamped metadata are made, so that it can redistributed or resync metadata with third-parties?
5. How will a journal recover from a history of bad data? (ie - when a journal has already published lots of articles with the wrong title or ISSN)

[NateWr]

@AhemNason has filed an issue about journal-level metadata. Please read and comment on the issue below to help us refine and scope the necessary work:

#7527

[NateWr]

Thanks for the discussion, everyone. If there are any further improvements that should be made to align OJS with the PIE-J recommendations, please file a new issue for each improvement.

[fgnievinski]

If de facto a lot of journals are changing their names without changing the ISSN, then this needs to solved with Crossref (and maybe others) first. Otherwise we end up with a code that attaches a historic journal name to the current ISSN and Crossre API will throw an error because they can not match the ISSN and the name.

I am not sure how they have arranged this. I mean, it could be that they can store multiple variants of the name to the db. But in this case, how to get those variants to the crossref db is unknown to me.

here are some answers from the Crossref forum:

We don’t import data from the ISSN Portal directly, nor do we send data to them. The way a journal’s title is reflected in Crossref’s systems is entirely dependent on how that journal’s publisher/registrant sends it to us in the metadata deposits used to register their DOIs.

When you first deposit metadata for a given journal, the journal-level metadata - including the journal title, ISSN(s), journal-level DOI if you choose to register one - are used to form a title record for that journal in our system. That record is also ‘locked’ to the particular DOI prefix used in that first deposit as well.

We require that all future metadata deposits for that journal must contain journal-level metadata that matches the record established in our system by the first deposit. So, if you submit a journal title one way in the first deposit and then later switch to using a “parallel” or alternate title, the metadata deposit will fail with an error message that goes like ISSN "[ISSN]" has already been assigned, issn ([ISSN]) is assigned to another title ([title we have in our records])

Our documentation references the ISSN Centre’s policies because our system supports the principle that a substantive title change requires a new ISSN. But, that’s as far as we go with that.

If it turns out that you made a mistake in that first deposit, or you changed your title in a relatively minor way that doesn’t require a new ISSN, or you want to use an existing parallel title, we can modify the title record in our system for you. Just send us an email at support@crossref.org with the ISSN and new title before you submit the next metadata deposit for that journal.

(...)

... the schema allows up to 10 <full_title> tags within <journal_metadata>, so if you’re creating your own XML, you can choose to add additional titles, in other languages or as other variations, there. But whichever <full_title> comes first in the XML has to remain consistent from one deposit to the next.
(...)
The title list is basically a reflection of all the title records we have at a given time. The variants are the result of both the additional <full_title> elements that are submitted via xml, and any past titles that were submitted before a title was manually changed by us at the request of a member. They’re mainly used for the purposes of citation matching, along with the title abbreviations which are also submitted in the xml.

https://community.crossref.org/t/parallel-titles-for-a-given-issn/2183?

PS: I've added this information to the old issue to keep the new issue focused on the implementation; let me know if a separate issue should be created just about the about DOI registration for journal title changes.