Subject: Request to register "identifier" relation type

From: Herbert Van de Sompel <[email-masked]>
Date: Fri, 4 Aug 2017 17:05:56 +0200

Dear

I would like to register the following relation type:

* Relation Name: identifier

* Description: A link with the "identifier" relation type indicates that
the link target is preferred over the link context for the purpose of
referencing.

* Reference: Van de Sompel, H., Nelson, M.L., Bilder, G., Kunze, J., and
Warner, S. (August 2017) Identifier: A Link Relation to Convey a Preferred
URI for Referencing.
https://datatracker.ietf.org/doc/draft-vandesompel-identifier/

While this request is based on the 00 version of an Internet Draft, we
would prefer registration at this point because:

- There has been significant communication/promotion for the use of the
"identifier" relation type in a target community (scholarly communication).
See e.g. http://signposting.org/, http://signposting.org/identifier/, and
presentations at several conferences, including PIDapalooza (Reykjavík)
OR2017 (Brisbane), DPLAFest 2017 (Chicago), OAI10 (Geneva).

- There already are adopters of the "identifier" link relation type (see,
e.g., http://signposting.org/adopters/) and support is listed the
development plan of institutional repository platforms.

- The authors are committed to taking the I-D to RFC status.

Greetings

Herbert Van de Sompel

-- 
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

==

---

From: Peter Williams <[email-masked]>
Date: Fri, 4 Aug 2017 22:20:31 -0600

On Fri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel <[email-masked]>
wrote:

> ...
> ...

How does `identifier` differ from `canonical` ("Designates the preferred
version of a resource" -- https://tools.ietf.org/html/rfc6596)?

Cheers,
Peter

---

From: Herbert Van de Sompel <[email-masked]>
Date: Sat, 5 Aug 2017 09:38:09 +0200

On Aug 5, 2017, at 06:20, Peter Williams <[email-masked]> wrote:
> 
>> On Fri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel <[email-masked]> wrote:
>> ... 
>> 
>> * Description: A link with the "identifier" relation type indicates that the link target is preferred over the link context for the purpose of referencing.
>> 
>> ...
> 
> How does `identifier` differ from `canonical` ("Designates the preferred version of a resource" -- https://tools.ietf.org/html/rfc6596)?
> 

The answer is in the I-D and in a blog post that is referenced in the I-D. Please have a look. 

Cheers

Herbert

---

From: Ed Summers <[email-masked]>
Date: Sat, 5 Aug 2017 07:59:58 -0400

> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel <[email-masked]> wrote:
> 

I think a crisp one or two sentence reply to Peter's question ought to be possible. He rightly points out that the shared use of 'preferred' by your I-D and canonical could cause some confusion for web publishers. It also begs the question of preferred *for what*.

The core issue with canonical seems to be less a matter of semantics and more a practical matter of web publishers not wanting to assign a canonical or bookmark link to another domain (e.g. dx.doi.org) because of uncertainty about what this would mean for their Google juice. There is an SEO infrastructure built up around canonical, which has led to it being used quite a bit.

I wonder if rather than adding another link relation to the mix if the HTML folks would be willing to update rel=bookmark to allow for usage with <link> which ought to make it amenable to use in an HTTP header as some other HTML relations are (e.g. alternate). The semantics of bookmark speak directly to the issue of persistence that your I-D seems to be addressing.

Also, while the name 'identifier' is elegant in some ways, I find it a bit hard to swallow since all link targets are technically identifiers.

//Ed

---

From: Herbert Van de Sompel <[email-masked]>
Date: Sat, 5 Aug 2017 14:56:59 +0200

> I think a crisp one or two sentence reply to Peter's question ought to be possible. He rightly points out that the shared use of 'preferred' by your I-D and canonical could cause some confusion for…

Good point. Here's my take on it:
- canonical: preferred for content indexing 
- identifier: preferred for referencing

> The core issue with canonical seems to be less a matter of semantics and more a practical matter of web publishers not wanting to assign a canonical or bookmark link to another domain (e.g. dx.doi.…

Publishers indeed use canonical to point to pages on their own site.  This rel type is intended eg for reference manager applications: use the target URI not the context URI in a reference. Our research (referenced in the I-D) has shown that landing page URIs (instead of HTTP DOI) are frequently used for referencing. 

> I wonder if rather than adding another link relation to the mix if the HTML folks would be willing to update rel=bookmark to allow for usage with <link> which ought to make it amenable to use in an…

Our I-D acknowledges that the semantics of "identifier" are similar to "bookmark". But "bookmark" is explicitly not allowed in <link> (and hence Link). One has to assume there were/are reasons for that choice because other rel types declared in HTML can be used in <link>.

> Also, while the name 'identifier' is elegant in some ways, I find it a bit hard to swallow since all link targets are technically identifiers.

Indeed. Then again, this relation type indicates that the target URI should be used as identifier. We have done several presentations at conferences, workshops, etc over the past months in which "identifier" was floated. It's been on the Signposting web site (which has an associated mailing list) for almost a year, see http://signposting.org/identifier/ . We have not received negative reactions to the choice of term.  Some implementations are meanwhile already out there. 

Cheers

Herbert

---

From: Michael Nelson <[email-masked]>
Date: Sat, 5 Aug 2017 13:25:03 -0400

On Fri, 4 Aug 2017, Peter Williams wrote:

> * Description: A link with the "identifier" relation type indicates that the link
> target is preferred over the link context for the purpose of referencing.
> ...
> 
> 
> How does `identifier` differ from `canonical` ("Designates the preferred version of a
> resource" -- https://tools.ietf.org/html/rfc6596)?

Hi Peter,

The short version (as per Ed's separate email) is that "canonical" exists 
to resolve URI aliases: 2 or more URIs for the same resource (i.e., 
duplicate content).  In contrast, "identifier" exists to establish 
relationships between different resources (i.e., different content).

Expanding further:

The short phrase for the rel registry RFC 6596 uses is indeed "Designates 
the preferred version of a resource", but then the RFC goes on to say:

    More formally, the canonical link relation specifies the preferred IRI
    from a set of resources that return the context IRI's content in
    duplicated form.  Once specified, applications such as search engines
    can focus processing on the canonical, and references to the context
    (referring) IRI can be updated to reference the target (canonical)
    IRI.

and then gives the illustrative example:

    If the preferred version of a IRI and its content exists at:

    http://www.example.com/page.php?item=purse

    Then duplicate content IRIs such as:

    http://www.example.com/page.php?item=purse&category=bags
    http://www.example.com/page.php?item=purse&category=bags&sid=1234

    may designate the canonical link relation in HTML as specified in
    [REC-html401-19991224]:

    <link rel="canonical"
            href="http://www.example.com/page.php?item=purse">

    or as a relative IRI:

    <link rel="canonical" href="page.php?item=purse">

In contrast, "identifier" is about establishing relationships between 
*different* resources.  This includes providing machine-readable linkage 
between:

https://doi.org/10.1371/journal.pone.0171057

and

http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0167475

but also between the DOI and the subsequents PDFs, PPTs, PNGs, XML, etc.:

http://journals.plos.org/plosone/article/figure/image?download&size=large&id=info:doi/10.1371/journal.pone.0167475.g003
http://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0167475&type=manuscript
http://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0167475&type=printable

If you discovered one of the three above URIs out of context, it would be 
nice if they expressed membership in "10.1371/journal.pone.0171057".  That 
wouldn't preclude additional boundary expressions, but the XML citations 
and PNG of an article image clearly can't use "canonical".

This general pattern is abstracted at:

http://signposting.org/identifier/dryad/

The blog post that Herbert mentioned is at:

http://ws-dl.blogspot.com/2016/11/2016-11-07-linking-to-persistent.html

Where it examines the suitability of:

     rel="canonical"
     rel="alternate"
     rel="duplicate"
     rel="related"
     rel="bookmark"
     rel="permalink"
     rel="shortlink"

regards,

Michael

> Peter

----
Michael L. Nelson [email-masked] http://www.cs.odu.edu/~mln/
Dept of Computer Science, Old Dominion University, Norfolk VA 23529
+1 757 683 6393 +1 757 683 4900 (f)

---

From: Ed Summers <[email-masked]>
Date: Mon, 7 Aug 2017 11:37:26 -0400

Hi Herbert,

Thanks for your responses.

> On Aug 5, 2017, at 8:56 AM, Herbert Van de Sompel <[email-masked]> wrote:
> 

Just to close the loop I thought I'd ask over on the whatwg discussion list [1] to see if anyone remembers why res=bookmark can't be used with <link>. It doesn't look like it's generating significant discussion, but I figured it was worth a shot.

Since HTML is a "living standard" one would think that it could be changed without too much fuss unless, as you say, it was debated before and decided against.

//Ed

[1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/0001.html

---

From: Michael Nelson <[email-masked]>
Date: Mon, 7 Aug 2017 11:53:41 -0400

Hi Ed,

My guess, based up reading:

https://www.w3.org/TR/html5/links.html#link-type-bookmark

is that an HTML doc can have multiple rel="bookmark" attributes, since 
it's seems to be used to specify relationships between the target page and 
specific elements within the source page.  To borrow from a scholarly 
example, to me it seems like reference citation context ("article B was 
referenced in this section of the article A").

The example from the link above:

  The following snippet has three permalinks. A user agent could determine
  which permalink applies to which part of the spec by looking at where the
  permalinks are given.

  ...
  <body>
   <h1>Example of permalinks</h1>
   <div id="a">
    <h2>First example</h2>
    <p><a href="a.html" rel="bookmark">This permalink applies to
    only the content from the first H2 to the second H2</a>. The DIV isn't
    exactly that section, but it roughly corresponds to it.</p>
   </div>
   <h2>Second example</h2>
   <article id="b">
    <p><a href="b.html" rel="bookmark">This permalink applies to
    the outer ARTICLE element</a> (which could be, e.g., a blog post).</p>
    <article id="c">
     <p><a href="c.html" rel="bookmark">This permalink applies to
     the inner ARTICLE element</a> (which could be, e.g., a blog 
comment).</p>
    </article>
   </article>
  </body>
  ...

If I'm understanding it correctly (and I'm not 100% sure on that), then 
that would be the reason you could not have a single value in Link, since 
it's purpose seems to be almost the inverse (obverse?) of <A 
name="foo"></a>.

To me, it seems like a weird corner case that has parked on an otherwise 
good term.  Like rel="archives" ;-)

regards,

Michael

----

---

From: Bjartur Thorlacius <[email-masked]>
Date: Mon, 7 Aug 2017 16:53:39 +0000

The short version (as per Ed's separate email) is that "canonical" exists
to resolve URI aliases: 2 or more URIs for the same resource (i.e.,
duplicate content).  [...]

and

If the content is different parts of a paper, then the subpages should
<link rel=up hef="/to/the/paper" >, should they not?

The DOI is the canonical IRI. There may be a couple of alternate
representations of the whole paper (HTML, PDF,  and paper). Then there are
parts with their own IRIs (images, tables, even chapters). The parts should
link up to the DOI (explicitly using rel=up).

To me, rel=identifier sounds like a hypernym of alternate and up
specifically intended for pointing to the nearest DOI. If it's only
intended for DOIs, why not just call it rel=doi? In non-DOI instances the
distinction between alternate and up seems important.

To be fair, RSS and Atom go so far as using alternate where index would be
more appropriate. So specifying the desired semantics explicitly, under a
new rel, and then moving to existing ones seems like a more
forwards-compatible strategy.

Regards,
Bjartur Thorlacius

---

From: Michael Nelson <[email-masked]>
Date: Tue, 8 Aug 2017 12:46:10 -0400

Hi Bjartur,

I reply inline below, but I also encourage you to check out a new blog 
post that we did that gives some more examples:

http://ws-dl.blogspot.com/2017/08/2017-08-07-relcanonical-does-not-mean.html

as well as the draft itself which covers additional scenarios:

> If the content is different parts of a paper, then the subpages should <link rel=up
> hef="/to/the/paper" >, should they not? 
>

They certainly can; navigation is orthogonal to identification.  Of 
course, if they page hierarchy is multiple levels, then the URIs used for 
things like "up" and "identifier" will likely diverge.

> The DOI is the canonical IRI. There may be a couple of alternate representations of the
> whole paper (HTML, PDF,  and paper). Then there are parts with their own IRIs (images,
> tables, even chapters). The parts should link up to the DOI (explicitly using rel=up).
>

Dereferencing a (http version of a) DOI doesn't always lead you to an 
"article".  Most of the time it leads you to a landing page, from which 
all the various parts are available (and are somehow collectively 
identified by the DOI).

Dereferencing:

https://doi.org/10.1145/3041656

leads to:

http://dl.acm.org/citation.cfm?doid=3077622.3041656

but what we'd conventionally consider the "paper" (in this case, available 
only as a PDF) is really at:

http://dl.acm.org/ft_gateway.cfm?id=3041656&ftid=1879413&dwn=1&CFID=593352672&CFTOKEN=50692319

If the PDF claimed:

Link: <https://doi.org/10.1145/3041656>; rel="canonical"

Then it would be telling Google et al. to index the content at 
https://doi.org/10.1145/3041656 (and then ultimately 
http://dl.acm.org/citation.cfm?doid=3077622.3041656) *instead* of the 
content at the PDF.

The PDF can claim:

Link: <http://dl.acm.org/citation.cfm?doid=3077622.3041656>; rel="up"

Because the HTML landing page really is the parent doc for the PDF.  In 
summary, the PDF "should" claim:

Link: <http://dl.acm.org/citation.cfm?doid=3077622.3041656>; rel="up",
   <https://doi.org/10.1145/3041656>, rel="identifier"

And the landing page should claim:

Link: <http://dl.acm.org/citation.cfm?doid=3077622.3041656>; rel="canonical"

to distinguish itself from all the crazy URL arguments that the ACM DL 
adds, like this real URL extracted from a search session inside acm.org:

http://dl.acm.org/citation.cfm?id=3041656&CFID=593352672&CFTOKEN=50692319

Which is really just the same page with a different URI.

> To me, rel=identifier sounds like a hypernym of alternate and up specifically intended for
> pointing to the nearest DOI. If it's only intended for DOIs, why not just call it rel=doi?
> In non-DOI instances the distinction between alternate and up seems important. 
>

But it's not just DOIs.  arXiv doesn't use DOIs, and it's a great 
candidate for this.  Consider:

https://arxiv.org/abs/1304.5213

This data set is clearly not rel="canonical" for arXiv:1304.5213:

https://arxiv.org/src/1304.5213v1/anc/dataset.csv

It could claim "up", but that's really for navigation.  Consider the DVI 
version:

https://arxiv.org/dvi/1304.5213

It should claim:

Link: <https://arxiv.org/format/1304.5213>; rel="up"
       <https://arxiv.org/abs/1304.5213>; rel="identifier"

It can't claim to be canonical or alternate for 
https://arxiv.org/abs/1304.5213, because https://arxiv.org/abs/1304.5213 
is an HTML landing page, not the PDF or PS version: so the DVI is not an 
alternate version of the landing page, and assuming Google "wanted" to 
index DVI, the HTML landing page is not a replacement version for the DVI.

The rel="up" link is there because the DVI is becaue the link for the DVI 
page is really only from https://arxiv.org/format/1304.5213, *not* from 
https://arxiv.org/abs/1304.5213.

You can do things like rel="up up", but that's even more clearly for 
navigation and not identification.

The summary is that if you wanted to create a single link to the resource 
in arxiv with the title "Carbon Dating The Web: Estimating the Age of Web 
Resources", then:

https://arxiv.org/abs/1304.5213

really is the best available single URI you can use, all the constituent 
resources (e.g., PDF, DVI, csv) are not canonical or alternate for each 
other, and since the arXiv model can go two layers deep, using "up" 
won't always get you back to "https://arxiv.org/abs/1304.5213".

The blog post linked above also covers a Wikipedia example, which I won't 
repeat here.

> To be fair, RSS and Atom go so far as using alternate where index would be more appropriate.
> So specifying the desired semantics explicitly, under a new rel, and then moving to existing
> ones seems like a more forwards-compatible strategy.

Yeah, RSS and Atom are kind of grandfathered in with the tuples of 
rel="alternate" and the corresponding mime types.  Of course, back in the 
syndication days the RSS feed was often a legitimate "alternate" 
representation of the corresponding HTML page, but that sort of diverged 
through time.

regards,

Michael

----

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 9 Aug 2017 16:35:02 +0200

On Sat, Aug 5, 2017 at 2:56 PM, Herbert Van de Sompel <[email-masked]>
wrote:

> > I wonder if rather than adding another link relation to the mix if the
> HTML folks would be willing to update rel=bookmark

to allow for usage with <link> which ought to make it amenable to use in an
> HTTP header as some other HTML relations are (e.g. alternate). The
> semantics of bookmark speak directly to the issue of persistence that your
> I-D seems to be addressing.
> >
>
> Our I-D acknowledges that the semantics of "identifier" are similar to
> "bookmark". But "bookmark" is explicitly not allowed in <link> (and hence
> Link). One has to assume there were/are reasons for that choice because
> other rel types declared in HTML can be used in <link>.
>
>
Update: Since, the above mail exchange regarding the suggested use of
"bookmark" the following actions were taken:

* On August 5, Ed Summers posted a question regarding applying "bookmark"
to <link> to the WHATWG list, see https://lists.w3.org/Archi
ves/Public/public-whatwg-archive/2017Aug/0001.html. There are no responses
to this post, so far.

* On August 9, Ed Summer posted a similar question to WHATWG/HTML GitHub,
see https://github.com/whatwg/html/issues/2899. There is a reaction from
@annevk who (1) speculates that the reason "bookmark" is not to be used
with <link> might be in order not to overlap with "canonical" (2) suggests
the use of "canonical" :-)

* Michael Nelson has further explored "bookmark" and has confirmed that
there effectively is a reason for not allowing "bookmark" in <link>. It is
related to its target use case: surfacing a link for content contained in a
*part* of a page. Hence, Michael concludes that making "bookmark" usable
with <link> will most likely not happen. @annevk's GitHub response does not
seem to contradict that. Michael based his findings on studying
http://tantek.com/log/2002/11.html#L20021128t1352 and
https://html.spec.whatwg.org/multipage/links.html#link-type-bookmark. He
may write another blog post about this, but, for now, here's how he
explained on Twitter https://twitter.com/i/moments/895081563653902336

As a summary, thus far, of these discussions:

* We have further explained, in a special-purpose blog post, that
"canonical" is not applicable for the use cases we describe in our I-D.

* We have shown that there is a reason why "bookmark" is not usable with
<link>. While the relation type name suggests it has the appropriate
semantics intended by "identifier", its intended use is surfacing a link
for content contained in a *part* of a page. That's not the intention of
"identifier", which is about surfacing another URI (for the purpose of
referencing) for an entire resource.

We agree with Ed Summers that we need to use the web we have, where
possible. To that end, we had included an analysis in our I-D explaining
why certain existing rel types are not applicable. Based on the
discussions, here, we will be able to further clarify that analysis in a
next iteration of our I-D. But the analysis will still reach the conclusion
that these existing relation types are not applicable. As such, we also
reconfirm our request to register "identifier".

Greetings

Herbert

==

---

From: Ed Summers <[email-masked]>
Date: Wed, 9 Aug 2017 12:17:55 -0400

Hi Herbert,

> On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel <[email-masked]> wrote:
> 
> * On August 5, Ed Summers posted a question regarding applying "bookmark" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/0001.html. There are no responses to this post, so far.

There have been a few responses if you look at the list of emails for August:

    https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/

> * On August 9, Ed Summer posted a similar question to WHATWG/HTML GitHub, see https://github.com/whatwg/html/issues/2899. There is a reaction from @annevk who (1) speculates that the reason "bookmark" is not to be used with <link> might be in order not to overlap with "canonical" (2) suggests the use of "canonical" :-) 

Yes, canonical seems to be the relation that most people are reaching for initially. I did myself on reading your I-D. The fact that seasoned hands like Kevin Marks and Anne van Kesteren are as well says something.

> * Michael Nelson has further explored "bookmark" and has confirmed that there effectively is a reason for not allowing "bookmark" in <link>. It is related to its target use case: surfacing a link for content contained in a *part* of a page. Hence, Michael concludes that making "bookmark" usable with <link> will most likely not happen. @annevk's GitHub response does not seem to contradict that. Michael based his findings on studying http://tantek.com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#link-type-bookmark. He may write another blog post about this, but, for now, here's how he explained on Twitter https://twitter.com/i/moments/895081563653902336

Yes, it looks like that's probably where things will sit. As Anne indicated it's likely that rel=bookmark cannot be used with <link> because of perceived confusion it would cause with canonical. The semantics of parts of pages vs the page itself don't seem terribly significant to me from an implementation perspective. Unfortunately 'identifier' will also probably cause some confusion as well. As systems that rely on 'identifier' get developed that will be something for them to deal with.

Thanks for considering all the questions and tracking the conversation over on the WHATWG list. It speaks to the spirit of what you all are trying to achieve with this I-D.

//Ed

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 9 Aug 2017 18:25:38 +0200

On Wed, Aug 9, 2017 at 6:17 PM, Ed Summers <[email-masked]> wrote:

> > * On August 5, Ed Summers posted a question regarding applying
> "bookmark" to <link> to the WHATWG list, see
> https://lists.w3.org/Archives/Public/public-whatwg-archive/
> 2017Aug/0001.html. There are no responses to this post, so far.
>
> > * On August 9, Ed Summer posted a similar question to WHATWG/HTML
> GitHub, see https://github.com/whatwg/html/issues/2899. There is a
> reaction from @annevk who (1) speculates that the reason "bookmark" is not
> to be used with <link> might be in order not to overlap with "canonical"
> (2) suggests the use of "canonical" :-)
>
> Yes, canonical seems to be the relation that most people are reaching for
> initially. I did myself on reading your I-D. The fact that seasoned hands
> like Kevin Marks and Anne van Kesteren are as well says something.
>
> Yes, it looks like that's probably where things will sit. As Anne
> indicated it's likely that rel=bookmark cannot be used with <link> because
> of perceived confusion it would cause with canonical. The semantics of
> parts of pages vs the page itself don't seem terribly significant to me
> from an implementation perspective. Unfortunately 'identifier' will also
> probably cause some confusion as well. As systems that rely on 'identifier'
> get developed that will be something for them to deal with.
>
> Thanks for considering all the questions and tracking the conversation
> over on the WHATWG list. It speaks to the spirit of what you all are trying
> to achieve with this I-D.
>
>
Thanks for thinking along with us, Ed!

Cheers

herbert

==

---

From: Peter Williams <[email-masked]>
Date: Wed, 9 Aug 2017 10:59:47 -0600

This discussion has convinced me that no existing relation is a good match
for the proposed semantics. However, i am concerned that the proposed
relation has taken this much discussion to understand. The confusion it
generated here does not bode well for it being used properly by mere
mortals.

I think a more concrete name would greatly improve the usability. Finding a
more concrete name will be challenging because this relation conflate
several different relationships into a single name. These different
semantics are called out in the I-D in sections 3.1-3.4.

Having multiple relations, one for each semantic, might be another way to
address the usability issues. Some of those use cases seem to be covered by
existing relations. For example, `canonical` seems tailor made for the
"Version Identifiers" use case. For other use cases, such as
"Multi-Resource Publications" and "Persistent Identifiers", there don't
seem to be any existing relations that would work. Relations for those
narrower use cases would be much easier to understand and use.

Peter

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 9 Aug 2017 19:20:08 +0200

On Aug 9, 2017, at 18:59, Peter Williams <[email-masked]> wrote:
> 
> This discussion has convinced me that no existing relation is a good match for the proposed semantics. However, i am concerned that the proposed relation has taken this much discussion to understand. The confusion it generated here does not bode well for it being used properly by mere mortals. 
> 

Personally, I think the confusion was largely caused by thinking from the perspective that this was canonical or bookmark, and us having to show it was not.

I hope that a reading of the I-D itself, without coming from the canonical/bookmark perspective does make it clear what "identifier" is about. Various scenarios illustrate what it is intended for, and, IMO, the short description "preferred for referencing" is clear too. 

> I think a more concrete name would greatly improve the usability. Finding a more concrete name will be challenging because this relation conflate several different relationships into a single name. These different semantics are called out in the I-D in sections 3.1-3.4.
> 

The semantics are the same in all scenarios: the target URI is preferred for referencing. 

> Having multiple relations, one for each semantic, might be another way to address the usability issues. Some of those use cases seem to be covered by existing relations. For example, `canonical` seems tailor made for the "Version Identifiers" use case.

Our blog post shows that "canonical" is not appropriate at all for the Wikipedia versioning case. They want the generic URI (current version) to be indexed - canonical. They want the version-specific URI to be referenced - identifier. 

Greetings

Herbert

> For other use cases, such as "Multi-Resource Publications" and "Persistent Identifiers", there don't seem to be any existing relations that would work. Relations for those narrower use cases would be much easier to understand and use.
> 
> Peter
>

---

From: Erik Wilde <[email-masked]>
Date: Wed, 9 Aug 2017 10:39:17 -0700

hello.

On 2017-08-09 09:59, Peter Williams wrote:
> Having multiple relations, one for each semantic, might be another way 
> to address the usability issues. Some of those use cases seem to be 
> covered by existing relations. For example, `canonical` seems tailor 
> made for the "Version Identifiers" use case. For other use cases, such 
> as "Multi-Resource Publications" and "Persistent Identifiers", there 
> don't seem to be any existing relations that would work. Relations for 
> those narrower use cases would be much easier to understand and use.

wrt to "semantic purity" of link relations: any attempt to avoid 
existing link relations because they are used in slightly incoherent 
ways and define new ones that are "more clearly defined" often just ends 
up adding to the overall noise.

pragmatically speaking, i think we have to accept the fact that no link 
relation has a precise and closely followed semantic definition. it 
always ends up being a loosely defined concept, and then it depends on 
the context to let us know what exactly this link relation means given 
the context where it is used.

i have no specific opinion regarding this case, but it just seems to me 
that the general path taken here (analyzing real-world usage of existing 
link relations and then deciding that some of the usage is not quite in 
line with the intended use in a new context) might lead to unnecessary 
duplication, and ends up with defining another link relation that over 
time will end up being "misused" anyway.

this is probably more of a general "how narrowly can we pragmatically 
define and guarantee the semantics of link relations" rant. i know that 
it would be great to have semantically pure link relations that we can 
interpret out of context because they are used consistently everywhere. 
it just seems to me that given the experience of how link relations are 
defined (generally fuzzy) and used (generally based on context), 
semantic purity may be an elusive goal to chase.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Peter Williams <[email-masked]>
Date: Wed, 9 Aug 2017 11:40:40 -0600

> The semantics are the same in all scenarios: the target URI is preferred

Given how much "reference" has come up in this discussion perhaps that
would be a better name for this relation? Or something based on it?

On Wed, Aug 9, 2017 at 11:20 AM, Herbert Van de Sompel <[email-masked]>
wrote:

> Personally, I think the confusion was largely caused by thinking from the
> perspective that this was canonical or bookmark, and us having to show it
> was not.
>
> I hope that a reading of the I-D itself, without coming from the
> canonical/bookmark perspective does make it clear what "identifier" is
> about. Various scenarios illustrate what it is intended for, and, IMO, the
> short description "preferred for referencing" is clear too.
>
> I think a more concrete name would greatly improve the usability. Finding
> a more concrete name will be challenging because this relation conflate
> "Version Identifiers" use case.
>
>
> Our blog post shows that "canonical" is not appropriate at all for the
> Wikipedia versioning case. They want the generic URI (current version) to
> be indexed - canonical. They want the version-specific URI to be referenced
> - identifier.
>
> Greetings
>
> Herbert
>
> For other use cases, such as "Multi-Resource Publications" and "Persistent
> Identifiers", there don't seem to be any existing relations that would
> work. Relations for those narrower use cases would be much easier to
> understand and use.
>
> Peter
>
>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2
>> 017Aug/0001.html. There are no responses to this post, so far.
>>

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 9 Aug 2017 20:03:11 +0200

On Aug 9, 2017, at 19:40, Peter Williams <[email-masked]> wrote:

> Given how much "reference" has come up in this discussion perhaps that would be a better name for this relation? Or something based on it?

We are listening. We have tossed around candidates. Turns out to be rather challenging. We ended up with "identifier". Socialized it at conferences and on website. Didn't get negative reactions in over a year. Actually people started implementing it. But, as I said, we are listening. 

"reference" doesn't work obviously. Intuition would take this to mean "context URI references target URI". 

So, I still very much think we want to stick to "identifier". 

Cheers

Herbert

> 
>> On Wed, Aug 9, 2017 at 11:20 AM, Herbert Van de Sompel <[email-masked]> wrote:

---

From: Peter Williams <[email-masked]>
Date: Wed, 9 Aug 2017 12:13:32 -0600

> semantic purity may be an elusive goal to chase.

Completely agree. Striving for semantic purity, in either relation
definition or usage, is a fool's errand.

Personally, i think relations have usages more than definitions. There are
clear and confusing ways to use relations, not really right or wrong.

The more the usages of a relation diverges the less useful it is. This
makes it important to ensure that new relations are evocative and cohesive
enough that usages will tend to cluster together and that they are distinct
enough from existing relations that they will not reduce the usefulness of
existing relations.

Peter

On Wed, Aug 9, 2017 at 11:39 AM, Erik Wilde <[email-masked]> wrote:

> wrt to "semantic purity" of link relations: any attempt to avoid existing
> link relations because they are used in slightly incoherent ways and define
> new ones that are "more clearly defined" often just ends up adding to the
> overall noise.
>
> relation has a precise and closely followed semantic definition. it always
> ends up being a loosely defined concept, and then it depends on the context
> to let us know what exactly this link relation means given the context
> where it is used.
>
> duplication, and ends up with defining another link relation that over time
> will end up being "misused" anyway.
>
> define and guarantee the semantics of link relations" rant. i know that it
> would be great to have semantically pure link relations that we can
> interpret out of context because they are used consistently everywhere. it
> just seems to me that given the experience of how link relations are
> defined (generally fuzzy) and used (generally based on context), semantic
> purity may be an elusive goal to chase.
>
> cheers,
>
> dret.
>
> --

---

From: Erik Wilde <[email-masked]>
Date: Wed, 9 Aug 2017 12:24:32 -0700

hello.

On 2017-08-09 11:13, Peter Williams wrote:
> Personally, i think relations have usages more than definitions. There 
> are clear and confusing ways to use relations, not really right or wrong.

absolutely. that's where i always pull out wittgenstein: "the meaning of 
a word is its use in the language." corollary: in open systems, you do 
not fully control the use of things, and therefore you do not fully 
control their meaning. at least not as much as you might want to...

> makes it important to ensure that new relations are evocative and 
> cohesive enough that usages will tend to cluster together and that they 
> are distinct enough from existing relations that they will not reduce 
> the usefulness of existing relations.

completely agree. and it's a tricky balance to find with no single 
correct solution/answer. i really like the imagery of "meaning clusters" 
we do not fully control, but that we ideally want to be both cohesive 
and distinct.

you do not want every link to be labeled as "related" (my very favorite 
link relation ;-) and then have to completely rely on context to 
understand how. on the other hand, you don't want definitions to be too 
narrow that very likely will not be used in their very narrowly defined 
way (if you want those, mint link relation URIs you own and use those 
instead).

cheers,

dret.

---

From: Peter Williams <[email-masked]>
Date: Wed, 9 Aug 2017 14:47:37 -0600

>
> sticking with the implemented relation name seems better than changing it
> to "cite" or "reference".

`identifier` would, if its use became common, almost certainly damage the
usefulness of `canonical`, `self` and `bookmark` all of which *identify*
the context of the link for some purpose. Most people aren't going to read
the I-D. Most won't even look at the IANA link relations registry. Most
will see an `identifier` link some place or skim a blog post and then start
using it where ever the name seems to make sense. The usage cluster of `
identifier` will be large, diffuse and will overlap the usage clusters of
those other relations. The end result will be a less useful web.

The semantics described in the I-D are distinct from existing relations but
the name, `identifier`, fails to evoke those distinctions. `citable` or
`cite-as` would be much more likely to result in targets of these
links being the resource that should be referenced when citing the context
of the link. I support a relation (or relations) for the use cases
identified by the I-D but not at the expense of several existing relations
with proven usefulness.

On Wed, Aug 9, 2017 at 2:00 PM, Bjartur Thorlacius <[email-masked]>
wrote:

>
>
> And sticking with the implemented relation name seems better than changing
> it to "cite" or "reference".
>

---

From: Herbert Van de Sompel <[email-masked]>
Date: Thu, 10 Aug 2017 00:40:31 +0200

FYI, some implementers seem to be rather OK with "identifier":

https://wiki.duraspace.org/plugins/servlet/mobile?contentId=87468598#content/view/87468598

Greetings

Herbert

On Aug 9, 2017, at 22:47, Peter Williams <[email-masked]> wrote:

>> sticking with the implemented relation name seems better than changing it to "cite" or "reference".
>  
> `identifier` would, if its use became common, almost certainly damage the usefulness of `canonical`, `self` and `bookmark` all of which *identify* the context of the link for some purpose. Most people aren't going to read the I-D. Most won't even look at the IANA link relations registry. Most will see an `identifier` link some place or skim a blog post and then start using it where ever the name seems to make sense. The usage cluster of `identifier` will be large, diffuse and will overlap the usage clusters of those other relations. The end result will be a less useful web.
> 
> The semantics described in the I-D are distinct from existing relations but the name, `identifier`, fails to evoke those distinctions. `citable` or `cite-as` would be much more likely to result in targets of these links being the resource that should be referenced when citing the context of the link. I support a relation (or relations) for the use cases identified by the I-D but not at the expense of several existing relations with proven usefulness.
> 
>> On Wed, Aug 9, 2017 at 2:00 PM, Bjartur Thorlacius <[email-masked]> wrote:
>> 
>> 
>> And sticking with the implemented relation name seems better than changing it to "cite" or "reference". 
>

---

From: Ed Summers <[email-masked]>
Date: Wed, 9 Aug 2017 19:49:49 -0400

> On Aug 9, 2017, at 4:47 PM, Peter Williams <[email-masked]> wrote:
> 

I very much agree with this and think that a relation like `citable` or `cite-as` would speak to what the preferred URL is for. Simply saying it is an `identifier` does not say enough about the context (thanks Erik) in which it is used. All link target URIs are identifiers.

//Ed

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Aug 2017 08:06:43 +0200

> I very much agree with this and think that a relation like `citable` or `cite-as` would speak to what the preferred URL is for. Simply saying it is an `identifier` does not say enough about the con…

+1

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 10 Aug 2017 17:35:12 +1000

> I very much agree with this and think that a relation like `citable` or `cite-as` would speak to what the preferred URL is for. Simply saying it is an `identifier` does not say enough about the con…

+1 for `cite-as`. The plain English meaning leaves very little room
for misinterpretation.  Is it a big break from tradition to use a
verb?  (I guess preconnect/-fetch/-load/-render are also verbs...)

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/