Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B9A132455 for ; Wed, 9 Aug 2017 10:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmbyoQVNoJ_Y for ; Wed, 9 Aug 2017 10:20:12 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D9F132456 for ; Wed, 9 Aug 2017 10:20:12 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t138so15367991wmt.1 for ; Wed, 09 Aug 2017 10:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3OXknlPpV2fLbek053uJ2DixKTgDhAx12D2W8gbNwKg=; b=U/5JIO9v1Ln/NY0dYaQpvaXr3OM1Zw7qZAp3Diycji0SyAmBUG649Cek7b3QWf8Q+A jA2dU14jFkQvbFHwumXHJzBie9c894ZY9WUjQQPki+EoPSMcx7qqpwANhxGJ8us0+9X+ 980q4deI7VWIIkfKtmbRjwpaHYpHe+RpKvxuGKlT8TYRnaHR76VqCwqfd2Gv/F1pDfJy xkcXUdKD9kNufpzRc5unVZHk9harGe0irfSUTa0QZYX+SEC+Fvygd0uVzz/v4CDhJp7B ecWhpJraXU111aA8hM+qbxKCbN/OVP+XhkwU6ERCU+65KoQNrBls4FAMbpvSL6zc5iqF +ZeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3OXknlPpV2fLbek053uJ2DixKTgDhAx12D2W8gbNwKg=; b=i37hevOgHMY4fV5BxS7qlvKjSV7GZX5h39niYULCg0KqIf7MxEElhVtd9+jeH8gkds aIO8E2dEwSvWQITioihepZ2dwBvDcpFWlG3Au/JCzndIELXRNKw7os2xc2W3ZAwggUJu eboS86lsVWTSiUvubl3xBTwQHNXrkwa7YbnQXKCBXjyO1HLg3OLj/QbDQHigPuz1l5/6 qChLHPPefFTAKIs7hVUPMtMMXqLSi67WQiTkTeUj0nAlB6WDywU5A3hAxi2nwTd4RLSs Hr1F/vcMy6QKautVXTx2HDTvStd/Iesqp9jOcxdS9UyI/rkNvqv+hxCnjdBVzemtjK6o MFiQ== X-Gm-Message-State: AHYfb5jmF562GpP9R8rZh7dAPHgXlqqIzLOiJImZcCxafE5+BVZgAQnA PHkFWcgZWAN4NXh/Z9I= X-Received: by 10.80.186.235 with SMTP id x98mr9180059ede.72.1502299210501; Wed, 09 Aug 2017 10:20:10 -0700 (PDT) Received: from [192.168.1.116] ([193.141.150.251]) by smtp.gmail.com with ESMTPSA id f13sm2590412eda.96.2017.08.09.10.20.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 10:20:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C9F68BCB-B4A2-448A-91C0-F2142C448684 Mime-Version: 1.0 (1.0) Subject: Re: Request to register "identifier" relation type From: Herbert Van de Sompel X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 19:20:08 +0200 Cc: Ed Summers , link-relations , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Transfer-Encoding: 7bit Message-Id: <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> To: Peter Williams Archived-At: X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 17:20:16 -0000 --Apple-Mail-C9F68BCB-B4A2-448A-91C0-F2142C448684 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 9, 2017, at 18:59, Peter Williams wrote: >=20 > This discussion has convinced me that no existing relation is a good match= for the proposed semantics. However, i am concerned that the proposed relat= ion has taken this much discussion to understand. The confusion it generated= here does not bode well for it being used properly by mere mortals.=20 >=20 Personally, I think the confusion was largely caused by thinking from the pe= rspective that this was canonical or bookmark, and us having to show it was n= ot. I hope that a reading of the I-D itself, without coming from the canonical/b= ookmark perspective does make it clear what "identifier" is about. Various s= cenarios illustrate what it is intended for, and, IMO, the short description= "preferred for referencing" is clear too.=20 > I think a more concrete name would greatly improve the usability. Finding a= more concrete name will be challenging because this relation conflate sever= al different relationships into a single name. These different semantics are= called out in the I-D in sections 3.1-3.4. >=20 The semantics are the same in all scenarios: the target URI is preferred for= referencing.=20 > Having multiple relations, one for each semantic, might be another way to a= ddress the usability issues. Some of those use cases seem to be covered by e= xisting relations. For example, `canonical` seems tailor made for the "Versi= on Identifiers" use case. Our blog post shows that "canonical" is not appropriate at all for the Wikip= edia versioning case. They want the generic URI (current version) to be inde= xed - canonical. They want the version-specific URI to be referenced - ident= ifier.=20 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 a= nd use. >=20 > Peter >=20 >> On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers wrote: >> Hi Herbert, >>=20 >> > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel w= rote: >> > >> > * On August 5, Ed Summers posted a question regarding applying "bookmar= k" to to the WHATWG list, see https://lists.w3.org/Archives/Public/pu= blic-whatwg-archive/2017Aug/0001.html. There are no responses to this post, s= o far. >>=20 >> There have been a few responses if you look at the list of emails for Aug= ust: >>=20 >> https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/ >>=20 >> > * On August 9, Ed Summer posted a similar question to WHATWG/HTML GitHu= b, 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" :-) >>=20 >> 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 l= ike Kevin Marks and Anne van Kesteren are as well says something. >>=20 >> > * Michael Nelson has further explored "bookmark" and has confirmed that= there effectively is a reason for not allowing "bookmark" in . It is r= elated 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= will most likely not happen. @annevk's GitHub response does not seem= to contradict that. Michael based his findings on studying http://tantek.co= m/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, b= ut, for now, here's how he explained on Twitter https://twitter.com/i/moment= s/895081563653902336 >>=20 >> Yes, it looks like that's probably where things will sit. As Anne indicat= ed it's likely that rel=3Dbookmark cannot be used with because of per= ceived confusion it would cause with canonical. The semantics of parts of pa= ges vs the page itself don't seem terribly significant to me from an impleme= ntation perspective. Unfortunately 'identifier' will also probably cause som= e confusion as well. As systems that rely on 'identifier' get developed that= will be something for them to deal with. >>=20 >> Thanks for considering all the questions and tracking the conversation ov= er on the WHATWG list. It speaks to the spirit of what you all are trying to= achieve with this I-D. >>=20 >> //Ed >=20 --Apple-Mail-C9F68BCB-B4A2-448A-91C0-F2142C448684 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Aug 9, 2017, at 18:59, P= eter Williams <pezra@barelyenou= gh.org> wrote:

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


