Talk:Uniform resource name
I. Experimental: These are not explicitly registered with IANA. They take the form X-<NID> No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. As there is no registration, no registration maintenance procedures are needed.
But urn:sha1:<base32 string> is fairly widely used despite being unregistered.
Difference from DOIs
This article should explain why URN's are useful. I mean, what good is it to know that the URN of a book is urn:isbn:0451450523? How is the knowledge of this book's URN beneficial to anyone? —Ksn 15:07, 28 July 2006 (UTC)
- It's uniform, man!
- No, seriously. The benefit is that URNs are uniform and thus easier to process (by computers). For things like ISBNs and such that are already codified this doesn't make an awful lot of sense, but supposedly the common scheme would allow easier resolution and mapping.
- Think of how you use search engines (i.e. Google): if you want to find info on, say, the Gopher protocol, you might want to look for "gopher". But that is terribly ambigious, so you might want to add "protocol". But that'd still not filter out "protocols" called "Gopher" or concerned with pests. If there was a URN like, say, urn:ietf:protocol:gopher (not an actual URN) you could search for every reference to that URN and avoid the ambiguity.
- Obviously that's not how it would work in real life, because most people don't know about URNs and even fewer are willing to take the time to look up something's URN before mentioning it or providing properly encoded metadata, but in the pipe-dream that is the Semantic Web, this makes perfect sense.
- Until the Semantic Web becomes a reality (that is, until Skynet takes over and actually decides to properly tag and categorise metadata rather than simply eradicate mankind), this will probably be mostly useless for you and me. But it probably already helps in some niches (i.e. whereever people are already generating and maintaining proper metadata for their resources).
- So, think Library of Congress, not Google. -- 220.127.116.11 (talk) 11:00, 3 November 2009 (UTC)
I do not understand that: "An editor has expressed a concern that the topic of this article may be unencyclopedic." I looked up URN to learn what a URN is, in the clear expectation that this would be in Wikipedia (or any other encyclopedia). Fortunately, it is here. Could you be more precise or specific about the concern? For example, do you think that the article falls into one of the "Wikipedia is not ..." items? I went through the list and did not see any. Tell me, so I can defend the article. Yours truly. —Preceding unsigned comment added by Olevv (talk • contribs) 2006-09-07T10:16:41
I was quite positively surprised to find an explanation in almost direct speech. I could immediately understand it. There was an objection that the article was not written in encyclopedic style. In the classical meaning of the term I have to admit that it is quite deliberately written. However my expectations are to understand and, if ever, to learn about the topic I'm looking up. And they are fully met. In this sense for me the article is more than ok. For heaven's sake, please leave it like this ,-) Thanks for the good article and basic introduction! — Keyanoo 08:12, 4 May 2007 (UTC)
- Yes, good objection! —Preceding unsigned comment added by 18.104.22.168 (talk) 12:00, 5 February 2008 (UTC)
unofficial / invalid
This is about section entitled Non-standard usage
Previous version said
- The following are examples for non-standard URNs, i.e. identifiers that look like URNs but don't use a valid namespaces and thus are invalid URNs.
User:Gerbrant's version said:
- The following are examples for non-standard URNs, i.e. identifiers that don't use officially registered namespaces and thus are unofficial URNs. <!--Note: original wording was "invalid" rather than "unofficial". I changed it because "invalid" carries the connotation "will not work". However, most software will either happily accept any scheme, or only accept a select few, regardless of registration.--!>
My version says;
- The following are examples for non-standard URNs, i.e. identifiers that don't use officially registered namespaces and thus are invalid URNs in terms of RFC 2141 (URN Syntax) and RFC 3406 (Uniform Resource Names (URN) Namespace Definition Mechanisms).'
I agree they are not invalid in the sense they work with lenient or specifically designed software. However, the current URN syntax specification does not allow some characters (such as '.'); and does not conform Namespace Definition Mechanisms. I tried to state this fact, while avoiding imply they simply "won't work".
In addition, I found the text "... don't use officially registered namespaces and thus are unofficial ..." a bit redundant.
Rjgodoy 11:28, 4 July 2007 (UTC)
- I've removed all of these examples, because they are implied by the definition and thus redundant. The list is potentially infinite, there's no point including it. — Hex (❝?!❞) 13:04, 7 December 2012 (UTC)
There are no authority for this?? Where the oficial resolver servers?? IANA not have a resolver and stopted to select by relevance and registry... The and the "IETF URN Working Group" not exist yet!
Some clues (no authority status):
- http://www.iana.org/assignments/urn-namespaces (empty of relevant news!)
- http://www.w3.org/TR/uri-clarification/ (2001 updated... where DOI, PURL, etc. iniciatives??)
- http://www.ietf.org/html.charters/urn-charter.html —Preceding unsigned comment added by 22.214.171.124 (talk) 11:58, 5 February 2008 (UTC)
- The IANA registry of URN namespaces  IS the official one, per RFC 3406.
- According to this, URIs are not standard or non-standard but registered or unregistered. Indeed, "the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards-track (...)" (Section 4.3 of RFC 3406).
- PURLs are not URN (either registered or unregistered), understanding URN as an identifier within the urn: URI namespace. Instead, they are http: URLs, and are resolved by means of HTTP redirection.
- The IANA registry of URN namespaces  IS the official one, per RFC 3406.
"There is nothing incompatible between PURLs and (...) URN. PURLs satisfy many of the requirements of URNs using currently deployed technologies and can be transitioned smoothly into a URN architecture once it is deployed .
- SICI and DOI are not URNs by themselves (particularly doi: is neither a registered URN nor a registered URI). However, both may be represented as URIs (not URNs) under the info: scheme. info: is defined in RFC 4522. Namespaces within the info: schemes are registered by the National Information Standards Organization (NISO) .
Examples and implementations
The article, though it does have outside links that work to back up written information, lacks citations and contains no Reference section. With some dispute going on about this article's content in addition to this problem, I have added a cleanup template message to the article.
transf to History section
The lead section is too detailed, suggestion to move from lead to a "History" section. From "Defined in 1997 in RFC 2141 (...)" to "URNs were originally (...)". --Krauss (talk) 08:48, 26 March 2015 (UTC)