I think this discussion is missing the original requirements
that led to “urn:” https://tools.ietf.org/html/rfc1737
“Functional Requirements for Uniform Resource Names”.
That conversation predates the mistake of introducing the false
distinction between URLs and URNs.
The distinction between URLs and URNs is not merely that
one is a “location” and the other is a “name” in some
abstract sense.
I think the practical distinction between “urn:<nsid>:<blah>”
and “<nsid>:<blah>” is that the “urn:” form provides some
useful information in the cases where <nsid> identifies
an externally, non-algorithmic organization that maintains
the authority of deciding when two expressions are “the same”
(see paragraph 2 of section 5 of RFC 1737).
Whether two streams of data, concepts, protocol parameters,
get the same ISSN, ISBN, UPC code, RFC number, MIME type,
etc. and thus are considered “the same” depend on an
identified “naming authority”; the nsid identifies the
naming authority.
With this perspective, urn:uuid: was a mistake, since
there is no uuid naming authority to resolve the question.
So while I agree that in many cases, the initial four
characters “urn:” are unnecessary, at least in some
situations, the prefix is useful in pointing out that no
resolution service that ultimately doesn’t consult
the identified naming authority for dispute resolution
can be authoritative.
Larry
—
http://larry.masinter.net