feat(fetcher): implement SearchBasedFetcher for ScienceDirect using scopus search API

[Siva-Sai22]

Closes #14421

Implemented web search capability for ScienceDirect by integrating the Scopus Search API, since the ScienceDirect Search API requires institutional access that most users don't have. Added a new ScopusQueryTransformer to convert JabRef search queries to Scopus query syntax, and rewrote the ScienceDirect class to implement PagedSearchBasedParserFetcher interface, enabling paginated search results with proper JSON response parsing, this allows users to search academic literature via the "Web search" feature in JabRef, which was previously not available for ScienceDirect.

Steps to test

• Go to settings -> preferences -> websearch.
• Add the ScienceDirect API key and test it.
• Then search using the ScienceDirect (Example query: Einstein)

Mandatory checks

• [x] I own the copyright of the code submitted and I license it under the MIT license
• [x] I manually tested my changes in running JabRef (always required)
• [x] I added JUnit tests for changes (if applicable)
• [x] I added screenshots in the PR description (if change is visible to the user)
• [x] I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
• [x] I checked the user documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

[github-actions[bot]]

Hey @Siva-Sai22! 👋

Thank you for contributing to JabRef!

We have automated checks in place, based on which you will soon get feedback if any of them are failing.

After all automated checks pass, a maintainer will also review your contribution. Once that happens, you can go through their comments in the "Files changed" tab and act on them, or reply to the conversation if you have further inputs.

Please re-check our AI Usage Policy to ensure that your pull request is in line with it. It also contains links to our contribution guide in case of any other doubts related to our contribution workflow.

[koppor]

Another view - from

[Siva-Sai22]

• [ ] API key should renamed from "Scopus" to "Esevier", since it covers both.

@koppor But the ScienceDirect is accessing the api key using the FETCHER_NAME (ScienceDirect). If we rename it to Esevier we have to change the fetcher name also importerPreferences.getApiKey(getName())

I think it would be better to take a scopus api key also.

[koppor]

• [ ] API key should renamed from "Scopus" to "Esevier", since it covers both.

@koppor But the ScienceDirect is accessing the api key using the FETCHER_NAME (ScienceDirect). If we rename it to Esevier we have to change the fetcher name also importerPreferences.getApiKey(getName())

I think it would be better to take a scopus api key also.

I searched for the code you gave

It seems that EACH FETCHER uses that thing.

Since the new fetcher is a SearchBasedFetcher displayed in the preferences, the old fetcher should use the key of the other fetcher. With that, both fetchers will share the same key and it can be configured.

Update That means, my idea with "Elsevier" was wrong and a concrete fetcher name is used. -- Please double check with the preferences code.

[Siva-Sai22]

@koppor I have checked the preferences code The api key is stored in a keyring and retrieved using the same when called using the concrete fetcher name So I think we can't have the same api key name for the two different fetchers.

I have changes in which we allow the user to input the api key for scopus (same as the scienceDirect one) and can display the search results.

If you are okay with this approach I will update the PR.