From nobody Fri Aug 4 08:06:02 2017 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 6EB2D13239A for ; Fri, 4 Aug 2017 08:06:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 BwQ6hL3XEohE for ; Fri, 4 Aug 2017 08:05:58 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 358D9132391 for ; Fri, 4 Aug 2017 08:05:58 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d145so10631847qkc.2 for ; Fri, 04 Aug 2017 08:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=9CI2kZz3uTX9hg0a8WzfWQTsLxKudxIpTr7y3hNUeLc=; b=iN391ghbyl8Z9XtPweTDDqQjNtPq8NJlIru+HjPkTwQwB1D3ClOEp1ZAmHc76VINbR IdGS0Nj4/VzHx2dYHM6s6Lt3zAG6Nm9S/Dc+1g9Ox55pb82XaCBvzRNggnlWgh9QALiz uIWXQR1DgNR280rbKsTIR2NSyoIuCqmHcXKtpLHuwmAUOBefJ0Uz5lpuamWYbDShkdg2 B3eWMKj5RHhAgdnTE+oYeRNVcPvOquiY1viovpZGQLS/iUZA/0Nj9GXlug+5dRXQsn0w 3/I7bMoQA+r26zmz/UgivPBIIja2l71ky04rwcfiQ0jR8kIFz/z6qW7W/Vr5BoAEYPge hT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9CI2kZz3uTX9hg0a8WzfWQTsLxKudxIpTr7y3hNUeLc=; b=GB1pvRKpZAA3hM0wNA9xFZIcMt1ciQuWXl6aGqS3L5x3ITvZOiWWKlpJQmdfTVDhbs 7RYGhZevSuOxlvOf124ZMzIIz3VGL4dFl3okladfkEAtsowa++Ghy6Stq6d8QLjkrhVH v4szD9GbVUdRUk8CkpPBODccl+KMuK4ZVmwE+WlkSr7BQFy9B6fgid3uRi9yBdFnZF4x mz/EfWs2RWPMW61nX+mbYWDyEdvzQVUsjYMQX0IDvqCRm622nfQb45i2hAD3nWuc9lxH UaM7TbwZuVqFDYRxMnWGokVjuFIV5U/RoNRbd7A8f2DSArqusPa14fhczAe2mU/25i4+ 53+w== X-Gm-Message-State: AHYfb5huFyKjIl99oluMI6hG+U2H7ogOEDYSPUFzjECTKuVqsUzs6P1B naWNfkYGamAwxLhQoYZxURUahvSniTDDWCM= X-Received: by 10.233.235.3 with SMTP id b3mr3253802qkg.138.1501859157249; Fri, 04 Aug 2017 08:05:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.1.194 with HTTP; Fri, 4 Aug 2017 08:05:56 -0700 (PDT) From: Herbert Van de Sompel Date: Fri, 4 Aug 2017 17:05:56 +0200 Message-ID: Subject: Request to register "identifier" relation type To: link-relations Cc: Herbert Van de Sompel , Michael Nelson , Geoffrey Bilder , "John A. Kunze" , Simeon Warner Content-Type: multipart/alternative; boundary="94eb2c09743e9212a30555eed500" 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: Fri, 04 Aug 2017 15:06:00 -0000 --94eb2c09743e9212a30555eed500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=ADk= ) 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 --=20 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 =3D=3D --94eb2c09743e9212a30555eed500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear

I would like to registe= r the following relation type:

* Relation Name: identif= ier=C2=A0

* Description: A link with the "identifier&quo= t; 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 Referencin= g.=C2=A0https://datatracker.ietf.org/doc/draft-vandesompel-identifier/<= /div>

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

- There has been significant communication/promotion fo= r the use of the "identifier" relation type in a target community= (scholarly communication). See e.g. ht= tp://signposting.org/, h= ttp://signposting.org/identifier/, and presentations at several confere= nces, including PIDapalooza (Reykjav=C3=ADk) OR2017 (Brisbane), DPLAFest 20= 17 (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 p= latforms.=C2=A0


--94eb2c09743e9212a30555eed500-- From nobody Fri Aug 4 21:20:36 2017 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 14A0912EB5D for ; Fri, 4 Aug 2017 21:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.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 LsNOZnCb2jR4 for ; Fri, 4 Aug 2017 21:20:32 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 6B97F12DDD0 for ; Fri, 4 Aug 2017 21:20:32 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x3so30577248oia.1 for ; Fri, 04 Aug 2017 21:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B89bVK2jHu2jcG7lWcf2Jic5LYj/ekmYot77iBe9a/8=; b=xpHnehUaoUnKuO9z+1N/J/vdyJQ35kemsfguu4UxI7EOwu6i1FaUh9O3d1E+n9nbxw soxkpL6Gpt5CllwgC7Dq5Cyi43RyobY/Q/SxPafpIFzbRo1yC4aqGv2miv+r5krzOiAp fYBt5SMMiLQzxWDxMp/MfX7i7K/TxCH2N+hKMfPWslGztqyYzn/GYIXAH8dHst3Ndz+2 jDkEwcrVFS+1WU82iz6oV0KftC3rd5vRXH6FeSbHUNpvu5HcKUV6izRgP3BQQf7YhzgS kAiaw4XkKrADoYR7eDsJAGQbQ0UqtKZ/PUyLmb+of1WelqajvbefU4H36Iz8yMyFxLGx fLjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B89bVK2jHu2jcG7lWcf2Jic5LYj/ekmYot77iBe9a/8=; b=iBYRv8PSsgdBDa+7xQn1kKDfQHiNYfpFDwAXew1S3Sqfrgw1cp3qjIVWgG1HxFxZOR SDiIPJZZZWiOUW4VYGtSleSQ599sXN+tGN0Julm4/9cYpHjC7Jz4+thI4MQ8by8C8wmu wgXOs6y5zOSyyrcMRyTQZYbvmsLiFSjwbBY0Z+GPkwy2UtpP/6+DHX2ujUWrCkRe6lCJ 0RhUG+54BTYRf46f07AUJfdjXLuiDTzcwS1SGlinHdSDWU9gxPW7zMCm6KqwxzOdos5j VeM5zioTh3UmtArYDboL43EoMTbz4QQbfAKQaCjV6IvmvjJ4oE0QlO9rCwfI3QhyATfs 70XQ== X-Gm-Message-State: AHYfb5gqsFRk0+e+g1ng1nIwOBiP83BOx3ombMizIMnL2THFl3GY+Lr9 8uRc9ymBBPQFLWJNs5n30qe11KB71X7Q X-Received: by 10.202.52.194 with SMTP id b185mr2985890oia.195.1501906831639; Fri, 04 Aug 2017 21:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Fri, 4 Aug 2017 21:20:31 -0700 (PDT) In-Reply-To: References: From: Peter Williams Date: Fri, 4 Aug 2017 22:20:31 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Herbert Van de Sompel Cc: link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" Content-Type: multipart/alternative; boundary="001a113d423c2f9d4f0555f9ef98" 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: Sat, 05 Aug 2017 04:20:34 -0000 --001a113d423c2f9d4f0555f9ef98 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel 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)? Cheers, Peter --001a113d423c2f9d4f0555f9ef98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel <hvdsomp@gmail.com&g= t; wrote:
...=C2=A0

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

=
...

