Wikidata talk:WikiProject Categories

WikiProject Categories WikiProject to solve any issues regarding categories.

Ask a question

Hi everyone! So, in this first day of the WikiProject I want to start discussing an issue that creates a lot of constraint violations.

So, at the moment there are 16465 cases of instance of (P31)Wikimedia category of stubs (Q24046192) + category combines topics (P971)Wikipedia:Stub (Q4663261). However, 12511 of them are constraint violations because category combines topics (P971) has only that value, even if it should have multiple values; the remaining items have category combines topics (P971)Wikipedia:Stub (Q4663261) + other category combines topics (P971) indicating stubs' topics.

1. My proposal is substituting category combines topics (P971)Wikipedia:Stub (Q4663261) with category contains (P4224)Wikipedia:Stub (Q4663261) and substituting the remaining category combines topics (P971) with main subject (P921) used as qualifier of category contains (P4224)Wikipedia:Stub (Q4663261).

Same problem regarding 216 cases of instance of (P31)Wikimedia templates category (Q23894233) + category combines topics (P971)Wikimedia template (Q11266439) (56 of which are constraint violations of category combines topics (P971)) and 34442 cases of instance of (P31)Wikimedia category (Q4167836) + category combines topics (P971)Wikimedia template (Q11266439) (34162 of which are constraint violations of category combines topics (P971)).

1. My proposal is substituting instance of (P31)Wikimedia category (Q4167836) with instance of (P31)Wikimedia templates category (Q23894233), substituting category combines topics (P971)Wikimedia template (Q11266439) with category contains (P4224)Wikimedia template (Q11266439) and substituting the remaining category combines topics (P971) with main subject (P921) used as qualifier of category contains (P4224)Wikimedia template (Q11266439).

Thank you for your interest in categories! Bye, --Epìdosis 13:04, 8 July 2018 (UTC)[reply]

• Maybe it's better to do discussions on the talk page (Wikidata talk:WikiProject Categories). I'd suggest to move this there. I'm not sure how to fix the button at the top of the page (Wikidata:WikiProject Categories). ( Done, thank you. --Epìdosis 13:37, 8 July 2018 (UTC))[reply]
  category combines topics (P971) has plenty of violations due to the multi-value constraint. This isn't really something that needs fixing. It just shows that when decomposing the scope of a category, there is no need to repeat the main topic of a category and eventually more should or could be added.
  De-composing it consists in determining the many topics this can combining. Frequently one is interested in one aspects and completes or queries just that.
  I don't think we should attempt to re-combined these to attempt to replace P31 with some compound.
  P4224 has some other function.
  --- Jura 13:24, 8 July 2018 (UTC)[reply]

  @Jura1: So in your opinion how should we deal with Wikimedia category of stubs (Q24046192) (22262 uses), Wikimedia templates category (Q23894233) (809 uses), Wikimedia infobox templates category (Q23894246) (201 uses) and Wikimedia navboxes category (Q13331174) (70 uses)? Maybe the last two are superfluous, but I think that the first two are necessary and should be used; Wikimedia category of stubs (Q24046192) is already widespread because I spread it after discussing with @Cycn:. --Epìdosis 13:37, 8 July 2018 (UTC) And I can't understand why you say that category contains (P4224) wouldn't fit in this case. --Epìdosis 13:39, 8 July 2018 (UTC) category contains (P4224) would be redundant if associated with Wikimedia category of stubs (Q24046192) or Wikimedia templates category (Q23894233), but no more redundant than category combines topics (P971) and, moreover, it wouldn't be a constraint violation. --Epìdosis 13:42, 8 July 2018 (UTC)[reply]

  • P4224: it might be fine. It's just that I don't have much of an opinion about it.
    I think we deleted one of the compound items some time ago. I don't recall what it was.
    I think the general idea was that we don't want to mirror the structure of Wikipedia categories with P31/P279 on Wikidata items about categories.
    --- Jura 13:49, 8 July 2018 (UTC)[reply]
  • BTW the deletion was at Wikidata:Requests_for_deletions/Archive/2017/09/21#Q29848066, but I don't recall the label :(
    For the ones being discussed here, I'd keep the stub ones, but do away with the others as well.
    --- Jura 14:19, 8 July 2018 (UTC)[reply]

    @Jura1: It was "category about events in a specific year or time period", it was effectively useless. I would keep Wikimedia templates category (Q23894233) because it regards not a particular type of articles, but templates (an entire namespace). Now let's hear other users. --Epìdosis 14:43, 8 July 2018 (UTC)[reply]

    Epìdosis
    Jura
    PKM
    ValterVB
    Jheald
    Ghuron
    Infovarius
    Sannita
    Avatar6
    Pasleim
    John Samuel
    ElanHR
    Tris T7 ^{TT me}
    D.C.flyer
    Csisc
    

    Notified participants of WikiProject Categories Please give your opinion! --Epìdosis 12:29, 11 July 2018 (UTC)[reply]

