Dear All,assignment , but I couldn’t find anything about exporting and registering DOIs.
For example nothing in the import/export tool section of the OMP documentation .
I have seen that @ajnyga have made a plugin to register CrossRef and DataCite DOIs that work on OMP 3.2 : on github and this post
Are there any plans to include a solution for exporting and registering DOIs starting from OMP 3.3 ?
Also, where can we see the planned development of the OMP ? (It looks like that OMP is missing in the the roadmap )
1 Like
Hi @mlarrieu ,
DOIs for OMP are still in the works. My understanding is that a drawback to this presently is that there is no Crossref plugin currently for OMP. As noted, @ajnyga is working on one, but it is not yet completed - and may be contingent on some more recent development that our team has been doing in version 3.4 (as I note below) .
With respect to the roadmap. OJS/OMP/OPS share a common codebase thatis about 90% the same between all 3 applications. And then there are variations in the specific products that account for the other 10%. The Roadmap applies broadly to all three software packages, and there are Github issues that are linked to from within the Roadmap that might relate more to a specific package.
There is some work going on in this regard in 3.4, some of which relates to OMP needing to have chapter landing pages:
opened 02:44PM - 03 May 21 UTC
closed 11:26AM - 15 Feb 22 UTC
Major Feature
## Motivation
DOIs are now a settled standard in scholarly publishing. DOIs cur… rently use the `pubId` plugin category, but this was built to make it easier to add pub ids to several object types (submissions, issues, galleys, submission files, chapters), and automatically have the form fields added to the forms.
However, it's become clear that DOI management is best done at the journal level (see https://github.com/pkp/pkp-lib/issues/6062). It has become increasingly difficult to build the desired UIs while maintaining compatiblity with the `pubId` plugin category architecture.
In addition, the `pubId` plugin category architecture does not provide tools for managing the registration and deposit of DOIs and metadata, which have become an important UX concern.
cc @ewhanson, @bozana, @asmecher
## Proposal
We should replace the DOI plugin with DOI functionality that is built into the core application(s), and refactor how DOIs are handled to support registering and depositing them with third-party services.
The following is an overview of the work required:
- [ ] A new database table for DOIs that gives each DOI a unique key and allows status to be tracked at the DOI level.
- [ ] DOIs should be assigned to their objects by their key in the database table, rather than saving DOI information directly into `publication_settings`, `submission_file_settings`, etc. This will make it easier to prevent duplicates and auto-generate DOIs.
- [ ] DOIs should be given a list of status that can be used to manage DOI registration and depositing (see below)
- [ ] By default, DOIs should be generated automatically using the [Cool DOIs](https://blog.datacite.org/cool-dois/). DOI generation patterns should be removed where possible and discouraged where they can't be removed.
### Statuses
DOIs should be assigned one of a few statuses which can be used to track their registration and deposit. These statuses should work regardless of whether the journal is depositing the DOIs manually or using our tools to deposit. They should also work regardless of whether the journal deposits to Crossref, Datacite, or another service.
Suggested statuses:
- **Unregistered: ** No attempt has been made to register this DOI.
- **Submitted:** The DOI has been marked for submission, but has not yet been registered. For example, OJS/OMP/OPS may create a job to register the DOI but the job may still be in the jobs queue.
- **Registered:** The DOI has been successfully registered and deposited in another service. This is to be used if it has been deposited in _any_ third-party service, and whether that deposit has been done through OJS/OMP/OPS or if the DOI has been manually marked as registered.
- **Error:** The DOI could not be registered or deposited in another service because of an error (examples: failed network requests, fatal software error, failed response from Crossref due to invalid data).
- **Stale / Requires Update:** The DOI has already been registered, but the data about this record has changed and any third-party deposit service should be updated about this change.
## Discussion
The following questions are still outstanding:
1. DOIs are stored at the object level (submission, galley, etc), but they are managed and deposited at the submission level. How can we structure the data so that we can make performant searches to identify DOIs that need to be registered, while still displaying the management UI at the submission level? For example, if just one galley of a submission has an `unregistered` DOI but the publication has a `registered` DOI, how can we make it easy and performant to say "get me all submission with an unregistered DOI"?
2. How can we build the DOI management UI to support additional data (like Crossref event logging) so that any service can record data and it can be exposed in the UI.
3. Would a journal/press/preprint server ever need to deposit to two services at once, eg - Crossref and DataCite?
4. What's the best language to use: "registered", "deposited", "minted"?
opened 10:52AM - 10 Feb 21 UTC
closed 12:14AM - 18 Feb 22 UTC
Major Feature
**Describe the problem you would like to solve**
Extend the OMP import export f… unctionality to include
- [ ] Chapter level DOI
- [ ] Book Series Title (for series attached to publications) (for series we only have path and Series Position for each publication.)
- [ ] Book Series description (for series attached to publications)
- [ ] eISSN for series attached to publications
opened 01:04PM - 15 Jun 21 UTC
closed 11:25AM - 17 Nov 21 UTC
Enhancement
**Describe the bug**
A URL that leads to a chapter with no version should alway… s go to the most recent published version of that chapter. For now, every new version the chapter id changes and there is no way to get the id from the source chapter. To build a chapter landing page with the possiblity to show different versions of a chapter, a chapter needs to know its source chapter id. Thats also important for urls of registered chapter DOIs.
A solution could be to add a source_chapter_id property.
**What application are you using?**
OMP 3.3.0
**Additional information**
***Example***
I've a chapter with id 8986. I register the chapter DOI by datacite. That way datacite saves an url for a chapter landing page. Part of this url will be the chapter id (https://omp.example.org/index.php/{press}/catalog/book/{book_id}/chapter/8986).
Now I create a new version and the chapter id changes to 9643. So the url by datacite is wrong now.
Or I'm on https://omp.example.org/index.php/{press}/catalog/book/{book_id}/chapter/9643 and want to show version 1 with version id 411 of this chapter, but there exists no https://omp.example.org/index.php/{press}/catalog/book/{book_id}/version/411/chapter/9643, there is only https://omp.example.org/index.php/{press}/catalog/book/{book_id}/version/411/chapter/8986.
That's no problem, if it would be possible to identify the source chapter id. Chapter 9643 has to know, that its source id is 8986.
So, I suspect there will be a lot more better support for OMP starting in version 3.4
-Roger
1 Like
ajnyga
April 29, 2022, 11:33am
3
Hi!
The Crossref plugin I made is very basic. I will upgrade it soon to support 3.3 because we are upgrading our own server to 3.3. However, the reason why the plugin is so simple is that PKP has been working on a larger overhaul of DOI functionality in OxS. So instead of spending a lot of time to make the plugin better, I decided to wait. It is lacking things like automatic registration etc.
1 Like
Thanks @ajnyga ! That makes good sense to wait and see what unfolds with DOI functionality.
-Roger
Thank you for your feedback Roger & Ajnyga, it really helps !@ajnyga (with a manual export for CrossRef registration) and wait for the new features for DOIs in OMP 3.4. My colleague has started to update your plugin and now it works for OMP 3.3. There is still some work to do to share the code, but we will get back to you once it is done.
1 Like
This topic was automatically closed after 4 days. New replies are no longer allowed.