Coverage Metadata 2.x-3.x migration

In our prior (original) 2.4.x install of OJS, Journal Setup->Submissions-> 3.4 For Authors to Index Their Work provided three entry boxes for “Coverage” metadata:

Provide examples of relevant geo-spatial or geographical terms for this field:
Please indicate any geographical areas that are relevant to, or described or depicted in the submission, e.g., Philadelphia, Pennsylvania; Onondaga County, New York.
(E.g., Iberian Peninsula; Stratosphere; Boreal Forest; etc.)

Provide examples of relevant chronological or historical terms for this field:
Please indicate any dates, eras, or other chronological periods relevant to the submission, e.g., 1970s; 21st century; 2007.
(E.g., European Renaissance; Jurassic Period; Third Trimester; etc.)

Provide examples of research sample characteristics for this field:

In our testing 3.1.2 install, on the Settings->Workflow->Submission page, one can activate only “Coverage.” Data from our prior (multiple) coverage fields did not successfully migrate into the single coverage field in 3.1.2.

This is very important for us not only for indexing, to have the past data properly migrated, but we drive visualizations of journal content off of chronological and geographical coverage independently, and need to have access to these prior coverage fields.

Has anyone else encountered this, and/or what might our solution path be?

Hi @blonsway,

Have a look at https://github.com/pkp/pkp-lib/issues/1143 – that reviews the discussion and motivation that led to the changes between the OJS 2.x and 3.x Coverage fields.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks for the link.

Drat, I wish I were there in Feb 2016! I would have argued against consolidating the two coverage fields…but not only because our front end data-viz/search relies on them being distinct.

From a data architecture standpoint, spatial and chronological data (not to mention the third (sample characteristics) field that was once present in 2.x) is taxonomically very distinct: I can’t format geospatial data using chronological data formatting and vice versa; each has native structures for search (on a map, for example, or on a calendar); and their value as metadata is autonomous (I may care about things from the 20th century, regardless of whether they reference the US; I may want to identify things from the 20th century specifically about the US; or I may want to identify things about the US from any time). It is a real information loss to have these distinct fields merged.

As I mentioned, a central part of our journal’s interface is a data visualization where one can filter by chrono or geo coverage, so this is a drastic loss for us.

I guess what I care most about is what happened to the data in the db that was originally in the chronological and geo-spatial coverage fields. It isn’t displayed in our OJS dashboard in 3.x after upgrade. Is is still in the db somewhere? If it is, we can extract it with a REST API extension (which is how we populate the viz).

Hi, I know some time has expired, but could you share some info on what happened to the data that was in those fields during the 2.x to 3.x migration? Our IT team has reported that it didn’t come across into the new single “Coverage” field.

Hi; our IT staff dug into the db, and found the data in the submissions_settings table. For anything created in 2.x, it made it through the migration.

I now have two questions:

  1. @NateWr, can we grab this data via the REST API?
  2. What would it take to add these two fields back into the interface so we can continue to use them going forward?

Brian

Hi @blonsway,

The data won’t be provided through the REST API by default, which means you’ll need to write some code to get it out of the database and into the REST API. This should be do-able and easier to do than writing your own API code as you’ve done in the past – which should make maintenance of this work easier over the long-term.

What does your timeline look like for having this running and working on a live site? I ask because we expect to release v3.2 in January and there are some significant changes coming in how you would solve this problem.

The good news is that v3.2 is introducing a more extensible data model for submission data that should make it much easier to extend the data attached to a submission and add input fields to the forms where this data needs to be entered.

The bad news is that if you can’t wait until January, you’ll probably need to do this work once now and again when you’re ready to upgrade to 3.2. :sob:

If you let me know what your timeline looks like, I can provide some guidance for your IT staff.