Closed dhimmel closed 5 years ago
It's actually not really parsing/enforcing any of those other ones — those formats are all just identifiable without prefixes. PMIDs, too, are just extracted regardless of a colon-terminated prefix, but since they're just generic numbers, there was some stricter logic that caused it to skip extracted PMIDs that didn't match the full input string. I've relaxed that in 5848d9e to allow a "pmid:" prefix.
(I've also fixed an issue that was causing PMIDs to be queried in Crossref first unnecessarily.)
The following identifiers are able to be searched:
doi:10.1371/journal.pcbi.1006561
arxiv:1604.05363v1
isbn:97813399198811
However,
pmid:30571677
does not succeed, but rather requires no prefix like30571677
. Ifpmid:
prefix is applied, translation-server returnsNo identifiers found
. Query below:Would it make sense to support a
pmid:
prefix, as well as apmcid:
prefix if PMCID support is added? For users that know what type of ID they are passing, it is preferable to prevent translation-server from guessing the identifier type.