I need help, we are using OJS as editorial management and publish articles on other external website.
When we try to export crossref xml we are not getting iparadigms valur and also we had given external pdf link in Galley, but still in XML it shows OJS article link, Can any one please help. OJS version 3.1.2.
Attached image of exported xml from plugin, it looks like Galleys is fetching empty.
Is any one can help me out on this topic, please.
I have also a problem in registering the content in crossRef.
Are you referencing the external website URLs as remote galleys within OJS? If OJS is not actually publishing the content, I don’t think you want to use the OJS plugin to register the articles within Crossref. Using remote galley links might be plausible, but I would be skeptical of whether this would work as you might want it to.
Is your problem related to this thread (registering articles published in another system)? If not, please share more details with us in a new thread.
Thanks for your reply.
Yes we are using remote galley link in OJS and like to generate crossref file with remote galley link.
For Example below is remote galley link, we had updated in OJS:-
Below file generated by Crossref Plugin:
Below file we had updated manually in crossref file: (We are looking for below file to be generated using CrossRef Plugin):
I think the core problem here will be the first instance of the
resource, which in the OJS example ends in “…/article/view/6”. This represents the article’s landing page, with the title, authors, abstract, etc. Since OJS is not publishing the content, OJS doesn’t know anything about what this would be.
We could modify the code such that the collection item resource points each remote galley, but this raises several questions regarding what to do about that first resource link.
- Would it be acceptable to CrossRef if this pointed directly to the PDF rather than to an article landing page? I don’t see anything in schema 4.4.2, but there might be other conventions to consider.
- Should OJS ask for a remote article landing page URL, if not being used to publish the content?
- Or, should this be the responsibility of the publishing system, and not of OJS?
- Should OJS just use the remote galley URL across the board, as you have done in your example?
- But what should be done if there are multiple remote galleys listed?
I think this is an interesting and plausible use-case, so I’ll try to invite some other’s perspectives on this.
@bozana, @vgabler, @AhemNason
Most publishers register the DOI at the item (article) level and not the galley level. Selecting the item/article level will use the URL for the Abstract landing page, which is appropriate for most publishers. The intention is for the DOI to be assigned to the complete article record with all associated files. In OJS 2 it is possible to register DOIs at the issue, item, galley, and supplemental article levels. In OJS 3 you can select to assign DOIs at the Issue, Articles, and Galley levels. You can configure these settings in Setup 4.3 for OJS 2 or DOI Plugin Settings for OJS 3. We do not assign DOIs to Issues or Galleys, but I assume that this will use the URLs for the Issue TOC and individual galley items, respectively.
I have just done some testing of this but have not tested it thoroughly. I tried to assign DOIs to only galley copies in OJS 3 so that I could see what URL is included in the CrossRef export, but it forces me to assign DOIs at the article level.
(Why is this optional in DOI Plugin Settings if it is required to complete the action? Error message: Plugin requirements not met: Articles are not selected for DOI assignment in the DOI public identifier plugin, so there is no deposit or export possibility in this plugin.)
I selected to assign both article and galley DOIs and created a galley copy with a remote URL as the only galley. The XML produced by OJS did not include that remote URL in the CrossRef XML output, but it did include a “new” URL that does point to the remote galleys. I included galleys with remote URLs to both an Abstract landing page and a remote PDF in my test. Both of these were included in the XML export, but they had transformed URL based on my OJS site URL even though entering them in a browser leads to the remote URLs.
I think that OJS is assigning the URLs appropriately for items that are published using OJS, but if a system is publishing content at a remote URL, then the remote URL entered should be what is used to generate the resource information in the CrossRef export (or an option included in the DOI Plugin Settings that says "Use remote URLs for items when available). There is currently a way to include a remote URL for galley copies in OJS, but I don’t believe there is a way to associate a URL on the Issue or Article level for items published elsewhere. (I could absolutely be wrong about this!) If the plugin were to be changed to use remote URLs when provided, it would need to be able to handle remote URLs for all possible items that receive a DOI.
So, my answer is that OJS is handling this correctly for content that is published using the system. The URL used for DOIs assigned to articles SHOULD be the abstract landing page and not a galley (unless the DOI is specifically being assigned to a galley).
OJS does allow for you to enter a remote landing page for the galley file in the system, but it doesn’t use that URL in the CrossRef XML export (though that URL does redirect to the correct remote page).
The remote galley URL should be used as the primary DOI resource when you are assigning a DOI to that galley copy; however, as is most often the case, if you are assigning the DOI on the article level, the galley URL should be included as an item resource but not the DOI resource.
I did not end up where I thought I would when I started looking into this, so please let me know if you have questions, if you would like me to do some more testing/research, or if I left parts of the topic unanswered.
Hi Thanks for Testing, but why “iParadigms” value not showing in CrossRef XML, its required by CrossRef for some services.
I will check as per your comments and get back to you.