Property talk:P605

Documentation

NUTS code
identifier for a region per NUTS

Applicable "stated in" value

Nomenclature of Territorial Units for Statistics (Q193083)

Data type

External identifier

Template parameter

en:Infobox German state (nuts) and many other templates

Domain

According to this template: places

According to statements in the property:
administrative territorial entity type (Q15617994), administrative region (Q3455524), administrative territorial entity (Q56061), political territorial entity (Q1048835) or statistical territorial entity (Q15042037)

When possible, data should only be stored as statements

Allowed values

[A-Z]{2}[A-Z0-9]{0,3}

Example

Västernorrland County (Q104891) → SE071 (RDF)
Brussels-Capital Region (Q240) → BE1 (RDF)
BE10 (RDF)

Formatter URL

https://op.europa.eu/en/web/eu-vocabularies/concept/-/resource?uri=http://data.europa.eu/nuts/code/$1

Tracking: usage

Category:Pages using Wikidata property P605 (Q55975186)

Lists

Proposal discussion

Current uses

Total	2,151
Main statement	2,148	99.9% of uses
Qualifier	3	0.1% of uses

Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Single value: this property generally contains a single value. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P605#Single value, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: province of Milan (Q15121), Metropolitan City of Milan (Q18288155)
List of violations of this constraint: Database reports/Constraint violations/P605#Unique value, SPARQL (every item), SPARQL (by value)

Format “[A-Z]{2}[A-Z0-9]{0,3}”: value must be formatted using this pattern (PCRE syntax). (Help)

List of violations of this constraint: Database reports/Constraint violations/P605#Format, hourly updated report, SPARQL

Type “administrative territorial entity type (Q15617994), administrative region (Q3455524), administrative territorial entity (Q56061), political territorial entity (Q1048835), statistical territorial entity (Q15042037)”: item must contain property “instance of (P31)” with classes “administrative territorial entity type (Q15617994), administrative region (Q3455524), administrative territorial entity (Q56061), political territorial entity (Q1048835), statistical territorial entity (Q15042037)” or their subclasses (defined using subclass of (P279)). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P605#Type Q15617994, Q3455524, Q56061, Q1048835, Q15042037, SPARQL

Item “located in the administrative territorial entity (P131)”: Items with this property should also have “located in the administrative territorial entity (P131)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Q27, Q28, Q29, Q31, Q33, Q36, Q37, Q38, Q39, Q40, Q41, Q43, Q45, Q142, Q145, Q183, Q189, Q191, Q211, Q213, Q215, Q218, Q219, Q221, Q222, Q224, Q229, Q233, Q236, Q29999, Q347, Q34
List of violations of this constraint: Database reports/Constraint violations/P605#Item P131, search, SPARQL

Item “country (P17)”: Items with this property should also have “country (P17)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Republic of Ireland (Q27)
List of violations of this constraint: Database reports/Constraint violations/P605#Item P17, search, SPARQL

Item “coordinate location (P625)”: Items with this property should also have “coordinate location (P625)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P605#Item P625, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P605#Entity types

Scope is as main value (Q54828448): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P605#Scope, SPARQL

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Format control doesn't allow NUTS 4, NUTS 5[edit]

The required format doesn't allow values of NUTS 4 and NUTS 5 (renamed later to LAU 1 and LAU 2). Can the definition be changed ~~to "[A-Z]{2}[A-Z0-9]{0,5}"~~?--Shlomo (talk) 11:25, 11 June 2013 (UTC)[reply]

According to en:Nomenclature of Territorial Units for Statistics, NUTS 4 and NUTS 5 were abolished in July 2003, with LAU 1 and LAU 2 as their successors. Since this property here (as it was discussed and decided upon at Wikidata:Property proposal) currently covers NUTS only, it would in my view be wrong to allow long-outdated NUTS 4 and NUTS 5 values. --UV (talk) 21:53, 11 June 2013 (UTC)[reply]

According to the discussion at WD:Property proposal/Archive/8#P605 this property was intended for different versions of NUTS (distinguished by a qualifier) including NUTS 1995 and NUTS 1999 which had also the 4th and 5th level defined. I can't see neither practical reason nor objections in the discussion against using this property for outdated levels (or even values), especially when we already have time qualifiers.--Shlomo (talk) 09:22, 12 June 2013 (UTC)[reply]

I removed the proposed filter format since I found that LAU codes have very different formats in different countries and I'm not sure about the (former) NUTS 4-5. Anyway, the problem remains - we should change the filter to allow the NUTS 4-5 values or make it clear that this property is only for NUTS 1-3 codes.--Shlomo (talk) 10:45, 12 June 2013 (UTC)[reply]

Also, can we use this property to enter actual LAU 1 and LAU 2 values or should I ask creating a special property for them? It seems to be a continuation of the former NUTS 4-5 system, but if it was split and renamed, maybe in fact there is some particular reason...--Shlomo (talk) 11:25, 11 June 2013 (UTC)[reply]

