Re: URN UUID question

Joel Kalvesmaki <> Thu, 20 March 2014 00:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 69BC71A0844 for <>; Wed, 19 Mar 2014 17:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gmmmgozmAW_w for <>; Wed, 19 Mar 2014 17:15:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::233]) by (Postfix) with ESMTP id 21E031A0836 for <>; Wed, 19 Mar 2014 17:15:12 -0700 (PDT)
Received: by with SMTP id ij19so101317vcb.24 for <>; Wed, 19 Mar 2014 17:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XXHj9Kes2ob+uAxMKxhDgwgTrCENjFL5205IgIORvq8=; b=u+m4dnbAR7Srp502v77pgOJPjx7qwuBwOzcr1PQPzDYPNi9XphJs9L5kDVepsEQQGb InfvIUvBdZXnzruUQ2w7fxofTx66n1kadzfQ4EguSaT6rAlR/ijqQfFzjUfVowTK5zgW f+XsVJv3Zie4mtoK/2zxTR3WVMRSEoROmrVxlnWjlVpMEDiTsCohYlS+CRsx7cSCDaGN hDIi9n/8TR8DHzMDr6B6HQceHFQPE+c4LXcUD2ilvh1FJQQeCLXpOSLzX07ydMlqMeki ULcxqn07GYF8T49d3INkfxPiRYbXCtzNia7IxkDwXEHzng98oUONESMcNMc1MtUqUEAq fL1g==
MIME-Version: 1.0
X-Received: by with SMTP id pj5mr2067369veb.38.1395274503162; Wed, 19 Mar 2014 17:15:03 -0700 (PDT)
Received: by with HTTP; Wed, 19 Mar 2014 17:15:02 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 19 Mar 2014 20:15:02 -0400
Message-ID: <>
Subject: Re: URN UUID question
From: Joel Kalvesmaki <>
To: "Dale R. Worley" <>
Content-Type: multipart/alternative; boundary=089e01183daa2010bb04f4fea939
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Mar 2014 00:15:14 -0000

Dear Dale,

Thanks for your response. Your "why" could be interpreted in multiple ways,
so forgive me if I've picked the wrong one.

I need unique, persistent names. The name needs to be a single IRI/URI to
allow any version of any document to be named easily in any RDF
declarations any third party might want to make.

As I understand it, all IRI/URIs are either URLs or URNs. My naming scheme
cannot rely upon URLs (I know I'm at odds with the recommendations of
Semantic Web advocates) because the names of these documents, which may be
used or referred to centuries from now, need to outlive any domain owners.
Plus I anticipate some users of this XML data model who will not be domain
name registrants (or have access to a domain name, or be interested in that
extra step). So that leaves me with URNs, right?

After reading the specs on the tag URN, I'm very impressed, and think that
it will suit the XML model nicely. Tag URNs provide two extra bonuses I
hadn't anticipated: human readability and decentralized unique agent

I do wish IRI forms of tag URNs had gotten off the ground, but maybe that
will come some day?

Best wishes,


On Wed, Mar 19, 2014 at 5:39 PM, Dale R. Worley <> wrote:

> > From: Joel Kalvesmaki <>
> > Are there any other issues I should consider before adopting a naming
> > scheme like this?
> There are many issues to be considered.  As you state it, the problem
> is very unconstrained.  At the very least, why you want it to be a URN
> is not explained.
> > [1:text/plain Hide]
> >
> > I am developing an XML data model that requires users to name versions
> of a
> > document. Each version's name should be unique, but patterned to allow
> > anyone (human or computer) to associate it with the names of other
> versions
> > of that document and to place it in chronological sequence. The name of
> > each version must be a single string, specifically a IRI/URI (to
> > facilitate, among other things, straightforward declarations in RDF). It
> > should not be split into two elements. Naming must be as decentralized as
> > possible.
> >
> > My favored scheme for naming these entities would concatenate a UUID (any
> > style), a middle delimiter, and an ISO date/dateTime, e.g.,
> >
> > urn:uuid:f60330fd-1900-44ac-a825-de70074e142e::2014-02-07Z
> > urn:uuid:f60330fd-1900-44ac-a825-de70074e142e::2014-02-28T00:20:58.3Z
> >
> > Would it be misleading to begin such a string with "urn:uuid:" and if so,
> > what are the alternative best practices?
> Given that the resulting string would not be a legitimate URN, the
> format is somewhat deceiving.  I suggest that the delimiter between
> the parts be a character that is not valid in URIs, thus clearly
> separating the URN from the version.
> Another alternative is to assign documents object IDs, and using the
> last number in the object ID to indicate the sequence.  Thus,
> urn:oid:
> designates a document (through its history), wile the various versions
> of it are:
> urn:oid:
> urn:oid:
> urn:oid:
> urn:oid:
> urn:oid:
> Dale

Joel Kalvesmaki