[OJS 3.2.1-1]: OAI earliestDatestamp problem

Dear all,

recently I’ve migrated OJS from 2.4.8.5 to 3.2.1-1.
I found any problems with OAI exit:

  1. When I call /index.php/index/oai?verb=Identify, I find that “Datestamp of response” and “Earliest Datestamp” are quite similar, eg: 2020-07-21T14:00:02Z vs 2020-07-21T14:00:02Z and both the dates show current date.

  2. When I call /index.php/index/oai?verb=ListRecords&metadataPrefix=oai_dc, I receive a lot of records with value of “Datestamp” valorized at today date.

These problems make harvesting very difficult and almost useless.

Has anyone experienced similar problems?

Thank you very much.
Antonio

1 Like

Hi @Antonio_Fracasso,

Is your OAI interface enabled? Check the “Distribution” area of Journal Settings.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

all the OAI interfaces are enabled on our multi journals installation.
We have disabled and re-enabled OAI interfaces but we have the same problem.

Thank you for your help
Regards
Antonio

Hi @Antonio_Fracasso,

  • What DBMS are you using (PostgreSQL or MySQL)?
  • Can you run the following queries for an article ID that’s showing a changing datestamp?
    SELECT s.* FROM submissions s WHERE s.submission_id=123;
    SELECT p.* FROM submissions s JOIN publications p ON (s.current_publication_id = p.publication_id) WHERE s.submission_id=123;
    SELECT i.* FROM submissions s JOIN publications p ON (s.current_publication_id = p.publication_id) JOIN publication_settings ps ON (ps.publication_id = p.publication_id AND ps.setting_name='issueId') JOIN issues i ON (i.issue_id = ps.setting_value) WHERE s.submission_id=123;
    

…with the article ID in place of 123 for each?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

OJS runs on mysql.
I’ve checked your query for article ID 67 that it presents the altered datestamp.

OAI record:

Query N.1

SELECT s.* FROM submissions s WHERE s.submission_id=67;

Query N.2

SELECT p.* FROM submissions s JOIN publications p ON (s.current_publication_id = p.publication_id) WHERE s.submission_id=67;

Query N.3

SELECT i.* FROM
submissions s JOIN publications p ON (s.current_publication_id = p.publication_id)
JOIN publication_settings ps ON (ps.publication_id = p.publication_id AND ps.setting_name=‘issueId’)
JOIN issues i ON (i.issue_id = ps.setting_value)
WHERE s.submission_id=67;

We have register that on 8000 oai records, 45% of these show altered datestamp.

Thank you very much!

Regards
Antonio

Hi @Antonio_Fracasso,

I think the issue.last_modified date is the problem – it’s set to null. Could you test whether setting that column starts presenting the datestamp via OAI properly?

Regards,
Alec Smecher
Public Knowledge Project Team

Good day @asmecher
Plz, What are the precedures to fix this error
Regards

Hi @asmecher
Is there another way to index ojs in google scholar without OAI
Regards

Hi @amirtfiha1,

I’m not even sure that Google Scholar uses the OAI interface. Unfortunately you’ll have to ask them.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher
I coudnot know how to deal with wronge datestamp, so I delete the issuse which have wrong datestamp and republished again, I still have this
fail in Checking for correct use of resumptionToken (if used)

REQUEST http://journal.tishreen.edu.sy/index.php/engscnc/oai?verb=ListRecords&metadataPrefix=oai_dc GET

WARN Bad HTTP status code from server: 500

FAIL Can’t parse malformed XML in response to ListRecords request. Cannot complete test for correct use of resumptionToken (if used)