Ask HN: Why are URNs not more popular? | Hacker News Reader

Ask HN: Why are URNs not more popular?

124 pointsdagss62 comments

I'm working on i18n of an API for a customer now. It's a domain where one needs to refer to phone numbers, bank accounts, National Identity Numbers, business / legal entity organization numbers etc; in short, IDs in misc. national and international registries.

URN should be perfect for this; I would expect to do the i18n by replacing a Norwegian account number "12345678902" with "urn:bban:NO:12345678902", or a Danish company number "987322431" with "urn:business:DK:CRV:987322431".

However, the list of URN namespaces is very lacking. I'd expect to at least see "urn:msisdn:<phone number>"; or "urn:nin:DK:..." for Danish national identity numbers. But it's not there.

What I see looking around is a lot of home made solutions that make inferences about ID spaces based on "country" that usually holds but not always; or solutions coming from the XML world that seem very complicated to figure out (like ISO 6523 which declares '0037' for the Finnish company registry, and the syntax around it is XML or home-grown). URN would have been such a simple and nice solution. Why has it not catched on?

View on HN

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:<domain name>:..." (for non-TLDs that otherwise don't conflict with the NID naming rules).

I think this probably covers it the best.

In terms of the semantic web, trying to semantically interpret the URN (as OP suggests) also seem like a conceptual mismatch, as there are other mechanisms that allow for the same thing in a more "robust" way.

E.g. in RDF one could pack all the semantics into the datatype of a literal like `Norwegian account number "12345678902"` -> "12345678902"^^<http://example.com/accountNumber/NO> (where the IRI `http://example.com/accountNumber/NO` then serves as an identifier for a concept that can be enriched with more information).

> 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.

