Live data from Hacker News

Ask HN: Why are URNs not more popular?

news.ycombinator.com

31–40 of 64 posts

Re: Ask HN: Why are URNs not more popular?

#31

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.

Re: Ask HN: Why are URNs not more popular?

#32

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 t…

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.

Re: Ask HN: Why are URNs not more popular?

#33
post #26
post #19

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…

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/accountN…

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.

Re: Ask HN: Why are URNs not more popular?

#34
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.`
  * IBAN account: `urn:oid:1.0.13616:` (note that there's also a URI scheme for this)
  * A publication: `urn:isbn:`
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).

Re: Ask HN: Why are URNs not more popular?

#35
post #21

Earlier quoted context omitted.

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 cod…

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?

Re: Ask HN: Why are URNs not more popular?

#36
post #30

> 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"…

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

[dead]

Re: Ask HN: Why are URNs not more popular?

#37
post #34

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. ` * IBAN account: `urn:oid:1.0.13616: ` (note that there's also a URI scheme for this) * A publication: `urn:isbn: ` 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 hav…

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.

Re: Ask HN: Why are URNs not more popular?

#38
post #24

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 li…

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 sav…

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

Re: Ask HN: Why are URNs not more popular?

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

Re: Ask HN: Why are URNs not more popular?

#40
post #37
post #34

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. ` * IBAN account: `urn:oid:1.0.13616: ` (note that there's also a URI scheme for this) * A publication: `urn:isbn: ` 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 hav…

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 sp…

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

Post reply on HN