Re: Request to register "identifier" relation type

Bjartur Thorlacius <svartman95@gmail.com> Mon, 07 August 2017 16:53 UTC

Return-Path: <svartman95@gmail.com>
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 <link-relations@ietfa.amsl.com>; 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 <link-relations@ietfa.amsl.com>; 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 <link-relations@ietf.org>; Mon, 7 Aug 2017 09:53:41 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id p3so6057531qtg.2 for <link-relations@ietf.org>; 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: <alpine.DEB.2.10.1708051248210.31417@sirius>
References: <CAOywMHeHcwP5h4vzbTY+q00AEYn85F0E+LKqnx0aWpK1kcA1AA@mail.gmail.com> <CAK5Vdzz8=+6pfEDA2gGvtYU8kNx4pPKmsme71szP-JrvhpoTdw@mail.gmail.com> <alpine.DEB.2.10.1708051248210.31417@sirius>
From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Mon, 7 Aug 2017 16:53:39 +0000
Message-ID: <CAOKKrgNWFA7bbRCaGsfdHxNgmxXgh6KhySytUdeoxxFCkHg+Cw@mail.gmail.com>
Subject: Re: Request to register "identifier" relation type
To: Michael Nelson <mln@cs.odu.edu>
Cc: Simeon Warner <simeon.warner@cornell.edu>, "John A. Kunze" <jak@ucop.edu>, Peter Williams <pezra@barelyenough.org>, link-relations <link-relations@ietf.org>, Geoffrey Bilder <gbilder@crossref.org>
Content-Type: multipart/alternative; boundary="001a113f42c65780a505562cb014"
Archived-At: <https://mailarchive.ietf.org/arch/msg/link-relations/iikLGmOvQbYvdgbXA5RHVX1KdhQ>
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/link-relations/>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 16:53:43 -0000

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

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
<link rel=up hef="/to/the/paper" >, should they not?

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

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

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

Regards,
Bjartur Thorlacius