Re: ORCID - unique identifiers for contributors

John C Klensin <john-ietf@jck.com> Tue, 17 September 2013 16:17 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76011E84A0 for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 09:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.549
X-Spam-Level:
X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akJelTIhfyTf for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 09:17:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A9C7411E84AC for <ietf@ietf.org>; Tue, 17 Sep 2013 09:16:41 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VLxwz-000ApU-20; Tue, 17 Sep 2013 12:16:29 -0400
Date: Tue, 17 Sep 2013 12:16:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Richardson <mcr@sandelman.ca>, ietf@ietf.org
Subject: Re: ORCID - unique identifiers for contributors
Message-ID: <A3B67B91B80804CC611555AD@JcK-HP8200.jck.com>
In-Reply-To: <6014.1379431237@sandelman.ca>
References: <20130916203141.86927.qmail@joyce.lan> <C65F64A8-2D7B-47AF-BAAC-DE4DE57586B7@checkpoint.com> <523791FB.2070807@gmail.com> <CABiXOEm+D4oE7NePHmR5gviOJURqkSAhDhGb=s1o1ayJZAc7kQ@mail.gmail.com> <523845F5.9050902@gmail.com> <CABiXOEmhe5p8jMW2W=9qnhUZ_ORhwKCgA1_-dxK_NtGNy7g1zA@mail.gmail.com> <5238517F.8060705@joelhalpern.com> <6014.1379431237@sandelman.ca>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 16:17:10 -0000

--On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson
<mcr@sandelman.ca> wrote:

> 
> I did not know about ORCID before this thread.
> I think it is brilliant, and what I've read about the mandate
> of orcid.org, and how it is managed, I am enthusiastic.
> 
> I agree with what Joel wrote:
> 
> Asking for ORCID support in the tool set and asking for IETF
> endorsement are two very different things.
> 
> Having tool support for it is a necessary first step to
> permitting IETF contributors to gain experience with it.   We
> need that experience before we can talk about consensus.
> 
> So, permit ORCID, but not enforce.

The more I think about it, the more I think that Andy or someone
else who understands ORCIDs and the relevant organizations,
etc., should be working on a URN embedding of the things.  Since
we already have provisions for URIs in contact information, an
ORCID namespace would permit the above without additional
tooling or special RFC Editor decision making.  It would also
avoid entanglement with and controversies about the rather long
RFC Editor [re]tooling queue.

Doing the write-up would require a bit of effort but, in
principle,
    URN:ORICD:....
is pretty close to trivially obvious.

Comments about dogfood-eating and not inventing new mechanisms
when we have existing ones might be inserted by reference here.

> An interesting second (or third) conversation might be about
> how I could insert ORCIDs into the meta-data for already
> published documents. 

With a URN embedding that question would turn into the much more
general one about how URIs in contact metadata could be
retroactively inserted and updated. In some ways, that is
actually an easier question.

best,
   john