Hi all! Some thouhgts on topic regarding template categories: 1. item Wikimedia templates category (Q23894233) and subclasses were created and used much earlier than P4224. 2. ...so some wikis used to use property P31 in their category related templates logic; wd-item deletion will broke it's logic. 3. Name of class, such as Wikimedia navboxes category is much easier to understand, than constructed statement, sentence from two or more Wikidata Properties, in some languages at least. 4.Some wikis used to pseudonamespaces in category namespace, e.g. Категория:Навигационные шаблоны:<topic>, Категория:Шаблоны:<topic> in ruwiki & it's satellite east slavic wikis. --Avatar6 (talk) 12:52, 30 July 2018 (UTC)[reply]

We previously had a short chat about that with @Jura1:, but I believe now we can involve a few other interested participants here. I would be very convenient to "mark" somehow metacategories (categories, that are intended to include other categories only). Although I understand that we don't want to "mirror the structure of Wikipedia categories with P31/P279 on Wikidata" I see nothing particularly wrong with marking such items as P31:Q30432511 (instead of P31:Q4167836) --Ghuron (talk) 12:26, 11 July 2018 (UTC)[reply]

I support instance of (P31)Wikimedia meta category (Q30432511) as I support instance of (P31)Wikimedia templates category (Q23894233) because these categories contain not articles, but respectively other categories and templates. --Epìdosis 12:33, 11 July 2018 (UTC)[reply]

• How would we know what Wikipedia/etc. users put in there? Would we have to monitor them? Redoing P31 periodically based on people's usage? Why complicate things for users how want to check a structure by splitting the topic among several properties? The point of a flat P971 is that it's flat ;)
  --- Jura 12:39, 11 July 2018 (UTC)[reply]
  • @Jura1: there is nothing wrong when bot will assign for all new categories (including metacategories) instance of (P31)Wikimedia category (Q4167836). But if someone will notice that particular category is indeed metacategory, she can narrow down P31 value. I have nothing against P971, and I'm using it extensively. The problem is that there is no universal way to express "this is metacategory" statement via P971. Instead I can say category combines topics (P971)by country (Q19360703) or category combines topics (P971)by city (Q18683478) or category combines topics (P971)by genre (Q42903116). And if I want to get "all non-meta-categories", I will have to FILTER NOT EXISTS {?cat wdt:P971/wdt:P31 wd:Q24571886}? It's gonna be slow :( --Ghuron (talk) 13:05, 11 July 2018 (UTC)[reply]
    • The problem is that people may not want any category items, so just exclude any P31 with a given value is way easier.
      It's still not clear how you decide what categories that only contain categories are.
      --- Jura 13:12, 11 July 2018 (UTC)[reply]
      • Well, judging mostly from the title (e.g. I assumes that Category:Argentine women by occupation (Q8262772) is intended to contains other categories). More formally, there is Q4048796, that is used at least in en-wiki quite extensively

        PREFIX mw: <http://tools.wmflabs.org/mw2sparql/ontology#>
        SELECT ?item ?page WHERE {
          hint:Query hint:optimizer "None" .
          SERVICE <http://tools.wmflabs.org/mw2sparql/sparql> {
            ?page mw:inCategory <https://en.wikipedia.org/wiki/Category:Container_categories> .
          }
          ?page schema:about ?item . ?item wdt:P31 wd:Q4167836
        }
        

        Try it!
        --Ghuron (talk) 13:29, 11 July 2018 (UTC)[reply]

•  Oppose It's in the nature of Wikimedia categories that they can contain either articles or sub-categories. Even if a category may be marked as intended only to contain categories, with a template such as eg c:Template:CatCat on Commons, there is no guarantee that users will respect this, nor that other wikis to which the category may be linked will impose the same rule. Jheald (talk) 16:47, 11 July 2018 (UTC)[reply]
  • Can someone put commons:File:Катлакалнская_евангелическо-лютеранская_церковь.JPG to commons:Category:Tales? Yes, of cause - it is nature of wiki projects. Does it stops you from specifying category's main topic (P301)Tales (Q1944909) for Category:Tales, Spain (Q55296298)? No, it does not, because you are capturing intended usage of this category. Help me understand how this case is different comparing to setting instance of (P31)Wikimedia meta category (Q30432511) for Category:Argentine women by occupation (Q8262772)? --Ghuron (talk) 17:05, 11 July 2018 (UTC)[reply]
    • The problem comes with something like en:Category:Arab physicians -- a container category in English, but not in eg French: fr:Catégorie:Médecin_arabe or Dutch: nl:Categorie:Arabisch medicus.

What we need perhaps is to focus more narrowly on categories of the type X by Y, the topic of recent discussion at Wikidata:Project_chat#Category:A_[split_up_by]_B.

For the record, I also dislike the idea of introducing lots of subclasses of Wikimedia category (Q4167836). I would prefer to indicate contents or attributes of the category by using additional statements. Jheald (talk) 17:21, 11 July 2018 (UTC)[reply]