I am not sure whether it would be better to change this property from "NUTS" to "NUTS/LAU" or whether it would be better to create a new property for LAU. Please discuss this question at Wikidata:Property proposal, because a discussion there will be perceived by more contributors than a discussion here. Greetings, --UV (talk) 21:53, 11 June 2013 (UTC)[reply]

OK, I'll move this question there.--Shlomo (talk) 09:22, 12 June 2013 (UTC)[reply]

The request has been hanging on the blackboard for one month now without any reaction. In the meantime, 76 NUTS4/LAU1 regions were added, which are now labeled as "Format violations". Can we do anything either with the format, or with the violation?--Shlomo (talk) 22:22, 11 July 2013 (UTC)[reply]

There are two differernt problems:

NUTS/LAU - It can be done by renaming of this property and with change format from "[A-Z]{2}[A-Z0-9]{0,3}" to "[A-Z]{2}[A-Z0-9]{0,4}". In Czech republic were NUTS4 for districts, which were renamed to LAU1 in 2008, but format was not generally changed.
Problem with NUTS5/LAU2 - every CZ municipality have its own code in format LAU1 some_number, but often is used only some number. So there should be new property.

But I don't know, how is it in other countries. JAn Dudík (talk) 06:39, 12 July 2013 (UTC)[reply]

In Sweden, I have only seen them used by Eurostat. Local authorities almost never use them. -- Lavallen^talk(block) 07:00, 14 August 2013 (UTC)[reply]

The renaming from NUTS 4 and NUTS 5 to LAU 1 and LAU2 should just be an alias of their name

However NUTS 4 and NUTS 5 were still part of NUTS before this renaming

Basically, leveled NUTS/LUA identifiers should just be subclasses of "NUTS identifier", using separate properties instead of the same one "NUTS identifier" (notably because some units hever several identifiers with different classes, e.g. Berlin). This would allow also placing these properties as real (unique) "Identifiers" for elements, instead of generic/descriptive properties. In this case, the single value for each of them can be enforced (no more exceptions !). In addition, the format of each of the 5 new properties can be more strict on their respective length! Verdy p (talk) 18:17, 28 February 2016 (UTC)[reply]

By now, there is LAU (P782) for LAU. Interesting idea to create a separate property for each level! --UV (talk) 20:15, 28 February 2016 (UTC)[reply]

Erroneous item constraint - P17 required[edit]

Another erroneous constraint is the country (P17) requirement. There are several states which are identical with NUTS1 and some of them even with NUTS2 or NUTS3. Can somebody change the constraint that the item should either have a country (P17) defined or set the instance of (P31) to sovereign state (Q3624078) (or country (Q6256) or state (Q7275), whatever)?--Shlomo (talk) 22:36, 11 July 2013 (UTC)[reply]

I have proposed an alternative solution to the problem you describe at Property talk:P17#Add a self-link to sovereign states?. --UV (talk) 23:30, 24 July 2013 (UTC)[reply]

Single constraint: ""Exceptions are possible"", ""The report can include false positives. No need to "fix" them.""[edit]

I readded the single value constraint as generally there is just one. Obviously there are few exceptions, but I think we already know them and thus they wont be cluttering up the report. -- Docu at 08:02, 14 September 2013 (UTC)[reply]

Should we have a general NUTS property or one property for each NUTS version?[edit]

User:Dispiste today changed this property's [en] label and description to "NUTS code 2010" and "NUTS-Code of a region, version 2010", apparently without previous discussion. I have reverted this change for now. In my view, one general NUTS property suffices: If the need arises, temporal validity can be indicated using start time (P580) and end time (P582) qualifiers. Otherwise, we would need to request separate properties for the other NUTS versions at Wikidata:Property proposal. --UV (talk) 12:29, 4 October 2013 (UTC)[reply]

If you look at how Swedish municipality code (P525) is used in Perstorp Municipality (Q504249), you can see that it's possible to describe a change of code in an item. It's also possible to handle several kinds of NUTS-codes in one property. The only problems I see, concerns contraints reports. -- Lavallen (talk) 13:09, 4 October 2013 (UTC)[reply]

I have now applied this solution to Greece (Q41) per de:NUTS:EL. --UV (talk) 13:56, 4 October 2013 (UTC)[reply]

Sorry, I should not edit without previous discussion. I am getting familiar with the system, so I didn't know there better ways to do it. Anyway, I will explain here the logic behind specifying the version: NUTS codes have different versions, and a NUTS code can be different for each version. For instance, the code for Greece on version 2006 is 'GR', while it is 'EL' in version 2010 (last available version). It is useful to have the different versions encoded someway, as it may be used to match Wikidata items with (for instance) statistics referred to a specific NUTS version code. If the version (or validity) is not specified, should we assume we are referring to the last version? This will probably make some wrong records when a new version becomes available. dispiste (talk) 14:02, 4 October 2013 (UTC)[reply]

