[OJS 3.2.1-1]: OAI earliestDatestamp problem

Software Support
,
1

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
2

Hi @Antonio_Fracasso,

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

Regards,
Alec Smecher
Public Knowledge Project Team

3

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

4

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

5

Hi @asmecher,

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

OAI record:

Selezione_004
Selezione_0041863×941 132 KB

Query N.1

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

Selezione_005
Selezione_0051170×84 11.7 KB

Query N.2

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

Selezione_006
Selezione_006979×69 9.16 KB

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;

Selezione_007
Selezione_0071575×73 12.7 KB

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

Thank you very much!

Regards
Antonio

6

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

2 Likes
7

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

9

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

11

@asmecher thank you very much. Your solution works well. Now I’m trying to mapping old data to the new field issues.last_modified.
Thank you very much.

Regards
Antonio

1 Like