To gather all the publications of a single author, two methods are described in the DBLP in the section of F.A.Q. But the problem is how to follow the precedure is notb well described. Can anybody help, in this regard.
The source of the next section is https://dblp.org/faq/How+can+I+fetch+all+publications+of+one+specific+author.html
There are actually two ways to achieve this.
Method 1: Using the explicit person page export API (recommended)
For each person page in dblp you can access its information directly in different export formats, such as XML, BibTeX, RDF triples, or as RSS Feed. See these example URLs:
To find the PID-based resource URI of a particular researcher, please visit that researcher's dblp web page and find the short URL within the "share" drop-down menu next to the researcher's name in the title bar.
Method 2: Using the dblp publication search API
There exists an individual search token for each person in dblp that can be used to retrieve exactly the publication records associated with that person via the publication search API. To obtain that token, please visit the researcher's dblp page and look for the "view this author in dblp search" link in the "ask others" drop-down menu next to the researcher's name in the title bar. If you follow that link you will find the token entered into the search field. You can use that token to obtain search results in the search API in different formats, e.g.:
That token may also be combined with other search query tokens to obtain more complex search results.
Which method should I choose?
We recommend to use Method 1 when building external services that load data from dblp. This is since the search tokens from Method 2 are not as stable as the PIDs from Method 1. In fact, a search token from Method 2 will definitely change if we ever have to change the surface form of the name associated with it (e.g., if we add a missing middle name, fix a diacritic, or if we have to split the profile because a second, homonymous researcher has emerged).
On the other hand, the PIDs from Method 1 are explicitly intended to be persistent identifiers that will never change for a profile. There might still be rare cases where a profile is severely "broken" (i.e., mixes up several identities indiscriminately) such that we would have to retire a PID and mint new ones, but those cases should be rare.
Unfortunately, the publication search API from Method 2 does not understand the PIDs from Method 1 (yet).