Wikidata:Property proposal/category contains

category contains

Originally proposed at Wikidata:Property proposal/Generic

Done: category contains (P4224) (Talk and documentation)

Data type	Item
Template parameter	in SPARQL form, on Commons c:Template:Category contains (experimental)
Domain	category items
Allowed values	class items
Example	Category:Grade I listed buildings in Bedfordshire (Q8497784) → building (Q41176), with qualifiers * located in the administrative territorial entity (P131) → Bedfordshire (Q23143), * heritage designation (P1435) → Grade I listed building (Q15700818)
Robot and gadget jobs	Move existing statements on category items using is a list of (P360) to use this property instead
See also	is a list of (P360), category's main topic (P301), category combines topics (P971)

Motivation

We currently have 12,434 items that are categories using is a list of (P360) for this purpose (tinyurl.com/hftsk55), using this format. This has been approved in an RFC, however before that close the question seemed to create a lot of dispute at Property talk:P360.

This kind of specification allows software like Reasonator to generate automatic lists of items with properties that appear to meet the criteria, which can then be compared with the current content of the actual list or category -- see for example the list offered by Reasonator on its page [1] for the list article Grade I listed buildings in Bedfordshire (Q5591762).

Coming back to this debate a year on, it seems to me it would be useful to separate the two into two parallel properties -- P360 specifically for lists, and this property specifically for categories. This would then mean that all uses of P360 would be for lists, all uses of the new property would be for categories. This would avoid the 'bad smell' of using a property called "is a list of" on categories, which definitely shouldn't be confused with lists; and it could help query performance, since excluding lists or excluding categories can be costly. Jheald (talk) 17:02, 11 February 2017 (UTC)[reply]

Discussion

Support so I assume you would transition all the P360's on categories to this new property? I think it's fine to be more specific like this, so I support it. ArthurPSmith (talk) 18:30, 13 February 2017 (UTC)[reply]
Support per the thorough consideration given above. --Swpb (talk) 16:25, 15 February 2017 (UTC)[reply]
Support. Thank you for proposing this. I agree that this would make creating lists easier and more flexible. YULdigitalpreservation (talk) 14:52, 16 February 2017 (UTC)[reply]
Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 24 February 2017 (UTC)[reply]
@Jheald: The property is currently missing an English description. ChristianKl (talk) 07:19, 25 February 2017 (UTC)[reply]
Oppose category combines topics (P971) should do.
--- Jura 10:31, 25 February 2017 (UTC)[reply]
@Jura1: That property fails to express how the categories are combined. It does not contain sufficient information to automatically be able to write a search query to find corresponding items, in the way is a list of (P360) does, which this property would be modelled on.

See also on Commons, the positive response from User:Astinson (WMF) (diff) to the idea of building information of this kind on Commons, with similar potential for automated searches, as part of preparations towards structured data there. This property would help that a lot, for when there are parallel categories here to Commons categories. Jheald (talk) 18:37, 2 March 2017 (UTC)[reply]

I think it works even better than is a list of (P360). Have a look at the first sample: Q7068416.
--- Jura 20:40, 2 March 2017 (UTC)[reply]

@Jura1: The use of related property (P1659) is interesting, I hadn't seen that before with category combines topics (P971). I'm not sure that "see also" is quite right, perhaps some more specific qualifier eg "object of" might be an idea. But the shape is interesting.

I suppose I am used to is a list of (P360), and there are a number of uses on lists that could be transferred straight over. (And, equally, a number of cases where we have parallel lists and categories, that I can see advantages in treating in the same way, to result in similarly parallel specifications).

Something I like about P360 is that it tells you immediately and clearly what the subject matter is: this is a list of people; this is a list of paintings; etc, that then is specified in more detail with the qualifiers -- which I miss with your design. (Indeed, you don't seem to be specifying P31 Q5 at all -- which is definitely information that it is useful for machine-parsing the category).

But I am interested -- what do you see as the advantages of your model of using P971; and what disadvantages do you see with the similar-to-P360 approach? Jheald (talk) 21:29, 2 March 2017 (UTC)[reply]

You are right, the sample could include Q5 as well. I did suggest a more specific qualifier, but people weren't interested or preferred P1659. As the result on my application is the same, it doesn't matter much:

It works for links on Wikidata:Database reports/items without claims categories/eswiki allowing to add statements to items lacking them.
--- Jura 21:35, 2 March 2017 (UTC)[reply]

@Jura1: But what do you see as particular advantages or disadvantages between the two forms? I've set out above why on balance I like the idea of something a bit more similar to is a list of (P360), which is already widely deployed. But what do you think are reasons to prefer or not prefer one over the other? Jheald (talk) 21:47, 2 March 2017 (UTC)[reply]

P971 is closer to Wikidata's incremental way of building things. It allows to specify parts that may not be included in statements to be added. I use less P360 as I think it relies too much on qualifiers. I don't see much of a problem converting the few uses of P360 on categories to category combines topics (P971).
--- Jura 21:57, 2 March 2017 (UTC)[reply]

@Jura1:, for me, your example of Category:Dutch politicians (Q7068416) is distinctly different than this proposal. It claims that Category:Dutch politicians (Q7068416) -> category combines topics (P971) -> Kingdom of the Netherlands (Q29999) and politician (Q82955). But neither of those are sub-categories or topics under Category:Dutch politicians (Q7068416), which is the point of this proposal as I understand it, and so category combines topics (P971) isn't really valid to use for the purpose proposed here. Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)[reply]

I think both can be used to build the same query. P971 just offers more flexibility. The exception may be sample you mention below.
--- Jura 03:42, 2 May 2017 (UTC)[reply]

Support after reading the above discussion I'm more convinced by Jheald's reasonings in support of this method than Jura1's alternatie. Thryduulf ( talk) 08:35, 12 April 2017 (UTC)[reply]
Question Category:Aircraft by registration (Q29642098) has more than 70,000 sub-categories. Would each of these (that have a WD item anyway) have its own claim under Category:Aircraft by registration (Q29642098)? Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)[reply]
@Jheald: I don’t really get the point. We already know from the item type if it’s a list or a category, so there is no need for two properties. I don’t really understand the « excluding list or categories » need as it’s enough to just select lists ( instance of wikimedia list article ) or categories or both and it’s just routine not costly sparql. No need to exclude anything. Did I miss anything ? author TomT0m / talk page 11:36, 20 May 2017 (UTC)[reply]
@Jheald: Can you add a description for this property? ChristianKl (talk) 11:05, 22 May 2017 (UTC)[reply]

@Jheald, ArthurPSmith, Swpb, YULdigitalpreservation, Pigsonthewing: @ChristianKl, Joshbaumgartner, Jura1, TomT0m: Done After reading the conversation, it seems like a useful addition to fill the gaps of category combines topics (P971).--Micru (talk) 13:29, 15 September 2017 (UTC)[reply]