I haven't worked very much with NUTS, but if there is no qualifier with dates in P525, I have used that as an implications that the code hasn't changed since the founding date of the entity. (That code has existed at least since 1950's, and it only change if a municipality change county, and that is rare.) If I have understood it correctly, NUTS can change every 3 years, but in most cases new versions uses the same code as the older. It will be less work and simplier coding in the client, if we only modify those items that change code, otherwise, we have to modify our templates with every new version, and the users in some WP's maybe not even will be aware of any change of that kind. -- Lavallen (talk) 14:28, 4 October 2013 (UTC)[reply]

I agree on this solution, as applied for instance to Greece (despite I am not sure which one is the correct end-date/start-date, as the old code belongs to NUTS2006 and the new one to NUTS2010. At the same time, NUTS 2010 has been declared valid since 1 January 2012 till 31 Dec 2014). dispiste (talk) 14:42 26 November 2013 (UTC)

Single value constraint[edit]

This property has the constraint property constraint (P2302)single-value constraint (Q19474404) but I found some exceptions, like Canary Islands (Q5813) and province of Milan (Q15121). At the first time I thought about to add it as exceptions with the qualifier exception to constraint (P2303), but then I checked the database report about this constraint violation and it has 229 violations.

In this case I think we should rethink if the single value constraint is correct in this property. If this constraint wouldn't be removed from the property, should we insert each reported item as an exception?

Regards, Ivanhercaz (Talk) 11:00, 13 July 2019 (UTC)[reply]

Notified participants of WikiProject property constraints. Ivanhercaz (Talk) 11:00, 13 July 2019 (UTC)[reply]

You could add "constraint status"="suggestion constraint". --- Jura 11:03, 13 July 2019 (UTC)[reply]

Or adding separator (P4155)=applies to part (P518) as the qualifier of the constraint. --Fralambert (talk) 11:54, 13 July 2019 (UTC)[reply]

@Jura1, Fralambert: Thanks both! Very good ideas, however I have applied what Jura proposed because I admit you, Fralambert, that I have not understand at all how I may use separator (P4155) and applies to part (P518) in this case. Could you explain me? Regards, Ivanhercaz (Talk) 15:10, 13 July 2019 (UTC)[reply]

If I understant the property, they have multiple ID because the place have multiple administrative levels. So you can add each level in applies to part (P518), Like I done with Canadian Register of Historic Places ID (P477) (see McAdam Railway Station (Q287207) for a exemple). --Fralambert (talk) 15:22, 13 July 2019 (UTC)[reply]

@Fralambert: All right! I already understood, thank you. Constraints are really awesome. I am going to check later Canary Islands (Q5813) and if I find more cases like this one, now I how this might work.

But the two qualifiers can be used together, I mean:

property constraint

single-value constraint

edit

constraint status

suggestion constraint

separator

applies to part

0 references

add reference

add value

Would it be correct? I think that it would be valid because if someone add more than one value to a statement with this property but without applies to part (P518) in each value, the system would still suggests that this property usually has only one value. If the statement has several values with the required applies to part (P518), the system wouldn't suggestion that the property usually has a single value.

Regards, Ivanhercaz (Talk) 15:45, 13 July 2019 (UTC)[reply]

Hi, it happens often that an entity has multiple nuts codes. They can change over time. For example here https://www.wikidata.org/wiki/Q3769. I would be for either removing this constrain or changing it to take time evolution into consideration. (Talk) 30 June 2020 (UTC)

Bump! :) I added items for the 2003-2021 versions of Nomenclature of Territorial Units for Statistics (Q193083). It would be nice if we could qualify the codes with a given NUTS version whenever a unit has multiple codes. I'm just unsure about which qualifier to use. I've considered statement supported by (P3680), catalog (P972) and determination method (P459) but looking at the examples on each page, I feel that they're all slightly different to this use-case. Another option would be to use stated in (P248) as a reference. But then the single value constraint would be violated. It would also make queries more complex. Popperipopp (talk) 16:23, 25 May 2021 (UTC)[reply]

located in statistical territorial entity (P8138)[edit]

How about replacing located in the administrative territorial entity (P131) to located in statistical territorial entity (P8138) at item-requires-statement constraint (Q21503247) of property constraint (P2302)? Сидик из ПТУ (talk) 13:37, 8 May 2020 (UTC)[reply]

New URL[edit]

I changed formatter URL (P1630) and URL match pattern (P8966) directing into a better and more updated vocabulary service by the Publications Office of the European Union (Q480222). Please mention if you notice any problems, the new match pattern should be working correctly. – Samoasambia ✎ 22:42, 11 January 2024 (UTC)[reply]