DOI is an important field that should be fetched if possible. In particular, when a new scientific publication appears may have DOI assigned but no volume or pages assigned. In this case the DOI is the only way to unequivocally reference such publication. I think we should make a priority to fetch always the DOI, if possible.
No, I do not imply that JabRef discards the DOI. As far as I know Google Scholar does not include DOI field in the bibtex file it provides.
However, the answer to “The Google Scholar fetcher should also fetch the abstract” seems to insinuate that the abstract could be fetched somehow using the DOI.
If this is indeed the case then it means that you have somehow access to the DOI itself and therefore it could be also included despite google Scholar not providing it directly. If I misunderstood this point then I guess that it won’t be possible to obtain DOI from the google scholar web search option.
I was referring to the “Lookup DOI” feature which is accessible in the “General” tab of the entry editor next to the DOI field:
Using this button it is tried to automatically determine the DOI - but the result should be checked as there are sometimes false matches resulting in a wrong DOI. (Which is also the reason we do not perform this lookup automatically for Google Scholar)
Neither DBLP nor PubMed are right for my topic, which is energy/engineering.
If I don’t know the DOI of a publication, I usually get better success from (1) using Google Scholar search for initial data, then (2) Lookup DOI to get improved data, however JabRef is doing that. Given the faultiness of so many of the Google Scholar citations, perhaps this approach could be automated, as a user option when using Google Scholar lookups.
Using this data source directly for searching instead of Google Scholar should improve the quality of the entries quite a lot - thus, I just created an issue at GitHub to make crossref.org available as “Web Search” fetcher in JabRef:
Performing automated (or even configurable) clean ups after fetching is on our “long term TODO list” but as this requires some more effort this won’t be implemented fast as we are constantly lacking man power…