One idea might be to identify such classes using something like

<category item> category combines topics (P971) "X"

<category item> category combines topics (P971) "Y" object of statement has role (P3831) "Partition class"

Category items with statements of this pattern would be fairly easy to require or to exclude in a query. Jheald (talk) 17:37, 11 July 2018 (UTC)[reply]

As an exploration of what we have to deal with, here's a quick query looking at 30,000 categories with en-labels of this form, to see the sort of partitioning classes that may be most relevant. tinyurl.com/y85gqesz. "By country" (4498), "by year" (807), "by nationality" (771), "by state" (755) lead the list. Jheald (talk) 18:01, 11 July 2018 (UTC)[reply]

For what it's worth, here are the current uses of category combines topics (P971) on such categories:

• "by country" tinyurl.com/y8j8gggw (4392 out of 4500 have topic by country (Q19360703), which I would propose to retire).
• "by year" : tinyurl.com/yczvajdc (68 out of 800 have topic by year (Q29053180) -- ditto).
• "by nationality" : tinyurl.com/yb2ogsr7 (298 out of 800 have topic by nationality (Q30905655), 195 have by country (Q19360703))
• "by state" : tinyurl.com/y98aeqc4 (10 out of 800 have topic U.S. state (Q35657); 6 have by subnational entity (Q19588365); 2 have state or territory of Australia (Q178712))
• "by quality" : tinyurl.com/yaesd4ew (9 out of 800 have topic by Wikipedia article quality (Q24575823))
• "by occupation" : tinyurl.com/y8b3xwtx (188 out of 500 have topic occupation (Q12737077) -- also 199 person related to this place (Q19660746) since the categories are also typically geographical)

Jheald (talk) 18:28, 11 July 2018 (UTC)[reply]

The "by ..." items are all members of meta category criterion (Q24571886)   , created by User:Shinnin. According to Reasonator, there are 38 items currently in this class. It's an interesting approach, but I don't think it scales well -- I think the qualifier I have suggested above would be a more general approach. On the other hand, perhaps it doesn't need to scale very far -- the number of partitioning classes we need to cope with is fairly finite, at least judging by the query above.

Pinging @Shinnin: Are there any particular advantages of your model that you would like to bring into the discussion? Jheald (talk) 18:40, 11 July 2018 (UTC)[reply]

@Jheald: I didn't create meta category criterion (Q24571886)   . "By <something>" type of items existed in Wikidata before I started editing here. I think by year (Q29053180) is my creation, the rest are not. I've used these types of items mainly because they seemed to be the de facto way of modeling these types of categories.

I do think that after category contains (P4224) was created, many of the current use cases could have been changed to use it instead of P971. E.g. Category:Albums by year (Q6695739)category contains (P4224)album (Q482994)grouped byyear (Q577) However, this approach would only work for categories that group articles based on their type. Not the ones that group them base on a common topic (e.g. Category:Geography by country (Q6491485)). All in all, I'm not an advocate of the current system. --Shinnin (talk) 20:10, 11 July 2018 (UTC)[reply]

I can see your point now and I believe I need to clarify what I'm trying to do. I want to exclude categories similar to X by Y from the scope of my queries. Although I believe that setting instance of (P31)Wikimedia meta category (Q30432511) for them is most efficient way to achieve that, I'm not against any other way to labeling them that would fulfill my needs. We've been discussing idea of using P971 on the thread above and I still do not see efficient way how I can exclude (compare this to this) --Ghuron (talk) 18:45, 11 July 2018 (UTC)[reply]

@Ghuron: I'm not sure that I would read too much into that comparison, unless that count is literally all you want to do, in which case you can calculate a count excluding a particular subset efficiently simply by subtraction.

The first query is fast because the query engine never has to materialise the items, it can just count the difference between two index positions.

As soon as you are wanting anything more concrete (typically involving a more restricted solution set), the difference in time between the two queries would be a lot smaller. Jheald (talk) 20:49, 11 July 2018 (UTC)[reply]

Also worth noting that this query is not particularly happy either. Jheald (talk) 20:56, 11 July 2018 (UTC)[reply]

Fair point about count, let's assume I want to get labels for all categories w/o P4224 (for machine learning experiment). No single query can return 4M records in 60 seconds, so I'm using LIMIT/OFFSET. Let's see how well each of discussed schemas fits here:

• instance of (P31)Wikimedia meta category (Q30432511) approach would be like this (chooses arbitrary high offset). It is simplified version, normally I would query labels for range of languages, but it has marginal performance impact and irrelevant for our discussion. MINUS{ ?cat wdt:P31 wd:Q30432511 } is redundant, because each category is either Wikimedia category (Q4167836) or one of its subclass such as Wikimedia meta category (Q30432511) But what might be interesting is that getting both Wikimedia category (Q4167836) and its subclasses is only slightly slower - I'm still reliably getting 50K records within 60s timeout.
• Jura's approach (the way I understand it: category combines topics (P971)by country (Q19360703), etc.) doesn't work with offset (inner query even with lower offset returns timeout). Looking for OPTIONAL {?cat wdt:P971 ?f} FILTER(!BOUND(?f)) instead of specific FILTER NOT EXISTS will work, but it reduces scope by 15% and going forward this gap will only widen
• Your approach cannot even return top50K records without offset - see [1]

