Also, we are current moving our CODES for Thema, so how we can change this
12
2.1
BIC CODE HERE
For this
93
THEMA CODE HERE
How we can adjust it so we don’t need to manually edit the xml file but instead already export with the format/data we want?
version running OMP - 3.3.0.14
OS platform - Linux
PHP version - 7.4.33
Apache version - Apache
Database driver - mysql
Database server version = 5.5.68-MariaDB
Based on the tags you’ve noted it sounds like you’re using the ONIX export plugin for OMP.
A number of improvements have been made recently to the ONIX exports, one of which is the addition of a <Website> node which includes the correct download URL. This is available as of OMP 3.3.0-18.
We are having same issue exporting from OJS as well.
version running OJS - 3.3.0.16
OS platform - Linux
PHP version - 8.1.31
Apache version - Apache
Database driver - mysql
Database server version = 5.5.68-MariaDB
Hi @gkuhn, the <RecordReference> is meant to be used as an identifier for the record itself, and does not necessarily need to resolve to the object - in fact, this identifier will be changing soon to better align with ONIX best practices (see this related issue on GitHub). Is it being used as a URL by Scopus?
Whenever you next upgrade your OMP instance to the latest release of 3.3.0-x, you will now see a <Website> node in the XML that correctly identifies the object, and better aligns with the ONIX standard. Ideally this should also be used by downstream metadata services like Scopus to point to the object, and not the <RecordReference>.
Let me double-check what are the versions where the bugs and modifications will be available.
We are currently using 3.3.0.14. We have the plan to update to 3.4.x a soon as it gets long term support.
If meanwhile we update to 3.3.0.20, this changes/fixes be available there, right? (as well as if we wait for 3.4.x?)
Also, do you have an idea about the agenda of when this fix will be ready/available?
Thus we can schedule here as well to update when everything is ready.
The added <Website> node with the correct URL is available as soon as you update, in both the 3.3.0-20 release and our latest 3.4 release.
The new structure for the <RecordReference> will be in the next 3.4.0-x release.
I’m working on a fix for the <Language>, but it’s not yet available - hopefully in the next 3.3.0-x release. You can keep track of the progress on this issue by following the ticket I created (if you have a GitHub account and are logged in, you can follow along with an issue by clicking the “Subscribe” button, under “Notifications” on the right side of the page).