Talk:Q7930989

Classification of the class city or town (Q7930989)   

For help about classification, see Wikidata:Classification.

Parent classes (classes of items which contain this one item)

• city or town (Q7930989)
  • urban settlement (Q124250988)
    • human settlement (Q486972) ^(@)→
    • urban area (Q702492)
      • human settlement (Q486972) ^(@)→
      • ^→(#) geographic region (Q82794)
        • geographical feature (Q618123) ^(%)→
        • region of space (Q26713767)
          • spacetime region (Q23956024)
            • spatio-temporal entity (Q58415929) ^(§)→
            • spatial region (Q124711484)
              • immaterial entity (Q124711467)
                • ^→(●) independent continuant (Q53617489)
                  • continuant (Q103940464)
                    • entity (Q35120) ⊸
          • spatial entity (Q58416391) ^(¶)→
        • geographic location (Q2221906) ^(†)→
  • locality (Q3257686)
    • ^→(@) human settlement (Q486972)
      • populated place (Q123964505)
        • geographic region (Q82794) ^(#)→
        • artificial geographic entity (Q27096235)
          • ^→(+) geographic entity (Q27096213)
            • geolocatable entity (Q123349660)
              • material entity (Q53617407)
                • independent continuant (Q53617489) ^(●)→
          • artificial object (Q16686448)
            • ^→(⁋) object (Q488383)
              • entity (Q35120) ⊸
      • ^→(%) geographical feature (Q618123)
        • geographic entity (Q27096213) ^(+)→
    • section of populated place (Q48907157)
      • part (Q15989253)
        • entity (Q35120) ⊸
      • ^→(†) geographic location (Q2221906)
        • geographical feature (Q618123) ^(%)→
        • geographic entity (Q27096213) ^(+)→
        • physical location (Q17334923)
          • ^→(¶) spatial entity (Q58416391)
            • ^→(§) spatio-temporal entity (Q58415929)
              • object (Q488383) ^(⁋)→

Subclasses (classes which contain special kinds of items of this class)

⟨city or town⟩ on wikidata tree visualisation (external tool)(depth=1)

Generic queries for classes

• Number of subclasses (query)
• List of subclasses
• List of direct subclasses
• Number of instances (query)
• Count of instances by class (query)
• List of instances (query)
• List of most frequent properties for items of this class (query)
• Properties suggested for this class (query)

Definition

How is city (Q7930989) different from city (Q515) or city (Q15253706), and why is it defined on purely lexical grounds?  – The preceding unsigned comment was added by Mpetrenk (talk • contribs) at 23:27, 11 января 2017‎ (UTC).

Because city or town (Q7930989) = city (Q515) and town (Q3957) together and this is a notion (which is absent in some languages, e.g. in English). --Infovarius (talk) 22:18, 13 December 2018 (UTC)

I doubt that having Q7930989 as a separate item about larger urban settlement really clears up things since city (Q515) and town (Q3957) judging by item statements and all site links are not about city and town in some strict (English-language) sense either. 2001:7D0:81F7:B580:30B7:EDA3:D850:4A41 15:25, 27 December 2018 (UTC)

You are wrong. How do you like "city" Chekalin (Q197902)? Or even Innopolis (Q4201239)? But they are real город. --Infovarius (talk) 21:20, 12 November 2019 (UTC)

There should be more clarity as "Ville"@fr "city"@en aren't clear on their description : people aren't able to pick the right city item. Bouzinac (talk) 08:43, 22 November 2019 (UTC)

That is, if you strictly define city as something that doesn't apply to these Russian cities (or towns, if you like). Item city (Q515) however isn't strictly defined like that. 2001:7D0:81F7:B580:40B2:87E9:EBF8:726 09:51, 28 November 2019 (UTC)

By the way, for classification purpose I'd suggest using an item that is precisely about type of city (or town) as defined in Russian legislation. There is federal city of Russia (Q183342), but different types of towns and cities in Russia (Q18398645) that would apply to these two cities (or towns) seems to be missing currently. 2001:7D0:81F7:B580:40B2:87E9:EBF8:726 10:07, 28 November 2019 (UTC)

Towns and cities as geographical objects

I just got an error message stating that a university's headquarters can't be located in a town because towns aren't geographical objects. Hence, I made them, on the highest level I could be sure of. If you have some crazy objection to it (as Wikidatans tend to), please don't just reverse my edit but also fix the problem in some other way. --Ehitaja (talk) 16:00, 20 April 2019 (UTC)

Slash in the name of items

This items name is bad as it cannot be replaced in the query service visual editor. I propose renaming it to something that is supported or fixing the script that does the replacement.--So9q (talk) 16:04, 11 November 2019 (UTC)

You may simply delete English label as this notion has no direct translation to English. --Infovarius (talk) 20:37, 12 November 2019 (UTC)

By the way, what "replacement" are you talking about? --Infovarius (talk) 21:21, 12 November 2019 (UTC)

Not having one correct translation to English does not really mean it has no (direct) translation. Usually, if there are more than one (common) translations, then one is provided as label and others are provided as aliases. Though, I understand that here multiple translations are entered as a label to make the intention behind having this as separate item more clear. 2001:7D0:81F7:B580:40B2:87E9:EBF8:726 09:51, 28 November 2019 (UTC)

@Infovarius: I meant that we should report this as a bug in the parsing of the WDQS UI (try to select this item by the ctrl+space UI = impossible). :D--So9q (talk) 18:17, 29 November 2019 (UTC)

Administrative entity

User:Jklamo, regarding Special:Diff/1302128728, see prior comments: 1) Talk:Q515#subclass of Q6501447 and Q1048835, 2) User talk:Infovarius/Archive/2019#Special:Diff/876748142. A city/town that isn't an administrative entity is supposed to show up as a constraint violation, after your revert it doesn't. Instead administrative territorial entity (Q56061) class should be applied to individual towns/cities or relevant country specific classes that actually are for administrative entities, without affecting other towns/cities that are not. 2001:7D0:81F7:B580:A93D:9C1C:E02D:1143 11:05, 7 November 2020 (UTC) {{edit protected}}

So I request removal of "P279: administrative territorial entity (Q56061)" statement as this is not true for all cities/towns. 2001:7D0:81F7:B580:6056:20F7:6C22:E2B0 09:54, 17 November 2020 (UTC)

@Jklamo: Do you have any comments on this edit request? Bovlb (talk) 22:05, 21 December 2021 (UTC)

 Not done very old request. This would be a non-controversial change. Better status quo until we will get more input, more discussion--Estopedist1 (talk) 10:37, 27 August 2022 (UTC)

{{edit protected}} I suppose I can simply renew the request then. In the meantime P279=political territorial entity (Q1048835) has been added which is wrong also as it refers to a subclass of administrative territorial entity (Q56061). So I request the removal of both of these P279 values. @Estopedist1: could you please clarify why would it be controversial? As far as I can see only the addition of these statements in the first place was controversial and it was done without any discussion and by ignoring previous discussion. The status quo was to omit these statements. Due to these statements many cities/towns that are not administrative entities are now erroneously classified as ones (see examples in previous discussions linked above).

Note that I see why link to administrative territorial entity (Q56061) has been added: people want to fix the value type constraint violations for located in the administrative territorial entity (P131). However to manipulate parent classes for this item is obviously the wrong way to fix constraint violations. There should be some visible guideline on this: administrative territorial entity (Q56061) should be linked only from an item of individual city that actually *is* an administrative entity, or from class item only in case all instances of this class actually *are* administrative entities as is the case e.g. for city in the state of New York (Q15063611). 2001:7D0:81E6:EF80:4C67:63BE:D9AA:BD09 07:42, 29 August 2022 (UTC)

when looking item's history several users has added and deleted the properties mentioned above. Just in case I am pinging someone @SR5:, @Jklamo:, @Peter James:. If there is no constructive answers, I will fulfill the request if 2 weeks are over Estopedist1 (talk) 11:19, 29 August 2022 (UTC)

 Oppose Item is pretty vague and it has different meanings in different languages, used in 2000+ items. In some countries simply it is administrative territorial entity (Q56061). In some cases, it may be only instance of (P31) in item. It is better to use country-specific items and stop using this item gradually, changing its vagueness is not the best idea. --Jklamo (talk) 18:55, 30 August 2022 (UTC)

@Jklamo: it is vague, but your edit indicates the opposite. By adding P279=Q56061 you made it less vague and you specifically made all cities in the world into administrative entities. I also agree that it's better to have country-specific items to classify individual cities that actually are administrative entities, but manipulating the parent classes here the way you did doesn't help with that goal, as far as I can see, it only messes things up further. 2001:7D0:81E6:EF80:EDFC:DA80:162C:B389 07:25, 31 August 2022 (UTC)

@Estopedist1: you declined the edit request as "controversial" (Special:Diff/1719559652). I see an opposition here, but I don't see an argument. I don't think that opposition per se makes it controversial. This item nor separate "city" and "town" items, in their descriptions nor in Wikipedia articles attached to these articles, define city/town as strictly an administrative entity, and this contradicts current P279 values. No one has even tried to make the case that there isn't contradiction or that there isn't a fairly obvious mistake for this reason. As for suggestion to compromise, I suppose we already agree that more specific classes should be used to classify individual administrative cities. Then people would have less reason to manipulate parent classes here to "fix" (suppress) constraint violations, and this could be perceived as sort of a compromise perhaps? Or, if P279 values in question really must stay, then what is the solution? Should we create yet another "city/town" class item that would be more generic in order to classify individual non-administrative cities correctly? 2001:7D0:81E6:EF80:391F:D6C5:6CDC:75B1 10:53, 3 September 2022 (UTC)

Sorry, but I can't fulfill edit request which is likely to be disputed (per e.g. user:Jklamo's comment above). There are also properties like statement supported by (P3680) and statement disputed by (P1310), maybe can be used in this case. Also, rational action may be if we discuss it at Wikidata:WikiProject Geography (or at enwiki where this WikiProject is more active)--Estopedist1 (talk) 19:49, 3 September 2022 (UTC)

