Shouldn't we return document instead of multiple when there's a single DOI? Even if it's invalid or not found, there's still no reason to show the Select Items dialog. (That would only make sense if it could actually result in a different item from the one you were expecting.)

Do we want to change this behavior for DOIs that are scraped from document too? Why then it was set to return multiple?

No. In the page we don't know if it describes the main item for the page. In the URL we do.

If a random string, which looks like a DOI, is extracted from a URL, it would prevent the further DOIs from document extraction. Which means if we want to return a single item we have to firstly resolve DOI metadata to make sure it's valid. And if not then extract and resolve items from a document. The current commit just puts all DOIs into one list, where all items are resolved and user just needs to select which one he thinks is correct. To be able to separately resolve DOI extracted from URL and from document, we would probably need serious modifications of the translator.

So as I said previously, it's not that rare to encounter web page URLs that contain a DOI, but we can't extract it reliably. For example:

URL: http://iopscience.iop.org/article/10.1088/0004-637X/768/1/87
Extracted DOI: 10.1088/0004-637X/768/1/87
Actual DOI: 10.1088/0004-637X/768/1/87

URL: http://journal.frontiersin.org/article/10.3389/fmicb.2014.00402/full
Extracted DOI: 10.3389/fmicb.2014.00402/full
Actual DOI: 10.3389/fmicb.2014.00402

And we can't do anything about this.

DOI from URL can be extracted incorrectly but it applies not only for the web page URL, but also for URLs found in the body.

For DOI(s) extracted from a web page URL there are a few possible outcomes:

1. It's correct and results to correct metadata
2. It's incorrect and results to no metadata
3. It's correct but results to no metadata (DOI RAs don't have it, i.e. JSTOR)
4. It's incorrect and results to incorrect metadata - is not possible, I would say. Except maybe in same rare cases it can result to the actual journal instead of the article

So the translator should work like this, depending on where and how many DOIs were found:

• one in URL - single
• one in URL, one in body and they are equal - single
• one in body - multiple
• in all other cases - multiple

URL: http://iopscience.iop.org/article/10.1088/0004-637X/768/1/87
Extracted DOI: 10.1088/0004-637X/768/1/87
Actual DOI: 10.1088/0004-637X/768/1/87

Is this what you meant? These are the same.

URL: http://journal.frontiersin.org/article/10.3389/fmicb.2014.00402/full
Extracted DOI: 10.3389/fmicb.2014.00402/full
Actual DOI: 10.3389/fmicb.2014.00402

And we can't do anything about this.

We could try stripping some likely suffixes, like /full and /pdf.

We could try stripping some likely suffixes, like /full and /pdf

given the most common academic CMS's, /full$ /pdf$
(as per the above examples)
/abstract$ and /abs$ (speculating about these -- I've mainly seen them before the DOI where they're no problem)

(edit: removed the ones already covered by the regex)

URL: http://iopscience.iop.org/article/10.1088/0004-637X/768/1/87
Extracted DOI: 10.1088/0004-637X/768/1/87
Actual DOI: 10.1088/0004-637X/768/1/87

Is this what you meant? These are the same.

Yeah, I just wanted to demonstrate the difference between the two URLs.

URL: http://journal.frontiersin.org/article/10.3389/fmicb.2014.00402/full
Extracted DOI: 10.3389/fmicb.2014.00402/full
Actual DOI: 10.3389/fmicb.2014.00402
And we can't do anything about this.

We could try stripping some likely suffixes, like /full and /pdf.

Worth to investigate this idea, but there can be many variants. More examples:
http://www.oxfordreference.com/view/10.1093/acref/9780199608218.001.0001/acref-9780199608218
http://onlinelibrary.wiley.com/journal/10.1111/%28ISSN%291470-9856/issues
http://iopscience.iop.org/article/10.1088/0022-3727/34/10/311/meta