PKP Bugzilla – Bug 4194
DOI display on table of contents
Last modified: 2014-03-04 05:13:46 PST
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
While CrossRef does not require that the online interface for a journal show the DOI, it makes sense in many instances to publicly display the DOI in an obvious location, not least since some citation styles are beginning to require that the DOI be included in references, if available. By modifying templates/issue/issue.tpl in our OJS instance, I was able to include the doi, properly linked, in the table of contents (see: http://thebalticyearbook.org/journals/baltic/issue/current#).
It would be preferable, however, to have this as an option at the journal level, and leave the decision to an individual journal manager. I would suggest making it a choice in setup, step one, right after the existing DOI options. Simply a checkbox which toggles DOI display in the TOC. An additional checkbox which would add it to the abstract view would also be a welcome addition.
Rescheduling to 2.3.4 in light of Vanessa's further comments: http://pkp.sfu.ca/support/forum/viewtopic.php?f=9&t=6817.
Alec, what do you think about this one? I can easily enough add the code to the tpl file to always display DOI info (if a DOI exists), but adding a configuration option to Setup Step 1 to en/disable display is maybe a bit beyond me, and would also add locale keys. Should I implement option 1, or defer?
Deferring until we can do it properly. Easy enough to edit a tpl file to pull the DOI, if that's what the journal needs.
James, I'm fine with displaying the DOI when it's available. I can't think of a reason journals would generally want to use DOIs without displaying them.
Just as an additional note, I'm pretty sure that CrossRef regulations state that the DOI must be displayed on the landing page of the article, if present.
I've made the modification that does this and it's available here: https://github.com/MartinPaulEve/ojs/commit/687007d5fc5e688144f179a23824a97871520e5c
I've got a pull request underway for this and for another patch.
note from Crossref: when displaying the DOI, have it link to http://dx.doi.org/[DOI]
This makes sense and, in theory, that URL should be pointing back to the journal article.
We should display the dx.doi.org URL even if we don't link it (i.e., just show the URL)
to be more explicit: the important part is that the dx.doi.org URL be _shown_. Linking would be additional.
This has already been committed to ojs-stable-2_4 thanks to UF Berlin (Thanks Florian/Bozana!) -- see eg. https://github.com/pkp/ojs/commits/ojs-stable-2_4/templates/article/article.tpl. There isn't a configuration option to en/disable DOI display, but I agree with Alec that this is such an edge case as to probably not be necessary. If folks need to display DOI display for some reason, they can do so by editing the relevant tpl files in templates/article/.
sorry to ask, instead of check, but does the DOI appear as a link to dx.doi.org/DOI? Crossref has requested this and I think it makes sense. In theory, it should resolve back to the same page
(In reply to comment #9)
> sorry to ask, instead of check, but does the DOI appear as a link to
> dx.doi.org/DOI? Crossref has requested this and I think it makes sense. In
> theory, it should resolve back to the same page
Hi Juan, just saw this now. The HTML in the template is as follows:
DOI: <a id="pub-id::doi" href="http://dx.doi.org/10.1234%2Fdemo.v1i1.1">10.1234/demo.v1i1.1</a>
... so the link doesn't explicitly show "http://dx.doi.org", but that can be quickly tweaked pre-release if you think it should. How does that sound?
here's the guide: http://www.crossref.org/02publishers/doi_display_guidelines.html
Done for 2.4.2; moving to 3.0.
tweaked DOI article display
Added to 3.0. Waiting for feedback from Florian before closing.
tweaked DOI article display
tweaked article DOI display
tweaked article DOI display
I suppose the citation formats using DOI (only ABNT and APA at the moment) should be changed accordingly?
I am wondering if the pubId display should be changed accordingly for the following cases too:
in the HTML meta tags (now):
<meta name="DC.Identifier.DOI" content="10.1234/t.v1i1.1"/>
<meta name="DC.Identifier.URN" content="urn:nbn:de:0000-t.v1i1.18"/>
<meta name="citation_doi" content="10.1234/t.v1i1.1"/>
<meta name="citation_urn" content="urn:nbn:de:0000-t.v1i1.18"/>
via OAI (now):
<article-id pub-id-type="doi" >10.1234/t.v1i1.1</article-id>
And what about OJSSwordDeposit.inc.php, DOAJExportDom.inc.php, PubMedExportDom.inc.php and CoinsPlugin.inc.php?
I suppose this is not necessary for DataciteExport, CrossRefExport, NativeExport, medra O4DOIExport?
Good questions! I think the most important issue for this report was that DOIs viewable from HTML landing and article pages include the "dx.doi.org" bit, but their guidelines (http://www.crossref.org/02publishers/doi_display_guidelines.html) do seem to indicate that it should be added anywhere the DOI is displayed. I don't think this is necessary to do for OJS 2.4.2, but I can definitely do this for 2.4.3/3.0.
That said, I don't think that bit should be added to the DC meta tags, or for any of the deposit/export plugins (which should only need the raw DOI). Unless you can think of an issue? If this is the case, then, only the ABNT/APA citation format plugins need changing.
(In reply to comment #18)
> I suppose the citation formats using DOI (only ABNT and APA at the moment)
> should be changed accordingly?
> I am wondering if the pubId display should be changed accordingly for the
> following cases too:
> in the HTML meta tags (now):
> <meta name="DC.Identifier.DOI" content="10.1234/t.v1i1.1"/>
> <meta name="DC.Identifier.URN" content="urn:nbn:de:0000-t.v1i1.18"/>
> <meta name="citation_doi" content="10.1234/t.v1i1.1"/>
> <meta name="citation_urn" content="urn:nbn:de:0000-t.v1i1.18"/>
> via OAI (now):
> <article-id pub-id-type="doi" >10.1234/t.v1i1.1</article-id>
> And what about OJSSwordDeposit.inc.php, DOAJExportDom.inc.php,
> PubMedExportDom.inc.php and CoinsPlugin.inc.php?
> I suppose this is not necessary for DataciteExport, CrossRefExport,
> NativeExport, medra O4DOIExport?
Thanks James! :-)))
The most important thing is that it is not so critical and thus doesn't have to be changed for 2.4.2 and I don't need to help (now) :-)
For some reason, DOIs aren't appearing on HTML or PDF pages -- only on abstract pages. They should appear on all pages.
Hmmm... In which OJS version? They are displayed in our 2.4.2 installations :-O
(In reply to comment #22)
> Hmmm... In which OJS version? They are displayed in our 2.4.2 installations
Hi Bozana, I'm testing on a fresh checkout of 2.4.2. I suspect a commit was missed somewhere. I'm going to split this off into a separate bug for now, but will CC you!
(In reply to comment #23)
> (In reply to comment #22)
> > Hmmm... In which OJS version? They are displayed in our 2.4.2 installations
> > :-O
> Hi Bozana, I'm testing on a fresh checkout of 2.4.2. I suspect a commit was
> missed somewhere. I'm going to split this off into a separate bug for now,
> but will CC you!
Hi Bozana, actually, this isn't a missed commit, and is relevant enough to this thread to add here; but if you want to split this off into a separate bug, please go ahead!
What I think is happening is this (in templates/article/article.tpl): the DOIs only display for galley files if there is a specific DOI assigned to that galley. If the journal isn't designating DOIs for individual galley items, nothing is displayed. However I think that in these cases, the overall "article" DOI should be displayed. Something like:
If there is a galley doi, display it;
otherwise, display article doi.
Any thoughts on this? I will note that if you look in the indexing metadata, the article-level DOI appears there.
are we ever assigning DOI's at the galley level? That seems like a bad idea. Journals pay per DOI assigned, so doing that will pretty much double their costs. In most cases, I imagine the article level DOI should be displayed...
(In reply to comment #25)
> are we ever assigning DOI's at the galley level? That seems like a bad idea.
> Journals pay per DOI assigned, so doing that will pretty much double their
> costs. In most cases, I imagine the article level DOI should be displayed...
Hi Juan, DOIs are assigned at the galley level only if explicitly configured as such (DOI configuration options are now found in the plugin settings, but for example you have the option to create DOIs for issues; articles; galleys; and supplementary files). I don't know if there's a particular use-case for having galley-level DOIs, but this option has been around forever. I agree that it is confusing though.
its also a terrible idea. Can you check the blame and see who did it so we can ask why? It essentially makes it so that you have a whole bunch of DOI's for the same article. I *REALLY* hope it is not the default.
(In reply to comment #27)
> its also a terrible idea. Can you check the blame and see who did it so we
> can ask why? It essentially makes it so that you have a whole bunch of DOI's
> for the same article. I *REALLY* hope it is not the default.
Hi Juan, it isn't the default, at the very least. I'm actually getting a little confused myself at this -- I think there's some sort of conflation of two configuration options (one old, one new) that I'd like some feedback from Bozana/Florian on.
Bug 3231 implemented a Custom ID option for individual galley files. If memory serves, this could theoretically be extended so that custom DOIs for galley files could be created/managed, but that wasn't strictly the purpose here. The configuration options for this, under Journal Setup Step 4.3 are as follows:
Articles and issues can be tagged with an identification number or string, employing a registration system such as the Digital Object Identifier System (DOI).
 Custom identifiers will be used to identify issues.
 Custom identifiers will be used to identify published items.
 Custom identifiers will be used to identify galleys (e.g. HTML or PDF files) for published items.
 Custom identifiers will be used to identify supplemental article files.
None are checked by default; if none are used, DOIs can still be generated as you would normally expect.
The new plugin structure for DOIs has moved the DOI configuration options under Setup Step 1 into the plugin settings page. The DOI Plugin Settings page also includes the following:
Please select the publishing objects that will have Digital Object Identifiers (DOI) assigned:
 Supplementary Files
NONE of these are enabled by default. They do seem to mirror the older configuration options described above, and I'm not sure how these two sets of options work together (or if they do). Bozana/Florian, if you could provide some guidance here that would be great.
If we continue to support unique galley & suppFile DOIs, we should probably include some sort of instructions here viz. what to do for CrossRef. One issue here is that OJS' DOI structure has never been explicitly meant for CrossRef, although that's really the primary (only, as far as I know of) use-case.
... I guess a larger question that I'm only hinting at here would be: should be look at the generic DOI plugin as specifically a CrossRef DOI plugin and rename and reconfigure it as such; or would it be worth duplicating the more generic & expansive plugin as a CrossRef variant with more limited features? I think we need to do something from a usability perspective at least -- I don't know if the current setup will be easily understood, let alone found, by users new to OJS.
(Likewise, the documentation (http://pkp.sfu.ca/wiki/index.php/DOIPluginsDocumentation) needs a very concise, simple-to-follow description of how to set up DOIs for CrossRef.)
@James: definitely want to support other DOI's, such as DataCite, as some journals use them for article DOI's as well (while others could potentially use CrossRef for articles and DataCite for SuppFiles).
@Bozana: Florian says I should speak with you and Albert about U Berlin's use case for galley-level DOI's. I think they are generally a bad idea and I would like to remove that option from our codebase. I just want to hear from you before we go that route.
Phew... What an overnight storm here! :-)
I think there are other cases how DOIs are used/assigned -- not only to the OJS article object. For example, the German National Library recommends to assign the persistent identifiers to the digital objects that are long term archived by the library, which are the full text PDF files per language at the moment, i.e. galleys in OJS. Thus, there are some journals using the DOIs (and URNs) like this, for example http://www.comparativepopulationstudies.de. S. DOIs in text here: www.comparativepopulationstudies.de/index.php/CPoS/article/view/104/112 and http://www.comparativepopulationstudies.de/index.php/CPoS/article/view/104/113. This journal has been assigning DOIs like this and registering them to DataCite manually till now, because of the lack of the possibility in the earlier OJS versions.
I also know a journal that wanted to be able to assign a persistent identifier to an issue, because the issue was something special.
I also don't know why shouldn't I be able to assign a DOI to a supp file -- I could have some research data added as a supp file in OJS that could be cited and is interesting/valuable on its own.
And finally, there are the other DOI registration agencies like DataCite and mEDRA that support all these cases.
The DOI plug-in also enables several options for suffix construction -- it doesn't have to be automatically constructed.
James, you are right, one of the options is to use the custom identifiers for the DOI suffix.
Thus, I prefer not to limit the use and the users but to provide them with all the possibilities and to give them a good documentation/explanations? Maybe also to extract a documentation only for the CrossRef users? If you however see the danger for CrossRef users, maybe to separate the CrossRef DOI plug-in?
We could eventually ask the DataCite and mEDRA users in other countries (maybe you know some?), how they are using it? Because, maybe it is a way I've experienced and think about it or a very rare and a special thing in Germany or German National Library or ...? Or, what would be the correct way in general and for the current and future publishing development and if the price and the CrossRef dominance wouldn't that matter?
And James, to your other question -- to display the article DOI on the galley sites:
Somehow I am not sure if this would be completely right, but it is partly influenced with my explanation above -- Somehow the DOI describes an object, in that case an article as a whole, with all its components, full texts (galleys) in different languages and formats, even with the supp files, I think. Resp. if the article DOI would be displayed on galley pages, I would hope that then there would not be a possibility there to use/cite/connect only one galley (e.g. PDF_de) with the DOI.
The reason it is displayed in the metadata in the RT is just because these RT metadata are always the same, i.e. for the article object and the GUI language. For example, if I am reading an English full text/galley but having GUI lananguage = German, then I will see only the German metadata there (which doesn't fit at all with the text/galley I am reading). Thus, I think, this RT metadata concept could be eventually improved? On the other places, like HTML meta tag and OAI, they are displayed correctly: for a galley page the article DOI is not considered in the HTML meta tag, and via OAI the article DOI is delivered in dc:identifier and galley DOI in dc:relation element.
This is just my oppinion/how I am thinking, but...
Thanks for asking/waiting for me/my answer! :-)
Hmmm... Maybe also another comment:
Somehow, the enhanced publications and compound objects are getting on popularity/importance. Maybe there is still not much use as such, but for example the research/open data seam to have brought some news and changes.
Like it would be rigid for a different language to be another publication/article, it seems that concerning just OJS article like this/like the only one would be rigid i.e. is already reaching some limitations, I think.
Sorry to have dropped this thread, ready to pick it up again.
Here is a response I received from CrossRef, which matched up with how I think EVERYONE should be using DOI's for articles, including DataCite and mEDRA. This is a question of promoting a best practice, even if the Germany National Library has different ideas. DOI's are not just about persistence, they are also about accurately capturing citations.
Normal practice is to register a DOI that will resolve to a landing page that allows someone to select a representation for download. We don't regulate what exactly a DOI is assigned to, but there is a strong guideline that it should be assigned to manifestations of a work that differ enough that they would be cited separately. Different representations, PDF, XML etc shouldn't fall into that definition, unless something has gone quite wrong in the publication process, so normally there would be one DOI for them all.
I like being able to assign DOI's to supplementary files, since the are a distinct version, but not to Galleys. I would like to remove the Galley code from the core.
@Bozana: could you put me in touch with the people that are promoting assigning DOI's to galleys? Whoever set out the spec for you? I'd like to understand the motivations and try to convince them of why Galley-level DOI's are a bad idea.
Assigning DOI's to issues also makes sense. Its galleys that I think is problematic.
The German National Library (DNB) longterm archives digital objects in PDF formats (at the moment) and they accept one data set per language and the URNs/persistent identifiers should be assigned to the digital objects that are longtermed archived. You can contact the URN service there, s. the e-mail on the bottom of this page http://www.dnb.de/EN/Service/DigitaleDienste/URNService/urnservice_node.html;jsessionid=FF43E96852BE1E2379C8BBCB55229C64.prod-worker3. They can then maybe give you contact to somebody responsible for longterm archiving.
Concerning the citation: Some journals would like to separatelly cite the aticles in different languages (they see them, like the DNB too, as a different edition or they just follow the DNB recomendations). One journal is mentioned/linked above. And, some think that it is very important to cite the exact document that was used, because also the different formats can differ, e.g. in a HTML article you can have videos, audio or some features you cannot have in PDF, for example. It also depents how a journal uses the different formats and it could also depend how it uses OJS galleys.
Maybe you can also get in touch with DataCite and mEDRA and ask what they would recommend? Or maybe even other countries, journals, uses,...?
And me personally don't understand why would you like to restrict it?
it would be bad practice in 99% of cases. Maybe a strong warning is enough to deter use, unless a journal _knows_ it needs to assign on a per-galley basis.
If I understand you correctly, I think that a strong warning would be OK -- just not to forbid/disable it.
Hi folks, just to chime in -- I think a strong warning should suffice.
Not sure why this was assigned to me ... Bozana, I'm moving over to you. :D We're looking at closing up all 2.4.3 bugs shortly, so if you could close or defer that would be great.
DOI display on table of contents
DOI display for citation formats
I think you were assigned to this because you said "I don't think this is necessary to do for OJS 2.4.2, but I can definitely do this for 2.4.3/3.0." in the comment 19 ;-)
Don't worry, it's no problem for me to do it. I am just not sure what everything should be done, because we discussed several things here. Thus, till now I inserted a strong warning in the DOI plug-in settings for the CrossRef users (s. my first commit, comment 40) and I inserted the resolver link in ABNT and APA citation format plug-ins (s. my second commit, comment 41). OK so?
As far as I can see, there are eventually two more things to be done:
1. Should we use the resolver link in the element <dc:identifier> via OAI? Now the element looks like this: <dc:identifier>10.1234/t.v1i1.1</dc:identifier>
2. Should the article DOI be displayed at the galleys pages if there is no galley DOI? I wouldn't do this (s. comment 31), but... I will leave the decision to you :-)
Else, I would close the bug :-)
-- assigning DOIs at the highest level structure and to the “work” instead of a particular “manifestation” or version of that work could have a negative impact on the integrity of the scholarly citation record that CrossRef is attempting to maintain.
Bozana: Geoff also says:
"In general, different “equivalent manifestations” of the same work can safely be assigned the same CrossRef DOI. So, for instance, the HTML formatted version an article and the PDF formatted version of an article can almost always be assigned the same CrossRef DOI."
Unfortunately, there is no hard and fast rule about where and when to assign new CrossRef DOIs. Instead there is only a guideline, namely:
“Assign new CrossRef DOIs to content in a way that will ensure that a reader following the citation will see something as close to what the original author cited as is possible.”
Yes, yes, agree... :-)
Is this entry still active? We're just preparing to start smoke testing of OJS 2.4.3, so if there are parts of this left incomplete that make sense to break off, I'd suggest filing them as a secondary entry.