Thank you for the FAQ regarding the country list. I appreciate the explanation about the reliance on ISO standards and the options for customization. However, we are hoping to understand more about the rationale behind the default inclusion of disputed entries and the long-term strategy for addressing these sensitivities within OJS, especially in light of PKP’s commitment to decolonization.
Moreover, we are also concerned about the potential negative downstream effects.
Impact on Upgrades: Do we need to revert the core sokil/php-isocodes library and then upgrade to 3.5?
Database Effects: What effect could manually changing the list have on the database, especially when upgrading the database?
Plugin Stability and Support: Regarding the customCountryList plugin, what is its current stability track record? Is it officially supported and maintained by PKP, or is it a community plugin with potentially varying levels of ongoing support and compatibility with future OJS versions?
OJS 3.5 Integration: Are there any plans to integrate this plugin into OJS 3.5?
Third-Party Side Effects: What are the potential side effects of this change on third-party systems that consume OJS metadata?
Disabling Country Selection: Is there a possibility or any discussion about simply disabling the option to choose a country?
In this case you are talking about renaming a label on a locale code, but the locale code itself wouldn’t change. Therefore downstream consumers of the data would not be affected. Likewise, the OJS database only stores the country codes, not the plain-text, so the database would not be affected.
If you opt to modify the software to accomplish your goals, as with any modification, you’d need to consider how to adapt those modifications when upgrading to a newer release.
The Custom Country List plugin is not in the Public Knowledge Project’s set of repositories – it’s in my personal github – so it is not maintained to the same level as “official” plugins. That said, it is a relatively simple plugin and my hope is that community support can help to keep it current. We do not have plans to integrate it into OJS.
There are many threads on the forum about what fields should be available, and which should be mandatory, and it is pretty much impossible to find a balance that works for everyone. Removing the country field from the user profile would likely deprive a lot of editors with useful information.
Regards,
Alec Smecher
Public Knowledge Project Team
Can you please elaborate this : “Users who customize the country list, particularly adding new entries or modifying the country codes, should be aware that there are possible negative downstream effects as the publication metadata gets sent to third party systems.”
Do you mean changing country list can cause issue with data sent to Orcid or Crossref or any other third party systems?
In this case you are talking about renaming a label on a locale code, but the locale code itself wouldn’t change. Therefore downstream consumers of the data would not be affected.
If you were adding a new country (and country code) outside of the standard, downstream consumers would not know what to do with it. But in this case you’re wanting to change the label for an existing country code, so there shouldn’t be any downstream concerns.
Regards,
Alec Smecher
Public Knowledge Project Team
can you provide specific examples of what the negative downstream effects would be (in case of new addition)? Would this have implications for ORCID, Crossref, and any other 3rd party harvesters/metadata integrations? Would a null value be returned by these sources or is it more serious (aka could they receive an error message when they went to extract data?
If you added an entirely new country to the country list, you would have to give it a country code (e.g. ca for Canada). For example, the code xx is reserved for unknown states, other entities or organizations. When that data is sent downstream to ORCiD, CrossRef, etc., typically associated with author data, the downstream consumer of that data would need to deal with potentially unexpected data. See this Wikipedia page, for example, which includes lots of codes that are not going to be 100% supported by all consumers. If you’re considering going that route, you’d need to confirm with the consumers of that data whether it’ll result in problems.
Regards,
Alec Smecher
Public Knowledge Project Team
As you mentioned, updating to “TAIWAN” should not have a negative downstream effect because the ‘TW’ country code will remain the same when sent to ORCID, Crossref, or other third-party sites. Is my understanding correct? Just would like to know more on this in case of Updating to Taiwan → Would this have implications for ORCID, Crossref, and any other 3rd party harvesters/metadata integrations? Would a null value be returned by these sources or is it more serious (aka could they receive an error message when they went to extract data?
Therefore, changing the country name shouldn’t affect our metadata or its consumers, as the ‘TW’ code is what’s transmitted to third parties.
for example, which includes lots of codes that are not going to be 100% supported by all consumers. If you’re considering going that route, you’d need to confirm with the consumers of that data whether it’ll result in problems. - However, in our case, we are only concerned with “TAIWAN” (‘TW’), and I assume this should be fine since this is supported.
In this case you are talking about renaming a label on a locale code, but the locale code itself wouldn’t change. Therefore downstream consumers of the data would not be affected.
…and…
If you were adding a new country (and country code) outside of the standard, downstream consumers would not know what to do with it. But in this case you’re wanting to change the label for an existing country code, so there shouldn’t be any downstream concerns.
Thanks,
Alec Smecher
Public Knowledge Project Team