At least in RDF-world (which admittedly isn't the only domain for URNs), this by now doesn't have to be inferred, but has over time formed into an undeniable reality.

In RDF from the beginning IRIs have been relegated to identifiers ("It only treats IRIs as globally unique identifiers" - RDF specification[0]) though it has been mixed with a lot of weak language/suggestions to also use IRIs as locators. And a lot of people/institutions did attempt to make follow that suggestion. However, since it's a lot harder to host a system in continuity that delivers content based on an URL (as evidenced by all the link-rot in the semantic web space) than it is to just coin IRIs, using IRIs as locators so rarely worked in practice that nowadays nobody even tries to do that anymore.

-----

DISCLOSURE: Self-promotion

Born out of the frustration of this issue (and some other issues, such as uncontrolled mutability when using IRIs as locators for semantics), we have built a package manager for ontologies[1] to serve as a foundation for stable semantic data systems.

In it we replace the fickle "maybe an IRI can be dereferenced to semantics" system of RDF/OWL with a package manager that allows for stable versioning and resolution of all the ontological dependencies of your system, so you end up with a stable set of documents that you can then interpret to get to the underlying semantics of an IRI.

Since there is a default registry[3] that even small projects can publish to, this also greatly reduces the barrier to entry for small projects to participate in building and publishing ontological definitions, as there isn't a burden of setting up and maintaining the hosting of the definitions.

We've been using that system for close to a year now as the underpinning for our platform[2], and it's been great so far. It allows us to offer different semantics to different customers (based on the packages they chose to import), and makes managing even a big set of often-changing semantic dependencies tractable.

[0]: https://www.w3.org/TR/rdf11-concepts/#referents

[1]: https://plow.pm

[2]: https://field33.com

[3]: https://registry.field33.com

Content-addressed RDF (possibly with the help of hashlinks and/or ERIS) feels like another good way to solve data stability/mutability, without introducing a package manager in the mix.

Yes, for that side of the problem content-addressing is a good solution. I've also explored content-addressed RDF and OWL in a past project[0], based on IPFS and multiformats. While it gives you good certainty about stability, migrating semi-popular concepts across the ecosystem is a big pain, as you have to regenerate all dependent data (if you go the hardcore route).

I think package managers are in general a pretty good abstraction that can foster structured collaboration across independent (but communicating) parties. It can also enable standardization-via-usage rather than standardization-via-authority, which I think has always been all too common in the semantic data space.

Plow is at its core also very much based on content-addressing, where after the dependency resolution phase, we mostly deal with the hashes of the package contents rather than their name-based identifiers. That also has the nice side-effects that you could easily host a private artifact storage that retrieves the packages for on-premise usage. The public package index is also hosted in a git repository, so all the building blocks would be there that you can record the whole state of the system in a content-addressable manner if you wanted to.

[0]: https://github.com/rlay-project

I’m not sure what you mean by “regenerated”. Sure, URNs will need to be updated to content-addressed ones, probably gradually, but you’d need to do the same to switch to a package manager.

We have such interrogations for our data strategy, at work. Can you drop me a message for further discussion? (@Datao on Twitter, or datao@datao.net)

There are URN namespaces that refer to other namespaces (notably OIDs) and many things can indeed be specified. For example:

  * A UK company: `urn:oid:1.2.826.0.1.<company number>`
  * IBAN account: `urn:oid:1.0.13616:<account>` (note that there's also a URI scheme for this)
  * A publication: `urn:isbn:<ISBN number>`

Chances are that a URN exists, or, if not, you can get a PEN from IANA and then use the `urn:oid` scheme.

However, the reason URNs don't have much traction is that, because they require interpretation to be meaningful, using 'correct' URNs is of little or no benefit. Besides purism, does your app _really_ benefit from using something like `urn:isbn:123` instead of `isbn:123`, `isbn-123` or simply `123`? In all cases you need additional logic to interpret the data. An advantage may be when interacting with other systems, but most likely you'll need to transform your data anyhow.

Adding to the issue above, another issue is that there might be several 'correct' URNs for the same external entity. For example, `urn:iso:std:iso:3166:USA`, `urn:oid:2.16.840` and `urn:oid:1.2.840` all refer to the same country (as well as `urn:uuid:7f5f8e3e-6f89-4903-a9c1-0fdb030ddb13`, that I just made up).

Good points. I think what I will likely do is {"scheme": "business:DK:CRV", "id": "123456789"} to refer to a Danish business in the CRV registry, and {"scheme": "business:NO:ORG", "id": ..} for a corresponding Norwegian business, and {"scheme": "nin:DE", "id": "..."} for a German citizen. (This is to refer to "a legal entity that can own something and that we have an agreement with")

I totally agree things require special handling and interpretation on both sides anyway.

I do not really see any value in forcing my way into URNs for the sake of it. Yes, I could use OIDs, but the result is not self-documenting in the way my examples above are so it would just make life harder for everyone I feel. (Every Danish person knows what a CRV is)

The main thing that bugs me is just having to invent those strings to refer to registries myself.

And many developers will go with "country" instead of "scheme" which is not always correct.

> I think what I will likely do is {"scheme": "business:DK:CRV", "id": "123456789"} to refer to a Danish business in the CRV registry, and {"scheme": "business:NO:ORG", "id": ..} for a corresponding Norwegian business, and {"scheme": "nin:DE", "id": "..."} for a German citizen. (This is to refer to "a legal entity that can own something and that we have an agreement with")

Yeah, I think in any case you need to end up with your own solution (personal ID numbers are especially messy because a single person might have none or many). However, may I suggest a less verbose format? Parsing JSON looks overkill for the purposes of IDs (I'm assuming this is something you'd want to index)

For example, you could go with `urn:<some prefix for your org>:<your app ID>:id:<entity type>:<ISO CC>:<ID type>:<ID number>`

> and {"scheme": "nin:DE", "id": "..."} for a German citizen. (This is to refer to "a legal entity that can own something and that we have an agreement with")

Off-topic, but there isn't really a general ID number for German citizens. There are some numbers for social security or tax purposes, but most people wouldn't give them to other entities and people wouldn't think of them when asked about a ID number in other context. (There is also a number of the ID card, but that only identifies the card and therefore changes whenever you get a new one) So this example would at least not be self-documenting.

Apologies for a bad example. Only strings for existing public registries should be used, so in this case there would be several or no cases for Germany; perhaps none of them prefixed with "nin:".

Minor nitpick: It's CVR, not CRV.

OP here. Thanks for a lot of useful insights and references.

An overall comment about a lot of the replies: A lot seem to say "you do not want to use URN because X" in much the same way I think that one might criticise JSON when JSON was launched:

What is the point of using JSON? Don't you realize that both systems still need to agree on a custom protocol?

Yet JSON is wildly successful.

I could have worded my initial request better (and the comments make me realize that, and brings my thinking forward, so thanks for that!)

What I am really after is: I want to have is a standard way to refer to "an ID taken from an existing public registry", in such a way that readers realize

A) they are looking at an ID in a registry

B) they see which registry

