Re: Request to register "identifier" relation type

Erik Wilde <> Wed, 09 August 2017 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7797B132455 for <>; Wed, 9 Aug 2017 10:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.791
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: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fXsEoZ2_PFEj for <>; Wed, 9 Aug 2017 10:39:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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;; 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 ([]:53437 helo=[]) by 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: <> <> <> <> <> <> <> <>
From: Erik Wilde <>
Message-ID: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
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


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.



erik wilde | |
            |    |
            |    |