Re: Request to register "identifier" relation type

Peter Williams <pezra@barelyenough.org> Wed, 09 August 2017 18:13 UTC

Return-Path: <pezra@barelyenough.org>
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 <link-relations@ietfa.amsl.com>; 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 <link-relations@ietfa.amsl.com>; 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 <link-relations@ietf.org>; Wed, 9 Aug 2017 11:13:33 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id g131so68743630oic.3 for <link-relations@ietf.org>; 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: <CAOywMHeHcwP5h4vzbTY+q00AEYn85F0E+LKqnx0aWpK1kcA1AA@mail.gmail.com> <CAK5Vdzz8=+6pfEDA2gGvtYU8kNx4pPKmsme71szP-JrvhpoTdw@mail.gmail.com> <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <DEE2ABBF-1146-4E17-875F-3F5EFFB540FB@pobox.com> <D933EB1A-CB2F-4BD3-9747-C03A0D78CACC@gmail.com> <CAOywMHf5JqQoFXLOi5cuD+HWTxMKu-JcjL_Zp0NWM7wqmBqSbQ@mail.gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> <CAK5VdzzpV6kdn-DFt-mBWeGZyL27xDPEZ+=dAd7qnO+O+-MqEA@mail.gmail.com> <6a1e9764-9efb-3ae3-e0d5-318713bd6010@dret.net>
From: Peter Williams <pezra@barelyenough.org>
Date: Wed, 09 Aug 2017 12:13:32 -0600
Message-ID: <CAK5Vdzw0ZE3iSp5FzQ9PZs0EYbdH2gN1WgFsvWOPq87TdZekdQ@mail.gmail.com>
Subject: Re: Request to register "identifier" relation type
To: Erik Wilde <erik.wilde@dret.net>
Cc: Ed Summers <ehs@pobox.com>, link-relations <link-relations@ietf.org>, Simeon Warner <simeon.warner@cornell.edu>, Michael Nelson <mln@cs.odu.edu>, Geoffrey Bilder <gbilder@crossref.org>, "John A. Kunze" <jak@ucop.edu>
Content-Type: multipart/alternative; boundary="001a113d83c4ad830d05565609df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/link-relations/UBBltWfRHKA369Vrwmv79CqpOX4>
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: Wed, 09 Aug 2017 18:13:36 -0000

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