Comment by emurlin | Hacker News Reader

Comment by emurlin | Hacker News Reader

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.

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

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

Reply on news.ycombinator.com