Persona= lly, I think the confusion was largely caused by thinking from the perspecti= ve 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 comi= ng from the canonical/bookmark perspective does make it clear what "identifi= er" 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 co= ncrete name will be challenging because this relation conflate several diffe= rent relationships into a single name. These different semantics a= re called out in the I-D in sections 3.1-3.4.


The semantics are the same in all scenari= os: the target URI is preferred for referencing. 

Having multiple relations, one for e= ach 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" u= se case.

Our blog post sh= ows that "canonical" is not appropriate at all for the Wikipedia versioning c= ase. They want the generic URI (current version) to be indexed - canonical. T= hey want the version-specific URI to be referenced - identifier. 
=

Greetings

Herbert
For other use ca= ses, such as "Multi-Resource Publications" and "Persistent Identifiers", the= re don't seem to be any existing relations that would work. Relations for th= ose narrower use cases would be much easier to understand and use.

Peter

On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers = <ehs@pobox.com>= wrote:
Hi Herbert,

> On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:
>
> * On August 5, Ed Summers posted a question regarding applying "bookmar= k" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/public-whatwg-arc= hive/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 GitHu= b, see https://github.com/whatwg/html/issues/2899. T= here 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 han= ds 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>. I= t is related to its target use case: surfacing a link for content contained i= n a *part* of a page. Hence, Michael concludes that making "bookmark" usable= with <link> will most likely not happen. @annevk's GitHub response do= es not seem to contradict that. Michael based his findings on studying http://tantek.com/log/2002/11.html#L20021128t1352 a= nd https://html.spec.whatwg.org/multipage/links.html#link-type-bookmark. He may write another bl= og 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 ind= icated it's likely that rel=3Dbookmark cannot be used with <link> beca= use of perceived confusion it would cause with canonical. The semantics of p= arts of pages vs the page itself don't seem terribly significant to me from a= n implementation perspective. Unfortunately 'identifier' will also probably c= ause some confusion as well. As systems that rely on 'identifier' get develo= ped that will be something for them to deal with.

Thanks for considering all the questions and tracking the conversation over o= n the WHATWG list. It speaks to the spirit of what you all are trying to ach= ieve with this I-D.

//Ed

= --Apple-Mail-C9F68BCB-B4A2-448A-91C0-F2142C448684--