One might argue that my task is rare, but even if we accept this, I still failed to see any reasons against using instance of (P31)Wikimedia meta category (Q30432511) except pure aesthetical (that are very subjective) --Ghuron (talk) 11:45, 12 July 2018 (UTC)[reply]

@Ghuron: It's not a great surprise that putting a LIMIT 50000 on a COUNT query with a one-line answer fails to be particularly effective  :-)

Starting with this (or its OPTIONAL { ... } FILTER (!bound(...)) alternative) might be more interesting. Jheald (talk) 13:03, 12 July 2018 (UTC)[reply]

@Jheald: yep, too may query windows open, but still getting timeout on OFFSET 1000000 LIMIT 1. Couldn't figure out how to use OPTIONAL { ... } FILTER (!bound(...)) here because (unlike P4224) we expect several values on P971, and having P3831 qualifier on ANY of them should eliminate category from output --Ghuron (talk) 13:09, 12 July 2018 (UTC)[reply]

@Ghuron: I would do it this way: generate a controlled number of categories first, then start applying tests to them. Jheald (talk) 13:26, 12 July 2018 (UTC)[reply]

On a tranche of 500,000 categories, the hash join to exclude p:P971/pq:P3831 is adding about 8 seconds (17 seconds vs 9 seconds). Jheald (talk) 13:31, 12 July 2018 (UTC)[reply]

This variant is a bit slower, at 29 seconds. Jheald (talk) 13:36, 12 July 2018 (UTC)[reply]

@Jheald: as long as it fits 60s timeout, a few seconds slower doesn't matter. Your approach works for both P3831 qualifier and by country (Q19360703)/by city (Q18683478)/by genre (Q42903116)/etc (see [2]). But my understanding was that if something can be expressed without qualifiers, it should be expressed so. Shouldn't we use meta category criterion (Q24571886) children? --Ghuron (talk) 13:47, 12 July 2018 (UTC)[reply]

@Ghuron: I would delete that entire class, because I think it just causes difficulty and confusion -- starting with the name, which is deeply opaque. IMO, if something is being used as the partitioning class, it is better to use the regular class-item for that, with a qualifier to say that that is its role, rather to expect people to create and consistently use parallel different items. Jheald (talk) 14:13, 12 July 2018 (UTC)[reply]

