Empty result for PubMed from Europe PubMed Central

[abargnesi]

The Europe PubMed Central seems out of sync with NCBI PubMed.

Example

Take the PMID 26672148. This was published in April of 2015.

• The Europe PubMed Central link is here. The result is empty.
• The NCBI PubMed link is here. The response contains one result.

Does it make sense to connect to multiple PubMed sources? Maybe try PubMed followed by Europe PubMed?

[wshayes]

NCBI’s web services are quite painful to use. The European one might be a little slow to pick up new records from the NLM which produces them.

If someone wants to write the library for NCBI’s service, I’m happy to use it.

On Dec 17, 2015, at 2:08 PM, Tony Bargnesi [email protected] wrote:

The Europe PubMed Central seems out of sync with NCBI PubMed.

Example

Take the PMID 26672148. This was published in April of 2015.

The Europe PubMed Central link is here http://www.ebi.ac.uk/europepmc/webservices/rest/search/resulttype=core&format=json&query=ext_id:26672148%20src:med. The result is empty.
The NCBI PubMed link is here http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=26672148&retmode=json. The response contains one result.
Does it make sense to connect to multiple PubMed sources? Maybe try PubMed followed by Europe PubMed?

—
Reply to this email directly or view it on GitHub #37.

[abargnesi]

It's actually pretty easy to use. I included the link in the original post.

For example here is PubMed 26672148 as JSON using the ESummary API.

http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=26672148&retmode=json

[wshayes]

Darn - got all excited: then saw this

http://www.fredtrotter.com/2014/11/14/hacking-on-the-pubmed-api/ http://www.fredtrotter.com/2014/11/14/hacking-on-the-pubmed-api/

http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&retmode=json&rettype=abstract&id=25081398,24792655 http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&retmode=json&rettype=abstract&id=25081398,24792655
This summary is great, but it will not get the abstracts, if and when they are available. (it will tell you if there is an abstract available however…) In order to get the abstracts you need to use the eFetch API http://www.ncbi.nlm.nih.gov/books/NBK25499/#chapter4.EFetch
http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&retmode=text&rettype=abstract&id=25081398 http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&retmode=text&rettype=abstract&id=25081398
Unlike the other APIs, there is no json retmode, the default is XML, but you can get plaintext using retmode=text. So if you want structured data here, you must use xml. Why? Because. Thats why. This API will take comma separated id list too, but I cannot see how to separate the plaintext results easily, so if you are using the plaintext (which is fine for me current purposes) better to call it a single id at a time.

On Dec 17, 2015, at 3:52 PM, Tony Bargnesi [email protected] wrote:

It's actually pretty easy to use. I included the link in the original post.

For example here is PubMed 26672148 as JSON using the ESummary API http://www.ncbi.nlm.nih.gov/books/NBK25499/#_chapter4_ESummary_.

http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=26672148&retmode=json

—
Reply to this email directly or view it on GitHub #37 (comment).

[abargnesi]

I echo Fred Trotter's sentiments. I learned the EUtils API a couple of months back, and just spent the last ten minutes reading it over again.

Anyway, who cares if it's XML? The point is to allow users to access current PubMed data.

We could make an XML request to EFetch and parse it with DOMParser. This seems well-supported in the browser as indicated here.