How does `identi= fier` differ from `canonical` ("Designates the preferred version of a = resource" -- https://t= ools.ietf.org/html/rfc6596)?

Cheers,
Peter
=C2=A0
--001a113d423c2f9d4f0555f9ef98-- From nobody Sat Aug 5 00:38:16 2017 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 89AF0131C95 for ; Sat, 5 Aug 2017 00:38:14 -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 vsRHWPu0m3N2 for ; Sat, 5 Aug 2017 00:38:12 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 82BE0131C9E for ; Sat, 5 Aug 2017 00:38:12 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id k20so16091017wmg.0 for ; Sat, 05 Aug 2017 00:38: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=xytIarT1wY4f2zG8aFCV8AlVsx8K097ftb4WTtPf89I=; b=c9r0jRIJEE57FQ9UwRRMGgbz/odqJIqbEabGEOxySn+mAmmKegkTXVZmjIEBIDyy9f L0Dnt77MAYd++kehLa/iUWigCPcM84P0YIDI5Vqae6vJGo5zC3mRtzUzOjPwbVBwMHRV ZGD2YrHcIVmSNAYyf+ZKsifmxFTHtis9xEtrgkVsF9uNVAQkzmcAp2d4MgBHdRKivSjl WgJb41n62cmxlZEUIVkMAFjimbN2EGXg2IzmXFoxz/KeD1TB9UNhPJdxXyN2zGk8Fv5V JYflPdsRbhhy9zRIq0cnoBTzrKXKTUss3Rn9OHuEqppVMc5Sk5Xg7WTKzyIL82Fik4Bv 9GeA== 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=xytIarT1wY4f2zG8aFCV8AlVsx8K097ftb4WTtPf89I=; b=Buzh7MurR4WpCyT6JES4bVYdf1JCaFkmjV6IWqcB6/IWuKSQHyVAf5dwOPqXjrxGIh MJsZ0PALZOa1T36XGKdrX1ixCdRBkOC0itIc7euK15wE+fuWQLFRuhVRq1aqhhhBPg3s GYP8vWFUb4tU9QOoqrqzuURaHiAfwYaanaNR6xN6NG0huGlD8gOBtXdvLr0PeEIQwpXx EGRDPLPNwEJg1Z7DXtc7W4xhnWLO6cs2EkvSI/iaRAIQXNj2x2kVAu0/4e8Ss7VVBjIi Ppr95KshTWSihmJYY/nVh8RmDwdV96kVDuZX5r6TqatcEPGcNMpFLknm9DJbePi32dAt 2KcA== X-Gm-Message-State: AIVw112/ANUcFpWonn+NiEds2w2mGHf+Wy8D42bF8f3V0RTpvoAEWMef r2HIxnL4yU6wATRYc2Y= X-Received: by 10.80.140.253 with SMTP id r58mr5170454edr.123.1501918690713; Sat, 05 Aug 2017 00:38:10 -0700 (PDT) Received: from [192.168.2.6] ([77.172.247.152]) by smtp.gmail.com with ESMTPSA id b45sm4522394eda.15.2017.08.05.00.38.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 00:38:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B1064DD0-643E-415D-B377-D24A8B5B3965 Mime-Version: 1.0 (1.0) Subject: Re: Request to register "identifier" relation type From: Herbert Van de Sompel X-Mailer: iPad Mail (14E304) In-Reply-To: Date: Sat, 5 Aug 2017 09:38:09 +0200 Cc: link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" Content-Transfer-Encoding: 7bit Message-Id: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> References: 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: Sat, 05 Aug 2017 07:38:14 -0000 --Apple-Mail-B1064DD0-643E-415D-B377-D24A8B5B3965 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 5, 2017, at 06:20, Peter Williams wrote: >=20 >> On Fri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel = wrote: >> ...=20 >>=20 >> * Description: A link with the "identifier" relation type indicates that t= he link target is preferred over the link context for the purpose of referen= cing. >>=20 >> ... >=20 > How does `identifier` differ from `canonical` ("Designates the preferred v= ersion of a resource" -- https://tools.ietf.org/html/rfc6596)? >=20 The answer is in the I-D and in a blog post that is referenced in the I-D. P= lease have a look.=20 Cheers Herbert > Cheers, > Peter > =20 --Apple-Mail-B1064DD0-643E-415D-B377-D24A8B5B3965 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Aug 5, 2017, at 06:20, Peter Willia= ms <pezra@barelyenough.org&= gt; wrote:

On Fri, Aug 4, 2017= at 9:05 AM, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:<= br>
..= . 

* Description: A link with the "identifier" r= elation type indicates that the link target is preferred over the link conte= xt for the purpose of referencing.

...

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

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

Cheers

Herber= t

Cheers,
Peter
=  
= --Apple-Mail-B1064DD0-643E-415D-B377-D24A8B5B3965-- From nobody Sat Aug 5 05:00:22 2017 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 F28C6131CDC for ; Sat, 5 Aug 2017 05:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=ehs@pobox.com header.d=pobox.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 Ag_u1I2QAtZD for ; Sat, 5 Aug 2017 05:00:18 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFA1131CB5 for ; Sat, 5 Aug 2017 04:59:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id BCE148AD0B; Sat, 5 Aug 2017 07:59:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= /V8UC+5IUottf+19SmakzkY38CA=; b=i13ofF+KLe5GULfBWIt8ky3bd2PnDrAA B09jeFJNDs1JxG0gdR8awtYmSNPw2DFL5Xm63Rvglsnd8P7gTQ+mGteZ0o8Wk6Qc IZhBPqrJ9cuUHh2FNbEGZfo+5o2jvNQcJaEUPm9RliQK7L9aARWN12Glw875fZ4G OQrRcKag8pI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=mGI0VraKoNPJzrGTsRpoZ5yi9zEsuhJELCtIeXbkQT3Qzk7iGJh0Q989 bERJELSUwlb9Tzvf/ywYAkvgl7WoorOv6ZVjUWg6MBhkV2cmKUtu9ib4ku7eda8l OkTvhVJGwOxXa+rH/cgtjtz5pl80ON0zaEV2L4HdoPuxgBhKeto= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B5D3C8AD0A; Sat, 5 Aug 2017 07:59:53 -0400 (EDT) Received: from prajna.fios-router.home (unknown [96.241.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id AD1D28AD04; Sat, 5 Aug 2017 07:59:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Request to register "identifier" relation type From: Ed Summers In-Reply-To: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> Date: Sat, 5 Aug 2017 07:59:58 -0400 Cc: Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , link-relations Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> To: Herbert Van de Sompel X-Mailer: Apple Mail (2.3273) X-Pobox-Relay-ID: 9757458E-79D5-11E7-9951-9D2B0D78B957-07615111!pb-smtp2.pobox.com 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: Sat, 05 Aug 2017 12:00:21 -0000 > On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel = wrote: >=20 > The answer is in the I-D and in a blog post that is referenced in the = I-D. Please have a look.=20 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=3Dbookmark to allow for usage = with 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 nobody Sat Aug 5 05:59:01 2017 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 A4523131EB3 for ; Sat, 5 Aug 2017 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 cWfUivfYg6eO for ; Sat, 5 Aug 2017 05:58:54 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 DE662131DAC for ; Sat, 5 Aug 2017 05:57:02 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m85so37729306wma.0 for ; Sat, 05 Aug 2017 05:57:02 -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=z06F5C9EBUAVRX2lNgE27znFuZSTffaHQKm/+u5BA44=; b=eBS0usP1XrxZ8t3EMDX35R7wZYtGPxcSg3GZyIUWp0i4L5tg1DyjVjxhRL7swKQY5t Uka4IqpsibaG1vtxjxAvhrWoxPg24v7uQE57/wR2BIGBnsAvx7qSqz2MitwBTJeZLCq+ C1WccOZvrU3BWEmin1ZzkOY392p9j+fvTU6iZzLdR+8+LU1fHLIP7YfdgX+TG2C6hOft LAU8VkVb+cSKIXV2yjqln8ANXmGO/jUFITNPvxY9XijKH/bEGEHH7SBdFKOEpuP3/fVG p195gAdztZtQAE8N0e/4BPIWPiezsRXDK8YIY2QmfYW3EHKPfEo1I9nJHRDr4kgPMusl JhiA== 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=z06F5C9EBUAVRX2lNgE27znFuZSTffaHQKm/+u5BA44=; b=LqOC8uXtGCBySf5PFXCmUKW0jmMjDtw/ZgSBg8p4Ji4NGgovuTAb/qAqXzc3orW9sl 2Zb/QtXSCapgiYXDBGPMTftR1rgn5ZurxetPB1Xl8MLZOFpA7XpkhTdKgF2HOOB4UgSw nrYKaTlyQwHDJH/6iMLR/J0BvzaYL4296Zed7iaFWlfMAJ5FXt4MGi95rPwP7B6wobEr Ndv+CC+Zi47zcLoTr5+T4DZWCtEV+mrJKkH3tYfUc6MGwqbZkEQlrF1XWbV9krNti0Jx fvkYBr9N4IS6cZk7q1Q98Nj+4UPsqAmRkpGJ1Eswz+oGI6RTtxTAKReHeqMFIMX2pQeI M0oQ== X-Gm-Message-State: AIVw112W17NE1sYQe3QDYqoDeU0jg8nYmhWkIozx1zSr5/DJRZtyRtKX yzzT9xoxl8PnMT/bRpY= X-Received: by 10.80.193.2 with SMTP id l2mr5657039edf.177.1501937821153; Sat, 05 Aug 2017 05:57:01 -0700 (PDT) Received: from [192.168.2.6] ([77.172.247.152]) by smtp.gmail.com with ESMTPSA id e9sm4992062eda.52.2017.08.05.05.56.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 05:56:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Request to register "identifier" relation type From: Herbert Van de Sompel X-Mailer: iPad Mail (14E304) In-Reply-To: Date: Sat, 5 Aug 2017 14:56:59 +0200 Cc: Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , link-relations Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> To: Ed Summers 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: Sat, 05 Aug 2017 12:59:00 -0000 On Aug 5, 2017, at 13:59, Ed Summers wrote: >=20 >> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel wro= te: >>=20 >> The answer is in the I-D and in a blog post that is referenced in the I-D= . Please have a look.=20 >=20 > I think a crisp one or two sentence reply to Peter's question ought to be p= ossible. 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 t= he question of preferred *for what*. >=20 Good point. Here's my take on it: - canonical: preferred for content indexing=20 - identifier: preferred for referencing > The core issue with canonical seems to be less a matter of semantics and m= ore a practical matter of web publishers not wanting to assign a canonical o= r bookmark link to another domain (e.g. dx.doi.org) because of uncertainty a= bout what this would mean for their Google juice. There is an SEO infrastruc= ture built up around canonical, which has led to it being used quite a bit. >=20 Publishers indeed use canonical to point to pages on their own site. This r= el type is intended eg for reference manager applications: use the target UR= I not the context URI in a reference. Our research (referenced in the I-D) h= as shown that landing page URIs (instead of HTTP DOI) are frequently used fo= r referencing.=20 > I wonder if rather than adding another link relation to the mix if the HTM= L folks would be willing to update rel=3Dbookmark to allow for usage with which ought to make it amenable to use in an HTTP header as some other H= TML relations are (e.g. alternate). The semantics of bookmark speak directly= to the issue of persistence that your I-D seems to be addressing. >=20 Our I-D acknowledges that the semantics of "identifier" are similar to "book= mark". But "bookmark" is explicitly not allowed in (and hence Link). O= ne has to assume there were/are reasons for that choice because other rel ty= pes declared in HTML can be used in . > 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. >=20 Indeed. Then again, this relation type indicates that the target URI should b= e used as identifier. We have done several presentations at conferences, wor= kshops, etc over the past months in which "identifier" was floated. It's bee= n on the Signposting web site (which has an associated mailing list) for alm= ost a year, see http://signposting.org/identifier/ . We have not received ne= gative reactions to the choice of term. Some implementations are meanwhile a= lready out there.=20 Cheers Herbert > //Ed From nobody Sat Aug 5 10:25:27 2017 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 8C4A4129B2A for ; Sat, 5 Aug 2017 10:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=olddominion.onmicrosoft.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 v2qz2c27ivVF for ; Sat, 5 Aug 2017 10:25:21 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0050.outbound.protection.outlook.com [104.47.32.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42458131D9F for ; Sat, 5 Aug 2017 10:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olddominion.onmicrosoft.com; s=selector1-cs-odu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZeFB/C+yr+xC8wtJejcKIh1d7gE1EGqNTt6Joh0Gieo=; b=XKDgdzr/3259HymDaa2ZhlY8o+BILGej+FvAIA3voe5QhL5jInjtmijav9ImIfdoBogZQ/a0n0QhLYzgRpeGXsC9XcGnMpGcyh7UgjCSLXMuBPM0EMnHp1fru/9+E7nCVVf2u5VyfPk9fZAiprZFf/l04S+yNHz7floMwlptnug= Received: from MWHPR17CA0072.namprd17.prod.outlook.com (10.173.106.162) by SN1PR17MB0271.namprd17.prod.outlook.com (10.163.12.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Sat, 5 Aug 2017 17:25:07 +0000 Received: from DM3NAM03FT005.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by MWHPR17CA0072.outlook.office365.com (2603:10b6:300:93::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22 via Frontend Transport; Sat, 5 Aug 2017 17:25:07 +0000 Authentication-Results: spf=pass (sender IP is 128.82.55.16) smtp.mailfrom=cs.odu.edu; barelyenough.org; dkim=none (message not signed) header.d=none;barelyenough.org; dmarc=bestguesspass action=none header.from=cs.odu.edu; Received-SPF: Pass (protection.outlook.com: domain of cs.odu.edu designates 128.82.55.16 as permitted sender) receiver=protection.outlook.com; client-ip=128.82.55.16; helo=webmail.odu.edu; Received: from webmail.odu.edu (128.82.55.16) by DM3NAM03FT005.mail.protection.outlook.com (10.152.82.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1304.16 via Frontend Transport; Sat, 5 Aug 2017 17:25:06 +0000 Received: from dax.ts.odu.edu (192.168.97.75) by kira.ts.odu.edu (192.168.97.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sat, 5 Aug 2017 13:25:06 -0400 Received: from sirius (172.18.200.43) by webmail.odu.edu (192.168.97.75) with Microsoft SMTP Server id 15.1.669.32 via Frontend Transport; Sat, 5 Aug 2017 13:25:05 -0400 Received: by sirius (Postfix, from userid 2444) id ECE1AC17F5; Sat, 5 Aug 2017 13:25:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by sirius (Postfix) with ESMTP id EA2E7C0C31; Sat, 5 Aug 2017 13:25:05 -0400 (EDT) Date: Sat, 5 Aug 2017 13:25:03 -0400 From: Michael Nelson X-X-Sender: mln@sirius To: Peter Williams CC: Herbert Van de Sompel , link-relations , Simeon Warner , Geoffrey Bilder , "John A. Kunze" Subject: Re: Request to register "identifier" relation type In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-286728032-1501953905=:31417" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:128.82.55.16; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(2980300002)(438002)(24454002)(199003)(377454003)(11905935001)(50944005)(189002)(606006)(512874002)(110136004)(2950100002)(42882006)(6916009)(4610100001)(26826003)(478600001)(54906002)(189998001)(966005)(16799955002)(15188155005)(5009310100001)(41446006)(60046009)(4326008)(33716001)(9686003)(53376002)(38730400002)(6306002)(8676002)(4001350100001)(2906002)(45336002)(46386002)(88552002)(86362001)(2476003)(84326002)(8936002)(83506001)(90966002)(356003)(50986999)(76176999)(229853002)(77096006)(8656003)(54356999)(106466001)(39060400002)(109096001)(2810700001)(6266002)(626005)(53546010)(246002)(6246003)(7596002)(75432002)(305945005)(5005980100005)(57986006)(76506005)(7126002)(5660300001)(70076001)(42262002)(19623215001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR17MB0271; H:webmail.odu.edu; FPR:; SPF:Pass; PTR:webmail.odu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT005; 1:NQ9sxDh1/UipWbuLEV3bCukfYTZt3JTkd7fcCaztu+RGbvww4Z54OTGurxoE0aTUJKbF35YlsR5bcu+yse0zfk9FO0961XfnWZNowuVRLxxGfFCpAEqMkbnVzoBDdK9zbYiZHFtLTnYeiVrG8zQdqXsDUydtJ3wv4uNzOLRQpxJZWEklnmCRIsBsYrBE3LQnwYQfj8VFJCvWWAI+OIVAzBATCWovrI2wpBYUJtlCXDd85fI94dcykvKIW4wm+7lMf5heBpJYgUcnjZr+pqiPW2wV2u8P0GP5PuC+PTUfePSM3fUb6vzODigM5EnRSgOElicEb8FL7KNWbhx6vXU7YBRfLuSpgaM4Os3CYx87MvwM3Q5hMrOgaUGOy2mh27axfGMTK5xluLw8yTNLdEHimA7/MOcTn/xOAXtmwbWhE9rDolQpJMCeZh06xe/xKAJHzsw3n9CrKv+3FNhACBd2B8LX0qwZuWJ9bTi/MOpLpMxYHOKEclY3jDTdAg656+J4lcBcz5HD7AbUYA8BPJs636NI23OsgRYBEVuUKbGYwmu76aNhuGPeeg+s610ASUUSLlE8D1+ZRORFp77HCGGAN10C63XCc7kCxRroGCEWs5NdNqUZNvhfEawLFWGQtT6W2vshV8FXvKAVXC0sAmgei3tae6OCNXkK76spBJHYYOf37RLMmeUMyRwPDmb4RBdOXwCjnyGfVi1fW+iqG23/IK3qj+T/lICapvtNidjvyiTJ4FJof98Db3XoEyDqU6Uxape8WrQFZtN3yyU72wP0AafSUKWE/eIuBmj2vpgASHFek2pncjhK8esSsiE6rMvYLBaqOBKXg+fxQvBw/hR7iNcgPC0cZpM/xuwZKJzXZQA= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f47d7f04-5926-4c81-07f7-08d4dc26ead0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR17MB0271; X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0271; 3:Dc6MOC8BOoGdTGccEeI13TuQ2c0FYT/wzRoaQkMpJpT2mcF/eUPgZXW4v6Ng65CKLtzCU+mMQmxEkrg84NGNdxcVOVw46NIJ/+PwSBfgvGtwH6n1b/zOuGG1N/Q8lqcsuufTWGlshF128A4Zk8CbH7zcCZ7GRlUQFBotP25YuHXzvAiS6NVXLlPHieBkiJccUdhVrHZC8PiEkENVHGbF41GxdVw0gqlto30uH5NdnXcCuoKzp3sxXa41Uu1zkn3UQxiI8IUtPK/6S7hIbxBEA/2X/VhlOSNs8zXfOATHcysuJXs39AXO2vWxL9oLsYrUWVwUrxcsWcTlP6qKZ6iOaJaBJvFTP8CIdMDr1SVQvcA=; 25:6nxz5mTAmZoTfQIXDQFP/gkOvqb93rdA7j0DBltZb+jNTWEr033IleZG3x3Eyryg6/Ym5tgg+S9bx1yYKq93iq2URNGoA5ZVcf+qWarFHNY6SD/+7qj7IgWyWp7Y3gJPntdZ+nlG3T248xRr/gdZrpmJoyy+VGM/aZinx39EJOSNycUp0e15GWZdYPGv0gnsZUHxfevw28rRbERqqXHclO0SxqSdFNMl2Tzig8VOLXxM9I43ru3GQxhqbPfy5kRKF6a6RQAtCOsUnfg02f4VlfJPejN8ldtS5VrU/zpQpaePlQA1j0xnG/N6MobskLpG5o8/mJvA6H+nIIdzz+LB3g== X-MS-TrafficTypeDiagnostic: SN1PR17MB0271: X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0271; 31:V3IAlyZcbA5eVyP4jLXb9yxHuwvY83BmIQqbPFPy6ZKatgpxEvD4TvbkQnnkWcn0klaR4g3cyuPblGGq001xCPXWNpVQrY7+eeYJMMgD/oOFDKbcbOf4R9C1pPX8ULk+LM2YAzmidriLIs5x5MgkAMJx4+onj7BpH5N0d0QSKjO0TntL2ngG36gnO/aXtzJLaLLgyA/csXrBVxOLGgR9FLabf3JEZjdyww1/0R+wWyA=; 20:IyZsLiy9AckESfk6XFAQKzfXg0wJqNv4MTsSph/QDLY56LYUV0XCa8JpShzeaKlz7lsII7bghpVzDLN8Hynj6W7z827iF6NyHSpV0N4WnN8NbaCw2kC65PkNLXjVv5Z2tWPvbniiTM2anpGCxqNs4/2wqZvQIurSrKGEy72SDlELmHzqIOmOYgyQbEyO860NivrY43KCmTSos8OwBXI7qxY5GxlqIazAF6A5IiH9uumHvzuvNtnxf8BgXvsPKpMy7IUXIy9h6W2nEEZdExu5PGQT34G44ri+VNAPaYzFholPo+gI9Y39HCq1Tyh4/4N+n+wLX0KROEzHc90vNKQ24wR3XeJVY6061MbF4eT0xj6beUQjt9/1JRGkVXEe9Pfa7/6Z/jYAQS5c2nuPuBwlN8J8n717hVm1mDVOFNsZY4LFbrsgK9coTrh5PYfJdK8SB5r5c/Nhbhk9MscCtLWMeg5jp5FHSdinXC3vxgUlnNLNO7SqIcd/Pg39Q1DM6d7syoWluBFCYD28azIKOHueEjqlbLecFK7P5RIN4+Giu9Zh4kFWwgkvKyKU3ZQ1+ufiUSaxWEci33q8a6LpbbKLnL6ThDM+EK0DloMNit4fgyA= X-Exchange-Antispam-Report-Test: UriScan:(165104125076784)(278428928389397)(162594542051504)(94499342411101)(79290750141951); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13013025)(5005006)(13021025)(8121501046)(3002001)(10201501046)(93006095)(93004095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR17MB0271; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR17MB0271; X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0271; 4:W6wHsPHm/N25nXWfp+kQh3n7os8yUkA1flwcHn0XuZf1Srgp1JDK+Ra20JHabWKwiqpLIylmqJALyhz0WGPGKiAHyf4AkB0kR/xc5w9tqmqs6nwysdNWpS0JTUyWEfXyNKZvFQJE6m9/xc4EA6Ol7QK17ZNM0s3YNP3lmjEXY2Qc3YMdQEISJd9cSmvlkItueTyBzlk5D+yuIXak5eY9r9XmWbCIx+naYXUy2DfZJPy09ar8oq7L7iFbypg7cWTW6bQtyJCV4wUB2mCE/wquAxsJfQyO0OiSi0cXhOFaB5IPH+HDVgf/Mmi7tRkRR2GjQ+jh52RSGzBBBfIYUgNQqTD2+Hkh0oBJZOyX+quxlO1xN+eMrwRBwGaiiB6i8iF6Yzk1PXJf2y6FKzBa/296pJqK2XBkn7Z1yENkOYdV1sJ7dOcuUvde0T8dAUUDLbYf X-Forefront-PRVS: 0390DB4BDA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR17MB0271; 23:orfV6ZYN82sNH11dPK9mCIaR9XXcXvbtYkdh6NoBn?= =?us-ascii?Q?NaH18ZnLqeo6IZsezRCoGdHO37b4bWZoTHskmUx87rKgrcyTnyNX3TNrKsPH?= =?us-ascii?Q?FXymnIWwrkpBhgzCiI0ml3z6QHLzrdnFYbxrUSncgCqltdGelVx1RT1bOvbO?= =?us-ascii?Q?WRqhJd0+r+VTDRRLcfY18in+GPS6JUUkxfErGhLdlyvekuHyt689Bxh2Nm39?= =?us-ascii?Q?82DDx8mQKk5ZyARP5AOX725j3xCSaWzmK5DgwUDW0x09K9AL/jOm53j0IWem?= =?us-ascii?Q?P1vQsWmh2mRMGoI94h5vAU8k8/3/3nKyRq8l0teDhjZaoby1LrryCKm+pYfr?= =?us-ascii?Q?Rf8+JYlPWkYGL+Zw/2bEZcRxqiLP17DQhq/K0+/87Ezu6ePmdZscsEuJrCrK?= =?us-ascii?Q?au0xQm2UIslLhaRv+oSra/4jLiOAglPn9QGafK1p3c16bv/0Vqp1SOAlEWrJ?= =?us-ascii?Q?hCLsMXVB3FvHZFCEd8SCGQeb/ZsAhomz0m6fw666rnhifrQDBZoMWgDk6MAr?= =?us-ascii?Q?vWw1CBEA19+S8SbZ9Oe4sblxJQ497RdLSJ7Cdl3znTsGxiXISFJs+rIZ4Tyr?= =?us-ascii?Q?6BG1MTNIqZhAUoQAf3gyNfDn2FVs+waY/28ckAzYy4Orjc806nwmEVX+7Dto?= =?us-ascii?Q?9v2UYaC8a1C5VgpJG0mFPjfLiafX/tlosT9GOwBlfI9lZFK7AfEYMygQpOD8?= =?us-ascii?Q?iZwlSzWpEbIE10y8DQ/XWJtqMwcXkwJdA3a/EubU+gMuoISETyE35LpQNNz0?= =?us-ascii?Q?X/11fqxzw0LREZYNyun12ZBNMaLFJZlA3yw9Oo1iC9ORjJdFELJfcbFfv3BH?= =?us-ascii?Q?rwP4PaFRl1VrqzKlw08YudGAVEWq3x/hP8SjThsQ/vvsuwon1clbxaB75J3e?= =?us-ascii?Q?H7geNr4abFYDFoqXvY4/UwRYyENHG/b8NuBmAR7196qUtY7C0d4L63ILTGbL?= =?us-ascii?Q?ixAkaohbo10s/45L4EOm1aDIRZ+oxhojLimdO4zwltcrbURFvyIRGa8xSKWB?= =?us-ascii?Q?GjlO/YoWu0AVJIbLHj9o2nUVFUzICtrbamZILCyFjsx9x/dy/TZ7CPowqa0Y?= =?us-ascii?Q?6WT67yEuyQHqF5x4O3HwD3KrgW3o9jlvGomXaw/cyAkUU/+77jlS4PtJ3mPB?= =?us-ascii?Q?v9pz81X8CaLKoO0me8jXopiHr4AyRGkhFsrRLjXCxIe7Ypz1GVny9iZzM+Qn?= =?us-ascii?Q?TOA5jq6A4EINF8VVpFGp+S2UlrozLMgLThd4Y7bpElEMFeePHrKmwb57+hK4?= =?us-ascii?Q?XaWaDHwyFdsIkRYatwPHcw5ji4X/2vQzjjHSAtM3wLlUA5RSTDcY3v/Vlojk?= =?us-ascii?Q?yF8P2YOI7PV7dtVHardXqyNzTf5cnJnc+c53cKnLr/TWLg6gf7Nas6vUoC0n?= =?us-ascii?Q?+YdqdHVPoXDc7vuz7CD+Ry+LSIuq3gRc0N5powdFgEbwFXIlW8LM4YTZ0OsL?= =?us-ascii?Q?sjW6+BJX6Y2vL7e6NG34MrogmI3Z0vaXnTMEq7qB2f0zYJHTSMKSAmOPiYd4?= =?us-ascii?Q?ZnRA/rtFrDns29YgI20dpRsEBbgsYHfxvlnOnTt0qacqxOg+BpWvvcj6RJ9H?= =?us-ascii?Q?5W4AREE8PFKPPvECD7jKOUGrB45Hwv0blqLrO47ecHToUSLlffJ4Itcw4pLO?= =?us-ascii?Q?KfCi/CIWJ81h8FXWsDRg10d5CsP8VPVtLJU+2yRHuzwNws4yeAvoLrpv9v40?= =?us-ascii?Q?lcARez7UNXAJjQYiXRL6PcK1VX/J8KFZlsTXyCn9wQLW0GX1PS100LWzHqXx?= =?us-ascii?Q?ZdVK28DhSD1BTmPVvyxlEULiqLR3JqYI9lFNIZJgJKMM9Fi/y7eL/Cgt0jmy?= =?us-ascii?Q?cFVkOhxAb3uH6r0X8zwyy/r8ej9+jyxKGZ61+UYRdtftZNZ3MI0EQU=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0271; 6:6dkjVmBrGY9uRiFyjtx8cFTbpXxdCuNDzBABAYS/B/RKGCeOvHtkmEBkdcVPGNC5MQU+daN8Vu+elJlTRnKW7VcjNRFAD5wi72ZsowiliJLmZkJQDP7C4Sf0DqA+nBKgrIYDVMDGbyfUtf4cqxs6H/ggfWWm+OJWSwR890JXWnyTUyM6FMszfNup4g81E5GKE2PBfYKzLn1RVSH2itRty8k/Xgr9t63Te6wLk1atXukgYbwfVqKhv1/pAcDoM6G/+08vC8aW/QA6SHqGbzZUBRNCukqAhPYb6pHU2XLOZRhURqGfQBZ6fJWuzVrCO+QHY6WBpLQ5ywKSyAL6cLHlsA==; 5:N8TOLN36YGqmUuoq4UeE9ecxLCSgyhetElRRASOqRal4hajBQyBOcF91eqJuWf9IN5NHIniqWqzs7urcdr8Xy81SzTi2hVIuvw8WmAJ5SvlVPjKuXdtBLix6OQ/Z78pMwvwiMzVR+U0F0bEiaKLZFg==; 24:0GGSqbO5BqRbZ3+9gfWFwAS8cLn/lALtZea0EUmFELTsOrh40oJUbOQpGxSBs119NAGRz4zrBfji6movZlJ/8uArp9LrNur5/N1pxLcv8+k=; 7:hSgcCTPYqohN5j4io3JH28ZH2XHnTR0bwnlwdf3S/owGCFsJ6PadH1MyMPWrz3xOvZOBs5JiUcaQO0hdyAAnYKI+vZcNf3w2xU4nX5kvFBE6YF/7AiwnMcJvYvYV1wJp6nWXWoZP75/bUxeDtU9QwCPUQSma4LZJofI9du9aC5KXntCl+8ysymwXeChuAZ+EKW50fLOc2mgUNjLu+Tx7FXM5yLQojOdY0Wgg1RMgENQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cs.odu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2017 17:25:06.9484 (UTC) X-MS-Exchange-CrossTenant-Id: 48bf86e8-11a2-4b8a-8cb3-68d8be2227f3 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=48bf86e8-11a2-4b8a-8cb3-68d8be2227f3; Ip=[128.82.55.16]; Helo=[webmail.odu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR17MB0271 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: Sat, 05 Aug 2017 17:25:25 -0000 --8323329-286728032-1501953905=:31417 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 4 Aug 2017, Peter Williams wrote: > On Fri, Aug 4, 2017 at 9:05 AM, Herbert Van de Sompel 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]: or as a relative IRI: 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 > > Cheers, > Peter >   > > ---- Michael L. Nelson mln@cs.odu.edu 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) --8323329-286728032-1501953905=:31417-- From nobody Mon Aug 7 08:37:32 2017 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 B50601325B4 for ; Mon, 7 Aug 2017 08:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=ehs@pobox.com header.d=pobox.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 epqon8oxD37M for ; Mon, 7 Aug 2017 08:37:29 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873801325A8 for ; Mon, 7 Aug 2017 08:37:29 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F36DA99760; Mon, 7 Aug 2017 11:37:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= tqTLPBlRElNhtOKd6bgAXQ6TbeQ=; b=SeGIuJQco+RAiFSkcDX3tKebc2OjwMqs MrpssSx4OdXAEUaeBIWOqs/schX5UGISTmqFSGHHiqBh8f0eD+Zy0mLJrSAZy+z8 4kqUSkkvaRfo2GVMouWHhIbjGElCPCbOVzMEwN6Vzcc9hORDudNCZ1DINWhdAsEu KZpG1zWovwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=Hbmnv0mzNZD2CaEHrz8SwG5lpsNi0i70eaEmlvrnMxOM6IhkbWVV1AFF d9IyAjRus/p5oO3BKtzlLLyT7ZNxAWRWWRv+otj9U4RV+j99cs1fX3KCF//cwxie RStYlI+4lxKjWfY11OblS5dzjGyB+xwv/aGMolV1H2//EyHMQXM= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EB8319975F; Mon, 7 Aug 2017 11:37:27 -0400 (EDT) Received: from wireless-10-104-179-255.umd.edu (unknown [129.2.180.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6DFC49975D; Mon, 7 Aug 2017 11:37:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Request to register "identifier" relation type From: Ed Summers In-Reply-To: Date: Mon, 7 Aug 2017 11:37:26 -0400 Cc: Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , link-relations Content-Transfer-Encoding: quoted-printable Message-Id: <5FE35A03-052D-4908-8F38-3D4A52F21FBB@pobox.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> To: Herbert Van de Sompel X-Mailer: Apple Mail (2.3273) X-Pobox-Relay-ID: 5126679A-7B86-11E7-90B8-9D2B0D78B957-07615111!pb-smtp2.pobox.com 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: Mon, 07 Aug 2017 15:37:31 -0000 Hi Herbert, Thanks for your responses. > On Aug 5, 2017, at 8:56 AM, Herbert Van de Sompel = wrote: >=20 > Our I-D acknowledges that the semantics of "identifier" are similar to = "bookmark". But "bookmark" is explicitly not allowed in (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 . Just to close the loop I thought I'd ask over on the whatwg discussion = list [1] to see if anyone remembers why res=3Dbookmark can't be used = with . 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.ht= ml= From nobody Mon Aug 7 08:54:11 2017 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 2425C1323A2 for ; Mon, 7 Aug 2017 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=olddominion.onmicrosoft.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 Hb0WDeLlycww for ; Mon, 7 Aug 2017 08:53:57 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0040.outbound.protection.outlook.com [104.47.33.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4CD1323BF for ; Mon, 7 Aug 2017 08:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olddominion.onmicrosoft.com; s=selector1-cs-odu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6Xz2Lx93TLVc0fsnxvq2MhOikXEoSEKhgx+0B627CSg=; b=puyCM9pWqSYi2iqfbQ3PB61XtGspGzwlVsQLkr5WKC18/boP0+PVE2yO4DLVYLtf5JdOyndB7P559NNgnOU6X3Nk0BPQ6RcVxXvsDY34/es1chDC5ecHBseWwIoCBfKlsra9qCXVmsL2sRAmLOr9xjx1R49bP0nc9e7Vs4vBOIM= Received: from DM5PR17CA0049.namprd17.prod.outlook.com (10.175.217.139) by BLUPR17MB0259.namprd17.prod.outlook.com (10.162.235.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Mon, 7 Aug 2017 15:53:52 +0000 Received: from BY2NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::208) by DM5PR17CA0049.outlook.office365.com (2603:10b6:3:13f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16 via Frontend Transport; Mon, 7 Aug 2017 15:53:52 +0000 Authentication-Results: spf=pass (sender IP is 128.82.55.16) smtp.mailfrom=cs.odu.edu; barelyenough.org; dkim=none (message not signed) header.d=none;barelyenough.org; dmarc=bestguesspass action=none header.from=cs.odu.edu; Received-SPF: Pass (protection.outlook.com: domain of cs.odu.edu designates 128.82.55.16 as permitted sender) receiver=protection.outlook.com; client-ip=128.82.55.16; helo=webmail.odu.edu; Received: from webmail.odu.edu (128.82.55.16) by BY2NAM03FT023.mail.protection.outlook.com (10.152.84.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1304.16 via Frontend Transport; Mon, 7 Aug 2017 15:53:51 +0000 Received: from dax.ts.odu.edu (192.168.97.75) by dax.ts.odu.edu (192.168.97.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 7 Aug 2017 11:53:50 -0400 Received: from atria (172.18.200.187) by webmail.odu.edu (192.168.97.75) with Microsoft SMTP Server id 15.1.669.32 via Frontend Transport; Mon, 7 Aug 2017 11:53:50 -0400 Received: by atria (Postfix, from userid 2444) id 176FC6E0601; Mon, 7 Aug 2017 11:53:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by atria (Postfix) with ESMTP id CDC0E6E05F9; Mon, 7 Aug 2017 11:53:49 -0400 (EDT) Date: Mon, 7 Aug 2017 11:53:41 -0400 From: Michael Nelson To: Ed Summers CC: Herbert Van de Sompel , Peter Williams , Geoffrey Bilder , "Simeon Warner" , "John A. Kunze" , link-relations Subject: Re: Request to register "identifier" relation type In-Reply-To: <5FE35A03-052D-4908-8F38-3D4A52F21FBB@pobox.com> Message-ID: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <5FE35A03-052D-4908-8F38-3D4A52F21FBB@pobox.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:128.82.55.16; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(2980300002)(438002)(377454003)(189002)(24454002)(199003)(54356999)(966005)(4001350100001)(50986999)(75432002)(5005980100005)(6306002)(47776003)(236005)(90966002)(246002)(76176999)(5660300001)(39060400002)(106466001)(77096006)(54906002)(109096001)(6246003)(478600001)(626005)(8936002)(8676002)(76506005)(4326008)(6916009)(26826003)(83506001)(93886004)(45336002)(38730400002)(86362001)(7126002)(8656003)(46386002)(110136004)(6266002)(57986006)(2950100002)(53546010)(42882006)(88552002)(2906002)(23726003)(50466002)(229853002)(2810700001)(189998001)(356003)(6666003)(7596002)(70076001)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR17MB0259; H:webmail.odu.edu; FPR:; SPF:Pass; PTR:webmail.odu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT023; 1:U2l3fGVcb7bHRsdog3C5W7JXewsUb5oGHEKWCBYHrqojoJwu6m4A53gH1wktbGww5f1K/oFb/kFwVXxkR01nPdNm6BiY95z0wkzubdC5ROz3BLEAtqxzCy03w/QLdRtYYf24Joan3moTqD+64PE5GiuYFoBKmvm2zgr3h3G8ok9O9YFUNq4RD02MclGWTdspJNopwUlHeVQ4vENLHx3S+pw/AvEtKZEMQ84m5i+Nz/fQ2A8DtKDmKQlGef3wr27ZKwvoJqe3QaDfvaq9NZzLkVsylPRZUN3af4ZGn4rYvuBl5ud0asnMFjRMFd6mKnGvq3z0YR9sTwbfG3hGCUG7FBm0x/wDB1Pt9nv9uYnhIbNN7IGGpGQ8J5ouRc76VGzVAb1WcxQCrO1IXkzRi2mFyIIsclYPkF+XrlYuxu/90H52IX+wxJm/3Lf9jKd0Yv02wxcK6kt7iSYJsk1gR2dCvtUXlnTI1OWK6QyKc2r5DQHRSEzG2ZPg0cbW+eaQmD4JeLXHdsDF4eo372BjOtPZOpdKE61H6CzCQSHv3hrPy0SKZrtFAQQth7vmYaFGyk/DHn9mFuqSzxzw8H+ge0vJkU6kUIWEIaS5FD/kfOLcWlHox1vVRjNq6X3P8P0lvb8EkKFD6tW6Upz+jZG6sx1q7ldFdS6oG2nCxTceCbj1+xHwXrOIiRxKYtfjc/p+ZPQkMLijFKIilRhUx8ernGuVFowMEUIBpuptPGbViSct+Yqad2UtveL6o46sz+cWYguLUtK/ADw9iaLWauFgz+jOhBUMC8uRMY7RprBXIeLU3wMdwZ2rgKBkE1C3EJFBgYYlbdC6A+2ba9aUCcn6Y378bTcknBiHuJT5y8dmnXZpBrk= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7826d883-4b36-4dcd-9163-08d4ddac7ff2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR17MB0259; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0259; 3:JxD9qNrYbwJRn4PcnL2rrlN1Q72iitZdlMO10H5f/K58l1IAZ3HW/UNfwiIwe0veD77DCLx/4EFNskaQbZ/SoCwzrCtYD3JoiDRf5TRTHi70jorQd/Rp00/GWxalHi7qSoFEsWf2nTP9r7QT36LtvxFIQrdtU2C8ZjJwMn37w4kTEDHT2YoSqQwgCLM6HEY5S29qXlhI5Gj7C2Ml4amFnkq9EIDTbDOVA8e2JPifI3YfpFManhEauQh28T7ysIB7lk/abrDG1xzT9pqvUkDqRtXmtdd9Y1T6WuC452eILAgpMZ6DQJYlnsp6ekAlkgfmG1nV5AM2PPwOxXTQMzGJ3g==; 25:gM0Lf6jfGmCanAQDfEFA9MV0VuXqmFTwlTiNC6f+6bsJ1Y0mq/KAY005i3EGMqmTYEmHL2ubV6SrXzgxzw8nto45AduZy/shWa25dkHZZepxHj09Kq79Mf0gytHouB/R5tx69+YaBV/uEuVYDJRJcGL/siiG4IetbytDpvpWfL5rg5OA0j0DCtfdHElbtJEsojFr6C5iQDWeJkOnbfpbagv2QSReVJmqWri3TJCZSK+yVdRbp9sKZeHJ1hhqONpoR2jERSsUT68GWpk04vzVIuSZkLor4kw/jxe75VwoM2hCY7KzTDTdxC0yCtEohs5pMZ7Rs0uDueCBytYRImU3pg==; 31:Iu2/TnvgyjswuQ3HLUo1/DvDqnG3KMSykQw5YUlss70sa+yy8FY3wsmT41QXTvxCi3H4MN2mJrdfbFwHTTUA6F0hHtZ7xx4X7P9DOonV4jlhG4DsKKgDTewkbWMDXGdKfEsI2lII+YPTBYUhhCaeEJJ7RaNADDF/sIS5NyjjAWZhkLmu4tWqCJQlTz4CCKMZu14spxRRkFAeB5Y2K0d8JdUASmJF5AKZPaLHiL6ldKc= X-MS-TrafficTypeDiagnostic: BLUPR17MB0259: X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0259; 20:Irw3r7maKo9D95IXoq+zfcEbf90n/STly0JtmtYufrmqd97hG7RtSZJUK4DwfnVU+wl5LoBzvRA/2gYGrUDYPyYwuipGUSxTlZMqnxgOR80MscGlLPTkAOxrOGyMt5NBIiaxQB7p524l6xgmsIXUwXLpuB59dq0J0woepQtrnh+JqNYLJGNrTPN/M4VEJp25pl4RakGTUAqd4lF0JWZFFtj4JbGOdk2z8uXLFfdZU9ZHbmScvfDDSSHXCYrOqGeQcp+/eKBU5ajZiTJH6nYTV+ETQk0DzXHsElkKe8YuFg+/xmgXwn1fKe5swImr9Qlctap6tgo8B9r6eKPY7CZfO3EB+cTmy6eE4Y9Sgnk7oDMhtV/p4biXAZEwlaKBN/G5R2JBDZDAEF3AVzZ5myFcXTu88pORPNmXa8IGqDcqMeKYt7CoyLwIWZu+rWZ7CR+SplkefAHW4X4idtAzfyPVdVFFECnth7pdHmQ4pwvb5hbpJ8y1B/tCAnvGmP1zfUByTT1OQDAECKOtOAWJnIMU1ieZ9kGi2RJvzdTSjc+yki+JSObTChmaAwj1kGB0ZnLzemPZ5KmF+hutQqfk6PqW1iPuPOrnZJG4BvucrqnDWuU= X-Exchange-Antispam-Report-Test: UriScan:(131327999870524)(162594542051504); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(13013025)(13021025)(3002001)(10201501046)(93006095)(93004095)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR17MB0259; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR17MB0259; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0259; 4:E+IpiEeDb8zkbP/D+U880ZyClBvOwBQbNqVEDmAQ/rdPz6MPjoiSttnnlTfeZYzhwyu6TQnypZiNmvX7ppOoe85E0sTo5jDoctKQ8CII/d5olPnZtzIS9no/ukRyrsXaATtwZqMSg5CITJ+/UAL6sGH4E3nVfy3o0Wx5v1kJeuerThaF1/3WEbxWhBqwi9JwdCVhzgbKncxuv3Gm8+zRmP0ScNe5FfdN/opv8rHLVaFb9xXLEyjX4w2/kG+Ls5ud9xhrT6/FGROQG9VLhK0PlZ2Bd5H7EX8cphHcP4A/uEHREmsnKTafVEgbOeMz+Rt6jUobTVxPPWj1uxct08jNbg== X-Forefront-PRVS: 0392679D18 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR17MB0259; 23:VpauCoCWqJf2KMfpVeY+ANYZG/hNn39D4CzHBYx84?= =?us-ascii?Q?nQy3G8fjXd/qNBeam0XO4gVmcv1LM5T9qhucf0P08/UzDEdCLsWWEXsao0P+?= =?us-ascii?Q?YoBQg2hUs4KA33bigFYkc9K4v1BJ3vV1zmxfsZs8hm4BebzMRarF8UJbY8yK?= =?us-ascii?Q?VOkb8yQleJd13o2RisjCUR+XrosJH1jBXwXUWINj3Qrtz1KsLXV4hmzULHGo?= =?us-ascii?Q?xMzG9G3WQUYlyAA5RieADq5mHtrJThcJak5PC+06odeaKSTLx9ATPG623Jh1?= =?us-ascii?Q?2B8FOeCIkqqsSRH3sEj/Sao9j/ampATNeTdeo5oiYTm7RUN/He4ob127rTBZ?= =?us-ascii?Q?nwUX9cUTInFBLEDqVnc9yEmLvnZvEnF1B8G2f5StBX518ZZNCOhPj/WYeejL?= =?us-ascii?Q?cRBMQd3c295kEW2tDFcT/ULvjlHzLamXUWwW+n19VwYC6a32416Rc6+C+JMb?= =?us-ascii?Q?R340SKJ/w3JiYVDn/BZpwZRZZFuq+1J9LTeyL6CAZvumUYzRyCmIKjNVvfGd?= =?us-ascii?Q?Vd3xSbHKOIEn4f1HFKgafZj9j8+61OUU/wcz8cfC62ucmKzkdlGAOKKQ26Pq?= =?us-ascii?Q?jCIwJ/kqBwxLyBt3mMVNXvs9g+Sf2Rw/F1XS4M9niEkOlRClPzkYY65gLwAy?= =?us-ascii?Q?9i3Q5Yjqn25LHpjN4VMJmzU8T5CDEVYSGb5sRhmzpsoA4mC9W6GHjX3p73ug?= =?us-ascii?Q?bu64O5ugFi2FOznih/E6Z+RueHT0RbGmNcYzepl3VdmFacZRZF9Nn1ztEA+f?= =?us-ascii?Q?C+6tfNzpO7+y5Go4xcXBu06bcasYiwraBaxwzrhkAXCq45U9qQ+u3s6F7ZSw?= =?us-ascii?Q?niONB+XD8HY9d1dt0XSmAA4GsmkYM5kmkruHvHMXdvRJt6bGwv3KyZqh12Gr?= =?us-ascii?Q?bMbEggud64k0jXmne7PFF+CY1qq2IIuR1tfh7P8t47eSPwC0MpRAEKITzkZe?= =?us-ascii?Q?NE7qDGj8SFjXjggcY0L8gDQvK++z8zr9OhNuaZDm4osyw2Io1SdaNUGTW7nl?= =?us-ascii?Q?gZWiM4ni5leYmgxVexWoWdq81wxB+MspxxjVMLOspmXgDHyTnP7CLGiCtle/?= =?us-ascii?Q?wXr336tR5FCxce6WKQ/gShPsg8Am05RzH5xlEL4qYNUEXTSYCRnZWZqiA/dL?= =?us-ascii?Q?5egi2d/FqHAEmC0qqosZyq3eCSGCjG4DdGY2IR+Y3OGl5t4tLM5NI6Yzcka7?= =?us-ascii?Q?AbGZi1EMA1nmBJ4OXWuG6z5s6AcI6KymQPsFP33KU49W9/0sftj3p+P7IWRp?= =?us-ascii?Q?qQ432BaOcq+mAlVDgfdxUlz8EkuLWjgTns6mtHa8JR07kfVxU9n9zErW+3kM?= =?us-ascii?Q?Wyx0d4OKWhQyAi/8eS9qijgDaVRiaLjAbxwmju0FHRVWPX+p68BU2RLu5FVi?= =?us-ascii?Q?UyDrYNsveqZ8vXwB1Hjj0y+W2q4RkyrVRorFZ8r60Clfvo3Y94iB50SGYE2e?= =?us-ascii?Q?mwfvRXM6CMMENh0jfFD/UXfWkxA/nDORL9x3wNp3EbomSTRBvVWJRjsxNGz9?= =?us-ascii?Q?mmKRTdZF/SRo5/3gYITvarPzxnrYfuGC48BywaWVBkgmOGnxcL6v+Wy7xI4J?= =?us-ascii?Q?dbnplIqE8TbbWiERQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0259; 6:jCoQ3azYt6LVYQcCl7mnAi4pv3weH9bBja6Uj3Mapi/c2fUtPiFKp5c/m/Z6mOJND+kCn9VQABPlowEEGo6IEbGfvWGmZRwrlK7KfENhpayxGCC13SOgSinn+C7aKTzQlNlCd1QXdRBpkY57yha9XzzxzUt9g5a7/4vL3/OpXahIg0es8we67TC0kP/A9NDYS3v97RvtfJb3gxHSdntKqNe73G8kvfC9yoMC9QmTnCCph6JJZeU8b0NPTJiDb1EBGozvC8ZCu+qjgMqc+LNL3E/BZnUu7e/OsNRRnY1/DfHtljp8PTeB+GZ9VLX256BCeoxwbJ4hOx5MylwGpNAQQw==; 5:UL48XW8qEzg8GREKTYtDrjaPe8kNSz0M3UyOV8SnUrrWctA3DP/G82TXlf6GyPmEaQVgOtgva0GuCHsJAhS+RzLLbg5ri7AaYxt4n/+aFcjFQwgo2DXZ1tTFK+6lGQVMr/zy9qFEyfWsD3oDDgTxKg==; 24:jEVZF7qfMbfioyJ1xezSnmCxGBSY234v/+qW0fqh9M+xEPa/+iyqix2ADIfTqesKN4Zg+0iJkSlhTCjcdFeOubmwJ7ShlFsi0RqVAnz9Uqs=; 7:XBzljCxaBDJXE8KONdvo8RDToit1K8I3ilgNfq2t4xwbJaVPNJDTbOvAuGJ23J4qncKH9AvndvTjhqitfNU/9bh97h+U5BzH8N5Ln+vibyUVBtsfNhW5lbzk+xrKHqGttVAVDb7EqQyFX9fXA77C+fpMgRZKEPCVApBtp9m5gI3MFAEGBqtk75bC6uKin41eFnc95Arg2n5MF3uD1ma9F50DJ97mY3nHknvy4RdvZwI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cs.odu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2017 15:53:51.1799 (UTC) X-MS-Exchange-CrossTenant-Id: 48bf86e8-11a2-4b8a-8cb3-68d8be2227f3 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=48bf86e8-11a2-4b8a-8cb3-68d8be2227f3; Ip=[128.82.55.16]; Helo=[webmail.odu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0259 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: Mon, 07 Aug 2017 15:54:09 -0000 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. ...

Example of permalinks

First example

This permalink applies to only the content from the first H2 to the second H2. The DIV isn't exactly that section, but it roughly corresponds to it.

Second example

... 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 . To me, it seems like a weird corner case that has parked on an otherwise good term. Like rel="archives" ;-) regards, Michael On Mon, 7 Aug 2017, Ed Summers wrote: > Hi Herbert, > > Thanks for your responses. > >> On Aug 5, 2017, at 8:56 AM, Herbert Van de Sompel wrote: >> >> Our I-D acknowledges that the semantics of "identifier" are similar to "bookmark". But "bookmark" is explicitly not allowed in (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 . > > 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 . 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 > ---- Michael L. Nelson mln@cs.odu.edu 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 nobody Mon Aug 7 09:53:45 2017 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 57CD613251F for ; Mon, 7 Aug 2017 09:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 UlAt9XW_Z8u1 for ; Mon, 7 Aug 2017 09:53:41 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 8241B132515 for ; Mon, 7 Aug 2017 09:53:41 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id p3so6057531qtg.2 for ; Mon, 07 Aug 2017 09:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NkdZtLcwHp4cNiYAzUVWynzss2NIQY6eSigPfOIYyx4=; b=Dhl7aZ/l8SuV4EwPsiqX3yOJwivQAp1H2zopT2Kk2RmUsng4OpU1PDghLPt7gCwB0T qGPzfISL3YK4hzMP1jTI7vBISz0+WeVsduqpKOjI7KPDGSCRkEi8KzoZOTC/g0xrdDQb 6DTIH7cmFgX9EjgzNKxUTpiqXLo29Mj4G2VGAmwk/XkD7p6aYHjIUdZXxqol8qUrzvLm PQ79g/uKSFUDxaIzY1XzcyXp+VYnXDXmzqYkKKg/A4sTBWw1IIdshPAolS6m+8uKVzCN ahq+m4AjxSbnqe3KQWbTOieJ+KlqdHukC3l42Bk0zPTVvQOhUaoXOZL9SLsstkdvKzaL pd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NkdZtLcwHp4cNiYAzUVWynzss2NIQY6eSigPfOIYyx4=; b=HUCvPcRUeMO9H/UoXPcQx6ujFSaD8d/+1g9UAT+gpnlfKNAzPx5inqqcKYMemSNZIf k6Y+iestRBVc5J8HBErXbGg5ldpO6O7NNtumR9gz/Y2GvyHp/queEyLpzbC7eb2oritp Blf/wLlBE5TL1gjnofAQEv3Vk4rae7zx67hdPIgyLCLB0Kx4yyCAY0Ffh81Y6x0d8chg TB8NwbcGPuZ/DALEHxVqhudlUQiV17L1sf57GgtWSR8RZvJoVtT73mxJTdOxJ7+ras+t ZGLs2lEuEd0o7BOSo0bcoa/duR82Es9JGT17xV9Z0bN1RDuIJwH6g2Camd4yGMQ0Z1yG /IJg== X-Gm-Message-State: AHYfb5jlLmntp7qZiVBahyCEWJ+KkSuzi0v9TuQrrsS3D5BEvDwu8OrT MwB6mqRqAQ8Gj9MB8ti97W5xuJcuZA== X-Received: by 10.200.42.35 with SMTP id k32mr1858059qtk.136.1502124820626; Mon, 07 Aug 2017 09:53:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.33.197 with HTTP; Mon, 7 Aug 2017 09:53:39 -0700 (PDT) Received: by 10.140.33.197 with HTTP; Mon, 7 Aug 2017 09:53:39 -0700 (PDT) In-Reply-To: References: From: Bjartur Thorlacius Date: Mon, 7 Aug 2017 16:53:39 +0000 Message-ID: Subject: Re: Request to register "identifier" relation type To: Michael Nelson Cc: Simeon Warner , "John A. Kunze" , Peter Williams , link-relations , Geoffrey Bilder Content-Type: multipart/alternative; boundary="001a113f42c65780a505562cb014" 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: Mon, 07 Aug 2017 16:53:43 -0000 --001a113f42c65780a505562cb014 Content-Type: text/plain; charset="UTF-8" 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" 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.: 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". If the content is different parts of a paper, then the subpages should , 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 --001a113f42c65780a505562cb014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The short version (as per Ed's separate email) is that "canonical&= quot; exists to resolve URI aliases: 2 or more URIs for the same resource (= i.e., duplicate content). =C2=A0[...]
In contrast, "identifier" is about establishing relationships bet= ween *different* resources.=C2=A0 This includes providing machine-readable = linkage between:

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

http://journals.plos.org/p= losone/article?id=3D10.1371/journal.pone.0167475

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

If you discovered one of the three above URIs out of context, it would be n= ice if they expressed membership in "10.1371/journal.pone.0171057"= ;.=C2=A0 That wouldn't preclude additional boundary expressions, b= ut the XML citations and PNG of an article image clearly can't use &quo= t;canonical".
If the con= tent is different parts of a paper, then the subpages should <link rel= =3Dup hef=3D"/to/the/paper" >, should they not?=C2=A0

The DOI is the canonical IRI. Th= ere may be a couple of alternate representations of the whole paper (HTML, = PDF, =C2=A0and paper). Then there are parts with their own IRIs (images, ta= bles, even chapters). The parts should link up to the DOI (explicitly using= rel=3Dup).

To me, rel= =3Didentifier sounds like a hypernym of alternate and up specifically inten= ded for pointing to the nearest DOI. If it's only intended for DOIs, wh= y not just call it rel=3Ddoi? In non-DOI instances the distinction between = alternate and up seems important.=C2=A0

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

Regards,=C2=A0
Bjartur Thorlacius
--001a113f42c65780a505562cb014-- From nobody Tue Aug 8 09:46:29 2017 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 480301327A1 for ; Tue, 8 Aug 2017 09:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=olddominion.onmicrosoft.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 riGzMa5lhWwS for ; Tue, 8 Aug 2017 09:46:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0068.outbound.protection.outlook.com [104.47.38.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D3B131CE6 for ; Tue, 8 Aug 2017 09:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olddominion.onmicrosoft.com; s=selector1-cs-odu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Pu+J0aL9rTI4di/5w4UXg9o1Ut0b/+y9p3MwlR2NDDw=; b=hnLZ/E3s8f4JAZ0RAzBPX/ZXo0y1UFT4+GU9zZDMwZGHQXv7lk6xX3XX9+4v7zlYBsEmvMUbohWCQKQpa9W3nNUvh1g7KAvWPvMKrAY9a+Z51uP0p6/T9NYtTZpaHF8ouIss4fsFS5TroEcSXv/vEqsjYkrqlV0QlDaX82BH8bQ= Received: from BLUPR17CA0004.namprd17.prod.outlook.com (10.164.14.142) by BN6PR17MB1585.namprd17.prod.outlook.com (10.175.192.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Tue, 8 Aug 2017 16:46:20 +0000 Received: from CO1NAM03FT004.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by BLUPR17CA0004.outlook.office365.com (2a01:111:e400:c464::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16 via Frontend Transport; Tue, 8 Aug 2017 16:46:20 +0000 Authentication-Results: spf=pass (sender IP is 128.82.55.16) smtp.mailfrom=cs.odu.edu; barelyenough.org; dkim=none (message not signed) header.d=none;barelyenough.org; dmarc=bestguesspass action=none header.from=cs.odu.edu; Received-SPF: Pass (protection.outlook.com: domain of cs.odu.edu designates 128.82.55.16 as permitted sender) receiver=protection.outlook.com; client-ip=128.82.55.16; helo=webmail.odu.edu; Received: from webmail.odu.edu (128.82.55.16) by CO1NAM03FT004.mail.protection.outlook.com (10.152.80.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1304.16 via Frontend Transport; Tue, 8 Aug 2017 16:46:20 +0000 Received: from kira.ts.odu.edu (192.168.97.76) by kira.ts.odu.edu (192.168.97.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 8 Aug 2017 12:46:18 -0400 Received: from atria (172.18.200.86) by webmail.odu.edu (192.168.97.76) with Microsoft SMTP Server id 15.1.669.32 via Frontend Transport; Tue, 8 Aug 2017 12:46:18 -0400 Received: by atria (Postfix, from userid 2444) id 9C6D16E0601; Tue, 8 Aug 2017 12:46:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by atria (Postfix) with ESMTP id 6BDA76E05F9; Tue, 8 Aug 2017 12:46:18 -0400 (EDT) Date: Tue, 8 Aug 2017 12:46:10 -0400 From: Michael Nelson To: Bjartur Thorlacius CC: Simeon Warner , "John A. Kunze" , Peter Williams , link-relations , Geoffrey Bilder Subject: Re: Request to register "identifier" relation type In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1384166916-1037815990-1502210778=:38593" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:128.82.55.16; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39850400002)(39860400002)(39410400002)(2980300002)(438002)(189002)(199003)(966005)(60046009)(41446006)(54356999)(50986999)(90966002)(2476003)(4001350100001)(76176999)(109096001)(57986006)(76506005)(7126002)(626005)(93886004)(5660300001)(106466001)(478600001)(4610100001)(26826003)(512874002)(77096006)(45336002)(8676002)(1411001)(2906002)(7596002)(305945005)(84326002)(4326008)(39060400002)(8656003)(83506001)(246002)(5005980100005)(356003)(6246003)(110136004)(38730400002)(6266002)(6306002)(54906002)(88552002)(2810700001)(2950100002)(189998001)(229853002)(5009310100001)(86362001)(46386002)(42882006)(6916009)(6666003)(75432002)(8936002)(70076001)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR17MB1585; H:webmail.odu.edu; FPR:; SPF:Pass; PTR:webmail.odu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT004; 1:MOErcxnvwFmILO+vQG4QDPCHp0QjI80QNpb0C7QuEb+OHSDUQOeCodHmsuk5q96EDXcu1oNvnVxYzK3gu+6Bol+ycUYHjB1wuXRGgcnfLQL+vz+O3wLw91Rm0p3chE0MW2SfDTFiwgkX7jV24mNLhMNyjdbZHw9JvFAWtnPsekH/g4RV1OM0FuOGrkr2hWabKD0Dspd5zbhwMep507kGvnmD5+TqOvKA3fHZCM4s/hOwlZtK2vvX4/hFAkfLRY1mhC8p/xgQssrDRZVZgIwtfe+XaOrV7ihBtn6YsVkP1B2obeo8W4GqvCmmBtycW7DHcrz9fNCdWE5LRh8Pb0bWWPbtp/QZ+GfREamR5F6guGYgdKpbWU0LdWSex6FCz5phLepmgXU03z8HSL+SpV/qqdwgb9rKGmoMzTyVP1ZV7dyFcQkt+S6KDW9gxIkXxNZq3wALBU5TGuqC+hAQlaq09ePMkegOvluYY4QXgKg48No3IwsQU2WvgE+mG32f2Vt8V7aQe/7Gn+GCzqMNd7X3YsWJ/E3cDDaOdB6M95plziKz/MMSB4WgbLaFgKA67afdcMaECaQ7YUB3c8zD2LlfDB6LXgX5y288C2576tFjhIHVXXo+h82fhpSstRpiEnDLp0oMo5SGlYvFgyvlPA5gNiyk5K85XYQ5uUlQaZBJahLvk/x6EBzAGW3jI4c1VGdwG/xeDjhO0piJb9XAPwA71aw7mvZYWKsZGrOM7YTSj7w0mY+YrpOvDJivIzq2Grd9ehk8hxDIRmNHSFnMdo0cG5clfniZiMkzsIasRUtEobEYuFZ1Gf4968hM9B6KAObY1KvZTHOoEHVnqfwI/gk+qpAN+MQYExvaOimByUd+oRE= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 28867d6e-a8d3-4eb3-deae-08d4de7cff14 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR17MB1585; X-Microsoft-Exchange-Diagnostics: 1; BN6PR17MB1585; 3:SSFa6bTuN1zbRbSmsSsfleJ0/Pl+CGCx8x/oHI+DdwEOgr5FOhVV9JXAXVHLmUqYOT7F1SvvVGfQBIw7od6xolnObwFvRAwt5aC7ngymg/dvDKVKWllfhhziSUtq/hFLtOvQnS02ZoEBIP8+Ocx0rAmljCxnmixvPfSe9PzPL/a87bue5b9OXEl40wbqFqg6ZnCOGOzaD6OYEp00uzrwOJgM0fI0hN7kVgRxrTYB73MXREDiqUfSd2doq+YMdqI5U1IX8gFAKLAIZaCXHZ4h1O5Uj4FOmNs6uRXKUh3DO4417jp4twyVRKZFd9i0/h9UjHj41kVXPWd74Lr2v+g2dg==; 25:7mIOWvkhAsHsgp7Cp5t/A7fTvh94gy7klMMWuxEarizPbkaH9Ch082s9sw8X91T+HUmQnYxoDk5dCDwDTPl1Pd2iK34lDENUdRd9Kn8LnUz0XDCVCX2iUTaGH9pEBKPSP4Cu40XUWzTbG51GEUyI4trCF7wynjkssBqjeAIjaWleUVd/FtS2L0ZrkrhK6okbZ5XNAuCa3PMOelZZXRLA+abxzcXtsojEGEYJ9dG8fTxjvLoKqoYDriM396V5MIUVWPUov6lXQhItJZmW6NbKVdZMa3F3oWt2/ApZm9qglu0FZOqX8GsPw2WJbA/NkzWB+DToHnmjiwwS0O0i77oLVQ==; 31:47v8k0oIalsfxf7P2vr3qfnYOALPSOaxgDH/lA1Z6Wrpf92xA10T4/Ov7Ry49BBmynRMgHJ95tv0+/mK3xHf0AbZ/PVnHblT9ZbONSQuQddyHxu89LNpSa7MhU30sxtxW0mdPNfFeHx3PcXy1V3wDC1mdZ9jLwCq6BS54vkD7p1A+JjMIKr0QUYceOf4hXlBnYMT9eSw8ckxTcSdSfhaFNxGoX27gi2Ew45SjZR2byU= X-MS-TrafficTypeDiagnostic: BN6PR17MB1585: X-Microsoft-Exchange-Diagnostics: 1; BN6PR17MB1585; 20:qRBdwFQitrlkjyn4hKY7x57OirxF5X4VvjtzAB/KVNxDJJUYqSSv76alZxDjMFmFiLTrauBiQuLG3rQvQaLiBnepRX2cLX50xASEWECsLCaYgHhhr9FoADPGya8UQpi2hCF1bcyRR64IfgzVAHS1jSTVmkS8baC4gIe9jAHVz26d5ogHx6MvCTV5F5YW+OXFVDi7ooNiX7Kc3okYSWycYEfryC+rp7hCAFj0zznzZQmLwaqbqj8OO4wsHvF2EHPvW5hoE/3h1TTtWG66zwk8wYeG4gFnYf1miqmh8iGap7kL9vr1uF89KOPW/Or/WFdEIeF84pk4Gf8jy7nfuyVJuZc7Du5mVl0x2A1ZtAYnkAE7fUOTgUnxRiT1ajJj/IOAgba1mbtVhu/Qg4KAXWjQmt9ydKo06pX13WE5+Xy1UAYO6YUAhhzu3sBADdk7CNoa9rG9wuSIU+CnQAApOwk3aZUTILWSgHD4A9WaZr9XrCZWNf7fRgIz8W3eGGgeRO3oYb8ZaeBWlogg8od/AuTMaJvg93elCtaAAE3jVwItmlGp38CiRB8CHFqvdax4va31SKPB5XvnuzFN7oVpMRI8s7acycs+Jr7DyTR7ZVGFxcQ= X-Exchange-Antispam-Report-Test: UriScan:(127643986962959)(165104125076784)(120809045254105)(162594542051504)(101264311250101)(213716511872227)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(13021025)(13013025)(3002001)(10201501046)(93006095)(93004095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR17MB1585; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR17MB1585; X-Microsoft-Exchange-Diagnostics: 1; BN6PR17MB1585; 4:wdr8lBMuQ2Bgn4T63Q1RA+eupoA+jW5ruGu68k8WXon+skalCS+uAl5Tr5pYi4Q4abg37wGVadq3e0suMWp2INjvVUWbAKyXqsgQZSlQ3g7C6kTl6WvEhElV00M5SkRyTBajV/nJ+4enM40b0lDs5VJ558g/jW2sB3WMUdKF6/s7ypTHxs1HKOby+Z9z8LMk8XO3HqifBFBF7GOjPCVCCylPYzf2C573eJMLgVm3bqgowDpul+2MtYNrnFKtnAhrbhfiPiuCw3GtoqKp9ihgizGnoOwI9eYzx21vBIVp4B45pP3K9tWe8XwcjFkN3pZiF/AtiEW4v0VdlRmtzIcohAf3cr9JWpKtZY7KZEJ32CGcevb6dID7X379uIIlPVxFBOk2F8fWPVFbR7vpxbbxjQ6rsZFh3wOZ2wB1Azvtj69RRl+BrlL+zEh2LuXgilComUVSx4dN5igbd3aX3Zx4F7/PEKiyvtCC2DB+awiWNLe24ydGljQy34APPUgIubCd X-Forefront-PRVS: 03932714EB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR17MB1585; 23:SKMK0+z++md/Gud3CqxN9aRnFHjAQMYwTQQFzd31G?= =?us-ascii?Q?RJ5Ga2o7/gca9f2+FtOllIWwL9aKHb1eGzwZmK9R+O3f5sV8l+KALTK0ZoIW?= =?us-ascii?Q?F2AaAL4PzZhonjmsnIziKtj3S29DpYlSoyF+ig6j+Eqa2lge2LbOHOsdpxVO?= =?us-ascii?Q?dGY4xWfP8LKuXFfDQcpKnmZPu6gaqAnMRt/81aXEmSdrxG4dgmGxL4mrrKVv?= =?us-ascii?Q?5wRcyR8FlnuxGTSV67n0ujI6+OztAulyt4+IsSICAyulb3EKkclUZYcY8e9L?= =?us-ascii?Q?0iFFInJoroALdGXO0gt6hDCmRAEygUcetA7vM6kCCPaK5Nj5su1dcdEmcQno?= =?us-ascii?Q?R+2ErZI4erVg12EOogGPZfc2XosZZJY3YsUIglc6LgPD0KVXogl35+uCvhhF?= =?us-ascii?Q?Jdw8ySf/kv8SSRjulAcXm0yMQjsys6cl5ptmSEtFUxQRHYjsI0BEaZfRGL0M?= =?us-ascii?Q?9ZqjlyNFQRRWFXq4NQ1XvhjOoqjOj8tQEKPnW1Ljq6OAS/+4YIebzHYPmcpD?= =?us-ascii?Q?9YBJ5NsLKHUBvsgVEKYKS7BhUADIxgjXUJFqwiPUrhTIci1K24cCOe7CBowU?= =?us-ascii?Q?pYJ20SGQpfpreH+f/wDOSFNNK9GVRHZw3H0yGZlv+PfT/lEQd39hYR8KCmYH?= =?us-ascii?Q?6s42CEev91wEZQ0H+94M7/azYLfL+O/BQyFREuINxyeF9ai3Q3RKP4gzurs1?= =?us-ascii?Q?k+jpScBHDzLglgA4AOXSGcnc803hBjK0cLZyJTXuduN75fsal3Ilx/pIYb1S?= =?us-ascii?Q?gokZEZPes6Xl5Zge8aZdrg3CSx+0BDUI3CBEabbc9NK9uDG09kV4Zq80sKlA?= =?us-ascii?Q?+I1lNPkFZYqtSuwAHGtVV2biR77jMFpaDQA5SF/Qp1xYA9FGgYbQj1PVjkuH?= =?us-ascii?Q?BfQKfEcDhKDQY4QVoDRfNCRko+bHGUHSBcsqucszUQIRC2FkGITdj4PfFC1E?= =?us-ascii?Q?lbMN7Bn6t/GB69j2TYmxUucJ30UDZo3rm7ynE119WF7s8Cqo/aJE62Vh3VuJ?= =?us-ascii?Q?CMoHijvYcL5NPrY1XKwcl+vK2hMC4S8VNcHNqtFCpaTjchH+hbBwn9JlZWwT?= =?us-ascii?Q?0fccww84AGDF5OYOvNUlkZVlE3vVXoBKs3A0zJE+I8tHBBCpW95JrBxoF4bu?= =?us-ascii?Q?gziR45KBc4BxY9P5kATIsV/wTrXnJ3ke6WzUXuovDuzC36v/jCKrYYFLtL/M?= =?us-ascii?Q?zuZABw9PShCd1wP5GnKppHzBY/+Qecuf5tC9ZA/zlbTohc+MFRKYYs7w+Pn1?= =?us-ascii?Q?FVTjkxxdQM9kj2pj7BzSD7i1GZJEop/von1wTJCZ63qIGuFn5v0L14gvMNMo?= =?us-ascii?Q?V/DNtvUNNsD7yEyAEny9EfdagMi+wp0kF9RdYzIb4lnjAhiGaJ9HQJ9OoFDn?= =?us-ascii?Q?ZUrHtzzkwa5gRPPxGGbd9ZG7zZN/Aby/zU8GWNypxI8eyURus/90s/CD4BCq?= =?us-ascii?Q?6QPB5oBrw18YvkxEUF+BIO/5gTwYWk4bReua/eN34NgWUIEoHcp3zV2wfUMa?= =?us-ascii?Q?gPja/v61tV9JSlHvGKCJ0BjRRwjZrF5WjhhPKHEgSbb97Z45FiNvAtsBVQHt?= =?us-ascii?Q?iJnxIxLZzkIk7GFj+qK5AGlHwzpYhNsOpqN3iBuyaU/FB62wC4rRQ6eUG69Y?= =?us-ascii?Q?ew7+NVhAYo/EVNc2dAAdQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR17MB1585; 6:uWaEFsoEBsBQkwDloxJgW0VjPm4uCx3fQ4UW0k+iZVhCQD+s8ntARNTqsE28jV/t+eG62bg8u6mQcoh2oEfcCpU0WPjN7sV/fm0xzht2Hp8c9sorL44vNeAHdZV490efSP2M8lhZ61fB4OydpfRenyA3HnE8hlX51+UoCI1NeTMSzzGdzGOkpOqXfoThV+tQ0A/0r+VNNjlRtM8aqu4W7h5OaVHXl+h0xpaom/gv9ybJkGtn002J3edad5EX+es/FYCYqj42rLah47O5nEtGs0qw940S4El1y34rY23NNGxHRz9Y/Mq+Sc7vXUUTiT1QeZCDpthg9CqK47n1FxgKjw==; 5:Xei5/mjk0G15T5H1WJ/26Jtul2/Fsk/wHKzlz6oNsdf5u7GCyhvKc6IAjCA3HejNcPtZZdaMgQtgq0SBNIXI1DgBmkq2SlQQS54X+9gE/bTEVyhpRMUwle0aWg3XqHL8cRvxTF9kfpTp9IFHBKuSeg==; 24:bAK1NIjWvwlePPSEkjHDFCtaGA5HGN5u9fTWbErgjvJNbsMK6ZoddJ6w625hY5hlUvpbx3tx98OfI9V+EIw/pUBj5fMR1lT/BbPAPeb+0/0=; 7:1U213gx/xRNUvxTjhVEPqcFKoeZbV/bl2PtnUzJPBQOFuuWueKfjjRdJ7OKQ3AyJi8YDHs5eMHWqZIFK1HhHOOdYLl5EAvaQ2aYRskGXJ7059IWXGk031DcTGfIPxBFTgAuivxVzQaJml4oZ0CsoifHWnXhwalOIvHE6veJVm/AncY8F+pO1jdSPdnDzTyO0J/o9UMPdKbLuDU2NWwBNrlaS87u+0NyureuAeNRDETs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cs.odu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2017 16:46:20.0138 (UTC) X-MS-Exchange-CrossTenant-Id: 48bf86e8-11a2-4b8a-8cb3-68d8be2227f3 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=48bf86e8-11a2-4b8a-8cb3-68d8be2227f3; Ip=[128.82.55.16]; Helo=[webmail.odu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR17MB1585 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: Tue, 08 Aug 2017 16:46:27 -0000 --1384166916-1037815990-1502210778=:38593 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT 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: https://datatracker.ietf.org/doc/draft-vandesompel-identifier/ > If the content is different parts of a paper, then the subpages should 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: ; 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: ; rel="up" Because the HTML landing page really is the parent doc for the PDF. In summary, the PDF "should" claim: Link: ; rel="up", , rel="identifier" And the landing page should claim: Link: ; 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: ; rel="up" ; 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 > > Regards,  > Bjartur Thorlacius > > ---- Michael L. Nelson mln@cs.odu.edu 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) --1384166916-1037815990-1502210778=:38593-- From nobody Wed Aug 9 07:35:09 2017 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 596881321F1 for ; Wed, 9 Aug 2017 07:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, 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 9FG3rmzn88-Z for ; Wed, 9 Aug 2017 07:35:06 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 AD26513232C for ; Wed, 9 Aug 2017 07:35:05 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s6so37523571qtc.1 for ; Wed, 09 Aug 2017 07:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B8VVnV8RqkcLDE69deyyZ95CqeWd62mjqJlogtPB/ho=; b=ZWBIJVbvZBoIf9RBz983gkEu2GqjDNRe10FG1POf31tKnCui+AxTjH3xQOlK1f9yH/ +wP0wPXSlMfxxEpVY09KwpRK5OqEBfqmqEYR0/p2cByTxWXLqAqKEaJPq0lzP9wALl34 3zOUFT9i+iOv8WWFl5lgYo4yqUmpU1wKoxXVstxtfRmPzQL9crEusIuiUIgh3GAzZnpb MNglWlLtlkqIYexjsNDPixcc0Sbyc77nfcaEquoDCdqMFAr9WklpkBbWktQ3tuAuFp8O SL5/0SOHRM4151bnrN4qVw8J7SYoddva8qmjQ/pC15VohDMTqYBOw0lpYh/YSl2DdJhg 0t/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B8VVnV8RqkcLDE69deyyZ95CqeWd62mjqJlogtPB/ho=; b=ibyeqU0vDTXnD3tS8fSHOBMHzfqhkaMmimyXxj0XRQ2b4w/gCdazH0rRuhc3kGwAJM odcPB2s1oiX9SgtLRCEluaxiztJvLgPF1cLgXGX2GR/TymWqhuPt415PWfgMmdnWDL4s rGGYIK1OMFMmj+XNhQMT48DXb+AwhuSDhY77yV2vrSQ1y3X3Q7ZJBMQmeBtnTqrAqVGY 40IkAPg3aO0rA47NzgJgo0vl0WApLiwkVoTpx04lBk+QY2cJDEtvxTsYVnjevqQUJyjP yR2Pysg9M8MQ/AXHHe7joHVt3h5RivIczqpQl7qxqZmX+nHYJRXd/fUmz280diHFu+YB jP+A== X-Gm-Message-State: AHYfb5jXKCGKW9XdU599kMid9qCY3evjW0zz8d7fGOiBZ6E1+XAfXLRS BwhsxcudOxe0+7IbwCP1ttxbIU2uGKh2 X-Received: by 10.200.42.176 with SMTP id b45mr11256846qta.76.1502289304264; Wed, 09 Aug 2017 07:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.1.194 with HTTP; Wed, 9 Aug 2017 07:35:02 -0700 (PDT) In-Reply-To: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> From: Herbert Van de Sompel Date: Wed, 9 Aug 2017 16:35:02 +0200 Message-ID: Subject: Re: Request to register "identifier" relation type To: link-relations Cc: Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , Ed Summers , Herbert Van de Sompel Content-Type: multipart/alternative; boundary="001a1135228a54a3db055652fc47" 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 14:35:08 -0000 --001a1135228a54a3db055652fc47 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 5, 2017 at 2:56 PM, Herbert Van de Sompel wrote: > On Aug 5, 2017, at 13:59, Ed Summers wrote: > > > >> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel > 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 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 (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 . > > 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 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 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 . 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 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 . 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 -- 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 == --001a1135228a54a3db055652fc47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 5, 2017 at 2:56 PM, Herbert Van de Sompel <hvdsomp@gmail.com&g= t; wrote:
On Aug 5, 2017, at 13:59, Ed Summers <ehs@pobox.com> wrote:
>
>> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:=
>>
> I wonder if rather than adding another link r= elation to the mix if the HTML folks would be willing to update rel=3Dbookm= ark=C2=A0
to allow for usage with <link> which ought to make it amena= ble to use in an HTTP header as some other HTML relations are (e.g. alterna= te). The semantics of bookmark speak directly to the issue of persistence t= hat your I-D seems to be addressing.
>

Our I-D acknowledges that the semantics of "identifier" ar= e similar to "bookmark". But "bookmark" is explicitly n= ot allowed in <link> (and hence Link). One has to assume there were/a= re 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 S= ummers posted a question regarding applying "bookmark" to <lin= k> to the WHATWG list, see=C2=A0https://lists.w3.org/Archives/= Public/public-whatwg-archive/2017Aug/0001.html. There are no respo= nses to this post, so far.

* On August 9, Ed Summe= r posted a similar question to WHATWG/HTML GitHub, see=C2=A0https://github.co= m/whatwg/html/issues/2899. There is a reaction from @annevk who (1= ) speculates that the reason "bookmark" is not to be used with &l= t;link> might be in order not to overlap with "canonical" (2) = suggests the use of "canonical" :-)=C2=A0

* Michael Nelson has further explored "bookmark" and has confir= med that there effectively is a reason for not allowing "bookmark"= ; in <link>. It is related to its target use case: surfacing a link f= or content contained in a *part* of a page. Hence, Michael concludes that m= aking "bookmark" usable with <link> will most likely not ha= ppen. @annevk's GitHub response does not seem to contradict that.=C2=A0= Michael based his findings on studying http://tantek.com/log/2002/11.<= wbr>html#L20021128t1352 and=C2=A0https://html.s= pec.whatwg.org/multipage/links.html#link-type-bookmark. He ma= y write another blog post about this, but, for now, here's how he expla= ined on Twitter https://twitter.com/i/moments/895081563653902336

As a summary, thus far, of these discussions:

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

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

We agree wi= th 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 a= ble to further clarify that analysis in a next iteration of our I-D. But th= e analysis will still reach the conclusion that these existing relation typ= es are not applicable. As such, we also reconfirm our request to register &= quot;identifier".

Greetings
--001a1135228a54a3db055652fc47-- From nobody Wed Aug 9 09:18:02 2017 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 3C9661323D4 for ; Wed, 9 Aug 2017 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=ehs@pobox.com header.d=pobox.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 nqRhKr8uGHdg for ; Wed, 9 Aug 2017 09:18:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6CA13240E for ; Wed, 9 Aug 2017 09:18:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EF1B7ACD52; Wed, 9 Aug 2017 12:17:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= SPqB28WEEa8aJK0AGDu6vbQvkYY=; b=V4U2jGw3qWl7Aa2EDkyv/HnkRwdyMMJs whQvIWDKezfBbLmQtrBnrbsHwqbs4KlBaFEMeVNm9YO4mNpWrjv438sC4cihG1S6 j27TcFHOm3OgiDi+2cFTiINj8JVWzxVn5mw+VkQezN3D4IsZQsLI4vsyszMn4FvA akJyVv3E2Rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=GHyAKqzycaUk+YEhvndOBdCsZ61Qgn0K/XNfBecP5DKIaFmEF58m1xs8 507FrMboUq3N56B5oCW5EUF/2bd+BUoPEVbWTiGMiu9jEPgpIvdof5bHDvdVNNyl +yU3hCJGIeqEzemLUk2vk9qDwpzEAqq8mzK8EsDWFQ3l18OuIXs= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E74FEACD50; Wed, 9 Aug 2017 12:17:56 -0400 (EDT) Received: from wireless-10-104-179-255.umd.edu (unknown [129.2.180.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 597DAACD4D; Wed, 9 Aug 2017 12:17:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Request to register "identifier" relation type From: Ed Summers In-Reply-To: Date: Wed, 9 Aug 2017 12:17:55 -0400 Cc: link-relations , Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Transfer-Encoding: quoted-printable Message-Id: <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> To: Herbert Van de Sompel X-Mailer: Apple Mail (2.3273) X-Pobox-Relay-ID: 4DB91E42-7D1E-11E7-A261-9D2B0D78B957-07615111!pb-smtp2.pobox.com 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 16:18:02 -0000 Hi Herbert, > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel = wrote: >=20 > * On August 5, Ed Summers posted a question regarding applying = "bookmark" to to the WHATWG list, see = https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/0001.ht= ml. 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 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 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 = . 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 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=3Dbookmark cannot be used with = 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 nobody Wed Aug 9 09:25:45 2017 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 A5B8513241D for ; Wed, 9 Aug 2017 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eOzVRGja0_d2 for ; Wed, 9 Aug 2017 09:25:41 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 0AADB132412 for ; Wed, 9 Aug 2017 09:25:41 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id 16so39373766qtz.4 for ; Wed, 09 Aug 2017 09:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FIeb/smkOPvNBBD86XVy7mMF4Tu3IVigLaBjqtK1w6g=; b=R8cMgF12zfaqUvld4jXVE3TAr8qqxNjXkOLqCYzNwQaa7/pYtrsrfEZtMw4zrvR9qU FSzGqU5bpb4s7HI4kgMRF3OKpcyeiXawBlDlsY2o1cP3VHsPVa8Ikly5BEPL/1AUWcx5 nfXGDVl6IcEZlWncHXFO7EjsqcK5ojnEoY2Y3DWIgDN/JpQ2bL6LVRxyM/KUB9ogijRJ 2R5EZV70ziJ4xWugvHJ1MfwRLmIsw9Srf0MtrgcbVnBzZvRUADWyWoZzGjc8xRHWaL5X gRGVjdyh486GLwuqIFmJeLoxZTwZzh23+V3FBFSKmz3nP+N508NouklI88UxHMI6+Fbb uBFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FIeb/smkOPvNBBD86XVy7mMF4Tu3IVigLaBjqtK1w6g=; b=RMWVnR78kTMrV/Z/jkKqDJP5YovHwTREgi5A/Kufa8MCmf1fYshgzmkW8rcwbwbUGG cA50NS4LMh1fAjBj8+an5mvZtnUr7sWKnpGLmZrEoNbbYUlIhHCsmb1/ocsU7B6gkaa0 9n+KyJBdOhWkJafsty9yvNJuGS9jwFoxpBxL4U7XIgdkrIbeQTKUkE8HPMl1SmsovLak E9Q9qVTZlDp97OYpe60QrdcLvOQlY/zZU1+ndKyoe7ehcfCmExjAIU9zl/FHOh5Ilke/ zT1EeYysiEqoG+aP5bjv2iYjeirK/Nn7wfjEibAr+DBttKZ8L7rpun7S8PWpD04jbIhU cFvQ== X-Gm-Message-State: AHYfb5gru+PuvCk1tROxQT9PpVOf7HHpKmAvCW2XCknjgNLIW36Vob3D 9M/aOdpMxLfTRhRh3SphnZOFOlU6FQ== X-Received: by 10.200.4.4 with SMTP id v4mr11535917qtg.23.1502295940166; Wed, 09 Aug 2017 09:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.1.194 with HTTP; Wed, 9 Aug 2017 09:25:38 -0700 (PDT) In-Reply-To: <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> From: Herbert Van de Sompel Date: Wed, 9 Aug 2017 18:25:38 +0200 Message-ID: Subject: Re: Request to register "identifier" relation type To: Ed Summers Cc: link-relations , Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , Herbert Van de Sompel Content-Type: multipart/alternative; boundary="f40304378c24dc7b6f055654878c" 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 16:25:44 -0000 --f40304378c24dc7b6f055654878c Content-Type: text/plain; charset="UTF-8" On Wed, Aug 9, 2017 at 6:17 PM, Ed Summers wrote: > Hi Herbert, > > > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel > wrote: > > > > * On August 5, Ed Summers posted a question regarding applying > "bookmark" to 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 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 . 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 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 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 > //Ed -- 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 == --f40304378c24dc7b6f055654878c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 9, 2017 at 6:17 PM, 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 "b= ookmark" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/pub= lic-whatwg-archive/2017Aug/0001.html. There are no responses to th= is post, so far.

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

=C2=A0 =C2=A0 https://lists.w3.or= g/Archives/Public/public-whatwg-archive/2017Aug/

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

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

> * Michael Nelson has further explored "bookmark" and has con= firmed that there effectively is a reason for not allowing "bookmark&q= uot; in <link>. It is related to its target use case: surfacing a lin= k for content contained in a *part* of a page. Hence, Michael concludes tha= t making "bookmark" usable with <link> will most likely not= happen. @annevk's GitHub response does not seem to contradict that. Mi= chael based his findings on studying http://tantek.= com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#lin= k-type-bookmark. He may write another blog post about this, but, f= or 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 Ann= e indicated it's likely that rel=3Dbookmark cannot be used with <lin= k> because of perceived confusion it would cause with canonical. The sem= antics of parts of pages vs the page itself don't seem terribly signifi= cant to me from an implementation perspective. Unfortunately 'identifie= r' will also probably cause some confusion as well. As systems that rel= y 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
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> //Ed



-= -
Her= bert Van de Sompel
Digital Library Research & Prototyping
Los Ala= mos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orc= id.org/0000-0002-0715-6126

=3D=3D
--f40304378c24dc7b6f055654878c-- From nobody Wed Aug 9 09:59:54 2017 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 9ACF4132446 for ; Wed, 9 Aug 2017 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.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 43PO1_40dETj for ; Wed, 9 Aug 2017 09:59:50 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 E44A5132444 for ; Wed, 9 Aug 2017 09:59:48 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id e124so67313213oig.2 for ; Wed, 09 Aug 2017 09:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kc5H2cHvH7pN5H+jXBXyjaGvh/Rq8GxUA/ub6blu2Ic=; b=XFMUgBNmnqz9n0YNs4vuQ5E3SjE84PAViMS8FTtDZO/Q7ooDHx9LCtpXlpN+7cmEXa 4jn2Wec7pAtINLSW0jNt9efC7Ysa/cw/LXYUNGYzWbZ8tDyEMTs04A+Eqii2Py40fSGW VuC1p+RtxeGMzmWW9dnv5bMrx+d3EnBDbrue3T0WfEs2WybGdCmij+skGNiua9f9UgoG 6e6wrysCYXxuypjiOa+3LN24UxUedEffYVWWNhgw3MD2GnrX/KzaEHP8ilQYYyCmB1FR km7O9WcWYWzpvlNzis0dt6Hrhw7RDBP5lYc5+JmOT8XWmtmtNzRw1a2C+Uu3baDQBqjk cwkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kc5H2cHvH7pN5H+jXBXyjaGvh/Rq8GxUA/ub6blu2Ic=; b=kdPxHU0iMlnDdx85jZxSdwuX7IQaa3VDxXYiKLeH9INEe9vjusjuPoElvFp82fyHDq upBrag9N1gLCLoKXqiK2bjIguOOWxCwoWM5c3TxUAvIhcfsMfwXphLpETJsNYeUQQI+/ JAA9mjsMQznbi6kiI4rngCFWkA9o9GI2AbrMJp29zaAa0WAcJ/mt/ECm/W2DosLkyjVI cyIvxEQ9R9XTUmRiKFfVw7+h5BO5jofjulX3d1FFIodIh4M9PxzMF86JPOPsLnsnZw8b +rTjwrrKW3T0w/dYxa+imq2VvJAwyrt4Y0HErjHDLX2Xpi70Apg6v2d0BeXNTx5nh1qC Osyw== X-Gm-Message-State: AHYfb5g0GT+FPpUZbgFZJhQQwVnqbDkXTCTClYHBeqGL6aqxgmR/gRQg 8mDVO7J9WnNRnDT6TjRAMOOSJfQiU6BO X-Received: by 10.202.79.84 with SMTP id d81mr9082710oib.50.1502297988119; Wed, 09 Aug 2017 09:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Wed, 9 Aug 2017 09:59:47 -0700 (PDT) In-Reply-To: <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> From: Peter Williams Date: Wed, 9 Aug 2017 10:59:47 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Ed Summers Cc: Herbert Van de Sompel , link-relations , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Type: multipart/alternative; boundary="001a113d83c4edd86b055655010c" 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 16:59:52 -0000 --001a113d83c4edd86b055655010c Content-Type: text/plain; charset="UTF-8" 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 On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers wrote: > Hi Herbert, > > > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel > wrote: > > > > * On August 5, Ed Summers posted a question regarding applying > "bookmark" to 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 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 . 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 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 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 --001a113d83c4edd86b055655010c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This discussion has convinced me that no existing relation= is a good match for the proposed semantics. However, i am concerned that t= he proposed relation has taken this much discussion to understand. The conf= usion it generated here does not bode well for it being used properly by me= re mortals.=C2=A0

I think a more concrete name would gre= atly improve the usability. Finding a more concrete name will be challengin= g because this relation conflate several different relationships into a sin= gle name.=C2=A0These different semantics=C2=A0are called out in the I-D in = sections 3.1-3.4.

Having multiple relations, one f= or each=C2=A0semantic,=C2=A0might be another way to address the usability i= ssues.=C2=A0Some of those use cases seem to be covered by existing relation= s. For example,=C2=A0`canonical` seems tailor made for the "Version Id= entifiers" 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 nar= rower use cases would be much easier to understand and use.

<= /div>
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 "b= ookmark" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/pub= lic-whatwg-archive/2017Aug/0001.html. There are no responses to th= is post, so far.

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

=C2=A0 =C2=A0 https://lists.w3.or= g/Archives/Public/public-whatwg-archive/2017Aug/

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

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

> * Michael Nelson has further explored "bookmark" and has con= firmed that there effectively is a reason for not allowing "bookmark&q= uot; in <link>. It is related to its target use case: surfacing a lin= k for content contained in a *part* of a page. Hence, Michael concludes tha= t making "bookmark" usable with <link> will most likely not= happen. @annevk's GitHub response does not seem to contradict that. Mi= chael based his findings on studying http://tantek.= com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#lin= k-type-bookmark. He may write another blog post about this, but, f= or 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 Ann= e indicated it's likely that rel=3Dbookmark cannot be used with <lin= k> because of perceived confusion it would cause with canonical. The sem= antics of parts of pages vs the page itself don't seem terribly signifi= cant to me from an implementation perspective. Unfortunately 'identifie= r' will also probably cause some confusion as well. As systems that rel= y 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

--001a113d83c4edd86b055655010c-- From nobody Wed Aug 9 10:20:17 2017 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-- From nobody Wed Aug 9 10:39:28 2017 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 7797B132455 for ; Wed, 9 Aug 2017 10:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 fXsEoZ2_PFEj for ; Wed, 9 Aug 2017 10:39:24 -0700 (PDT) Received: from dret.net (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40431321C7 for ; Wed, 9 Aug 2017 10:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=A2eVYNq5hHHhkS0YDORvsDPXbpK76FQXpKI21gMxrDk=; b=W+J4zNO3zyQBdsEdWM2RZ5f9/0 fvW7vkhnK3GiRwb8W2yjDY4QaAcMFysVZJgMkUC012jCJtTvvZMrUZRSvrV/WfsqwYg27w3tffVGk E3qnG5fcFhV9QLnQ8irZ3275eCGM0rj30b0MWPKETf4QyIFqWwfsEYfwY3Ym012GLlr3V8CZQXmyI yeIXh/+I2axSBvZf/WpfC9rInHqEaWOy1fwUucs3d3+OoaapRvOWRb48vkwu4Hs28yi1jpx0SSsRy eO8Nxs+mVIP2UEXp9aK4QeLDvTDbyCqqtqmXrIg32G740bmPUKwJ0YR34RLDSedBX/eSX3Zc8GH+K C8jQQivg==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:53437 helo=[192.168.1.67]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dfUwz-0007qW-EH; Wed, 09 Aug 2017 13:39:21 -0400 Subject: Re: Request to register "identifier" relation type To: Peter Williams , Ed Summers Cc: link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> From: Erik Wilde Message-ID: <6a1e9764-9efb-3ae3-e0d5-318713bd6010@dret.net> Date: Wed, 9 Aug 2017 10:39:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: 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:39:26 -0000 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:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Aug 9 10:40:45 2017 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 EAADE13245B for ; Wed, 9 Aug 2017 10:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.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 Y--VOI_rm6zQ for ; Wed, 9 Aug 2017 10:40:41 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 1F53A1321C7 for ; Wed, 9 Aug 2017 10:40:41 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x3so68250989oia.1 for ; Wed, 09 Aug 2017 10:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M21MDo4yLvJZnjoAXbnJyOpde62m9THDEt5Lf9H6IjQ=; b=qebtoJkOGsHGWVcYF+6CCCh7ZcPeIOxKG+98JUpvjQw0PvQZ0q0ofqtIeq7yIRI/oB nzAnYA/LP0x0MHLqXvWCTEP/Ln3yiu5Q5fPuQBc1ENQgl8Ejwau0AWfwPV3srVBmA8oD YFlB3Uswy8z4duJbxZnKtJfmLmFajFB0gXwsX33TYZWQRTknj/xZMuj8b/I0pRm6rjyE EeyqneKbyjWzp0D5lXK6IpBgLnsS+Ss+tMFUXX8pUx2CopmGdhaCYuswS1dOSVJK7ChN /qmyOPe8klhfEeHwwEAIoT//cj/HMccBZyAkQmtg74FHq99uAOzzXqs5ictxLiq8kgN2 5Anw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M21MDo4yLvJZnjoAXbnJyOpde62m9THDEt5Lf9H6IjQ=; b=QNNBB4Cs80YjrjnxuwfRIS4PmVkdQzqTmAhr9SUi5gvZytN4x0NSzFk+RIqM9J6nt3 5y3qqwgs+oQka1mixtqive25M4TvIeVHGdzcMY786MZFlA5Mnq1rKqDRFqrepV2KsZhD N7cWJtxMRJtp2pkQvwDQAidmPdD1BwZtmUCyDcq9zyjBu8qjOEe48txYrSZ8O/AhOHEF slv19358yRFdO+2hzCHcuPwdFtEY44jNwTXIUk9ecJY6foQOk9QRg/hyFhS3eoComftY 0rfFuKUa/7GkTBLlhB968rNQqvPROMeq7dK0oKCdMrbykwQXD1IqDZsYHzgTaRHDKAYh AnHQ== X-Gm-Message-State: AHYfb5i23HVF4K5N/YuSq7x3K1vCFJYiGwZ+wbTUgLZQbtSqGCX3hunc Dkfi41xyI0ulrdX3t6egUKAuiBbqLQBN X-Received: by 10.202.52.194 with SMTP id b185mr9083816oia.195.1502300440443; Wed, 09 Aug 2017 10:40:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Wed, 9 Aug 2017 10:40:40 -0700 (PDT) In-Reply-To: <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> From: Peter Williams Date: Wed, 9 Aug 2017 11:40:40 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Herbert Van de Sompel Cc: Ed Summers , link-relations , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Type: multipart/alternative; boundary="001a113d423c1951a405565594f9" 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:40:44 -0000 --001a113d423c1951a405565594f9 Content-Type: text/plain; charset="UTF-8" > > The semantics are the same in all scenarios: the target URI is preferred > for referencing. 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 wrote: > On Aug 9, 2017, at 18:59, Peter Williams 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 > > On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers wrote: > >> Hi Herbert, >> >> > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel >> wrote: >> > >> > * On August 5, Ed Summers posted a question regarding applying >> "bookmark" to to the WHATWG list, see >> https://lists.w3.org/Archives/Public/public-whatwg-archive/2 >> 017Aug/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 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 . 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 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 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 > > > --001a113d423c1951a405565594f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The semantics are the same in all= scenarios: the target URI is preferred for referencing.=C2=A0=

<= /blockquote>Given how much "refe= rence" has come up in this discussion perhaps that would be a better n= ame for this relation? Or something based on it?

On Wed, Aug 9, 2017 at 11:20 AM, Herbe= rt Van de Sompel <hvdsomp@gmail.com> wrote:
On Aug= 9, 2017, at 18:59, Peter Williams <pezra@barelyenough.org> wrote:
This discussion has = convinced me that no existing relation is a good match for the proposed sem= antics. However, i am concerned that the proposed relation has taken this m= uch discussion to understand. The confusion it generated here does not bode= well for it being used properly by mere mortals.=C2=A0


Personally, I think the conf= usion was largely caused by thinking from the perspective that this was can= onical or bookmark, and us having to show it was not.

<= div>I hope that a reading of the I-D itself, without coming from the canoni= cal/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.=C2=A0=

I think a more concrete name would greatly improve the usab= ility. Finding a more concrete name will be challenging because this relati= on conflate several different relationships into a single name.=C2=A0These = different semantics=C2=A0are called out in the I-D in sections 3.1-3.4.


The se= mantics are the same in all scenarios: the target URI is preferred for refe= rencing.=C2=A0

Having multiple relations, one for each=C2=A0semantic,= =C2=A0might be another way to address the usability issues.=C2=A0Some of th= ose use cases seem to be covered by existing relations. For example,=C2=A0`= canonical` seems tailor made for the "Version Identifiers" use ca= se.

Our blog post= shows that "canonical" is not appropriate at all for the Wikiped= ia versioning case. They want the generic URI (current version) to be index= ed - canonical. They want the version-specific URI to be referenced - ident= ifier.=C2=A0

Greetings

Herbert

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

Peter

On Wed, A= ug 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 "b= ookmark" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/pub= lic-whatwg-archive/2017Aug/0001.html. There are no responses to th= is post, so far.

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

=C2=A0 =C2=A0 https://lists.w3.or= g/Archives/Public/public-whatwg-archive/2017Aug/

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

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

> * Michael Nelson has further explored "bookmark" and has con= firmed that there effectively is a reason for not allowing "bookmark&q= uot; in <link>. It is related to its target use case: surfacing a lin= k for content contained in a *part* of a page. Hence, Michael concludes tha= t making "bookmark" usable with <link> will most likely not= happen. @annevk's GitHub response does not seem to contradict that. Mi= chael based his findings on studying http://tantek.= com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#lin= k-type-bookmark. He may write another blog post about this, but, f= or 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 Ann= e indicated it's likely that rel=3Dbookmark cannot be used with <lin= k> because of perceived confusion it would cause with canonical. The sem= antics of parts of pages vs the page itself don't seem terribly signifi= cant to me from an implementation perspective. Unfortunately 'identifie= r' will also probably cause some confusion as well. As systems that rel= y 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


--001a113d423c1951a405565594f9-- From nobody Wed Aug 9 11:03:23 2017 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 CF713132462 for ; Wed, 9 Aug 2017 11:03:21 -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 oVZ74R1v_gCe for ; Wed, 9 Aug 2017 11:03:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 D56621321BF for ; Wed, 9 Aug 2017 11:03:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i66so2926511wmg.0 for ; Wed, 09 Aug 2017 11:03:18 -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=baO9PPxTyTYRc0G/zhxFjaFvEZmJnLozLhAK6Y/wOJk=; b=JeDeN4zVmsOl6PHTvvcwz/fZJZIG5u95OCpXN4EySj3y7DBLB1eLYt3xU2rIh/sbZb SePhC0c7R6tHcwIC+mYATPCs2bwOAbqdayZsYpKYvlI4XIHwOX9jwB3bQSBfvLw0bLTx jVG/iijt5ojiOPVWGZ6kyJHGbNeseHvKrxzsenN2eFQk+NKvnLe3LYhEgor0iGhcW14o 00QnhjbyKDu49mkaKsFsvEnL7T21cS+QC/+X/xePCVqd1pXG3gFe88M20aIuDG77F0rX ItYfyZ/kCGsuBCGIaVc64epQz7qahH2YNUQcdcI2UE4WsNyCVwhFSqzMQgK3TKcN0Ycx uLrw== 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=baO9PPxTyTYRc0G/zhxFjaFvEZmJnLozLhAK6Y/wOJk=; b=flCSTMRXpIP3eJbyyU1aoWGCDHE22d0ObEY01T02h5xeOzAI0n/gMapII7nd2WZLJD zkJ8uzJDsh3rPMTl+YTvhOMXSheOGcsVBfTPkju+TS6/jOt9Y5nSgsmNH3cZxgKQ0XkK azKabM5H0A/Y/BPlRodWdutg7XHKVvbo1YuQSUljW1dcPTk9rZa4xfo559meRVaERFSv l93g0PjsYBAA05Y3OcWqKBhygavZKSbhzkSJPM1ys7vDzIFNA20l0RfHuglzy+0qizAX LCbSmJkVNfxSbL4WCdISIx7Lf2i29/r31fe8Rls/jhm3X8EzBaJrj/eXBZoDtm29Ot9I Iahw== X-Gm-Message-State: AHYfb5i9DUhJcIBpcvRx4w8KLc2ZAtv0j5cCtE1X/e6aQrh134kueytp PqNeBgLzAKuZFZ4LFWE= X-Received: by 10.80.129.135 with SMTP id 7mr8901925ede.237.1502301796897; Wed, 09 Aug 2017 11:03:16 -0700 (PDT) Received: from [192.168.1.116] ([193.141.150.251]) by smtp.gmail.com with ESMTPSA id m14sm2138217edl.95.2017.08.09.11.03.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 11:03:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-41E9001E-ED48-466C-BADF-1F97656C0700 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 20:03:11 +0200 Cc: Ed Summers , link-relations , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Transfer-Encoding: 7bit Message-Id: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.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 18:03:22 -0000 --Apple-Mail-41E9001E-ED48-466C-BADF-1F97656C0700 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 9, 2017, at 19:40, Peter Williams wrote: >> The semantics are the same in all scenarios: the target URI is preferred f= or referencing.=20 >=20 > Given how much "reference" has come up in this discussion perhaps that wou= ld 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 c= hallenging. We ended up with "identifier". Socialized it at conferences and o= n website. Didn't get negative reactions in over a year. Actually people sta= rted implementing it. But, as I said, we are listening.=20 "reference" doesn't work obviously. Intuition would take this to mean "conte= xt URI references target URI".=20 So, I still very much think we want to stick to "identifier".=20 Cheers Herbert >=20 >> On Wed, Aug 9, 2017 at 11:20 AM, Herbert Van de Sompel wrote: >>> On Aug 9, 2017, at 18:59, Peter Williams wrote:= >>>=20 >>> This discussion has convinced me that no existing relation is a good mat= ch for the proposed semantics. However, i am concerned that the proposed rel= ation has taken this much discussion to understand. The confusion it generat= ed here does not bode well for it being used properly by mere mortals.=20 >>>=20 >>=20 >> 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 w= as not. >>=20 >> I hope that a reading of the I-D itself, without coming from the canonica= l/bookmark perspective does make it clear what "identifier" is about. Variou= s scenarios illustrate what it is intended for, and, IMO, the short descript= ion "preferred for referencing" is clear too.=20 >>=20 >>> I think a more concrete name would greatly improve the usability. Findin= g a more concrete name will be challenging because this relation conflate se= veral different relationships into a single name. These different semantics a= re called out in the I-D in sections 3.1-3.4. >>>=20 >>=20 >> The semantics are the same in all scenarios: the target URI is preferred f= or referencing.=20 >>=20 >>> Having multiple relations, one for each semantic, might be another way t= o address the usability issues. Some of those use cases seem to be covered b= y existing relations. For example, `canonical` seems tailor made for the "Ve= rsion Identifiers" use case. >>=20 >> Our blog post shows that "canonical" is not appropriate at all for the Wi= kipedia versioning case. They want the generic URI (current version) to be i= ndexed - canonical. They want the version-specific URI to be referenced - id= entifier.=20 >>=20 >> Greetings >>=20 >> Herbert >>=20 >>> For other use cases, such as "Multi-Resource Publications" and "Persiste= nt Identifiers", there don't seem to be any existing relations that would wo= rk. Relations for those narrower use cases would be much easier to understan= d and 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 wrote: >>>> > >>>> > * On August 5, Ed Summers posted a question regarding applying "bookm= ark" to 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. >>>>=20 >>>> There have been a few responses if you look at the list of emails for A= ugust: >>>>=20 >>>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/= >>>>=20 >>>> > * On August 9, Ed Summer posted a similar question to WHATWG/HTML Git= Hub, see https://github.com/whatwg/html/issues/2899. There is a reaction fro= m @annevk who (1) speculates that the reason "bookmark" is not to be used wi= th 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 f= or 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. >>>>=20 >>>> > * Michael Nelson has further explored "bookmark" and has confirmed th= at there effectively is a reason for not allowing "bookmark" in . It i= s 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 wi= th will most likely not happen. @annevk's GitHub response does not se= em to contradict that. Michael based his findings on studying http://tantek.= com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipa= ge/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/mome= nts/895081563653902336 >>>>=20 >>>> Yes, it looks like that's probably where things will sit. As Anne indic= ated it's likely that rel=3Dbookmark cannot be used with because of p= erceived confusion it would cause with canonical. The semantics of parts of p= ages vs the page itself don't seem terribly significant to me from an implem= entation perspective. Unfortunately 'identifier' will also probably cause so= me confusion as well. As systems that rely on 'identifier' get developed tha= t will be something for them to deal with. >>>>=20 >>>> Thanks for considering all the questions and tracking the conversation o= ver on the WHATWG list. It speaks to the spirit of what you all are trying t= o achieve with this I-D. >>>>=20 >>>> //Ed >>>=20 >=20 --Apple-Mail-41E9001E-ED48-466C-BADF-1F97656C0700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Aug 9, 2017, at 19:40, P= eter Williams <pezra@barelyenou= gh.org> wrote:

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

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 rathe= r challenging. We ended up with "identifier". Socialized it at conferences a= nd 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 V= an de Sompel <hvdsomp@gmail.com> wrote:
On Aug 9, 2017,= at 18:59, Peter Williams <pezra@barelyenough.org> wrote:

This discussion has convinced me= that no existing relation is a good match for the proposed semantics. Howev= er, 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 be= ing 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 r= eading of the I-D itself, without coming from the canonical/bookmark perspec= tive does make it clear what "identifier" is about. Various scenarios illust= rate 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 c= hallenging because this relation conflate several different relationships in= to 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 U= RI is preferred for referencing. 

Having multiple relations, one for= each semantic, might be another way to address the usability issu= es. Some of those use cases seem to be covered by existing relations. Fo= r example, `canonical` seems tailor made for the "Version Identifiers" u= se case.

Our blog p= ost shows that "canonical" is not appropriate at all for the Wikipedia versi= oning case. They want the generic URI (current version) to be indexed - cano= nical. They want the version-specific URI to be referenced - identifier.&nbs= p;

Greetings

Herbert

For ot= her use cases, such as "Multi-Resource Publications" and "Persistent Identif= iers", there don't seem to be any existing relations that would work. Relati= ons for those 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/m<= wbr>ultipage/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-41E9001E-ED48-466C-BADF-1F97656C0700-- From nobody Wed Aug 9 11:13:37 2017 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 EC7EF132448 for ; Wed, 9 Aug 2017 11:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.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 bQ3C05mIdrAm for ; Wed, 9 Aug 2017 11:13:34 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 E217813246F for ; Wed, 9 Aug 2017 11:13:33 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id g131so68743630oic.3 for ; Wed, 09 Aug 2017 11:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=So+8rS870xdBc/nhbY8z/dM0+EbWoQi+2/f76JYY+JQ=; b=TMNt4ntReVefqs9HBs+J7MWBXBqJOf76nccYBb9XQhQFOUbqFPY8Ga83IInWM0HFzM S2BkzGZNcUy0sCspRq3NrqFWgTKAblR7zIIrOy2+jO4fZBTJdiQNnUrNa+HAitpBJrMq ds564LRO7lGh4N8wpdBjQ86xXgyRKTgvCbn4WANntyJhySJ9BGgeyFP+kZh1wCYrSLJx YTmyiffnYFl5JINf3dCUm07d30xeREVMVgcEAFCBciYBm+tz+UNdZrET3wLTiicBJmIw hSXNKnepkbmyGvCi4zZY6NjNj7FJ4KRpxQ0eWusmqd6XPtRKaF3YZ+x0GTKrQGOfXW3w +LSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=So+8rS870xdBc/nhbY8z/dM0+EbWoQi+2/f76JYY+JQ=; b=Dd2+Ft1OURh1dPOLx9JdxAsjRMO4bbU9P+frcBE2EpFl+B4uC0JZV31ttuxVGuGPXy xZsHJVdFm6LWnkG/7G0pcpjCAzBRu1jfSIXGuH0Z3PKNmFvSWyTwewsXK4HScdhXKdFx 6ppNDxnxMWNvUcaSCCecSwWMBfUMPSVuujm6j9I6fmxj7qFVsz6nJuNIgWkLvDFh+1ht yiMYmyxXi8U4fyoDai/OH1/RS6dl921NoxwepLXbSP5duDh68wHyM79DVrfmGTYdq9nR lb2iI3ZWGLZgpzuostQ/biyOaAVfHHCFViKm7J/74xQdH0Kkt3k0k136Vd8Npz+B4JnM 4NeA== X-Gm-Message-State: AHYfb5iAAk34SBNdld7E2yL+8z5P8CLieIbVXxMmR1tY3GrxRlNQPlCv nqN+mjsoSbWgNxSmBXZmTfhcIpTIXS+2 X-Received: by 10.202.79.84 with SMTP id d81mr9359297oib.50.1502302413084; Wed, 09 Aug 2017 11:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Wed, 9 Aug 2017 11:13:32 -0700 (PDT) In-Reply-To: <6a1e9764-9efb-3ae3-e0d5-318713bd6010@dret.net> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <6a1e9764-9efb-3ae3-e0d5-318713bd6010@dret.net> From: Peter Williams Date: Wed, 9 Aug 2017 12:13:32 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Erik Wilde Cc: Ed Summers , link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" Content-Type: multipart/alternative; boundary="001a113d83c4ad830d05565609df" 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 18:13:36 -0000 --001a113d83c4ad830d05565609df Content-Type: text/plain; charset="UTF-8" > > 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 wrote: > 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:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > --001a113d83c4ad830d05565609df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
semantic= purity may be an elusive goal to chase.

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

Personally,= i think relations=C2=A0have usages more than definitions. There are clear= =C2=A0and confusing ways to use relations, not really=C2=A0right or wrong.= =C2=A0

The more the=C2=A0usages of a relation dive= rges the less useful it is. This makes it important to ensure that new rela= tions are evocative=C2=A0and cohesive enough that usages will tend to clust= er together and that they are distinct enough from existing relations that = they will not reduce the usefulness of existing relations.
=C2=A0=
Peter

On Wed, Aug 9, 2017 at 11:39 AM, Erik Wilde <erik.wilde= @dret.net> wrote:
hello.

On 2017-08-09 09:59, Peter Williams wrote:
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 = existing relations. For example, `canonical` seems tailor made for the &quo= t;Version Identifiers" use case. For other use cases, such as "Mu= lti-Resource Publications" and "Persistent Identifiers", the= re don't seem to be any existing relations that would work. Relations f= or 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 a= nd define new ones that are "more clearly defined" often just end= s up adding to the overall noise.

pragmatically speaking, i think we have to accept the fact that no link rel= ation has a precise and closely followed semantic definition. it always end= s 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 tha= t 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 wit= h 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 tha= t it would be great to have semantically pure link relations that we can in= terpret out of context because they are used consistently everywhere. it ju= st seems to me that given the experience of how link relations are defined = (generally fuzzy) and used (generally based on context), semantic purity ma= y be an elusive goal to chase.

cheers,

dret.

--
erik wilde | mailto:erik.wilde@dret.net |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret=C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://twitter.com/dret=C2=A0 = =C2=A0 |

--001a113d83c4ad830d05565609df-- From nobody Wed Aug 9 12:24:38 2017 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 E0F3613248C for ; Wed, 9 Aug 2017 12:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 uKXLOG4UWM7F for ; Wed, 9 Aug 2017 12:24:35 -0700 (PDT) Received: from dret.net (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762C0132471 for ; Wed, 9 Aug 2017 12:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=od9XgzXOL4MkRt/3YcKtLDaKxQidBxNFtweYeNF0Jqg=; b=ZYH4kN0EgGZgPXkyOToBY9+H0k +1/Zdit+yyhIwtsEMRUzrZokLJlrxTT/EgpDNYlN+xOJloaDQSJYCR1wx36NGI7qYnjrlObOCdKOH DRVoFZ9w6q67BKYc4dQMY2DIPf+n4fuZCLjjFLpmAH549Lo0MCdD4MF6N6CBOeXQkAKkxphEFC/v3 EncLyQppTSoIMROX5HlknJz8+cy6fO8lo5QIa40WSI3xEMFpC07sWxDmYVUN7TxirKiBD79ism6VY mnq2KSn0uwiT3z7vq4958dVfqHoUQ1yFfnQ2es1OkgC1fYuzU/Ygwgocm9wIgO2INtTJuPvJuZxtO EQd+YuOg==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:57557 helo=[192.168.1.67]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dfWam-0002PF-Hi; Wed, 09 Aug 2017 15:24:32 -0400 Subject: Re: Request to register "identifier" relation type To: Peter Williams Cc: Ed Summers , link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <6a1e9764-9efb-3ae3-e0d5-318713bd6010@dret.net> From: Erik Wilde Message-ID: <1932da5f-6113-1750-4085-ab24832eb1bd@dret.net> Date: Wed, 9 Aug 2017 12:24:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: 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 19:24:37 -0000 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... > 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. 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. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Aug 9 13:47:42 2017 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 E94BC132379 for ; Wed, 9 Aug 2017 13:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.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 rOUflrdx70LO for ; Wed, 9 Aug 2017 13:47:39 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 04229132051 for ; Wed, 9 Aug 2017 13:47:38 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id e124so72962111oig.2 for ; Wed, 09 Aug 2017 13:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tm7dZKwP0T+xnJk0zbu1ANimc4m5peteMBywDBYxJN4=; b=Qg43yzWHUIfHC1IS9oTb60/a8OU3yTJYcUMwqixjQK0WrwgpQdt3lYyZxoPCXilQeN eUq66SgIjDGxcxQwNv45t1tJvcO+rNBSU8S+fIQ4vA4HlbvXp5dvoSCL3U//sx3R5bkE oszSFzEHWxQHf/ZTPSCLGz88ny/v9WQ6I2RYqoLADaKw0vVLChUWuijFF/rWgDN4qK9F Ct7r8W4KYu7qhgo+iDRXia0TlvpVGV0ucdKLmhHR5r8hIQLh8mTWHqs3dS+E8faJLihZ ILe95JW7LIzDEFU/Z1VdtC6FE7AT3jX3Axw0za5rF7xVYzfq675WSshJxXRm5YuzEZYu GVWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tm7dZKwP0T+xnJk0zbu1ANimc4m5peteMBywDBYxJN4=; b=Gq9qsxdHIqHTKFwMi8iTk0eSlONcJ1iEKZwYDZ/GrBBqBCyznJcOi1wCgixtQOK2Mx DsBdkQEcjjigwLvT/TwME9C0ob2/ED0VR/jWwpLPNNc6HgrgJlotN49s/gn+CB2tDhJS 4NSXgAAZblt/VEq61wiR1VePplTlkI262FeHSmtGILmSy8n5fFGMVu/VacNlb4PuEO61 Lu8xOD6+AZyE6lt51atfKqI3J2gg34aco3HaTk0hG0zUc2xiLCbuYArfIvlBqGAPrXxu 5L2GuEibouk6CBYU+dSkR3sQcI3XUUmzRHSNdUFGkh1OMhRw4QUZCO75JcaK87PtHp1C Ulsg== X-Gm-Message-State: AHYfb5gIxCyeEah2wZeX7jZ57ejljbVZPlUBkiZiFKIXF5MRC4bjAMaH kPunpwzYTV8OkAurG9/eNEKndvXBXbyZ X-Received: by 10.202.225.67 with SMTP id y64mr10566260oig.159.1502311658387; Wed, 09 Aug 2017 13:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Wed, 9 Aug 2017 13:47:37 -0700 (PDT) In-Reply-To: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> From: Peter Williams Date: Wed, 9 Aug 2017 14:47:37 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Bjartur Thorlacius Cc: "John A. Kunze" , Simeon Warner , Herbert Van de Sompel , Michael Nelson , Geoffrey Bilder , link-relations Content-Type: multipart/alternative; boundary="001a113d4d6ebd92f30556583092" 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 20:47:41 -0000 --001a113d4d6ebd92f30556583092 Content-Type: text/plain; charset="UTF-8" > > 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 wrote: > > > And sticking with the implemented relation name seems better than changing > it to "cite" or "reference". > --001a113d4d6ebd92f30556583092 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
sticking with the implemented relation name seems be= tter than changing it to "cite" or "reference".<= /blockquote>
=C2=A0
`identifier` would, if its use=C2=A0= became common, almost certainly=C2=A0damage the usefulness of `canonical`, = `self` and `bookmark` all of which *identify* the context of the link for s= ome purpose. Most people aren't going to read the I-D. Most won't e= ven look at the IANA link relations registry. Most will see an `identifier` link some place or s= kim a blog post and then start using it where ever the name seems to make s= ense. The usage cluster of `identifier` will be large, diffuse and will overlap the usage cluste= rs of those other relations. The end result will be a less useful web.

The semantics described in the I-D= are=C2=A0distinct 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=C2= =A0being 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=C2=A0of several existing relations with p= roven usefulness.

On Wed, Aug 9, 2017 at 2:00 PM, Bjartur Thorlacius <s= vartman95@gmail.com> wrote:


And sticking with the implemented relation name seems better than chan= ging it to "cite" or "reference".=C2=A0

--001a113d4d6ebd92f30556583092-- From nobody Wed Aug 9 15:40:38 2017 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 4C8C5132380 for ; Wed, 9 Aug 2017 15:40:37 -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 spK88S0f4xmu for ; Wed, 9 Aug 2017 15:40:35 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 A583313239B for ; Wed, 9 Aug 2017 15:40:34 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id k20so17015232wmg.0 for ; Wed, 09 Aug 2017 15:40:34 -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=eBPbwUrFZ+GnbQZ/tMGHOI2TeybpNnBvsqB4fOTeeQI=; b=TOrfkVrCBOKFZ0o6tgFZ8UVttXhLd2zdZrk/UisMtbUJJn0GOsvUkQFvM+d9TLML1j OqHKvmYBea/2HOBDVVp/bA1+CqxzDr3ehJdQ46j5dVye8g41d7MWSsRJDYBORgt3mvug iYKhOY20RLkrZmHO+EXMl4eaMSFowpXT5NPtCH/oMm+rmWIsFWDD/Xgoa89Qw4Df1rPh U0YzJUtraYIRdy6qZtLX/dpvN7big/YfJGNKUA5N/TZUByx2hZ8UZF3DqspKJar0k2VQ QTUyYunT2djJ7ixLcTxnfVuPjVvOnUvkWjpKtAN3WrHeMgRd8/6bQrYTC1wYbEtlPDEE c/lA== 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=eBPbwUrFZ+GnbQZ/tMGHOI2TeybpNnBvsqB4fOTeeQI=; b=OtwjGXtne3T06L+/UENG4cw+w21dy5Q9UBh6etId72zQVF5DEXS25cjoKCooHIqYnW PEuCVSjuiKeiyOFI3mJwMZSE7nyVgwOGolp8EJFleH11b7dgbQ3ZrOEg3PBUpTdQShCZ jG7lRKQe0gJ6QmaciCRHXbsf/kKBQhk4xGVVE03z77mO3o9xxLoZ4xaP7i1+brpa0r2X E0hzMsTMmXBRde7moB6qVVRJxsvwyQkxEZA8wSO0rCfH0L6T9P0uMfVPge1foDLIvM/0 5AiKPV+T9FlT+0GW7te8+HNJJFBxou0X+T67E1NgU75nL/HCCysaohJ6r7ai29pioTJK EinQ== X-Gm-Message-State: AHYfb5j7R2+4qZzJa/t0d0jcr1ikjIirAcEZoqKbJZo7AsCFTTYnuKL1 BmsdZ9i2LDlC0PQbVCE= X-Received: by 10.80.148.211 with SMTP id t19mr9405876eda.128.1502318432830; Wed, 09 Aug 2017 15:40:32 -0700 (PDT) Received: from [192.168.2.6] ([77.172.247.152]) by smtp.gmail.com with ESMTPSA id n12sm2566285edd.4.2017.08.09.15.40.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 15:40:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-784EB572-4C30-4839-88DA-986A1991991E Mime-Version: 1.0 (1.0) Subject: Re: Request to register "identifier" relation type From: Herbert Van de Sompel X-Mailer: iPad Mail (14E304) In-Reply-To: Date: Thu, 10 Aug 2017 00:40:31 +0200 Cc: Bjartur Thorlacius , "John A. Kunze" , Simeon Warner , Michael Nelson , Geoffrey Bilder , Peter Williams Content-Transfer-Encoding: 7bit Message-Id: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> To: link-relations 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 22:40:37 -0000 --Apple-Mail-784EB572-4C30-4839-88DA-986A1991991E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable FYI, some implementers seem to be rather OK with "identifier": https://wiki.duraspace.org/plugins/servlet/mobile?contentId=3D87468598#conte= nt/view/87468598 Greetings Herbert On Aug 9, 2017, at 22:47, Peter Williams wrote: >> sticking with the implemented relation name seems better than changing it= to "cite" or "reference". > =20 > `identifier` would, if its use became common, almost certainly damage the u= sefulness of `canonical`, `self` and `bookmark` all of which *identify* the c= ontext 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 a= n `identifier` link some place or skim a blog post and then start using it w= here ever the name seems to make sense. The usage cluster of `identifier` wi= ll be large, diffuse and will overlap the usage clusters of those other rela= tions. The end result will be a less useful web. >=20 > The semantics described in the I-D are distinct from existing relations bu= t the name, `identifier`, fails to evoke those distinctions. `citable` or `c= ite-as` would be much more likely to result in targets of these links being t= he 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 b= ut not at the expense of several existing relations with proven usefulness. >=20 >> On Wed, Aug 9, 2017 at 2:00 PM, Bjartur Thorlacius = wrote: >>=20 >>=20 >> And sticking with the implemented relation name seems better than changin= g it to "cite" or "reference".=20 >=20 --Apple-Mail-784EB572-4C30-4839-88DA-986A1991991E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
FYI, some implementers seem to be rath= er OK with "identifier":


Herbert

On Aug 9, 2017, at 22:47, Peter Willi= ams <pezra@barelyenough.org= > wrote:

sticking with the implemented relation name seems better than changing it t= o "cite" or "reference".
 
`identifier` would, if its use became common, almost certainly damage the= usefulness of `canonical`, `self` and `bookmark` all of which *identify* th= e 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 se= e an `identifier` link s= ome place or skim a blog post and then start using it where ever the name se= ems to make sense. The usage cluster of `identifier` will be large, diffuse and will overlap the us= age clusters of those other relations. The end result will be a less useful w= eb.

The semantics described in t= he I-D are distinct from existing relations but the name, `identifier`, fails to evoke those distinctions. `citable` o= r `cite-as` would be much more likely to result in targets of these links&nb= sp;being the resource that should be referenced when citing the context of t= he 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 prov= en usefulness.

On Wed, Aug 9, 2017 at 2:00 PM, Bjartur Thorlacius <svartman= 95@gmail.com> wrote:


And s= ticking with the implemented relation name seems better than changing it to "= cite" or "reference". 

= --Apple-Mail-784EB572-4C30-4839-88DA-986A1991991E-- From nobody Wed Aug 9 16:49:55 2017 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 0DBB21324BE for ; Wed, 9 Aug 2017 16:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=ehs@pobox.com header.d=pobox.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 ArysbD5pvfKA for ; Wed, 9 Aug 2017 16:49:52 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A62132495 for ; Wed, 9 Aug 2017 16:49:52 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4212999659; Wed, 9 Aug 2017 19:49:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= lZGnZABt/qR3as+wyT31RureuvE=; b=FB9ytjutNmweJbACu39kvLz9hvZRJi/v n4+t7jWhrTmVPs/Kq8cIHBz4RJwZzvQ9hwEV59nDqXVsxfY66657ok3GYKPi2EyF 3MXqyJAtt8voCNelhYbL3MzmlnAF5BiB2MoQ/8jzF2zlP/IBAOusItuso9QGVUww yJI1US6Dg6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=ZcEW3TC5/4ibwr48Q12QojATqkfMuezk5HERW0Ow7t22lXXNmWABOXWN 0FqChNhT2oP1YNUnhMl8HGt0PgKvrZv7tSQu5IqHhH1G/JpIGLdSqrakGH8fGlpJ iMhB/z8e4WMbazyvQvPKhF7Ck9pyZ4LtAV/VUUP0mknClIy5hsc= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 38EA699658; Wed, 9 Aug 2017 19:49:51 -0400 (EDT) Received: from prajna.fios-router.home (unknown [96.241.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 8994599657; Wed, 9 Aug 2017 19:49:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Request to register "identifier" relation type From: Ed Summers In-Reply-To: Date: Wed, 9 Aug 2017 19:49:49 -0400 Cc: Bjartur Thorlacius , link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> To: Peter Williams X-Mailer: Apple Mail (2.3273) X-Pobox-Relay-ID: 6F13A0BE-7D5D-11E7-B540-9D2B0D78B957-07615111!pb-smtp2.pobox.com 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 23:49:54 -0000 > On Aug 9, 2017, at 4:47 PM, Peter Williams = wrote: >=20 > 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. 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 nobody Wed Aug 9 23:07:03 2017 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 A01DC132557 for ; Wed, 9 Aug 2017 23:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hmYpJF_ZvbFl for ; Wed, 9 Aug 2017 23:07:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AA5D0132493 for ; Wed, 9 Aug 2017 23:06:59 -0700 (PDT) Received: from [192.168.178.20] ([93.217.127.12]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MHX4u-1deagi3RFM-003Ob0; Thu, 10 Aug 2017 08:06:45 +0200 Subject: Re: Request to register "identifier" relation type To: Ed Summers , Peter Williams Cc: link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> From: Julian Reschke Message-ID: Date: Thu, 10 Aug 2017 08:06:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D9ipVLpG/b7oKF9j01dB+QuqXQrTHiKXOrcJ5KZz1hG22Fz5s7P mUqx+SVW1TwWi8ZNcU/GM/PD7YF27s9lNbEZ0h34zqAz/uuvJwpnuAxfYE6ROqoVKOWn++r I71Br8Y2lYOd3FyrT3mgrUD9ZEG1HoBhnPkev8FUR9/gTLWVfwuwHZwmJ+w8BzQ1wqxoXpi xzhX+bKYB5W8NKspwXTTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Wf2bsq63Z0k=:ZtekC+PolUWPqVcry0Lyjh RyyDR1e/7hzLt2IvpHEEA5F9TkpNboYP84vxgnldUABPDqnITlGe4oU3O9etIJPFFBgujiS7C 0urtEtcDO1hDhqZqoi6i6DeQiJKj9igTeQrDMK1gNZatenIk6WK6jPni8Al6xIcI4ZOcanf2H mabwkTr4zIHJSyITE4hmp0DiJ1bCtCHdZ7qdseOwoHE0/ZZWdFNU2yESy1n3LUFof02lKhj6B +bW75CtwxiXzHh1oU3JTuX8xYi3yGmU1wp/QpYxHnWTKaf41J6gbnODPvcSpv5pF4VUNj12wI Ffg1I3Hv+7ie2w7MHbZbUL4ntNqjWjxE+RFkCfebI5Z+g34v3vV15ZSOI7Q+ptnzUyCoz7e8V P4vpVuVS5Mr4ah6kqgP529U+rjrIPje2PzERGhJ1Xl7oI2WFZCrdS+xI5PgCKyrKqphfgSEou sGd4skxrEBptp2V+MkYRyhJmgbPKaM2y/wB7ThFu0fQJEvIcTaFdHc0kPBdypZux/LfJwcdL9 SIcUKuZ1x3MwWjtTywoWuziZSHyeTnDJoBVvkVVnd6J0C2LTHNGvlr0tsBzpYZa2MH3TrSJ3k TEM8CfmrkpJRDKYCpW+7Jbl7L3IRkEvGVveEVS9eHG+ypaAINpWlbNlLO7efBWHZzVQyl/yI0 57EIZRiJKF+hUtVWiu3fD/TeYa9VgxOkxPIUT43DDV73lPHfl1Kexur8nAmjSmxxFt8L7coRL HosNKCfhdMAuZkTM1YYWZ1736ZxB8FyX2odZYEVnAzVBkLHeZ3qrOj4G3AAbKiyoCncGKY9Eo Z78dPCDmmL14TRREW+iqGCAADsbWDwBMGNcWfKFzGgA4HpK9ys= 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: Thu, 10 Aug 2017 06:07:01 -0000 On 2017-08-10 01:49, Ed Summers 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. > ... +1 From nobody Thu Aug 10 00:35:17 2017 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 5E633132628 for ; Thu, 10 Aug 2017 00:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Edo8Qmy8T-6k for ; Thu, 10 Aug 2017 00:35:13 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 BBF5B131D27 for ; Thu, 10 Aug 2017 00:35:13 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 76so9246389ith.0 for ; Thu, 10 Aug 2017 00:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=BX6+blT+Bu0Fpj+7Z/i24QQbzhBFeVIrlGX2fUv0+18=; b=YvmOml51Ff8b/u4FRe+qhIjmiUVzYaze65N1+iaRqK+vMgWdy1c0yldc7sp8w0qeJR uNGbt9WAumu/DiW3yoDB0ZH1Y1UllLn5jWDMVF71o2c+O98cvlJgr7eCQtYaq96IiLeU +F5ljg70FHkSFQWj9peP1nMKDY9NfOfc8nczZvtIVt5nPQ//eLrLIcjLefdNS7umFyf1 oWTfOpG95qCY1UMFZ12DRHC9BuN9N9V2JD6yg5gP9RmdkBJPkp29DfBVOxokdIKjisk7 S5Bytwda/mtOy+U7ixNXe4lyQe1jHtoGuzPR6rAy2gq5ZbZqkl/fiGhuoBZId1oiVwSN ULQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=BX6+blT+Bu0Fpj+7Z/i24QQbzhBFeVIrlGX2fUv0+18=; b=Tqkbbd5PY+5dIu79LmJi4pQ3CT1fWdhC0JQH7sVo+loySSVcOSkZEFIE+U9pKf+6iR wUkrIOOZL5nQ2g0r1wRVCrrbUKShCPIhOCPINytEuzxu39NWINzujp0vFmcpdkLSknlM QA7+OobVOnLRvPTDBleHShoR+tZCiaH3YaDftFLpMX5lnl8dCO0nIqSvsGA7FoMFJ26n 8k344qxBnhGRkT/4Mi7F1rCnCjNAD71pew3ljNJ+juRZf/3r4Veo1lk+F1elA4MgF8PG P1NKpXvm+bISiUjYdGUbVh52VPCQIsc4n1tVbN7Z6sLtIxqpHX+Fty7/bwRUc3ITz9xN w4rg== X-Gm-Message-State: AHYfb5jJ6fLpheNnzUJOtQHIBm4mINQ8YWp/agDA1ReQ1Er1TOKP25eL DDO/72q3n7D1GW5wyv2vmUaC+wrmxA== X-Received: by 10.36.196.68 with SMTP id v65mr8998690itf.117.1502350513102; Thu, 10 Aug 2017 00:35:13 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.38.70 with HTTP; Thu, 10 Aug 2017 00:35:12 -0700 (PDT) In-Reply-To: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <775EE8C8-306E-4617-8333-5A5F3B69B59B@gmail.com> From: Matthew Kerwin Date: Thu, 10 Aug 2017 17:35:12 +1000 X-Google-Sender-Auth: hCJgrke-pcjuI4msqTjAZ5Rml38 Message-ID: Subject: Re: Request to register "identifier" relation type To: Ed Summers Cc: Peter Williams , link-relations , Simeon Warner , Michael Nelson , Geoffrey Bilder , "John A. Kunze" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 10 Aug 2017 07:35:16 -0000 On 10 August 2017 at 09:49, Ed Summers 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 whic= h it is used. All link target URIs are identifiers. > +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 --=20 Matthew Kerwin http://matthew.kerwin.net.au/