Adding multiple NUTS years, fix urls

[matamadio]

Related issues

Solves
#465
#464

Description

Add multiple NUTS years; fix NUTS urls

Merge checklist

If you added, removed or renamed a field:

• Update the collapse and externallinks options of the jsonschema directives in reference/schema/
• Update the diagrams in reference/schema/
• Update the JSON files in examples

Always:

• Update the changelog (style guide)

Having trouble?

See how to resolve check failures.

[duncandewhurst]

I think https://ec.europa.eu/eurostat/web/nuts is more likely to persist than the glossary URL.

See my comment in the issue regarding the change to the URI pattern.

Suggested change

NUTS 2024,EU Nomenclature of Territorial Units for Statistics 2024,The Nomenclature of Territorial Units for Statistics (NUTS) was established by Eurostat in order to provide a single uniform breakdown of territorial units for the production of regional statistics for the European Union.,Subnational,https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary:Nomenclature_of_territorial_units_for_statistics_(NUTS),https://ec.europa.eu/eurostat/web/nuts/maps

NUTS 2024,EU Nomenclature of Territorial Units for Statistics 2024,The Nomenclature of Territorial Units for Statistics (NUTS) was established by Eurostat in order to provide a single uniform breakdown of territorial units for the production of regional statistics for the European Union.,Subnational,https://ec.europa.eu/eurostat/web/nuts,https://publications.europa.eu/resource/authority/nuts/code/{identifier}

(For the avoidance of doubt, the same suggestion applies to the other NUTS codes.

[matamadio]

Thanks, since https://publications.europa.eu/resource/authority/nuts/code/{identifier} would return a json that also includes year reference, would it make sense to go back to just one NUTS selector value? But it's not obvious by the link and it seems the user would likely prefer to have an explicit year selector.

<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2006"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2010"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/1999"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2003"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2021"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2024"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2013"/>
<skos:inScheme rdf:resource="http://data.europa.eu/nuts/scheme/2016"/>

Just to say we need to find a balance between values being self-explanatory and unambiguos without exploding the number of choices too much.

[duncandewhurst]

According to https://interoperable-europe.ec.europa.eu/sites/default/files/document/2018-03/D04.02.1%20NUTS%20RDF%20Model%20revised%20v1.00.pdf:

NUTS Codes are not versioned because their meaning is stable – a code is withdrawn if fundamental aspects change, e.g. when the region that it represents changes.

As NUTS Codes are not versioned and NUTS Versions (see below) are versioned, a NUTS Code may be a member of more than one NUTS Version.

So I think it's okay to have a single entry covering all the NUTS versions.

[duncandewhurst]

Forgot to say - also needs a changelog entry.