@Jheald, Jura1, Epìdosis: So apparently we have 3 or 4 competing proposals here (not counting what was discussed in Wikidata:Project_chat#Category:A_[split_up_by]_B). Since any of them will work for me, I don't really care which one will be selected, but I do want us to select one (so I can start using it). Please advise how should we proceed from here --Ghuron (talk) 17:12, 12 July 2018 (UTC)[reply]

• To avoid making this too complicated and as the items won't plenty of statements, maybe one could just add has characteristic (P1552) with some value one thinks applies.
  --- Jura 13:07, 12 July 2018 (UTC)[reply]
• There is one more thing that need to be considered. Those (meta)categories are not suitable for category for the water basin (P1200); category for alumni of educational institution (P3876); category for employees of the organization (P4195); category for films shot at this location (P1740); category for people born here (P1464); category for people buried here (P1791); category for people who died here (P1465); category for pictures taken with this camera (P2033) and category for recipients of this award (P2517). It would be nice to add corresponding constraint there --Ghuron (talk) 10:21, 16 July 2018 (UTC)[reply]

metacategory can not be strict class on wikis. Its only intention to be so. If metacategory contains pages it is not an error, it is just warning, because it can be happened on much reasons, e.g. wiki does not have sutable subcategory for that metacategory. Either dnot have yet or have not much usability of such subcategory name, or for now only.--Avatar6 (talk) 13:13, 30 July 2018 (UTC)[reply]

Hi all! I want to restart the previous discussion from another point of view: redundant information. These are the cases:

• instance of (P31)Wikimedia category of stubs (Q24046192) + category combines topics (P971)Wikipedia:Stub (Q4663261) + category contains (P4224)Wikipedia:Stub (Q4663261) (e.g. Category:Sweden stubs (Q4352), more than 16000)
  • add instance of (P31)Wikimedia category of stubs (Q24046192) + category contains (P4224)Wikipedia:Stub (Q4663261) NOT category combines topics (P971)Wikipedia:Stub (Q4663261) (e.g. Category:France geography stubs (Q7477980), nearly 6000)
• instance of (P31)Wikimedia templates category (Q23894233) + category combines topics (P971)Wikimedia template (Q11266439) + category contains (P4224)Wikimedia template (Q11266439) (e.g. Category:Sports templates (Q3811), nearly 1000)
  • add instance of (P31)Wikimedia category (Q4167836) + category combines topics (P971)Wikimedia template (Q11266439) + category contains (P4224)Wikimedia template (Q11266439) (e.g. Category:Coordinates templates (Q5612380), more than 33000)

In your opinion how should we deal with these? Thank you, --Epìdosis 19:52, 29 July 2018 (UTC)[reply]

• I think P4424 was created knowing that it would duplicate P971. It's just meant to provide some different functionality. It may or may not be useful for stub categories. Maybe one shouldn't fill P4424 unless actually needed.
  --- Jura 05:39, 30 July 2018 (UTC)[reply]
• I do not see huge issues with duplicated information between P971 and P4224. Of cause, once data model for categories would be agreed and accepted, it will be more elegant comparing to examples above. I prefer to work with P4224, Jura - with P971, so examples above merely represent "work in progress" --Ghuron (talk) 06:40, 30 July 2018 (UTC)[reply]

• • @Ghuron: There's a fundamental problem with P4224, that I only realised after I had proposed the property, and after it had been created: namely P4224 can't handle cases where the category membership/non-membership would correspond to the presence or absence of a qualifier with a particular value. For example (adapted from this current discussion at Project:Chat), suppose we had a category Category:cardinals created by Pope Sylvester II. It is not possible to code this with P4224. One can state category contains (P4224)human (Q5) and one can add the qualifier position held (P39)cardinal (Q45722), but it is not appropriate to add the further qualifier appointed by (P748)Sylvester II (Q172383), since this fact would not appear as a main statement on the item for the cardinal, but as a qualifier on the P39 statement.
    In contrast, if a couple of appropriate properties were created, this information could be recorded on the P971 statement, by giving category combines topics (P971)human (Q5) qualified by property (P2306)=instance of (P31) and category combines topics (P971)cardinal (Q45722) qualified by property (P2306)=position held (P39) and appointed by (P748)Sylvester II (Q172383). (P2306 doesn't quite work like this, one would need to invent a new similar property; but the above is enough to indicate how the scheme would be possible and consistent). Jheald (talk) 22:38, 31 July 2018 (UTC)[reply]
    • @Jheald: There is nothing wrong with slight duplication. For instance in ideal world we don't have to capture in wikidata en:Category:cardinals created by Pope Sylvester II because it is easily calculated using dates of pontificates and dates of consistory that promotes specific cardinal. But having in mind complexity of corresponding SPARQL and current limitations of blazegraph, it would make sense to store it somewhere. And I agree that P4224 has limitations, but a) P4224 has very expressive syntax, intuitively captured by viewer b) unlike P971 it can be utilized in queries in a very consistent way c) we are far away from seriously hitting limitations of P4224 (<5% of potential usage). I think we should continue populating all appropriate properties for categories in a consistent way, ignoring information duplication. --Ghuron (talk) 09:31, 1 August 2018 (UTC)[reply]

Hi all! I write again to try to solve the problem of template categories: my proposal is

	instance of (P31)	category combines topics (P971) + category contains (P4224)
General purposes	Wikimedia templates category (Q23894233)	Wikimedia template (Q11266439)
Navboxes	Wikimedia templates category (Q23894233)	Wikimedia navigational template (Q11753321)
Infoboxes	Wikimedia templates category (Q23894233)	Wikimedia infobox template (Q19887878)
Userboxes	Wikimedia templates category (Q23894233)	Wikimedia userbox template (Q20769160)
Babel	Wikimedia templates category (Q23894233)	Wikimedia user language template (Q19842659)

And, in my opinion, Wikimedia navboxes category (Q13331174) and Wikimedia infobox templates category (Q23894246) should be deleted. Here you can see how many times they are used. What's your opinion? --Epìdosis 08:30, 25 August 2018 (UTC)[reply]

You are right that Wikimedia navboxes category (Q13331174) & Wikimedia infobox templates category (Q23894246) seems to be redundant. But they do preserve category classes in parallel with category contains (P4224) & category combines topics (P971) and were created and is used for now in template uk:Шаблон:Категорія шаблонів to classify template categories by "pseudo category-namespaces". And, besides, they can be used to simply descriptions that differs and more exact from overused description "Wikimedia category".--Avatar6 (talk) 06:41, 28 August 2018 (UTC)[reply]

Hi all! How would you describe a Wikidata property usage tracking category (Q24514938)? At the moment two different systems are used:

1. instance of (P31)Wikimedia administration category (Q15647814) + category combines topics (P971)Wikidata property usage tracking category (Q24514938) (around 2700 cases)
2. instance of (P31)Wikidata property usage tracking category (Q24514938) (around 50 cases)

I'm not sure about which is the best: what's your opinion? --Epìdosis 08:40, 25 August 2018 (UTC)[reply]

As for me 2nd way is simpler and more exact. Sole P31 is always better i think. P971 should contain pid and case of tracking (same as WD, differs from WD, noWD...).--Avatar6 (talk) 06:48, 28 August 2018 (UTC)[reply]

In the second case category combines topics (P971)value from Wikidata (Q40218570) (and the other 3 similar) should migrate to category contains (P4224)value from Wikidata (Q40218570) and category combines topics (P971)Wikidata property usage tracking category (Q24514938) should obviously be removed, is it correct @Avatar6, Jura1:? --Epìdosis 09:49, 31 August 2018 (UTC)[reply]

I support this change, as it makes things easier:

• instance of (P31): Wikidata property usage tracking category (Q24514938) (and no other P31 claims)
• category combines topics (P971): item for "value same as/different/not in/used from Wikidata" moved to category contains (P4224) with same value as before
• category combines topics (P971): Wikidata property usage tracking category (Q24514938) removed

—MisterSynergy (talk) 19:51, 31 August 2018 (UTC)[reply]

Thank you. If there is no opposition, I will do it on the 7th of September. --Epìdosis 09:46, 1 September 2018 (UTC)[reply]

• I don't really care what you do with P4224, but it seems that the proposal doesn't meet the English description of the property: "category contains elements that are instances of this item". As for P971, please don't remove the value from there.
  --- Jura 10:14, 1 September 2018 (UTC)[reply]

@Avatar6, MisterSynergy, Jura1: So which combination of properties do you prefer?

1. instance of (P31)Wikimedia administration category (Q15647814) + category combines topics (P971)Wikidata property usage tracking category (Q24514938) + category combines topics (P971)="value same as/different/not in/used from Wikidata" OK (e.g. Category:Pages using Wikidata property P345 (Q26997818))
2. instance of (P31)Wikidata property usage tracking category (Q24514938) + category contains (P4224)="value same as/different/not in/used from Wikidata"

At the moment all the items use option 1. --Epìdosis 15:56, 21 April 2019 (UTC)[reply]

I still go with my comment from 31 August. Jura has a point, but as long as P4224 does not formally constrain its values with a constraint, I think it is okay to use it with "value same as/different/not in/used from Wikidata". —MisterSynergy (talk) 16:29, 21 April 2019 (UTC)[reply]

For serial categories by date it realy helps. Pls see the idea at Category:Populated places established in 2018 (Q48328925), Category:Populated places established in 2017 (Q28605372), Category:Populated places established in 2016 (Q24089347), Category:Populated places established in the 2010s (Q7476468).--Avatar6 (talk) 06:16, 28 August 2018 (UTC)[reply]

@Avatar6: The use of subclass of (P279) for category items is deprecated, so it should be removed; regarding the other statements in the items, I support them. --Epìdosis 10:23, 28 August 2018 (UTC)[reply]

Removing is as simple and quick as adding do not. Any replacement? The use of catalog (P972) for same porpuses is also prohibited as I see. So how we can seek e. g. decade category for year category ? or (meta)categories fo geo-regular ones?--Avatar6 (talk) 10:54, 28 August 2018 (UTC)[reply]

• I think the P971 statements aren't optimal. Something like "settlement", "by inception", "2018" would be preferable.
  --- Jura 10:30, 28 August 2018 (UTC)[reply]

  Why "settlement" if named "populated places" which is in P4224? "by inception" - is a METAcategory criterium, but this ones are not a metacategories.--Avatar6 (talk)

  • yes, "inception" is actually better, but "populated places" can be in there. P4224 is unrelated. I don't see why "calendar" would be there though.
    --- Jura 07:39, 30 August 2018 (UTC)[reply]

We have discussion with Avatar6 regarding possibility of using P4224:Q5 for categories like Category:Spanish people by occupation (Q7088137). My understanding is that P4224 is intended to specify types of element, that are normally included into that category. Categories like Category:Spanish people by occupation (Q7088137) are not intended to contain anything but subcategories by definition. My opponent believes that we can specify here P4224:Q5 because "P4224 means that category or its subcategories contains statement:P4224 or its subclases". What do you think? --Ghuron (talk) 04:43, 30 September 2018 (UTC)[reply]

@Ghuron: He's right, you're wrong.

But we should maybe come up with some way to indicate that a category is normally completely diffused. Jheald (talk) 08:23, 30 September 2018 (UTC)[reply]

As Jheald. --Epìdosis 10:42, 30 September 2018 (UTC)[reply]

@Jheald, Epìdosis: I would certainly accept consensus here, in fact his approach would technically be easier for me, but I'd like the get some clarifications. Transitivity of categories is not #1 priority in local wikis, I'm frequently encountering cases like en:Category:Soprano Arias is included in en:Category:Sopranos. Having said that and considering that any wikidata item for category can have its own P4224 statement, why exactly we need transitivity of P4224? --Ghuron (talk) 06:40, 1 October 2018 (UTC)[reply]

@Ghuron: Sorry that I was blunt above, you do deserve a bit better & explanation. For me there are a few issues here. First, if we think how these are going to appear e.g. in a Commons infobox, giving a useful breakdown of the title of the category into distinct atomic elements that may be translated into the readers own language, it's useful for that breakdown to give a complete statement of what the category stands for, and it's useful to go to the level of distinct atomic concepts. Second, if we think of a new file being trickled down the category hierarchy until it finds the category where it belongs, it's useful to indicate at each level the specification for the category and its subcategories, to test the file against. Thirdly, if we're researching how inheritance works (and doesn't) going down the category hierarchy, that's easier with a full spec of what the category represents.

Category meanings aren't transitive -- or at least, not as straightforwardly as subclass of (P279). You tend to find you get a series of sequential refinements, but then you get to a 'knuckle' where the structure radiates off into all sorts of different directions. This is because a category tries to capture things related to X, rather than just subdivisions of X. But the test of whether a file (or article) being categorised should continue to trickle down through and beyond this category is a good one, I think, when considering what ought to go in to a category contains (P4224) specification. Jheald (talk) 09:01, 1 October 2018 (UTC)[reply]

When I'm looking on infobox of commons:Category:People of Spain by occupation, P971 provides much more "useful breakdown of the title of the category" than just P4224:Q5. I'm not sure I fully understand how this file categorization thing really works, but there is nothing that makes my life more difficult, so I'm ok with either decision here. I guess if we will not hear any objections, we can consider this as a consensus --Ghuron (talk) 08:58, 2 October 2018 (UTC)[reply]

When wikipedia infobox displays some data from wikidata, it is natural to add some categories based on that data. For instance, if someone's place of birth (P19)Naples (Q2634), infobox can automatically add this article to Category:Births in Naples (Q6587112). There is no performance-efficient way to look for item that has both category combines topics (P971)Naples (Q2634) and category combines topics (P971)place of birth (Q1322263), so it was decided to create a property category for people born here (P1464). We also have P1200, P1465, P1740, P1791, P1792, P2033, P2517, P3876, P4195, P5996, P6112, P6186 and may be some more. It is clear that this approach does not scale very well, in order to add support for categories like Category:EMI Records albums (Q6571286), I will have ask for another property.

May be it would make sense to ask for "generic" property like "Corresponding category" and specify "type" via of (P642) qualifier? For instance in example above there will be corresponding category (Pxxx)  Category:Births in Naples (Q6587112) with qualifier of (P642)place of birth (Q1322263). @Jura1, Ivan A. Krestinin, Чаховіч Уладзіслаў, ԱշոտՏՆՂ, ChristianKl, Сидик_из_ПТУ: what do you thing? --Ghuron (talk) 08:19, 6 December 2018 (UTC)[reply]

Sounds logical, but I would like to know why this approach was not chosen initially. Is category for the water basin (P1200) chronologically the first property of this type? Are the statements from the discussion about this relevant now?Сидик из ПТУ (talk) 08:33, 6 December 2018 (UTC)[reply]

@Сидик из ПТУ: Technically the first one can be considered topic's main category (P910), I've seen that User:ChristianKl was proposing this approach here --Ghuron (talk) 09:18, 6 December 2018 (UTC)[reply]

• I think Ghuron makes excellent use of categories, but I'm not really convinced we should generalize support for categories beyond statements on categories themselves. Furthermore, I don't see an advantage of property+qualifier compared to property only. --- Jura 08:10, 8 December 2018 (UTC)[reply]

  @Jura1: thank you, I really appreciate your thoughts :) There are two reasons regarding property+qualifier vs property question. First, it would makes identification and usage of new "category class" easy. Let's take category for members of a team (P6112) as an example. If I want to be able to automatically categorise people based on the team they belongs to I should:

  1. Create a property proposal and wait when one will be approved
  2. Load some data that uses that property (mostly based on category combines topics (P971) values in categories)
  3. Make necessary corrections in local wikipedia (can be as simple as this)

  I'm proposing to replace first step with something like "Create an instance of appropriate metaclass like sportsperson who competes in this club (Q58840094)". That should makes our life easier.

  Another reason is derived from the fact all of properties outlines above have their "normal" counterpart like P1464->P19, P3876->P69, P2517->P166, etc. Not all of properties of wikibase-item type are going to have "categories" counterpart (e.g. for spouse (P26) it is unlikely), but some of them are going to have multiple (see my first 2 examples for here for producer (P162)). Having in mind that right now we have 1200+ properties of wikibase-item type, we are talking about hundreds of properties that does not make much sense outside of wikimedia projects. --Ghuron (talk) 16:50, 8 December 2018 (UTC)[reply]

Please see Property talk:P6186#The object is not "eponymous" if you are interested --Horcrux (talk) 16:30, 9 December 2018 (UTC)[reply]

Are we sure that Wikimedia meta category (Q30432511) are just caegories "that are intended to include other categories only" (i.e. a container category)? I'm asking this because, according to c:Commons:Meta category, a metacategory is a "category by criterion" (e.g. "Drawings by artist"), that is a specific type of container category.

If the correct meaning is the first one, I guess this edit should be rollbacked. Otherwise, this constraint and maybe others are wrong. --Horcrux (talk) 16:44, 9 December 2018 (UTC)[reply]

In my opinion Wikimedia meta category (Q30432511) is a "category by criterion" and items with category for eponymous categories (P6186) should have not Wikimedia meta category (Q30432511) as instance of (P31) value, but a new "container of eponymous categories" instead. --Epìdosis 09:06, 10 December 2018 (UTC)[reply]

I believe I agree with Epìdosis's characterization of Wikimedia meta category (Q30432511). The most common (and I believe correct) usage for Wikimedia meta category (Q30432511) is to specify which property is being used to diffuse/slice their parent category. For example in the chain Category:Writers (Q5849863) --> Category:Writers by genre (Q6855547) --> Category:Humorists (Q8527577) links two Wikimedia category (Q59542487)s and specifies that a 'genre' should be used for every descendant the metacategory.

As an aside I believe the current system of using category combines topics (P971) to hold meta category criterion (Q24571886)s makes it hard to make use of otherwise structured data. I think this could be made more flexible and more structured by adding a property along the lines of "metacategory diffused by propery X". Some tricky examples that would be solved by this:

• "by year" (is it publication date (P577), date of birth (P569), etc.)
• Category:Paintings by artist (Q6361568) diffuses by performer (P175) while Category:Albums by artist (Q7103475) diffuses by creator (P170)

- ElanHR (talk) 05:29, 29 January 2019 (UTC)[reply]

@ElanHR: Hi! Thank you very much for your opinion! I agree with you about needing a new property to specify the criterion of a Wikimedia meta category (Q30432511). Only a question: if Category:Wikipedia categories named after churches (Q8980959) is not a Wikimedia meta category (Q30432511), how would you manage it? Maybe we need a new "container of eponymous categories" item to be used as instance of (P31)? --Epìdosis 07:34, 29 January 2019 (UTC)[reply]

@Epìdosis: Apologies for the delay! I thought had responded but apparently never hit publish. :P

That's good question! I think on one level "eponymous categories named after <class of things>" can be considered a Wikimedia meta category (Q30432511). I guess my concern is that the "named after type of X" can be tricky to model and is sometimes language-specific. I like your idea of having a "container of eponymous categories" as it is straightforward and has very clear semantics for people interested in this property. As a bit of an aside, often I've found that membership in a "container of eponymous categories" is often a good signal that it is a Wikimedia topic category (Q59541917) and am planning to publish a dataset based on this for community review once I have a good measure of precision. - ElanHR (talk) 09:29, 5 March 2019 (UTC)[reply]

Notified participants of WikiProject Categories Hello, I am at the moment fighting with categories associated with the alumni of some French schools. Some of these schools have been replaced or grouped. On the French wp, there is one category pro school, in particular when two of them have been grouped, there is a category for the two schools before the grouping and one category for the alumni of the new school after the grouping. In some other languages (eg : en), there is only one category grouping the alumni of any of them (before and after the grouping). Accordingly, there are wikidata elements for the alumni of each school (associated to the pages of the categories on the French wp) and a unique wikidata element for the alumni of all of them (associated to the page of the category on other wp). So far, so good. But then I need to add the property P3876 to the wikidata elements for the schools ("category for the persons who have studied there") and of course, for each school, I have several possible categories (the one strictly associated to it, and the one which groups the alumni of several schools). And WD protests, because P3876 should be associated to one value only...See for instance an example at Q3578285. I suppose it happens all the time (as the categories are not exactly the same in all languages), but I could not find an answer. Thank you in advance.

@Cgolds: First of all, it is definitely not ok to specify multiple qualifiers for category contains (P4224)human (Q5) so I've temporary removed all of them for École normale supérieure de Fontenay-aux-Roses (Q3578285). I'm not sure I understand all struggles regarding this category, but the idea is that each item should sitelinks for categories that has exactly the same inclusion criteria. Error happens, but I don't think it is "all the time". The idea behind category for alumni of educational institution (P3876) is that it should points to the most specific category not "the one which groups the alumni of several schools" --Ghuron (talk) 22:28, 1 June 2019 (UTC)[reply]

@Ghuron: Hello, thank you very much for this quick answer and correction, sorry I did something wrong with the qualifier. My point about "all the time" was not about errors (?), but about the fact that categories being differently delimited in different languages of the Wp world, the one-to-one association is often not strictly possible. Here there is the fact that "category for the persons who have studied there" does not precise when (the names and the grouping changed over time). But Ok for the answer, I shall correct and put only to the more specific category. Thank you again, --Cgolds (talk) 06:11, 2 June 2019 (UTC)[reply]