Town/city in Ukraine

In Ukraine there is old term містечко for town. And in USSR they were transformed into селище міського типу. That's why I am sure, that "Місто"@uk didn't include "town" and I will move it to city (Q515). --BogdanShevchenko (talk) 15:28, 17 December 2020 (UTC)

Talk:Q515

Talk:Q515#Q7930989. Oleg3280 (talk) 11:03, 4 April 2021 (UTC)

About removing Q7930989 (city) from subclasses of Q56061 (administrative division)

Hi all! I'm seen that @MB-one was removing city or town (Q7930989) from subclasses of administrative territorial entity (Q56061). This is lead to display constrain warning in a many items for cultural heritage objects, where city used as value for located in the administrative territorial entity (P131) (one from required property). Examples: Gagarin Street 26, Kirzhach (Q116691377), Ilyins mansion (Luga) (Q107136394).

Please explain, on what consensus your change was based? I'm going to revert this edit.

PS: @MB-one, please clear your personal talkpage that is very big; the size of more than 2 MB prevents using the CD tool there Kaganer (talk) 19:59, 23 December 2023 (UTC)

Потому что не везде города являются АТЕ (а всего лишь населёнными пунктами)... Например, Stockholm (Q1754) - город, а Stockholm Municipality (Q506250) - коммуна (АТЕ). --Infovarius (talk) 22:46, 24 December 2023 (UTC)

