Closed bozana closed 6 years ago
Hmmm... I am not sure if this can/should be considered for OMP 3.1. We haven't asked Crossref about that explicitly yet, I think. I found this page: https://support.crossref.org/hc/en-us/articles/213125186-Books-and-book-chapters. It says that there could be DOIs for chapters, but only if the book has a DOI too. It seems to be something similar to article and galleys? There is still no Crossref export/registration plugin for OMP, but we could eventually consider this chapter option already/however? Or shall we wait till we start implement those export/registration plugins? @asmecher, @jmacgreg and @stranack, what do you think?
Hi Bozana! Unless we have heard of many many requests for this in OMP (I haven't), or have someone volunteer to fund the work, I'd prioritize the OJS stuff first and push this to OMP 3.2.
For the record, Language Science Press runs OMP and has DOIs for both books and chapters e.g. http://langsci-press.org/catalog/book/121 . There have been requests by authors to have landing pages for chapters as well, different from the landing page for books. This is currently not possible.
Dear all. I would strongly like to second that. We definitely need DOIs for chapters including landing pages for chapters in order to stay within the DOI reglations of DataCite or CrossRef. It does not really make sense to assign DOIs to the files only (with URLs all leading to the same TOC of the book), especially as this is not conform to DataCite's regulations (and to CrossRef's as to my knowledge). This is all just workarounds. As for th discussion concerning CrossRef, have a look at springerlnk. Their DOIs are provided by CrossRef and they are working very well (DOI for the book, DOI for chapters, landing pages for book and chapters each). In order to further promote OMP, also in the bibliographic sense, it is just state of the art to have unique identifiers for chapters for distribution, visibility, archiving etc.
Regards Klaus
FTR, we now use Zenodo DOIs and duplicate our content there, as Zenodo offers both book landing pages and chapter landing pages. This is obviously a move away from OMP as a hosting platform. Our DOIs do not resolve to our OMP instance, but to Zenodo instead.
I have toyed around with a Jekyll version of the catalog, which does indeed have chapter landing pages. An example can be found here: http://langsci.github.io/chapters/108-3 . Maybe this can inform the discussion. I am aware that Jekyll and PHP are very different technologies.
PRs: pkp-lib master: https://github.com/pkp/pkp-lib/pull/3355 omp master: https://github.com/pkp/omp/pull/498
ojs master: https://github.com/pkp/ojs/pull/1863 (funciton parameter names changes)
@asmecher, could you review the PRs above?
@NateWr, currently I display the chapter DOIs here i.e. like this: https://github.com/bozana/omp/blob/1692/templates/frontend/objects/monograph_full.tpl#L201-L210. Is it OK for now?
Yeah that seems alright. Maybe not everyone wants them there but I don't think we'll be able to please everyone and that seems as good a place as any.
Oops, I posted a quick review on the PR, not the issue. See https://github.com/pkp/omp/pull/498#issuecomment-366765272. Thanks, @bozana!
Just a heads-up that I think this is still on your plate, @bozana.
:+1: I know, I know... :-)
Sorry for the pestermail :)
I see this has been closed, but the request for landing pages for chapters was not included in the changes I think?
Is there an intention to add this feature? Could not find another issue related to it.
We are looking into a project where we would open a service for books. However, many of these books are edited volumes and the chapters are actually individual articles. I think that a chapter with a landing page comes close. With the current features OMP has, we can not probably use it.
It seems like we'd be open to a contribution on this, @ajnyga.
Ok!
I think throwing in chapter page numbers would make sense? I have seen a request about that on the forum.
Also I think that adding chapter galleys at the moment is a bit too complicated (or I am just not familiar enough with OMP). I have a suggestion how to change this, but I still need to think it in more detail. But that is a separate issue anyway.
Overall, this is way down on my todo list at the moment, because the project I mentioned is still a sketch.
The way I am seeing it is that in edited volumes the chapters should work more like articles in OJS. This would mean that chapters would have their own DOIs, landing pages and things like statistics.
But I am fairly sure (without looking in too deep) that the current database structure is not going to support this too easily.
Springer Link was already mentioned above and I think it is a very good example of how things maybe should work:
Edited volume: https://link.springer.com/book/10.1007/978-3-319-94487-6 Monograph: https://link.springer.com/book/10.1007/978-3-319-97837-6
Note that they add chapters also for monographs, but I think that should be optional as it is now. But when you add a chapter, it should always have a landing page with the possibility to assign a DOI.
Also note that in Springer the chapter DOIs are pointing to the landing page. This enables the publisher to add different file formats of the same chapter.
Thanks @ajnyga for your comment which I fully support. The way Springer is disseminating their chapters is very similar to journal articles. Therefore it is also necessary to put these data into the DOI registrations (esp. towards DataCite) at OMP. Just download a sample XML of Springers DOI-Data from CrossRef to see how much is in there and how accurate it is. Therefore, I already posted a feature request for having editors of jounal issues and their articles on OJS (https://forum.pkp.sfu.ca/t/name-editors-in-issues/47421). So this is one more issue where OMP- and OJS-Structures should be merged.
May I strongly urge you to activate the opportunity to have chapter landing pages for OMP, so it will be possible to register the chapters with DOIs. I was not aware that it is not possible in the current setup. We are now faced with having to publish an anthology on our OMP platform, which in the printed version has already been assigned with DOIs on the chapter level. The DOIs are generated from our OMP platform. For me one of the greatest features in OMP 3 compared to OMP 1 was exactly the option to give chapters a DOI. Regards Niels Erik
Hello! I would like to also request that OMP creates the option for chapter DOIs with chapter landing pages, much the same as article landing pages. This is particularly important for dissemination and discoverability and reflects the way researchers access content now (i.e. going straight to the parts they need rather than sifting through a book). A Crossref plugin where we can export the metadata would be crucial, too.
Is this still on the cards and, if so, when might it be implemented?
Best, Rebecca
Ignore me - I see that chapter DOIs have already been installed.
However, are there plans for a Crossref plugin? Or a QuickSubmit button?
Best, Rebecca
cc @ajnyga I believe you might be working on OMP plugins for Crossref and QuickSubmit?
Yes, I have these for OMP 3.2 https://github.com/ajnyga/datacite/tree/crossref https://github.com/ajnyga/quickSubmit/tree/omp https://github.com/ajnyga/autoApprovePublicationFormats (this is not required but handy)
@ajnyga this is fantastic, thanks. Are there any plans for future upgrades to have these auto-installed as they currently are on OJS, @NateWr?
The Crossref plugin is really a temporary solution. I am waiting for the current DOI work finish and will revisit it after that. It works, but lacks for example automatic registrations.
The quicksubmit plugin is maybe something that could be released "officially" but also there Nate has plans to incorporate a quicksubmit like functionality to the core.
But I plan to support these because we use them in our own OMP installation, which I will upgrade to 3.3 during the winter and update those plugins in the process.
Are there any plans for future upgrades to have these auto-installed as they currently are on OJS, @NateWr?
It's up to the plugin developer (@ajnyga or his institution) to decide whether or not they want to add a plugin to the plugin gallery. Doing so brings with it the responsibility (or at least the expectation of responsibility) to maintain the plugin with future releases as they appear. That can be a significant commitment for an institution to make.
Implement the public identifiers for chapters in OMP