I am testing whether OMP could be used for handling PhD thesis submissions at my university. One of the features we would need to add is support for embargo times on certain objects. At submission the user should be able choose to add an embargo time for their thesis (or possibly for each chapter/file). Later, when the thesis is cleared for publication it should appear as a title in the catalog, but access to all or some of the files should be blocked until the embargo period is over.
As an experiment, I have made a crude implementation for adding submission embargoes here: GitHub - ubbdst/omp: Open Monograph Press. That solution has several problems, I have to alter core tables and a large number of classes to make sure the embargo is respected and propagated throughout the site (and I probably missed some places). But, I have struggled trying to separate it. If I store the embargo times in a separate table I run into problems with submissions not being assigned ID’s before the end of the submission wizard (if I understood it correctly?). If I attach embargoes to files instead of submissions, I am afraid there will be some complicated book-keeping in propagating the embargo over several revisions (one option could be to only add embargoes before production). I also tried creating a plugin, but ran into two additional problems: some of the steps where I need to extend behavior don’t have hooks (which seems straight-forward to solve), and I need to modify some of the templates for the submission wizard and frontend/catalog (which seems difficult?).
So, my question is, is the first approach the best, in spite of it meddling with a lot of core functionality, or is there a more modular/isolated approach that you could suggest? Also, would there be interest in adding this as an optional feature of OMP/PKP?
Hi @simonmitternacht,
are you really planning a “Press” or do you want to fulfill the obligatory publication of an ETD.
Most universities use a repository software (DSpace, EPrints, Fedora …) for this. We are using DSpace and it got a built in embargo functionality.
Hope this helps
Claudia Jürgen
Hi @cjuergen,
We will definitely be exporting to one or several DSpace installations, but are exploring the possibility to use the press as an extra frontend that only shows the PhD thesis section of our repository. It’s still very early in the process, so everything is still open. However, even if we end up only using OMP for handling submissions, we need to be able to store the submitter’s requested embargo with the document.
The reason we’re investigating OMP and not just adding to our DSpace is that we wanted to see if we could integrate the thesis review and also communication with the layout and printing people in one tool.
Simon
Hi @simonmitternacht,
Glancing over your code so far, your approach is about what I’d recommend. It’s true that you’re hitting a number of classes and templates, but each intervention is logical and none are duplicated.
One option you might consider is looking in the ONIX standard (which we try to align OMP’s features with to some extent) to see if it supports embargoes. If so, implementing your changes to OMP to align with ONIX might make it a good feature for merging into the core codebase, after which of course you wouldn’t have to maintain it separately.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
Thanks for your reply. I will try to integrate ONIX then, seems like “Content date role - From date” (list 155:14) is the most appropriate. Will get back to you when I have something more polished!
Simon
Hi again @asmecher
I now have something in our fork that is roughly what we want for ourselves: GitHub - ubbdst/omp at embargo
It still needs some testing and fine-tuning (I am sure there are still some bugs) but I think this would be a good point for feedback on my solution.
- I have added a settings tab under press > distribution, where one can turn on Chapter and/or Monograph Embargoes, and decide whether authors can request embargoes or not (editors can always change them).
- At submission step 3 the author can set a global monograph embargo date and/or embargoes for individual chapters.
- When the monograph is added to the public catalog the editor can modify these dates or add their own. I have added a validation step to this form that doesn’t allow there to be both monograph and chapter embargoes, since that could cause ambiguities as to what files are available. It might be more straightforward for the press to only allow either chapter or monograph embargoes, but not both. For our application I think we will only need chapter embargoes.
- In the catalog frontend embargoes are shown as a label next to where download links would be, and download links are only shown for files that are out of embargo. I found out how to close the backdoor to a monograph file (in CatalogBookHandler:
download()), if the whole monograph is under embargo. But so far I haven’t been able to block access to someone guessing the URL of a chapter file.
- ONIX export includes embargo information, but I’m not sure I’ve covered all the relevant fields.
One idea I’ve had that’s not relevant for our application, but might be for others is to set embargoes for each publication format instead of for each title.
I haven’t written unit tests, I guess that would be a relevant addition, but I didn’t find many examples of tests for other similar classes, so I’m wondering if you only have tests for some of the trickier functions, or if I was looking in the wrong place. Either way I will probably need some pointers for where to start with those.
Simon
Hi @simonmitternacht,
Sorry for the delay in responding – this is my oldest active browser tab. Would you like me to take a look and perhaps do a code review? If you’ve got anything to push up first, let me know!
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
No worries. No new code to push, but we will be moving forward again on this after the holidays, so I am thankful for any input!
Simon