4 ms·

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

by dagss 4y ago

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.

zauguin 4y ago
> 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.
- dagss 4y ago
  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:".
IceDane 4y ago
Minor nitpick: It's CVR, not CRV.
emurlin 4y ago
> 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>`

by dagss 4y ago

zauguin 4y ago

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

dagss 4y ago
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:".

IceDane 4y ago

Minor nitpick: It's CVR, not CRV.

emurlin 4y ago

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