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.

The first version of this is implemented on the site:

http://citeas.org/cite/https://easy.dans.knaw.nl/ui/datasets/id/easy-dataset:61891

I would love to see some additional examples if you have any. After using it a few times I think it needs to be refactored into its own provenance section, so I am planning to do that next. But I wanted to get the initial feature tested and working.

As for looking at multiple links, I went to submit an issue for requests but found a way to parse the links with their utility function called parse_header_links. So this works to get the list of cite-as links so the software can find the preferred DOI link:

r = requests.get(url)
header_links = requests.utils.parse_header_links(r.headers['link'])
cite_as_links = [link for link in header_links if link['rel'] == 'cite-as']

Cool! More examples are available via the Early Adopters page of Signposting, see http://signposting.org/adopters/