Refactor ORCID disambiguation to be more precise and comprehensive

[jvwong]

• Search the ORCID public API using fielded search: DOI, 'self'
• For unique last names, match the ORCID search result on last alone, else resort to first name
• Store the ORCID accession (local ID) rather than the url moving forward
• Lots of weird edge cases like
  • PubMed putting ORCIDs in the wrong format
  • PubMed can store the ORCID URL or the accession

Refs #1064

[jvwong]

@metincansiper do you remember why the Document provided field has a name attribute rather than just using the authorName?

factoid/src/server/routes/api/document/index.js

Lines 1911 to 1917 in 94586cc

	const handleAuthorName = doc => {
	if ( !authorName ){
	return doc;
	}
	return doc.provided( { name: authorName } ).then( () => doc );
	};

[metincansiper]

@metincansiper do you remember why the Document provided field has a name attribute rather than just using the authorName?

factoid/src/server/routes/api/document/index.js

Lines 1911 to 1917 in 94586cc

	const handleAuthorName = doc => {
	if ( !authorName ){
	return doc;
	}
	return doc.provided( { name: authorName } ).then( () => doc );
	};

@jvwong I actually could not remember any specific reason for that. I suspect it may just be a confusion of me at that time. Actually, it seems like that name is used instead of authorName but both of them are being available because authorName is used as is during the doc creation and name is added later as a new field.

See this line (https://github.com/PathwayCommons/factoid/blob/unstable/src/client/components/editor/title.js#L60) and line 43 above that authorName is retrieved from document.provided() and it seems to be working since authorName is also available (BTW I guess in line 60 it may make sense to use the already defined provided variable).

There may be 2 things we must consider before removing name field:

• There may be a very little possibility that there would be reason behind setting name filed that I cannot remember now.
• Because of some possible dynamic/implicit assignment of field names etc. we may end up with having a bug while renaming that field (as it is used by different parts of the code now, probably implemented by different people I may miss something).

Considering the 2 thing above and that both of the fields (name and authorName) are available, maybe we can consider keeping the name field but replacing any explicit usage of it with authorName and add a comment to where name field is introduced so that we would encourage usage of authorName instead of it.

I can make the needed changes we agreed on after this PR is merged.

What do you think?

[metincansiper]

@jvwong looks good to me!

[jvwong]

There may be 2 things we must consider before removing name field:

I agree that's its probably redundant.

Considering the 2 thing above and that both of the fields (name and authorName) are available, maybe we can consider keeping the name field but replacing any explicit usage of it with authorName and add a comment to where name field is introduced so that we would encourage usage of authorName instead of it.

I won't change anything right now. I think these changes, if made, could be part of another issue so don't worry about making any changes.

Thanks!