Даже в России не все города являются АТЕ, это не секрет. Мой вопрос касался того, на основании чего именно была сделана указанная правка (без каких-либо сопутствующих масштабных изменений)? При том, что предыдущее состояние элемента существовало более 3-х лет (см. [1]). Kaganer (talk) 12:42, 25 December 2023 (UTC)

Правильно ли я понимаю, что в России, всё что имеет код ОКАТО, является АТЕ? Avsolov (talk) 20:33, 25 December 2023 (UTC)

Думаю, да. И тут хороший пример - Pushkin (Q7947), у которого указан код ОКАТО, но в справочнике мы видим пометку "исключен". Kaganer (talk) 09:41, 26 December 2023 (UTC)

Дак тогда может просто пройтись по элементам со свойством P721 и у тех, у которых выпала классификация как administrative division, добавить что-нибудь типа administrative territorial entity of Russia? Avsolov (talk) 11:41, 26 December 2023 (UTC)

See previous topics above, including links to previous discussions. The constraint is there with a reason, it shouldn't be just suppressed by messing up top level classes such as this one here. Only these particular cities/towns that actually are administrative entities should be set as ones, e.g. one way to properly fix the constraint violation in Q116691377 is this: Special:Diff/2036493511. 2001:7D0:81DB:1480:CC87:4846:DA70:2EE7 08:50, 25 December 2023 (UTC)

Of course, I know what it might say (without even reading it). But the previous state of the element is more than 3 years old, and many other elements refer to this as a value of property located in the administrative territorial entity (P131) (based on his place in classification).
You can't just go and "improve" something in one place by just leaving all the related data "as is". The person who undertakes to improve the classification tree should take responsibility for correcting all linked data (at least, propose a roadmap).
The element city/town in Russia (Q106389302) has the same problems as city or town (Q7930989) - not all Russian settlements classified as "city" are administrative entities. Kaganer (talk) 12:52, 25 December 2023 (UTC)

Then figure if another class item is for Russian type of settlement is needed, or use administrative territorial entity (Q56061) directly as P31 value where needed, or check if the use of located in the administrative territorial entity (P131) in the first place is appropriate (should it link to non-admin entity). Surely it is possible to deal with constraint violations in a clean way. 2001:7D0:81DB:1480:F0D4:E3BD:9175:32B 19:16, 25 December 2023 (UTC)

@Kaganer per 2001:7D0:81DB:1480:CC87:4846:DA70:2EE7: Q7930989 is characterized by being a subclass of a human settlement (Q486972) but not all instances of a Q7930989 fulfill the criteria of being a administrative territorial entity (Q56061). MB-one (talk) 13:12, 25 December 2023 (UTC)

@MB-one. This was known more that 3 year ago. If you've decide improve this today, please also organize and coordinate improving all linked data, that was configured based on previous state. Kaganer (talk) 13:24, 25 December 2023 (UTC)

I think you look at this sort of backwards. Things need improving cause evident classification errors exist (they existed all these years and before) not just because relevant constraint violation is displayed again. Now hopefully people can make proper use of this constraint violation and accordingly repair actual problems, instead of looking for a robust and messy way to just suppress the constraint violation. (Or, if there really are too many violations that people don't care about properly fixing then we should probably rather consider removing the constraint altogether.)

Wikidata includes many long-standing classification errors. I don't think that longevity of errors indicates that errors are intentional nor that it's useful to keep the errors as long as errors are somewhat stable, if this what you suggest.

Note that this bad statement in the first place was added 3 years ago without any consensus or discussion, and just by ignoring previous discussions. Before that this item was without given statement for most of the time. 2001:7D0:81DB:1480:F0D4:E3BD:9175:32B 19:16, 25 December 2023 (UTC)