C) in a way that is mostly self-documentary (unlike OID!)

That is only solving a single one from a ton of issues; much like two systems cannot communicate just because they both speak JSON.

The biggest advantage of JSON (I believe) is that it was already supported by all web browsers, so it started out as a lightweight communication method with browsers, where in the early days you didn't really want to add an alternative heavy-weight parser.

From a quick google, urn isn't built into browsers. There is a urn-parser package on npm, but it hasn't been updated in 5 years, and has exactly 0 tests. That package tells me to use the URI package, which has an open issue saying it's broken in firefox since 2011!

I have a general policy of not writing parsers wherever possible, as they are (a) really hard to get 100% right, and (b) if no-one can be bothered to keep at least one parser up to date, then it doesn't feel like a well supported language!

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentation will include a list of possible values, and tooling might even generate the nice enum for you.

Is it a standard? No. But does it need to be to be useful and obvious to everyone?

Agreed and in fact this is what is in our code even before I made the post. My main problem is that we have to invent this idSource string for all registries we support.

What does “support” entail? Whether “we print its friendly name on the invoice before its value” or “we validate it, fetch the business data from the national registries and auto-fill the rest of the form”, you still need some special handling and registration. In that case, you don’t save much by using an existing scheme, and you there is a bigger risk of someone providing a schema you don’t support.

The usefulness of JSON is that while both systems still need to agree on a custom protocol, it gives you an implementation for half of that custom protocol - ubiquitous libraries to parse and generate the format, so the application needs only to handle the semantics of a particular field. If they made a custom format from scratch, both apps would need to reinvent the wheel and write a bunch of boilerplate code for serialization, deserialization and handling format errors.

This does not apply for URNs - the "custom protocol" replacing URNs is simply transferring a string, so choosing URNs doesn't save most apps anything.

The other aspect is that I (and looking at the other comments, probably most people) don't really identify with your use case i.e. "a standard way to refer to "an ID taken from an existing public registry"". The common use case for handling IDs from an existing registry is in systems where the requirements specify a particular existing registry, not an arbitrary one; and any URN which specifies some other registry should be rejected as invalid, so including that in the data is just useless overhead.

In general, I consider that is useful to have a reference to a specific registry if and only if I have some special integration with that registry. I.e. it's useful to denote that this is a registration number from the Danish company registry iff I do something specific with the Danish company registry (e.g. fetching whether that registration is valid and the company has not been liquidated). And in that case, I don't really need a universal format to represent arbitrary numbers, I need an 'enum' showing that this is one of the acceptable (closed!) list of number types the system can understand, or possibly even split them in separate fields in JSON/XML/whatever.

On the other hand, if try to I imagine some use cases where really there is a need for processing IDs from an open set of many registries (which exist but IMHO are quite rare) then in those cases the interpretation of these IDs is generally not done by the computer system, they are transferred and stored as-is, and perhaps later printed shown to a human. In this case, having a machine-readable URN is not an advantage, as the computer system doesn't care which registry is being used (so it doesn't need to tell that its looking at an ID in a registry, much less which registry) and potential human consumers of the data (end users like customers, accountants, etc - from whom a URN is definitely not 'self-documentary') would not be able to write or decode URNs, they would not recognize that a URN represents an ID in a registry or tell which registry is used, they would need a different, human-readable format for that.

URN are the "missing link" in the semantic web. If you look at examples where somebody writes an RDF file they typically use identifiers like

   <http://dbpedia.org/resource/Tin>

which are fine for cases where you want to publish the data on the web but not for the much more common case of "our own private data".

It is straightforward in principle to use URNs, but it is not easy to find examples or discussion of best practices with URNs. For one thing you can always write

   <urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66>

so you can generate as many unique ids as you need.

You can always use something like <#abc> or :abc for terms of the document being described or just an extra graph that is just private and not shared like <http://comp.com/abc>. Anyhow I don't think this is what is missing to make the semantic web work.

I remember the semantic web people telling me when asking about URN they said "we don't use those anymore", so that is that, and the story of the semantic web.

> Why are URNs not more popular?

For the same reason that lots of general-purpose classification schemes are not popular: they are brittle and unstable. They smear information out into awkward and hard-to-reuse hierarchies. I refer you to https://www.gwern.net/docs/technology/2005-04-shirky-ontolog...

It does have that "Borges Encyclopedia" character where a leaf close to the root urn:uuid: lets the community assign a unique id to every Iron atom in an Iron filing.

A person like Shirky would appreciate systems that let you reify subjects by coining unique identifiers and to not have to buy into any hierarchy at all.

If you look at the registry of URN prefixes

https://www.iana.org/assignments/uri-schemes/uri-schemes.xht...

note that most of them come across as application specific such as "jabber", "mailto", "secondlife" or "ms-access" or "ethereum" or are related to computers and networking such as "view-source", "udp", "ldap", etc. You have to dig a few levels deep to find the great namespaces for ISO standards,

https://en.wikipedia.org/wiki/Object_identifier

and all that. Would be nice to have a road map.

How have I not heard of "Borges Encyclopedia" before? Thank you for pointing me this.

And I 100% agree with the idea of the reification of subjects without buying into a formal hierarchy. As long as the system gets the right ideas into the heads of the right people, it's workable.

The specific reference is to the essay "The Analytical Language of John Wilkins", in which Borges likens an taxonomy proposed by Wilkins to a (almost certainly fictitious) Chinese encyclopedia which groups animals into fourteen categories:

> (a) those that belong to the Emperor, (b) embalmed ones, (c) those that are trained, (d) suckling pigs, (e) mermaids, (f) fabulous ones, (g) stray dogs, (h) those that are included in the present classification, (i) those that tremble as if they are mad, (j) innumerable ones, (k) those drawn with a very fine camelhair brush, (l) others, (m) those that have just broken a flower vase, (n) those that look like flies from a long way off.

That's a very creative way to say "I don't like your taxonomy". Serious commitment to the put-down.

I don't really want to classify objects.

I want to refer to a registration in a registry. Objects can of course be regidtered many places for many reasons but that is not my concern here.

As long as I can serialize the tuple (registry-somone-made, id-in-that-registry) in a standard and readable way that would be a huge step forward

> I want to refer to a registration in a registry.

But that's not the question you posed in the original post. You asked about URNs, and the URN registry imposes a taxonomy. You're wanting a registry of identifiers classified by country and type. That's a taxonomy.

Why depend on someone else's registry? Make your own, don't worry about taxonomy, and use it.

Thanks for that explanation. My first guess that it was an analogy to the Library of Babel and I was able to convince myself that made sense.

Why restrict to URN when you can use a URI that looks similar to a URL but doesn't have to be accessible. I've used URIs for partner supplied identifiers. They're also used with GraphQL as resource ids.

For widely standardized things URNs make complete sense e.g. ISBN for books.

Well I want to refer to things that are widely standardized within countries: Business registration numbers and bank account numbers.

However when you go international, how should you refer to "business registration number in Norway"?

Perhaps you encode that as "NO" but then you hit Denmark which has not 1 but 5 business registries....

The ONLY thing missing is really a standard way to refer to "the registry in which the ID is registered". Like "urn:isbn:" does.

I would love to have the same e.g. for referring to a business registration number or bank account number.

Making my own URLs to refer to a business registration number that users of the system provides...not sure in what way I would do that or what value it would give.

So URIs are almost the opposite. If you think of the 'path' as the thing being registered, then the hostname part (which aren't resolvable hosts but can follow domain ownership convention) is where it's registered. (Could also use up to a common path prefix.) What we don't have are standards for the 'path' parts for various usages.

No one cares. Not trying to be mean - just stating the fact. It's just another very abstract and fragile solution to a problem that is minute and can be solved ad-hoc via more general and well-known approaches.

Why "urn:msisdn:" when "tel:" already exists?

Possibly because "fax:" also exists, and you want to abstract over that. Maybe more importantly, the format of MSISDNs is more strictly defined than for "tel:" and "fax:".

Why would you want to abstract over tel: vs fax:? If you try to send a fax to a phone number, or call a fax from your phone, the end result is a confused human. Also, what “more strict definition” do you have in mind? Sure, MSISDNs are digits only and always include the country code, but any reasonable software dealing with phone numbers could easily parse out the extra punctuation (and possibly fill in a country code from some other data source).

I guess if you are a phone company and want to track which phone numbers are registered to which client, you don't really care if the number goes to a phone or fax machine?

You probably wouldn’t store any of "tel:", "fax:", and "urn:msisdn:" in a database, because the column name “msisdn” is enough. Those would make sense only for data exchange, primarily links on websites.

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.

Yes, there is, the FeDerated Content (FDC) urn type. https://www.rfc-editor.org/rfc/rfc4198.html

    urn:fdc:domain-i-controlled-at-time.com:202212:resource:fred

Having to register a NID of a URN would stop most developers from using official URNs (costs time&money for possibly no immediate benefit --tragedy of the commons)

Mainly because unless it's a business requirement, developers that work with the internals of software (so not just some CRUD layer and protocol that already has been abstracted) prefer to use things that feel good and look nice. XML for example isn't one of those, it looks like a mess.

Granted, anything can be made to look like a mess, but it seems that JSON is much more enjoyable than XML, and such preferences tend to make a whole lot more impact on what is going to be used than technical/academic prowess. Applies to most things, and factors in to what kind/type of person you get when you talk to developers at a startup, a bank, general commerce, a FAANG or a technology provider. Not everyone seems to enjoy the kinds of people that "exclusively write complex systems software" or "exclusively write business software for the money" just like not everyone likes "exclusively writes software because they enjoy it", and that's fine. But it directly impact adoption of stuff.

URNs, URIs, and UTIs (and UBL) are all fine examples of technology designed to solve a thing, but also fine examples of not getting the adoption you'd thing it gets when it is "technically correct".

There's something almost hinted at in some comments here that I'd like to raise. Often times the localised name for something might differ, despite being effectively the same piece of information.

The a good example of this is the Google Places API[0] - if you just want to fetch the region of a place in a country, what you might actually be looking for could be one of several different things. Google abstracts this to a "region" that can be 4 different things: sublocality, locality, and administrative_area_level_1 (or 2).

So now on top of your URN you might either be missing extra specifity (e.g. this is a locality and not a province) or you need to find a way to add that somewhere.

A colloquial-vs-technical example as well is tel vs msisdn.

[0]: https://developers.google.com/maps/documentation/places/web-...

Yes good point.

In my case the IDs I want to refer to are much more specific (e.g. registration numbers or VAT numbers for businesses), it is just that referring to the registry itself is difficult.

So YES: Also in this space there is similar ambiguity -- what is really a "business", what is a "VAT number", in what way does IDs from one registry directly correspond to a concept in another registry.

But: one still needs to store and use these IDs (somehow). So my proposal is I guess to simply ignore the classification issue, but still use URNs to solve a subset of the problem.

URN already does this, e.g. by allowing use of urn:isbn: or urn:issn:, without one needing to really take a stance about when something is a book, when something is a series, whether something printed can be both. It is enough that the ISBN and ISSN registries exist and you just refer to these registries and that is all you can do.

So in your example with regions, an example could be

urn:geo:german-city-database:munchen

urn:geo:norwegian-town-database:notodden

...where "german-city-database" etc is a placeholder just for any kind of official registry.

As long as such registries exist and are recognized as somehow official and given names, that is one step.

What you discuss is then I think whether the entries in "german-city-database" and "norwegian-town-database" hold objects of the same "type". That seems like another issue.

I think URN could be useful while totally ignoring that issue. There are registries and there are IDs in registries; URN deals only with that; and the problem you raise -- knowing when IDs from a given registry can be used in a given context or not -- must be solved somewhere else.

In the same way all these American websites’ address forms insist on having everyone on Earth input a state. Or it’s equivalent. Even when there is no point to it, it makes no sense, and the country doesn’t have an equivalent.

Some abbreviations and acronyms I didn't know and had to google:

i18n: short for internationalization

URN: Uniform Resource Name, a specific type of URI

Because they are explained to decision takers with all the accompanying semantic web talk those men and women do not understand.

Explain it as an "ID", leave out any mentioning of RDF or semantic web and the deal is made.

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?

I really just want to be able to refer to e.g. a business registration number in a standard way. There is typically one registry per country, but some countries have multiple registries, etc.

If I want to refer to a phone number, that has an international standard (msisdn), so that problem is solved really. But not so for bank accounts or business registration numbers, or NINs.

I think I have ended up with simply saving (scheme, id), where scheme names the registry in which ID is registered (e.g., for a business, or a bank account, etc). But, I have to make up our own names for "scheme" for each supported registry.

Interopability isn't really a requirement. It works fine to self-invent how to refer to an ID in a registry but it also feels odd, like, someone else should have solved this already...

The closest thing to a current ‘official’ way to do this internationally is probably ISO 17442 Legal Entity Identifiers, originating in the financial services industry; part of this is even more directly relevant to you in that this includes a global list of registration authorities [1] which are maintained as an integral part of the LEI system (LEIs generally are very helpful in dealing with international company data, where they are registered, not least because they are very reliable, and explicitly freely-available data!). The nearest alternative (proprietary, but larger dataset ) are DUNS numbers.

[1] https://www.gleif.org/en/about-lei/code-lists/gleif-registra...

> Why are URNs not more popular? […] Why has it not catched on?

1. Usability: a developer must register a URN with IANA which is a huge hurdle compared with minting a URI which only requires control over an email address or domain name. <http://enwp.org/Tag_URI_scheme>

2. Cumulative advantage: everyone knows how to dereference an IRI/URI/URL with the HTTP scheme because the software capable of doing so is deployed million-fold, and dereferencing may also lead to a representation describing the resource which is readable by humans and machines. One can't really do the same with URNs, or at the very least it's much less convenient.

3. Flexibility: if you mint a PURL <http://enwp.org/PURL> with an extremely long lived redirecting service (e.g. <http://w3id.org> or <http://purl.org>), you are able to point the identifier to different resources, this indirection leaves you with options over the time of its existence. URNs have no redirects, they need to be perfect from the start, which is not a reasonable assumption when humans are involved.

At least one of your items, telephone numbers have their own URI scheme [0] (in the original model, URNs were non-locators while URLs were locators; telephone numbers are arguably locators, but in any case URLs being replaced with URIs, which need not be locators, and URNs becoming a URI scheme mean that there is really very little good rule as to when a non-locator identifier should be a URN namespace vs. its own scheme.)

Also, the same rationale that led to the closure of the registry foe the somewhat similar info: scheme registry [1] likely contribute to limited registration for URN NIDs.

[0] tel: (RFC 3966) https://www.ietf.org/rfc/rfc3966.txt

[1] https://oclc-research.github.io/infoURI-Frozen/

I felt the same about many other subjects in the past because they were just needed at that moment. Once the need is gone, the personal demand for it disappears. So your current wish to have URNs to be more popular will be over once your current project is done.

This is first I’ve ever heard of it.

RFC2141 just defines a way to make ids in a non conflicting way. you don't need to use one of the registered namespaces to use URN, you can make up your own and you don't need to register them for them to be useful. at my company we use urn:l6: namespace (company name is L6) whenever we need ids. it very useful especially when you use barcodes, rfid, etc..

>Why are strings not more popular?

It's probably the most popular data type out there, both in data and in codebases. URNs don't bring a lot more than strings on the table, so people go to the easy route.

  * LEIs for companies
  * IBANs for bank accounts
  * ISINs for securities (independent of country)
  * SEDOL for securities (country dependent)

Wish SEPA would adopt this + QR code standard. Bank transfers are ubiquitous around EU, but typing in bank account numbers is a PITA.

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

Most of the people have never heard of the term so, probably lousy marketing.

I use it as redis keys, like a namespace thing.

> 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.

Reposting my response to a similar comment:

I don't really want to classify objects. I want to refer to a registration in a registry. Objects can of course be regidtered many places for many reasons but that is not my concern here.

As long as I can serialize the tuple (registry-somone-made, id-in-that-registry) in a standard and readable way that would be a huge step forward

Reply on news.ycombinator.com