is it possible to get all citations to concrete publication (by scopus_id, doi ...) with Elsevier API?
I was trying do that, by all I can do, is get count of citations, but i need Authors annd Titles al least.
For example, if I wanna do:
https://api.elsevier.com/content/abstract/citations?pubmed_id=3472723&httpAccept=application/json&apiKey={myKey}
I get:
"{"service-error":{"status":{"statusCode":"AUTHENTICATION_ERROR","statusText":"Requestor configuration settings insufficient for access to this resource."}}}"
Is it possible to get what I want?
Thanks
I had same problem, but i found this solution:
Firstly you should have json with article data and article's 'eid'. Thus, you can find all citations of this article by next query:
"https://api.elsevier.com/content/search/scopus?query=refeid(" + str(article['eid']) + ')'
article is json data of this article
Also i had problem with keywords, and solution is:
Article json has article['prism:url'] parameter, and you can use it with keywords field, so you query to get keywords is:
article['prism:url'] + "?field=authkeywords"
Mikhail's answer is the best way to reach your goal, since you need authors and titles of citing works.
But for those who come here searching for the specific error: it is due to the fact that the https://api.elsevier.com/content/abstract/citations API needs "specific permission from Elsevier", which means that you need to write to their Integration Support, explaining your use case and providing your API key.
(as explained to me via email by a member of the Integration Support itself)
Just bumped into the same problem. the interactive API of Scopus might help you a lot with this and similar issues.
How to proceed:
Visit https://dev.elsevier.com/scopus.html#!/Citations_Overview/CitationsOverview
(If you are logged in and have an API key, the API key will automatically appear in the corresponding field)
Insert the doi of the article from which the citations are required in the appropriate field.
Get Request URL - here is an example: https://api.elsevier.com/content/abstract/citations?doi=10.1287%2Fmnsc.42.4.541&apiKey={apiKey}&httpAccept=application%2Fjson
(don't forget to insert your apiKey in the curly brackets.
Hope this helps and makes things a lot easier!
In case one cannot obtain "specific permission from Elsevier" to use their API in this manner, you can use the API of OpenCitations (documentation here).
Use the URL https://opencitations.net/index/coci/api/v1/citations/{DOI}. The field name citing contains as values the DOIs of all publications that cite the {DOI}.
One example with three citations here (as of January 2021).
Related
How can I retrieve the number of citations of a paper in a given year?
I had a look at Scopus Citation Overview API but the pybliometrics documentation says the API key needs to be approved by Elsevier for this purpose, and in fact it is returning error 403.
Are there other data sources from which I can retrieve the number of citations?
The rcrossref package provides a function cr_citation_count which seems to get the number of citation today.
I need the number of citation at a given year (for instance, if a paper was published in 2010, I may need the number of citation in 2015, not as of today at 2021).
First, access the OpenCitations API with a given DOI.
Second, fetch the DOIs of all the citing papers.
Third, use these newly fetched DOIs and loop them through the CrossRef API to obtain the respective publication dates.
Example:
You are interested in obtaining all citations from the year 2020 to the paper with the DOI 10.1080/17512786.2019.1682940.
First, access OpenCitations via https://opencitations.net/index/coci/api/v1/citations/10.1080/17512786.2019.1682940 (which finds 6 citations in total).
Second, fetch the values in the field citing -- they show the DOIs of the citing papers. For example, the second citing DOI is 10.17645/mac.v8i3.3019.
Third, access CrossRef with the help of these DOIs, such as via https://api.crossref.org/works/10.17645/mac.v8i3.3019, and look at the published-field (which is 2020-07-10). Keep only those values that start with the year 2020.
Note - - maybe you could omit the third step if you fetch the creation-field in OpenCitations during the second step (it seems to be identical to the published-field in CrossRef). I haven't tested that systematically.
Be aware that the citation counts between OpenCitations and CrossRef can vary (OpenCitaions usually shows less citations than CrossRef).
I am a very new to LUIS. I am not able to use phrase list and pattern. Since I could not find any resource (Except Microsoft document), where I can get more details about it neither I could find any reference of demo.
It would be nice if any one can explain a bit in layman language in which scenario we can use both.
One more thing phrase list are not listing with entity while we are working on Utterance in intent creation
Since I could not find any resource (Except Microsoft document), where
I can get more details about it neither I could find any reference of
demo.
You can find more examples from this StackOverFlow answers about using Patterns feature and Phrase Lists other than Microsoft documentation.
It would be nice if any one can explain a bit in layman language in
which scenario we can use both.
In short Patterns are used for labeling entities which follow a specific pattern without providing more examples whereas Phrase Lists are used for providing synonyms of the utterances.
One more thing phrase list are not listing with entity while we are
working on Utterance in intent creation
Please read more about Phrase Lists about how to use it and how it works. If you still have issues send the snapshot with more details to Luisuservoice#microsoft.com.
I just wanted to know if anything changed on geocode API from 21 st February because before 21st it was validating zip code 9 digits but from yesterday it is giving an error on 9 digits zip code and now it only validating 5 digits zip code.
More information in your question would be helpful.
I haven't noticed any change, but I thought I'd take a look at the GeoCoder Documentation FAQ for you.
Yes, based on that date, I'd say something changed recently.
Perhaps this is what you're referring to, but that's only a speculation since you didn't provide any detail or examples.
Troubleshooting
I’m getting more queries that return ZERO_RESULTS with the new geocoder. What’s going on?
In the new geocoder, ambiguous, incomplete and badly formatted queries, such as misspelled or nonexistent addresses, are prone to produce ZERO_RESULTS. These queries would typically produce incorrect results in the old geocoder, such as returning the suburb if the address could not be found. We believe that returning ZERO_RESULTS is actually a more correct response in such situations.
If your application deals with user input of addresses, the Place Autocomplete feature in the Places API may produce better quality results. Place Autocomplete allows users to select from a set of results based on what they’ve typed, which allows users to choose between similarly named results, and to adjust their query if they misspell an address.
If you have an application dealing with ambiguous or incomplete queries or queries that may contain errors, we recommend you use the Place Autocomplete feature in the Places API rather than the forward geocoder available in the Geocoding API. For more details, see Best Practices When Geocoding Addresses and the Address Geocoding in the Google Maps APIs blog post.
More Information:
Documentation FAQ
Related Issue Tracker
I can't seem to find an official google plus people.search query parameters documentation. on the official page (https://developers.google.com/+/api/latest/people/search) there is only the ambivalent saying: "Specify a query string for full text search of public text in all profiles.".
But how? what about using some 'Geo', some 'by_name', a bit of 'gender'?
sorry if it's appear as a newbie question
Unfortunately, you currently cannot search by specifying metadata and scope to type on results. You can carefully craft your queries to find strings that match your target, however, and I don't recommend doing this. Please file an issue request on the Google+ issue tracker.
For example, how does StackOverflow decide other questions are similar?
When I typed in the question above and then tabbed to this memo control I saw a list of existing questions which might be the same as the one I am asking.
What technique is used to find similar questions?
I got an email from team#stackoverflow.com on Mar 20 that mentions how it works:
the "ask a question" search is
exclusively on title and will not
match anything in the body. It is a
mystery to me why people think it's
better.
The last sentence refers to the search bar, which I've found is less useful when I'm trying to find a specific question I've already seen.
I think it's plain old word matching. However, I might add that this feature does not work as well as I would like it to. It's much better to do google search with site:stackoverflow.com prefix than to rely on SO to provide the relevant suggestions.
Poorly -- using MS SQL Full Text Search, I believe. You'll have better luck using Lucene, IMO. For more background on the topic see the Wikipedia article on Lucene or the general topic of information retrieval.
The matching program would store an index of all questions. When you ask a question, all keywords in your question are matched against the index. This is similar to Google Search. Lucene open source search can be (and with high probability has been) used for this. Since the results are not quite accurate, I presume they index just the headlines of the questions, as an approximation.
The other related keyword is collaborative filtering, the algorithm popularized by Amazon to recommend products based on behavior of other similar customers. In the current case, an alternative algorithm based on collaborative filtering is: keywords are extracted from the question, then tags associated (in the history) with the keywords are found. Questions which have those tags are returned. Well, experiments are needed to see whether it works well at all.