This direct link between the tag and the official registry makes it easy to verify (just paste the number into the site) and easy to maintain (no extra naming layers).
Adding something like ref:sv:hjartstartarregistret.se only adds complexity
The first two are domain names, which are already “guarantueed” to be globally unique, and probably need another kind of discussion. All the other current “ref:SE:” and “ref:[DE|FR|US|…]:” do not contain domain names.
For “ref:sl_stop_id” it says: “The value of sl_stop_id is an internal ID used by SL Stockholm Public Transport” - in case it is restricted to Stockholm län, in ISO 3166 that would be SE-AB cf: ISO 3166-2:SE - Wikipedia . (For DE and US some keys use subtags like “:DE-BE:” and “:US-TX:”)
That leaves only “ref:NVRID” for which it says: “identifier for an area protected under the Environmental Code of Sweden” - i.e. it is: for all of Sweden and not maintained by a private company - seems like a perfect fit for “ref:SE:” instead of “ref:”.
Is it really the best approach to hardcode the country code (e.g. “SV”) directly in the name of the external identifier?
Wouldn’t it be more flexible to represent the region through structured data instead — similar to how OpenStreetMap handles it with Property :P48 – “limited to region”?
But especially for SV, as for any Spanish-dominant country it would probably help to avoid misuse of Keys or having Keys used for different ID systems.
Yes, it would be more flexible, but why would one want flexibility when it comes to UIDs maintained by the government of Sweden?
Yes, flexibility may seem unnecessary for something as fundamental as government-maintained UIDs — but the issue isn’t really about flexibility for its own sake.
When we start embedding different kinds of metadata into the name string itself, we move away from the KISS principle. It introduces hidden complexity and makes it harder to evolve or reuse the data cleanly.
Adding a proper reference, or reusing an existing URL pattern with minimal modification, is both simpler and more robust. The goal should be to keep identifiers stable and neutral, while the meaning and context can be described through linked metadata.
To me, having static, language-bound “name strings” is a form of technical debt. We already have better solutions — for example, Wikidata’s multilingual model. Property P18 (image) shows how one statement can yield labels in 200+ languages (example SPARQL query).
If we want data to be usable globally, we should explain things in the reader’s preferred language, not hardcode names in one. OSM’s wiki pages are a good step in that direction — but ideally, even key names themselves should be less static and more semantically linked….. but that I guess is another issue….
What you present is a different topic. The current situation is that users face the key name in different places.
“ref:SE:” is not a language, any capable tool can do things on top. One can store things three or more times as is done now (Wiki template, Wiki category, Wikibase data items(plural!)) - but the simplest currently available is, to store it only once, namely in the key name:
“ref” means reference (can be displayed in any language, eg. deu:Referenz)
“SE” means Sweden (can be displayed in any language, e.g. deu:Schweden)
Replacing “ref:raa=” with “P1234” would be a different topic: FAQ - OpenStreetMap Community Forum “Don’t divert a topic by changing it midstream.”
Focus on user-friendly, KISS-style solutions (Keep It Simple, Stupid)
Move away from a “one alphabet fits all” mindset
Embrace multilingualism and internationalization (i18n) to make the system truly global
Design solutions with better granularity than country
Strengthen the use of “same as” links to external references — in a digitally mature ecosystem, platforms like OSM will increasingly rely on these connections to stay synchronized and up to date Since we already have an “instance” of Wikidata (OSM Item:Q23184) that supports storing objects and keys in a language-independent way — why not use it? Perhaps we could even explore federation with Wikidata, where entities like a region are directly linked to their Wikidata items - see federated queries / Wikibase federation
Simpler than replacing “ref:raa=” with P1234 (and waiting for new software) is to just add the ISO 3166 code “SE”, which can be handled by existing software.
Please create a new topic for your proposal. If there is support for replacing the current Key name system with Pxxxx that can be taken as a reason not to go forward with ‘Standardise - switch from “ref:raa” to “ref:SE:raa”’
Add metadata as structured data, not duplicated text
