cr_cn: support link-based content type requests for more formats

[njahn82]

While using cr_cn, I realized that one doi works with link-based content type requests

curl http://api.crossref.org/works/10.5604/20831862.1134311/transform/application/vnd.crossref.unixsd+xml

but not with accept header statements

curl -LH "Accept: application/vnd.crossref.unixsd+xml http://dx.doi.org/10.5604/20831862.1134311

In order to avoid confusion in future, I thought it might be helpful, if we switch to link-based content type requests not only for citeproc-json (see #62), but for all formats except text and datacite-xml

[njahn82]

created a pull request #86

What do you think @sckott ?

[sckott]

Thanks for raising this and the PR.

In principle seems like a good idea, but I do want to make sure this is a move that Crosssref folks think is a good idea. E.g., I wonder if non-Crossref DOIs will still work against api.crossref.org

[njahn82]

Right. As an alternative, we could add an format option in cr_works to avoid conflicts with non-CrossRef DOIs

[sckott]

Hmm, I don't follow. Can you clarify?

One problem with moving to api.crossref.org is we'd have to check minting agency first, which is another API call (e.g., http://api.crossref.org/works/10.5284/1011335/agency for a datacite DOI, for a medra DOI http://api.crossref.org/works/10.3233/978-1-58603-887-8-100/agency) - I'd rather not do another API call, but it is very fast, so we could try it

Hmm, looks like medra doesn't support link based requests, I guess we just always do doi.org for those DOIs

[njahn82]

I thought of providing an extra parameter

cr_works("10.5604/20831862.1134311", format = "crossref-xml")

for people who want to re-use the raw output within R.

The cr_works documentation warns that this function only works for CrossRef DOIs, so the agency is transparent to the users.

[njahn82]

Sorry, just realize this would only work for querying DOIs, but not when filtering etc like

http://api.crossref.org/works?filter=has-orcid:true,from-pub-date:2004-04-04

[sckott]

I see, thanks. I'd rather keep the use cases clearly differentiated. Where cr_works() gets the metadata crossref gives back on works, while cr_cn() does content negotiation.

I think if we had cr_works() do content negotiation as well it would be less predictable in outputs

Sorry, just realize this would only work for querying DOIs, but not when filtering etc like

right, would only work for api.crossref.org/works/<doi>

[sckott]

I think we can try link based requests, but checking minting agency first, and then do the best thing given the agency

[sckott]

@njahn82 Sound good to do a minting agency check first, then proceed with either link based or header passing?

[njahn82]

Sounds good! Would be happy to help with the first attempt.

[sckott]

please do if you have time

[njahn82]

guess, I close it now?

[sckott]

maybe, but in #87 you said

The next step could be that cr_cn only allows content types as argument, which are supported by the respective agency. According to http://www.crosscite.org/cn/ supported content types differ.

[njahn82]

I would rather open a new ticket like "Let cr_cn check supported content types for each doi minting agency"

[sckott]

ok