asking input re "identifier" rel type
20 views
Skip to first unread message
Herbert Van de Sompel
Dec 15, 2016, 11:27:31 AM12/15/16
to signposting, Herbert Van de Sompel
Dear all,
I would like to ask you all to consider an issue that just popped up:
(1) The core purpose of the - yet te be formally specified - "identifier" relation type is to express a URI that is preferred over the URI of the resource that provides the link. For example, a landing page would use the "identifier" link to point at the DOI HTTP URI because referencing the latter is preferred over referencing the landing page URI. In this specific example, the "identifier" link somehow functions as the inverse of the HTTP 302/303 redirect that leads from the preferred identifier to the less preferred one.
(2) One of the Author patterns released yesterday uses links with the "identifier" relation type in a rather different manner; see examples http://signposting.org/author/figshare/ and http://signposting.org/author/dtu/ . Rather than linking to a preferred identifier as in the above case, the link is to a somehow "equivalent" identifier. In one example, it links from the Figshare URI of Martin Fenner to the ORCID URI of Martin Fenner. It expresses that the source and target URIs of the link identify the same thing (sorry for referring to you as a thing, Martin, but it's for the good cause), not necessarily describing it in the same way. This is very useful information as it can lead to the construction of a "bag" of equivalent URIs.
One can see that "identifier" links as per (1) could be used by e.g. reference managers or bookmarking tools to record the preferred identifier (e.g. DOI HTTP URI) instead of the URI of the resource that provides the link (e.g. the landing page). That's the goal, really. However, that URI "replacement" behavior is not desired for (2): Figshare is not expressing that its URI for Martin should be replaced by his ORCID URI, rather it is sharing useful information that there's another URI for Martin. Actually, it is possible that ORCID also provides useful information by linking from Martin’s ORCID URI to his Figshare URI, clearly making a "replacement" behavior impossible.
In conclusion:
(A) It seems that the use of the "identifier" relation type with semantics (and intended behavior) as in (1) is not appropriate for (2).
(B) Expressing the equivalence-style relation as per (2) is very helpful but should be done with another relation type, not "identifier".
(C) It follows that another relation type should be used for (2), either:
I would like to ask you all to consider an issue that just popped up:
(1) The core purpose of the - yet te be formally specified - "identifier" relation type is to express a URI that is preferred over the URI of the resource that provides the link. For example, a landing page would use the "identifier" link to point at the DOI HTTP URI because referencing the latter is preferred over referencing the landing page URI. In this specific example, the "identifier" link somehow functions as the inverse of the HTTP 302/303 redirect that leads from the preferred identifier to the less preferred one.
(2) One of the Author patterns released yesterday uses links with the "identifier" relation type in a rather different manner; see examples http://signposting.org/author/figshare/ and http://signposting.org/author/dtu/ . Rather than linking to a preferred identifier as in the above case, the link is to a somehow "equivalent" identifier. In one example, it links from the Figshare URI of Martin Fenner to the ORCID URI of Martin Fenner. It expresses that the source and target URIs of the link identify the same thing (sorry for referring to you as a thing, Martin, but it's for the good cause), not necessarily describing it in the same way. This is very useful information as it can lead to the construction of a "bag" of equivalent URIs.
One can see that "identifier" links as per (1) could be used by e.g. reference managers or bookmarking tools to record the preferred identifier (e.g. DOI HTTP URI) instead of the URI of the resource that provides the link (e.g. the landing page). That's the goal, really. However, that URI "replacement" behavior is not desired for (2): Figshare is not expressing that its URI for Martin should be replaced by his ORCID URI, rather it is sharing useful information that there's another URI for Martin. Actually, it is possible that ORCID also provides useful information by linking from Martin’s ORCID URI to his Figshare URI, clearly making a "replacement" behavior impossible.
In conclusion:
(A) It seems that the use of the "identifier" relation type with semantics (and intended behavior) as in (1) is not appropriate for (2).
(B) Expressing the equivalence-style relation as per (2) is very helpful but should be done with another relation type, not "identifier".
(C) It follows that another relation type should be used for (2), either:
- An already registered one, as per http://www.iana.org/assignments/link-relations/link-relations.xhtml: Possibilities include "about”, "describes”, and “related” but both are defined rather generically and neither expresses a kind of equivalence.
- A to-be-defined one: This would require some work. But (a) a specification needs to be written to define the "identifier" relation anyhow and both could be handled in the same spec (b) defining it would allow to be more precise regarding the equivalence notion.
Please do share your insights about this issue. Input is essential on this one.
Greetings
Herbert
Please do share your insights about this issue. Input is essential on this one.
Greetings
Herbert
--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126
==
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126
==
Martin Fenner
Dec 15, 2016, 11:54:05 AM12/15/16
to Herbert Van de Sompel, signposting
Herbert,
thanks for taking me as an example :). I wasn't even aware of that Figshare page, or have forgotten about it. As someone working for a PID provider, and having worked with ORCID for a long time, I think that the "identifier" relation also works for people. This is also how I have implemented at DataCite: curl -I https://search.datacite.org/contributors/0000-0003-1419-2405. I agree that the meaning of that "identifier" relation is different than for a publication with a DOI, but I think it is important to have a concept of a preferred identifier that is persistent and expressed as stable HTTP URI (the figshare or dtu page might go away any day, or have a different URL). This is different from having multiple pages with information about a person linked to each other.
The interesting question is reciprocal linking, i.e. from ORCID to figshare and DTU. The ORCID Metadata has something called "external-id" for this, and they could expose all "external-ids" registered by the user in the link header. Not sure about the appropriate "rel", though. I am working on pushing Github usernames as external-id into ORCID records, and it would be nice to see them not only in the API response, but also as link headers.
And of course it would be nice to also include the following in both the author pages at figshare and dtu and the author HTTP URI at ORCID:
Link: <http://schema.org/Person>; rel="type"
Best,
Martin
--
You received this message because you are subscribed to the Google Groups "signposting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signposting...@googlegroups.com.
To post to this group, send email to signp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/CAOywMHeo2Xf1OSREr3EFK6rNPpOrNYoz1_LR9FF3yJ4SGsnDCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Martin Fenner
DataCite Technical Director
http://orcid.org/0000-0003-1419-2405
Herbert Van de Sompel
Dec 15, 2016, 12:49:02 PM12/15/16
to Martin Fenner, signposting
Hi Martin
Thanks for your feedback! I'm interested in hearing what others think.
One quick response re:
That will be part of a Resource Type pattern that we will start working on soon. Meaning in January, probably.
Cheers
Herbert
Herbert Van de Sompel
Dec 16, 2016, 5:42:32 AM12/16/16
to Martin Fenner, signposting, Herbert Van de Sompel
On Thu, Dec 15, 2016 at 5:53 PM, Martin Fenner <martin...@datacite.org> wrote:
Herbert,thanks for taking me as an example :). I wasn't even aware of that Figshare page, or have forgotten about it. As someone working for a PID provider, and having worked with ORCID for a long time, I think that the "identifier" relation also works for people. This is also how I have implemented at DataCite: curl -I https://search.datacite.org/contributors/0000-0003-1419-2405. I agree that the meaning of that "identifier" relation is different than for a publication with a DOI, but I think it is important to have a concept of a preferred identifier that is persistent and expressed as stable HTTP URI (the figshare or dtu page might go away any day, or have a different URL).
Agreed. As long as the intent of providing the "identifier" link is to express that the target URI of the link is preferred for referencing over the anchor URI of the link (the URI of the resource that provides the link) that is, of course legitimate. Also, from the perspective of the "identifier" relation type the type of the resources that are involved in the links (papers, authors, datasets, movies, blogs, ..) doesn't matter. The links are between web resources that have URIs.
This is different from having multiple pages with information about a person linked to each other.The interesting question is reciprocal linking, i.e. from ORCID to figshare and DTU. The ORCID Metadata has something called "external-id" for this, and they could expose all "external-ids" registered by the user in the link header. Not sure about the appropriate "rel", though. I am working on pushing Github usernames as external-id into ORCID records, and it would be nice to see them not only in the API response, but also as link headers.
That is, indeed, the second case I was discussing, the one for which I argued we need another relation type and you seem to agree. We can tink a bit about an appropriate name for the rel type, which makes sense web-wide but I do think we agree re what we are talking about. Note again, that the provision of such links would be very useful. For example, in our EgoSystem work (see http://journal.code4lib.org/articles/9519), we had to use all kinds of error-prone techniques to discover various identities of researchers.
Cheers
Herbert
To unsubscribe from this group and stop receiving emails from it, send an email to signposting+unsubscribe@googlegroups.com.
To post to this group, send email to signp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/CAOywMHeo2Xf1OSREr3EFK6rNPpOrNYoz1_LR9FF3yJ4SGsnDCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--Martin Fenner
DataCite Technical Director
http://orcid.org/0000-0003-1419-2405
--
You received this message because you are subscribed to the Google Groups "signposting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signposting+unsubscribe@googlegroups.com.
To post to this group, send email to signp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/CAG9q6AZHX2KdVRMF%3DL0nM0Ce%2BsgxBxnZF0m%2BHuTcBbi7Z%2Bk3ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages