Ask HN: Why are URNs not more popular?

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.

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

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

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

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