Fix DOI fetcher and add documentation on fetcher trust levels

[koppor]

Follow-up to This reverts #6937 in order to add documentation on our decisions taken in 2018.. That PR added a workaround to thing introduced in 15c7981.

In this PR,

• A bug in DoiResultion is fixed: String similarity was used (where it should not have been)
• Documentation on fetcher trust levels is added

Small, unlreated changes:

• Fix reading of keys from build.properties. Gradle wrote literally null in the generated build.properties. It was changed to contain "" instead of "null" for an unknown key
• Fix typo "chache"

Side note: It seems that 15c7981 accidently committed to the master branch and not using a PR.

• Change in CHANGELOG.md described (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[tobiasdiez]

Thanks!

I still think that Publisher should be a higher priority as Source. They also take the DOI into account, but use the publisher-specific API to get the fulltext url. Thus, they are more reliable than just following the DOI and then trying to guess the PDF path from the webpage.

[stefan-kolb]

Thanks!

I still think that Publisher should be a higher priority as Source. They also take the DOI into account, but use the publisher-specific API to get the fulltext url. Thus, they are more reliable than just following the DOI and then trying to guess the PDF path from the webpage.

• Publisher can only be higher ranked than source if it ALWAYS searches via DOI and does not return close/related results or even searches based on strings.
• We might switch priority then but should rename SOURCE to e.g. DOI then
• Another "problem" is that the downloads might take longer than before as they Publisher fetcher s are generally not that fast compared to the direct DOI forwarding

[tobiasdiez]

Ok, so we have: Publisher_Identifier (use doi or other identifier, uses publisher API), Identifier (general identifier-based), Publisher (not identifier-based), preprint, other

I'm not sure if the distinction between publisher with and without identifier is really necessary, but that should make it clear also in the future.

[koppor]

The issue is about full-text fetchers.

The issue was that one fetcher implementeation fetches the complete proceedings and the other fetcher fetches the concrete paper. A DOI points to the paper; the publisher fetcher fetches the complete proceedings. This is unintended.

I will try to pair-up with @stefan-kolb

[stefan-kolb]

We fixed a similarity problem inside the DoiResolution that REALLY caused this issue.

[tobiasdiez]

Generally, LGTM. One question though.