Note that other Signposting patterns can also be leveraged by the citeas.org service. Links with the "describedby" relation type provided by the landing page URI lead to bibliographic information about the artifact the landing page is about. Using the same landing page as above, the complete HTTP Link header is as follows:

curl -I https://easy.dans.knaw.nl/ui/datasets/id/easy-dataset:61891

HTTP/1.1 200 OK
Date: Fri, 20 Dec 2019 08:28:07 GMT
Link: <https://doi.org/10.17026/dans-zm3-nkk4> ; rel="cite-as",
 <https://doi.org/10.17026/dans-zm3-nkk4> ; rel="describedby" ; type="application/vnd.datacite.datacite+xml",
 <https://doi.org/10.17026/dans-zm3-nkk4> ; rel="describedby" ; type="application/vnd.citationstyles.csl+json"
Content-Type: text/html;charset=UTF-8
Content-Language: en-US

The bibliographic information that is linked to is - in this case - obviously also available from the DOI API. But that requires the client to have out-of-bound knowledge about that API. With the above "describedby" links, a client can just follow its nose to the metadata.

This is great! I am close to implementing it within CiteAs. One issue I have found with the above example is that there are actually two cite-as relations returned for that link:

<https://doi.org/10.17026/dans-zm3-nkk4> ; rel="cite-as",
<http://www.persistent-identifier.nl?identifier=urn%3Anbn%3Anl%3Aui%3A13-z7og-v8> ; rel="cite-as"

Requests has good support for these headers, but in this case it returns the second link:

import requests
r = requests.get('https://easy.dans.knaw.nl/ui/datasets/id/easy-dataset:61891')
print(r.links['cite-as']['url'])
http://www.persistent-identifier.nl?identifier=urn%3Anbn%3Anl%3Aui%3A13-z7og-v8

I think the DOI may be better but that would involve manual parsing of the headers. I prefer to use requests as it will provide consistent results. Do you think the second result is bad? It's still pointing to a cite-as reference that the author apparently intended.

To me this seems like a bug with Requests in that it looks like it is unable to parse multiple links with the same link relation type. Meaning a similar problem would occur for Link headers with eg multiple “alternate” links (instead of “cite-as” links), which is rather common. Maybe an issue should be posted for Requests with this regard?

BTW in most current implementations there will only be a single “cite-as” link, typically pointing at a DOI. But multiple persistent identifiers for a resource is not really uncommon. So, it would be better to tackle the issue at the source, which - I speculate - is Requests.

Yes I'm with you. Requests should be returning a list rather than a single item. I'll implement this with Requests but also submit an issue so that it hopefully gets fixed. Or maybe they have a suggestion on how to handle these situations. It would be nice to iterate through the list and look for a DOI.