Ask HN: Why are URNs not more popular?

I feel URLs are easier to access, think of something like google.com would be easier. People forget things over time.

Maybe I'm missing something, I just don't feel like globally recognized URNs have much value. I am using them in my software which supports external plugins, and this seems like a great use: I and plugin authors get to define the namespaces, which are useful in the context of my application and not beyond. Similarly, AWS makes extensive use of URNs, which are useful in the context of AWS but not beyond. This seems like a good system.

What utility does URN have in your application? Why do you need your URNs to be globally recognizable?

> However, the list of URN namespaces is very lacking

Because ontology is fucking garbage.

All ontology fails, it always has.

Why are we still discussing this?

> Why are URNs not more popular?

Wiki - "URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable"

Why do I care about this for data? Why would I constrain myself? It's bureaucratic nonsense for people to have meetings on. I'm not a library putting angels on a pinhead, real world data is messy.

Asking because I don't know, and I can't believe nobody anticipated it. (Blames "Semantic Web").

Is there not a version of URN that allows you to use a registered domain name or IP address as a scope or scheme?

Something in the spirit of:

   urn://mycompany.com/Whatever/I/Want

   urn:mycompany.com://192.168.0.1/Whatever/I/Want

Semantically, a "uniform" private resource identifier that's "uniformly" parsable while avoiding the unpleasantness of IANA registrations.

I've scraped with IANA protocol registrations before. It wasn't fun at all. I can't imagine doing it for schema or urn schema registration.

There is only a marginal benefit in using "urn:foo:..." over "foo:...", namely making it clear that it is only intended to represent a name and not a locator. That benefit is marginal because without knowing the spec for foo, you can't really do much with the knowledge that it is a URN. Without knowing the spec, you can't even compare URN values to check if they represent the same name (e.g. ISBN URNs may or may not contain hyphens, and there are equivalent ISBN-10 and ISBN-13 numbers).

Conversely, there are non-URN URI schemes that still represent only names (like doi), and there are URL schemes that, despite the "L", are also used for non-locator names (the http scheme in particular, e.g. in RDF and for XML namespaces). So it's all a wash.

In either case (URN or non-URN), you would have to register the URN namespace or the URI scheme, if you want to use it publicly. Often http is used instead, where the domain name serves the role of the namespace, because usually a suitable domain name is already registered. Of course, this latter practice has the drawback that one has to infer from context that it is a name and not an HTTP web resource.

Unfortunately, dots are not allowed in NIDs. Otherwise it would have been possible to introduce the free use of "urn::..." (for non-TLDs that otherwise don't conflict with the NID naming rules).