Athens talks: OMP joins Open Editions. How to?

Community Showcase
1

Hello,
in the frame of OPERAS Conf. 2018 in Athens last week, we reasoned how to integrate OMP and the OPEN EDITIONS platforms.

Let’s explain the case:
We have an institutional platform for monographs and series based on OMP.
We also want to open a partnership with https://www.openedition.org/ and create series through their platform.

How to?

A raw, but sufficiently agnostic, starting point could be:

  1. Open Editions realizes an API and assigns to the partner (me) an API-key. Pointing to the API I can get/import, in an easy format like JSON, monography metadata and, at least, one URL to the hosted book on Open Editions.

  2. On the other side, OMP needs a plug-in that get/import those JSON data and show them as a common item but with one or more URLs to Open Edition that grants me to choose the download format with a query string:
    eg.
    www.my_url_on_open_editions.org/get/item?apikey=12345&output=xml
    www.my_url_on_open_editions.org/get/item?apikey=12345&output=html
    … or any possible output according to my partnership.

What do you think about?

Alfredo Cosco

Centro di Ateneo per le Biblioteche
Università degli Studi di Napoli Federico II

2

Hi Alfredo, very good start. Thank you ! Here are my thoughts on the topic :slight_smile:

  1. We presume that books are prepared through Lodel and published first on OpenEdition and then republished on OMP, right ?
  2. In that case, the API already exists : our OAI-PMH repository where you can access not only metadata in various formats (including links to download the files), but also, if you want, the full text in TEI and basic TEI : http://oai.openedition.org/?verb=ListMetadataFormats
    3.To access full text, you need to be a partner eg you send us your ip address to be authorized. It’s as simple as that !
  3. On top of that we have an embedding feature to represent html in your platform. Here’s an example :
    <iframe src="http://books.openedition.org/res/1039?format=embed" style="padding:5px;border:2px solid #ddd;" width="500" height="375"></iframe>
3

But what would be nice is that Lodel could query OMP API to get automatically metadata and the Word styled document from OMP back office, closing the loop. So:

  1. you peer-review and copy-edit the book in OMP, producing a pdf and a Word file ready for Lodel
  2. Lodel query OMP API to ingest the pdf, the word file and the metadata
  3. The file is converted in XML, HTML, EPUB in Lodel. Metadata are finalized and completed (we have additional metadata needed on our platform)
  4. OMP harvest OpenEdition platform to get back new metadata, the pdf, epub, XML if useful for something else and/or embed HTML
1 Like
4

Hi all,

The current release of OMP doesn’t have an API, but one of our developers is currently adding one based on the OJS API. That work is in progress at https://github.com/pkp/pkp-lib/issues/3719.

It sounds like one of the basic endpoints you’d need is the ability to submit or publish content into OMP via the API. That doesn’t currently exist either in OMP or OJS, but is definitely a use case that’s come up, so we’d love to catch some requirements and discuss it further. (There are examples of systems that create submissions in OJS, but they currently do it via custom OJS plugin code rather than an API – see example https://github.com/OSCOSS/OJS-Authoring-Integration-plugin.)

Thanks,
Alec Smecher
Public Knowledge Project Team

5

As I understand, we wouldn’t need to implement plug-in or dedicated scripting if there would be an OMP-API working with private keys.

This flow is the easier I can imagine:

  1. The partner prepares a “Lodel ready” book using MSWord macros released by OpenEdition. Then submits the book in its OMP, at this stage the book is not published;

  2. OpenEdition queries the partner’s OMP-API to catch the new data (to make this much more simple is possible to store a hash of the data to compare). Then OpenEdition transforms the raw MSWord file and publishes it to OpenEdition website, according with the policies decided with the partner;

  3. Then, always using the private api-key released by the partner, OpenEdition has to log-in and edit the book record, ie. completing metadata, adding the links to download formats (or really uploading files on it) and hides the raw MSWord file.

On the other side, without the API the flow I can imagine is:

  1. The partner prepares book using MSWord macros released by OpenEdition, then completes it through Lodel and publish it first on OpenEdition website

  2. A OMP plug-in in the partner installation queries the OAI-PMH OpenEdition repository and import metadata and files

6

Hi both, yes it’s almost that, with some differences:

  1. on step 3, I don’t think it’s feasible to log-in Lodel instance to push new metadata back to OMP. Particularly because that “new metadata” are particular to OpenEdition environment and I doubt OMP has fields for them.
  2. I think it’s simpler if OMP simply harvest OpenEdition OAI repository to have the files and metadata it needs.
  3. We need to compare OMP and OpenEdition metadata fields to see how it compares
  4. We need to draw a schema. I’ll involve OPERAS coordinator Arnaud Ginglod in this conversation to formalize it a little bit more
  5. For the record this could be applied to OJS OpenEdition Journals almost the same way.
  6. Beware that when we talk about “books”, in fact we talk about a container including several chapters : one word file per chapter
7

Hello everyone,

Sorry for the late participation in the conversation.
We’ll certainly need other exchanges on the subject but, as I jump in after the beginning, I just wanted to summarize the above discussion to make sure of what we would like to achieve.

Here is the possible and very general workflow I get from the suggestions:

  1. Reviewing/editing through OJS/OMP
  2. Styling of the DOC file according to OpenEdition’s Lodel requirements
  3. DOC,PDF stored in OJS/OMP
  4. OE download DOC files through API or plugin
  5. OE generates metadata and publication formats XML-TEI, Epub, PDF
  6. OJS/OMP retrieves the full text TEI, the download links, and the metadata through OAI-PMH

Do we all agree on that?
Of course there are specifics to discuss. For instance, I don’t make the distinction between OJS/OMP because I don’t think it’s necessary at this general level.

Let me know what you think, this will help me to see which information could be useful for the next steps.

Thank you.

AG

8

Hi all,

The piece of this that would be the most difficult is…

  1. OJS/OMP retrieves the full text TEI, the download links, and the metadata through OAI-PMH

OJS/OMP currently provide data via OAI-PMH, but do not consume it (i.e. as a client to another OAI-PMH service). Depending on what is intended here, it could have significant development implications.

Regards,
Alec Smecher
Public Knowledge Project Team

9

To jump into this discussion out of the blue, I’d like to ask if OJS/OMP is able use the SWORD protocol to ingest metadata and content, as it is able to provide data in that format?
Best
John Willinsky

10

Hi @JohnWillinsky,

OJS is able to make deposits via SWORD (using the soon-to-be-released SWORD plugin for OJS 3.x or its equivalent that ships included in OJS 2.x), but we have not until now had a use case for ingest into OJS. I agree that SWORD would be a better mechanism than OAI-PMH, off the top of my head.

Regards,
Alec Smecher
Public Knowledge Project Team

11

The emerging use case that I envision for OJS/MP both producing and ingesting deposits via SWORD or OAI-MHP could involve (a) its integration into OE’s Lodel (if it can take on SWORD protocol) and (b) preprint servers that would be able to more readily submit to OJS journals (a direction we’re also considering with an OJS preprint service). I note that this 2017 article on preprint servers https://riojournal.com/article/11825/ reports a favoring of (and recommends) OAI-MHP over SWORD as an output standard for preprint servers (with arxiv.org alone using SWORD) which leans the case, along with Lodel, to an ingest OAI-MHP use case.

12

Hi @JohnWillinsky,

The relevant distinction I tend to use to choose between OAI-PMH and SWORD is as follows: if the task is to report on your holdings, then OAI-PMH is the best match. If the task is to move a holding between one system and another, then SWORD is the best match.

If content is being ingested into OJS for workflow and eventual publication, then I think SWORD is a better fit.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like