search

sul-dlss / sul_pub

SUL system for harvest and managing publications for Stanford CAP, with controlled API access.
http://cap.stanford.edu
Other
8 stars 3 forks source link

Publications added by authorship controller can sometimes include MEDLINE: prefix #1653

Closed peetucket closed 1 year ago

peetucket commented 1 year ago

Reported in #sul-cap-collab : 

When trying to add a publication by searching, using the 'Add New Publication' search by title and year option, after getting the results of the search, and clicking on '+Add' for some publications, we are seeing the error message:
"Unable to update this publication right now.  Please try again later."
For example, trying searching for "Trends in Maxillofacial Trauma During COVID-19 at a Level 1 Trauma Center"  in "2022", the search results return:
Trends in Maxillofacial Trauma During COVID-19 at a Level 1 Trauma Center ENT-EAR NOSE & THROAT JOURNAL
Longino, E. S., Landeen, K. C., Wessinger, B. C., Kimura, K. S., Davis, S. J., Shastri, K. S., Stephan, S. J., Patel, P. N., Yang, S. F.
2022
Then I select to add the publication to the profile and it gives the above noted error.
peetucket commented 1 year ago

Investigation of this by (1) searching for the title above on the PublicationsController#sourcelookup method (which is what the API call for searching for publications uses) https://github.com/sul-dlss/sul_pub/blob/main/app/controllers/publications_controller.rb#L152C4-L152C4 and then (2) taking the resulting IDs and sending a message to AuthorshipsController#create

This worked as expected for the publication above. However, I noticed the response from the sourcelookup includes a PMID even though the search is from WoS. The PMID includes the "MEDLINE:" prefix. If you send a PMID with a MEDLINE: prefix to the authorship controller instead of sending the WOS_UID, the publication is not found. This is because when we get a request to add a publication for a specific PMID, we go straight to the Pubmed API to look for that PMID, and to do this, we do NOT want the MEDLINE: prefix.

I suspect the Profiles code is inspecting the response, and if it finds a PMID, it sends that preferentially over the WOS UID. (I verified that ONLY send the PMID in this example, even though our search result included both the WOS UID and the PMID) Previously I suspect the WOS record was not including the PMID, so Profiles was sending the WOS UID. Now the WOS response includes the PMID, so they are sending that instead, and with the MEDLINE: prefix, the lookup fails when adding.

peetucket commented 1 year ago

Solutions:

  1. The Profiles team should send the WOS UID when adding a publication if they have it in the result set preferentially over the PMID.
  2. We can strip the MEDLINE: prefix from any PMID sent.

The first is the best solution, but will likely take time from them to implement unless they are actively working on the code. In the meanwhile, we can implement two very easily. The only potential issue is that the search results will have come from WoS, but when they add the publication, it will actually come from Pubmed. I believe this is fine though, the metadata should all be the same.

peetucket commented 1 year ago

Also, we are creating Pubhash records with invalid Pubmed URLs that look like this: https://www.ncbi.nlm.nih.gov/pubmed/MEDLINE:35414268