This property was nominated for deletion for several times, where all results of them were keep. Please check discussions before next nominating:

Documentation

Commons category
name of the Wikimedia Commons category containing files related to this item (without the prefix "Category:")

Represents

Commons category (Q24574745)

Data type

String

Corresponding template

Template:Commons category (Q48029)

Template parameter

commons or commonscat in dozens of templates in many languages, such as nl:Sjabloon:Taxobox

Domain

No restriction (note: this should be moved to the property statements)

Allowed values

According to this template: Only existing Commons categories are allowed. The name is without the "Category:" prefix

According to statements in the property:
[^{}\[\]<>]+

When possible, data should only be stored as statements

Usage notes

입력할 때 분류명 앞에 붙는 "Category:"는 빼고 쓰세요.

Example

Calosoma reticulatum (Q569101) → Calosoma reticulatum
Gorilla (Q36611) → Gorilla
Bangladesh Armed Forces (Q790022) → Bangladesh Armed Forces
Barack Obama (Q76) → Barack Obama

Formatter URL

https://commons.wikimedia.org/wiki/Category:$1

Robot and gadget jobs

Bots should be collecting this based on current template usage. If a category at Commons gets deleted and/or renamed, Wikidata should be updated. The commonscat.py Pywikipedia script should be updated.

Tracking: same

Category:Commons category with local link same as on Wikidata (Q11925741)

Tracking: differences

Category:Commons category with local link different than on Wikidata (Q11925740)

Tracking: usage

Category:Commons category link is on Wikidata (Q22914718)

Tracking: local yes, WD no

Category:Commons category not in Wikidata, but available on Wikipedia (Q19821559)

Constraints

Commons sitelinks to be copied to P373 property
Items with no P373, but with a category in the Commons sitelink. That category can be saved as P373. (Help)
Violations query:

SELECT ?item ?sitelink WHERE {   ?item ^schema:about [ schema:isPartOf <https://commons.wikimedia.org/>; schema:name ?sitelink ] .    MINUS { ?item wdt:P373 [] } .   MINUS { ?item wdt:P31 wd:Q4167836 } .   MINUS { ?item wdt:P31 wd:Q4167410 } .   FILTER( STRSTARTS( ?sitelink, 'Category:' ) ) . } LIMIT 500

List of this constraint violations: Database reports/Complex constraint violations/P373#Commons sitelinks to be copied to P373 property

Commons sitelinks different from P373 property
Items with sitelinks linking to a different category than the property (Help)
Violations query:

SELECT DISTINCT ?item {   ?item wdt:P373 ?ccat;         ^schema:about [           schema:isPartOf/^wdt:P856 wd:Q565;           schema:name ?name         ] .   FILTER ( STRSTARTS( STR( ?name ), 'Category:' ) ) .   FILTER ( STRAFTER( STR( ?name ), 'Category:' ) != ?ccat ) . } LIMIT 7000

List of this constraint violations: Database reports/Complex constraint violations/P373#Commons sitelinks different from P373 property

Two category items linking to the same Commons category
Generally only one category item should link to a Commons category (Help)
Violations query:

SELECT DISTINCT ?item ?item2 ?value {   ?item wdt:P373 ?value .   ?item wdt:P31 wd:Q4167836 .   ?item2 wdt:P373 ?value .   ?item2 wdt:P31 wd:Q4167836 .   FILTER( ?item != ?item2 && STR( ?item ) < STR( ?item2 ) ) . } LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P373#Two category items linking to the same Commons category

Commons category sitelink does not match P373
P373 should generally be the same as the sitelink (Help)
Violations query:

SELECT ?item ?commonscat ?sitelink ?name WHERE { ?item wdt:P373 ?commonscat. ?sitelink schema:about ?item; schema:isPartOf <https://commons.wikimedia.org/>; schema:name ?name . FILTER( CONTAINS(STR(?sitelink), 'Category:') = true ) . FILTER( ?commonscat != SUBSTR(STR(?name), 10) ) .} LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P373#Commons category sitelink does not match P373

This entity (P373) is used by Wikimedia's setting of Wikidata. Please contact the development team or file a bug on Phabricator before big changes (renaming, deletion, merging, etc.).

Discussion

Context at time of creation

This property is an intermediate step until we have full Commons support. When we get that we can just convert the data. Up until now Commons category links got updated the interwiki way: Decentral with a lot of efforts, see this page for some statistics. By putting this in a central place we are much more efficient and it doesn't really matter anymore what kind of templates some language Wikipedia use to represent the data. Multichill (talk) 20:44, 30 March 2013 (UTC)[reply]

See Wikidata:Wikimedia Commons for next discussions. --ŠJů (talk) 21:52, 25 April 2013 (UTC)[reply]

English property title

Hi. I changed "Commons category" to "Wikimedia Commons category", as I think the former is ambiguous and confusing. My edit was undone in this edit as being "too long". I don't understand. Are there length restrictions or guidelines somewhere? --MZMcBride (talk) 16:34, 6 April 2013 (UTC)[reply]

Dear MZMcBride, names here can be ambiguous, that's why we have a description for this property. This is the standard name used in most Wikipedia's and changing it is confusing. Multichill (talk) 18:30, 9 April 2013 (UTC)[reply]

"Wikimedia Commons" seems to be far more popular as an article title than "Commons", looking at Q565. "Commons" is a regular noun in English. That's where the name "Wikimedia Commons" got its name, of course. It seems kind of silly to now associate "Commons" primarily with a file repository. --MZMcBride (talk) 06:43, 12 April 2013 (UTC)[reply]

Capitalized word Commons is not a regular noun in English, the capitalization is adequate distinguishing. --ŠJů (talk) 15:57, 6 August 2013 (UTC)[reply]

Galleries on Commons

There're a lot of pages in the main namespace on Wikimedia Commons, they are usually galleries and also often contain interwiki. Is there a property for this? If no, I want to create one. Ain92 (talk) 11:27, 12 June 2013 (UTC)[reply]

No, that one hasn't been created yet. Probably has to do with the fact that galleries are much less used than categories on Commons. Commons has 109.210 galleries and 2.727.327 categories. Multichill (talk) 21:45, 13 June 2013 (UTC)[reply]

Proposed at Wikidata:Property proposal/Sister projects#Commons gallery 7 July 2013. --ŠJů (talk) 15:52, 6 August 2013 (UTC)[reply]

Unique value violations

This should ignore duplicates which are in different namespaces (article/category/portal). JAn Dudík (talk) 09:28, 1 August 2013 (UTC)[reply]

Already done, special form {{Constraint:Unique value|separate category processing=yes}} is used. — Ivan A. Krestinin (talk) 20:06, 6 August 2013 (UTC)[reply]

commons:Template:Disambig

A check of disambiguation pages would be fine, because a commons category link should not be disambig.

It is possible to check this in the database by joining the table page_props on pp_page = page_id and look for rows, where pp_propname = 'disambiguation'. Thanks. 84.182.127.111 13:48, 6 August 2013 (UTC)[reply]

This check can be included in the "Existing category" check. Treat a disambig category as missing and add a hint behind it to see it in the database report. That would be enough, no need for a new check. 84.182.125.23 02:25, 13 August 2013 (UTC)[reply]

commons:Category:Category redirects

A check if the linked commonscat is a "category redirect" would be fine. 84.182.125.23 18:35, 12 August 2013 (UTC)[reply]

This check can be included in the "Existing category" check. Treat a category redirect as missing and add a hint behind it to see it in the database report. That would be enough, no need for a new check. 84.182.125.23 02:25, 13 August 2013 (UTC)[reply]

This check is included in the "Existing category" already. — Ivan A. Krestinin (talk) 03:22, 13 August 2013 (UTC)[reply]

Next step

At Wikidata:Property proposal/Generic#Topic main category I proposed a new property that will replace this one over time. Multichill (talk) 19:01, 9 September 2013 (UTC)[reply]

Now that Commons is linked to Wikidata, is it time to get rid of Commons category (P373) entirely? — JFG ^talk 02:30, 31 October 2013 (UTC)[reply]

See Wikidata:Requests for comment/Commons links. — Ivan A. Krestinin (talk) 04:10, 31 October 2013 (UTC)[reply]

No, too early. This is used a lot and no replacement is available yet. Multichill (talk) 20:40, 31 October 2013 (UTC)[reply]

Just a late comments, interwiki links are for galleries therefore this property is still essential. John F. Lewis (talk) 20:26, 30 January 2014 (UTC)[reply]

Galleries are rare on Commons and most of them look abandoned and out of date. Interwiki link to Commons is enough for me (and it doesn't really matter if it a category or gallery (since they both linked to each other). -- Alexander Vasenin (talk) 22:01, 30 May 2014 (UTC)[reply]

Hindi constraint violation

When I tried to revert some vandalism in the English label, I received an error about Hindi label constraint violation, so I trimmed the Hindi label, and then could fix the vandalism. John Vandenberg (talk) 09:16, 2 December 2013 (UTC)[reply]

Thanks for fixing this. I repeatedly reported this bug on Wikidata:Contact the development team, but unfortunately the development team does not consider it as bug ?! Mostly there is problem with label in some "exotic" language (like Hindi), that nobody dares to fix, so really thanks. --Jklamo (talk) 11:10, 2 December 2013 (UTC)[reply]

Thanks! I see Wikidata:Contact_the_development_team/Archive/2013/10#Undo_error and Wikidata:Contact_the_development_team/Archive/2013/09#Undo_error. They dont provide a very technical answer :/ All invalid values should be listed so we can fix them early. John Vandenberg (talk) 13:30, 2 December 2013 (UTC)[reply]

Nominated for deletion

Idiotic to nominate something and not leave a message here. See Wikidata:Properties_for_deletion#Commons_category_.28P373.29. Multichill (talk) 22:20, 10 March 2014 (UTC)[reply]

Kept! -- Lavallen (talk) 12:17, 14 March 2014 (UTC)[reply]

See deletion discussion. - LaddΩ chat ;) 18:56, 17 April 2014 (UTC)[reply]

Nominated with reasoning that information is duplicated: Wikidata:Properties_for_deletion#Commons_category_.28P373.29 Tamawashi (talk) 05:31, 27 June 2014 (UTC)[reply]

WD:PP

I have proposed a replacement of this property at Wikidata:Property proposal/Sister projects. -- Lavallen (talk) 18:45, 17 March 2014 (UTC)[reply]

Shouldn't be allowed on Category items

In my opinion, this property shouldn't not be allowed on items which are instance of (P31) Wikimedia category (Q4167836) or any subclass of (P279) it, since those should just use the ordinary interwiki links.

Unfortunately there don't seem to be any appropriate constraint templates. —SamB (talk) 00:10, 25 March 2014 (UTC)[reply]

You're entitled to have you own opinion, but please don't remove these claims because these are in use in several Wikipedias. Multichill (talk) 07:33, 25 March 2014 (UTC)[reply]

Well, they should at least have matching values then. —SamB (talk) 00:16, 26 March 2014 (UTC)[reply]

People are working on that, see Wikidata:Commons category tracking. Feel free to help! Multichill (talk) 08:59, 27 March 2014 (UTC)[reply]

constraint report relating to Wikimedia disambiguation page (Q4167410)

If instance of (P31) is a Wikimedia disambiguation page (Q4167410) the presence of Commons category (P373) is prohibited

see: Wikimedia disambiguation page (Q4167410) with Commons category (P373) . Usualy there might be more possibilities:

a) Please identify the non - ambiguation page (WD item) where the property Commons category should be moved;
"normally" no other statements should be left at the disambiguation page.
It can happen that a set of properties should be moved to another (a second) WD item, another set to a third WD item etc.

b) (recomended method:) Verify which language is a disambiguation page and separate it from the rest. Please use Gadget-labelLister.js ^{can be activated at preferences#gadgets} to remove all faulty (disambiguation) descriptions after the disambiguation page is separated: Verify the descriptions for the following languages: de, en, fr, es, pt, pt-br, ru, sv which where added by bots long time ago and take a short look at the other language descriptions.

c) If method b) can not be used because all linked WMF-project language pages are (local) disambiguation pages please create a new WD item and add a proper description in your native language and in English.

Thanks in advance! gangLeri לערי ריינהארט (talk) 19:53, 4 June 2014 (UTC)[reply]

There are still 979 items found by the query. לערי ריינהארט (talk) 06:00, 23 July 2014 (UTC)[reply]

Hi לערי ריינהארט, what about Wikimedia Commons categories that are disambiguation page ? Cdlt, VIGNERON (talk) 09:00, 19 October 2014 (UTC)[reply]

About external links

When this property is used in item, why do some have external links to the commons category (e.g. carbon) while others have not (e.g. Africa)? --Neo-Jay (talk) 15:51, 31 July 2014 (UTC)[reply]

It's not a difference in the data; it's a bug in the Wikidata interface that automatically generates external links as a convenience for various properties. The first time you load a Wikidata item page, the properties' values show up as external links; the next time you load a Wikidata item page (regardless of whether it's the same or different page), the links have vanished from the values. At least that's how it's always happened for me. I just did it with carbon (Q623) as you mentioned: The first time I loaded, I got a link; then I refreshed, and the link disappeared. I haven't figured out how long I have to wait or what I have to for the bug to "reset" and show me the links the first time again. --Closeapple (talk) 23:12, 31 July 2014 (UTC)[reply]

I see. Many thanks for your explanation. --Neo-Jay (talk) 05:36, 1 August 2014 (UTC)[reply]

in may opinion the property Commons category (P373) should only be used on Wikidata elements for topics and must be used on Wikidata elements created for Wikimedia categories.

On Wikidata elements for topics:

the property P373 must be set to the pagename of the category (without its "Category:" namespace prefix) on Commons where files about this topic are stored;
the external links must be pointing only to articles on those wikis about this topic, not to categories on those wikis;

On Wikidata elements for Wikimedia categories:

the property P373 must not be used at all (a Wikimedia category is not a valid topic for which Commmons will host any files);
the external links must be pointing only to equivalent categories on those wikis (including Commons, Wikipedia, Wikivoyage, Wikinews, Wikisource, Wikispecies, and maybe later Wiktionary with a #anchor to a language or lemma section...). Verdy p (talk) 02:21, 4 April 2016 (UTC)[reply]

P373 "no value"

Hello! Regarding these constraint violations, would it be possible to have the list of items that use the property 373 with a blank value? --Horcrux92 (talk) 09:41, 1 May 2015 (UTC)[reply]

It is possible. but please note, novalue is valid value for this property. It needs to distinct cases "Commons category presence is unknown" and "Commons does not have category for this item". Also novalue is used to avoid invalid values reimport by bots. — Ivan A. Krestinin (talk) 09:51, 1 May 2015 (UTC)[reply]
~~Oh, I didn't know that. So I think I won't need that list anymore. --Horcrux92 (talk) 10:03, 1 May 2015 (UTC)~~[reply]

@Ivan A. Krestinin: Forget it, it would still be useful (at least for me). --Horcrux92 (talk) 10:15, 1 May 2015 (UTC)[reply]
The simplest way is new constraint: {{Constraint:Format|pattern=.+}}. — Ivan A. Krestinin (talk) 10:19, 1 May 2015 (UTC)[reply]
Yes. Can you handle it? --Horcrux92 (talk) 10:52, 1 May 2015 (UTC)[reply]
Added, this action does not require any special permissions. — Ivan A. Krestinin (talk) 11:42, 1 May 2015 (UTC)[reply]
Sure, I just didn't know where to do it. Thank you so much, --Horcrux92 (talk) 13:34, 1 May 2015 (UTC)[reply]

Commons category on Wikimedia category item

Wikidata:Requests for comment/Commons category on Wikimedia category item. FreightXPress (talk) 19:49, 13 May 2015 (UTC)[reply]

Why not linked?

Why value of this property is not clickable (as link)? IMHO it's necessary to make it clickable and property will be more useful (especially for humans, not only for bots and tools). --XXN, 15:43, 6 February 2016 (UTC)[reply]

It is clickable. Try to reload the page. --Jklamo (talk) 16:04, 6 February 2016 (UTC)[reply]

For example in Q3939372 I see Commons category (P373)Rocar De Simon U412 and value "Rocar De Simon U412" is not clickable for me. Only for me? --XXN, 16:27, 6 February 2016 (UTC)[reply]

Works for me, though not always. Be patient, linking it will soon become part of the software. Matěj Suchánek (talk) 16:33, 6 February 2016 (UTC)[reply]

Most of the time it does not work. Sometimes there's a link. I wonder if this happens only on specific instances of hosts deployed (for tests) to serve Wikidata. Verdy p (talk) 02:06, 4 April 2016 (UTC)[reply]

Tested logged out - works; logged in - does not work (never). Probably some gadget or user script is conflicting with it. --XXN, 14:26, 3 December 2016 (UTC)[reply]

Thanks to Ladsgroup, I've found the cause of this problem in my case: the gadget "Authority control" was disabled for me and that's why for me the values of P935 and P373 were unlinked. --XXN, 11:17, 18 April 2017 (UTC)[reply]

Links never work for me and a gadget "Authority control" is not available on Special:Gadgets. Any advice? --MB-one (talk) 14:27, 11 March 2018 (UTC)[reply]

The issue is that P373 is a string" property and wikidata does not know it is a link to a page. The issue with "Authority control" was reported in phabricator:T177698 and I proposed phabricator:T179937 to create new property type for linking to pages on Commons. As long as this property remains a string I have little hope that problems with display as string not a link or linking to non-pages will be solved --Jarekt (talk) 02:52, 12 March 2018 (UTC)[reply]

Conflicts with constraint

In this edit the conflicts with Wikimedia disambiguation page (Q4167410) constraint was removed with comment "Commons category can be a disambiguation page, e. g. Category:Congo". I restored the constraint because I don't agree. The description of this property is "name of the Wikimedia Commons category containing files related to this item". A disambiguation category on Commons, like Commons:Category:Congo, should never contain files so Category:Congo (Q7283569) shouldn't have Commons category (P373) at all. Multichill (talk) 19:26, 10 March 2016 (UTC)[reply]

I agree with you. Sjoerd de Bruin (talk) 10:26, 11 March 2016 (UTC)[reply]

I don't agree with you if the topic in Wikidata is also a Wikimedia category page for the same ambiguous topic.

But may be you only disallow this property on the Wikidata element, but not the link to other sites (including Commons).

It's true that Commons:Category:Congo does not contain any files (or any subcategories, or any pages i.e. articles/galeries/users/templates/modules/discussions...), it just shows static text (and static links to other relevant categories) in its description page.

But this should de documented somewhere, and this message can make it clear for others:

to solve this conflict, remove the property but keep its value, in order to put it in the link to other sites by adding there an entry for Commons. Verdy p (talk) 01:59, 4 April 2016 (UTC)[reply]

Property values starting by the "commons:" interwiki prefix

This property should have its value starting by the "commons:" or "c:" interwiki prefix (case insensitive). But Commons still has a local "project" namespace named "Commons:" (first letter is case insensitive), so a wikilink to it from Wikidata would be "commons:Commons:..." or "c:Commons".

A classic error is to include the "commons:" (or "c:") interwiki prefix in the value. We can easily detect "c:" because it is not a valid namespace on Commons and cannot be leading any article name (it is always interpreted as an interwiki prefix, on Commons and on Wikidata). But can we have in Wikidata a link to a page in the "Commons:" namespace in Commons ? If so, the value "Commons:Help" is valid for this property.

Otherwise, "Commons:Help" is invalid as it could mean the page "Help" in the main namespace of Commons (for which the Wikidata property should only be "Help").

This property is also more precise as it should be a category name on Commons, so the actual full wikilink (with the interwiki prefix) is "commons:Category:..." or "c:Category:...". Under this form, it is possible to have Commons category names whose title starts also by "C:" or "Commons:" (Commons categories may be named with a title starting by "Category:", such as "c:Category:Category:..." but these are frequent creation errors on Commons that should be detected, so they should not exist at all on commons, so we should not have any "Commons category property" in Wikidata starting by "Commons:"

But it's possible to have categories in commons whose title starts by "C:" such as "c:Category:C:..." and made for relevant topics. In Wikidata the "Commons category property" will then be set to "C:..."

So could we add a constraint here that invalidates values starting by "[Cc]ommon :" (first-letter is case-insensitive) which are always errors, or by "[Cc]:" (case insensitive too) which are almost always errors (except for a few known topics about "C:" games (those known cases could be listed as exceptions if ever such category is created ; for now there's no such category in Commons, and it's also not possible to create any page in its main namespace for that topic with a title starting by "C:", except by changing the colon into something else such as an ideographic wide variant) ?

Can we create a value contraint with a regexp that the value must not match ? Here the regexp should be:

^[Cc](ommons)?:

-- Verdy p (talk) 01:59, 4 April 2016 (UTC)[reply]

Of course we can, for example by extending the current one to {{Constraint:Format|pattern=(?![Cc](ommons)?:).+}}. Matěj Suchánek (talk) 13:33, 4 April 2016 (UTC)[reply]

automated creation/ update

what is the state about automated updates / creations of this property by bot? I've created some scripts /templates on de.WP that depend on this property (categorisation proposals) and it is tedious to update / create it manually. Any information welcome. Also if there is a better place to initiate this. regards --Herzi Pinki (talk) 15:13, 18 April 2016 (UTC)[reply]

Cleaning up Unique_value constraint violations

Unique_value constraint violations report contains 209,672 item pairs where P373 point to the same category on Commons. It seems to me that the main reason is the article/category item pairs. If there is such a pair of items with properly set category's main topic (P301) and topic's main category (P910), than only article item should have P373 property. I wrote this query to find such pairs. I believe that for all category items returned from it we could remove P373 and I was planning to use use Auto List tool to do it. Any objections? Also I am new to SPARQL and if anybody knows how to speed up my query I would appreciate any hints, as it often times out. --Jarekt (talk) 13:35, 3 November 2016 (UTC)[reply]

I think the constraint report used to skip that. Maybe @Ivan A. Krestinin: needs to fix it.
--- Jura 13:47, 3 November 2016 (UTC)[reply]

So your advice would be relax the constraint and adjust the reporting query to allow this case instead of fixing the data? I like the idea of uniqueness as it might simplify reverse lookup if it ever is possible in the future, as discussed in phabricator:T99899 --Jarekt (talk) 17:14, 3 November 2016 (UTC)[reply]

I prefer also the uniqueness. Linking between a category item and a commons category can also be done with sitelinks and doesn't need P373. --Pasleim (talk) 19:54, 7 November 2016 (UTC)[reply]

I believe this query is returning category items with P373 and a sitelink to the same Commons category. Those category items also have properly linked "twin" article items with P373 to the same category. I think we should remove P373 from those items. There should be 173,135 of them. --Jarekt (talk) 15:43, 8 November 2016 (UTC)[reply]

@Multichill: your bot adds many of P373s. How do you feel about removing them once they become redundant and violate Unique_value constraint? --Jarekt (talk) 14:40, 9 November 2016 (UTC)[reply]

Hold on. Before you start doing any mass edits, please model how it should look in the different cases. Current situation:

So here you would remove Commons category (P373) from Category:Haarlem (Q7427769) (example)? I'm not against that, the two items are linked with category's main topic (P301) and topic's main category (P910), but some local templates have to be updated before you would do this otherwise you'll flood Category:Uses of Wikidata Infobox missing Commons Category statement (Q11925744).

We did most of the Commons category (P373) work before we had arbitrary access. Now that we have it, we should probably update some local templates and clean up data here. Anyone good with lua? ;-) Multichill (talk) 18:22, 9 November 2016 (UTC)[reply]

I do not want to break anything, so that is why I am discussing it here. For 173k items we have 3 different places we store the same link to Commons category: Article item P373, Category item P373 and category item sitelink. Two of those P373 violate uniqueness constraint and are not necessary. Two copies are enough and it should reduce maintenance as we would not need to verify that all 3 are the same. I do a lot of work with lua. What do you have in mind? For example with c:Module:Wikidata q-code's articleId function I can look up article item q-codes from any category following category's main topic (P301). I just looked up Category:Uses of Wikidata Infobox missing Commons Category statement (Q11925744) and en:Template:Commons category. The template can be easily rewritten to follow category's main topic (P301) if Commons category (P373) is missing. Should I do a prototype? --Jarekt (talk) 19:23, 9 November 2016 (UTC)[reply]

Maybe time has come to do away with P373. I don't really see why would still need it. Given that we don't want to break anything, I think might just want to leave it as it is.
--- Jura 07:55, 10 November 2016 (UTC)[reply]

Jura do you mean to do away with P373's uniqueness constraint? --Jarekt (talk) 13:37, 10 November 2016 (UTC)[reply]

Let's try the approach of using as few Commons category (P373) as possible. We basically only want to use it when no category item is available or maybe as an override (the edge cases will always bit you).

Say that I have a Commonscategory template on Wikipedia on a category. The category should have a sitelink on Wikidata and that links to the category on Commons. P373 could be used as override (?).

Say that I have an article on Wikipedia which connects to a category item on Wikidata using topic's main category (P910), it can use the Commons category sitelink on that item. P373 can be used as override.

If the article doesn't have topic's main category (P910), Commons category (P373) can be used.

Please do make a prototype Jarek. Multichill (talk) 14:15, 10 November 2016 (UTC)[reply]

@Multichill: I totally disagree with this. If we're trying to map a Commons category to a set of articles in different language Wikipedias, (eg as the wdcat.js does; and as we also will probably do when we're trying to map Commons categories to topics for structured data), it's far easier to just have to look in one place for that -- to know that there either is or isn't a P373 pointing from the article to the Commons category. It adds complexity to have to look to see whether there's a P373 from an article, or failing that a link from a category that then is the target of a P910. Queries looking at this kind of relationship in bulk are so close to timing out already, they really don't need any more complexity.

The complaint at the top of this section was that the Unique value constraint violations report has become unusable. The reason for that is that the constraints query used to separate out links from article items and links from category items and allow one of each. The way to fix the problem is to restore that previous behaviour. Jheald (talk) 00:10, 27 January 2017 (UTC)[reply]

Here's a query to return the Commons cats that have more than one category-like item linking to them tinyurl.com/jgmp8aj. Perhaps it or something like it could be used as the basis for a complex constraint condition?

I tried changing it to list out the items one per line with their labels, but this runs out of time. I also tried changing to filtering for items which are not categories (ie article-like items), but this also takes too long. Perhaps somebody can find an optimisation; or perhaps constraint checking could be requested to run on a server with longer timeouts ? Jheald (talk) 10:44, 27 January 2017 (UTC)[reply]

I was cleaning a lot of bad P373 properties where the same category was added to up to 500 items. At the moment 25 items linking to a single category is is the max. --Jarekt (talk) 03:23, 16 February 2017 (UTC)[reply]

Doublon de cette propriété avec P910

Bonjour, il me semble que cette propriété est en doublon avec Property talk:P910, car pour beaucoup d'éléments, par exemple Aristophane, la catégorie Commons est présente à la fois dans la propriété 373 (ce qui paraît normal car c'est le titre de la propriété), mais également dans la propriété 373 qui est beaucoup plus inclusive. Je ne comprends donc pas l'utilité de la propriété 373, dans le sens où elle est plus restrictive que la propriété 910. --Consulnico (talk) 10:56, 17 March 2017 (UTC)[reply]

There is already a constraint for commons category on P910 with 1000 tracked violations. 1000 is the limit, and as long as nobody (=no bot) cleans this up it will get worse. –89.204.138.33 00:30, 7 October 2017 (UTC)[reply]

Scribunto error

Cf. Property_documentation#deltabot. –89.204.138.33 00:22, 7 October 2017 (UTC) [reply]

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. HotFixed by Matěj Suchánek, thanks. –89.15.236.224 20:26, 7 October 2017 (UTC)[reply]

Linking multiple items to the same Commons category

Is there any problem with linking multiple items to the same Commons category if they aren't distinguished on Commons? E.g, linking both human (Q5) and Homo sapiens (Q15978631) to c:Category:Homo sapiens? Ghouston (talk) 06:36, 1 November 2017 (UTC)[reply]

For a long time we had "distinct values constraint" on Commons category (P373). It was not working right because many catching category-items and article-items point used P373 pointing to the same category, but in general other than category-items / article-items mess P373 should be unique. In the past I was doing a lot of cleanup of constraint violations. If phabricator:T99899 ever happen I would like to look up item based on value of P373 and I would like to find a single item. --Jarekt (talk) 15:59, 1 November 2017 (UTC)[reply]

Seems reasonable, we are trying to set up a one-to-one relationship between Commons categories and article items. In this case, human (Q5) probably shouldn't have a Commons category (P373) value, since there's no corresponding category in Commons. Ghouston (talk) 21:15, 1 November 2017 (UTC)[reply]

Agree --Jarekt (talk) 12:52, 2 November 2017 (UTC)[reply]

Conflicts with "Wikimedia disambiguation page" is a problem

We have a constraint that items with P373 should not be "Wikimedia disambiguation pages". That is not correct as many items for disambiguation pages are linked through P373 to disambiguation categories on Commons. For example, Martin (Q28492) is linked to disambiguation category c:Category:Martin. Or Ostrovskogo Street (Q18073) is linked to c:Category:Ostrovsky Streets in Russia. That is correct use of P373. Should we add all such cases to a long list of exceptions or get rid of that constraint? --Jarekt (talk) 12:51, 2 November 2017 (UTC)[reply]

I removed conflicts with "Wikimedia disambiguation pages" constraint. --Jarekt (talk) 13:30, 7 November 2017 (UTC)[reply]

format constraint

Notified participants of WikiProject property constraints: The format constraint on this property currently uses the regular expression [^{}[\]<>:]+, which is legal in PCRE, but not in java.util.regex.Pattern, where the unescaped [ begins a nested character class (which is not closed). Since the WikibaseQualityConstraints extension uses the Wikidata Query Service to check constraints, and WDQS and BlazeGraph use plain Java regexes for the SPARQL REGEX() function, this means that the constraint check reports “[^{}[\]<>:]+ is not a valid regular expression.” To fix this, I suggest escaping the [, i. e. changing the pattern to [^{}\[\]<>:]+. It appears this form is also supported by PCRE, which KrBot uses. --Lucas Werkmeister (WMDE) (talk) 11:55, 3 January 2018 (UTC)[reply]

Also ping Matěj Suchánek, who AFAICT introduced the unescaped [ and isn’t part of the above {{Ping project}}. --Lucas Werkmeister (WMDE) (talk) 12:59, 3 January 2018 (UTC)[reply]

I am rather confused by format as a regular expression (P1793), what tools are using it and what format are supported. At some point I discovered that whatever format is used, it is not compatible with LUA regexp. This is I think the first place I have seen some explanation. Thanks --Jarekt (talk) 14:55, 3 January 2018 (UTC)[reply]

@Jarekt: it’s a complicated situation… I tried to explain it on Help:Property constraints portal/Format (which should be linked from the gadget). --Lucas Werkmeister (WMDE) (talk) 15:56, 3 January 2018 (UTC)[reply]

If it works for both systems, this should be ok. I think we should avoid that changes elsewhere by the paid WMDE development team break a working volunteer built solution.
--- Jura 17:27, 3 January 2018 (UTC)[reply]
Thanks for the notification. I didn't realize it should be compatible with both libraries. Matěj Suchánek (talk) 17:33, 3 January 2018 (UTC)[reply]

format constraint: namespaces

I changed [^{}\[\]<>:]+ to [^{}\[\]<>]+ as we have a lot of false alarm "Format" violations related to categories with ":" in it. At some point I added ":" to the format constraint in order to catch pages that start with "Category:" or other namespace. I guess those are also caught by "Commons_link"_violations. Commons Creator page (P1472) has format constraint (Q21502404) (?![Cc]reator\s*:)[^][|]+. May be change P373 format constraint from [^{}\[\]<>]+ to (?![Cc]ategory\s*:)[^{}\[\]<>]+? --Jarekt (talk) 16:35, 24 January 2018 (UTC)[reply]

distinct values constraint (Q21502410

@Jura1: please explain why having a constraint with 229093 is useful. Because this doesn't explain it and to be honest, comes across as very boorish. Multichill (talk) 20:56, 5 February 2018 (UTC)[reply]

It's a constraint we always had. It allows to find problematic claims such as Q30260456#P373. It's not entirely clear why it was removed without prior discussion (somewhen last year). There used to be a parameter "|separate category processing=yes" on the template. @Ivan_A._Krestinin: can we still specify this in one way or the other with statements?
--- Jura 21:12, 5 February 2018 (UTC)[reply]
- Always having something is not really a good reason. This is also causing warnings on a large number of items if you have the constraint checking gadget enabled, see for example Category:Grote Kerk, Haarlem (Q9102304). No, this is not useful. I removed the constraint. I suggest you add a {{Complex constraint}} to cover whatever cases you want to find. Multichill (talk) 22:20, 5 February 2018 (UTC)[reply]
  - I think that just means that the gadget needs to work like Constraint Reports. Adding FILTER (NOT) EXISTS { ?item wdt:P31 wd:Q4167836} in its code should do it.
    --- Jura 00:51, 6 February 2018 (UTC)[reply]

I am all for "distinct values constraint" P373, but lets I would exclude article / category pairs from this constraint. I my opinion constraint is useless to check if you have 10s or 100s thousands violations and no plans to fix them. I would vote to {{Complex constraint}} done either on article or category items. --Jarekt (talk) 13:20, 6 February 2018 (UTC)[reply]

I'm not sure how that helps identifying duplicates. In the way it's currently set, we have bots and tools adding countless duplicates (e.g. [1]). Maybe @Vojtěch Dostál, Pasleim: want to comment/support the actual duplicate creation (statement is already on Q47530495).
--- Jura 13:30, 6 February 2018 (UTC)[reply]

@Jura It seems very reasonable to me to set the unique value constraint but I can't see all the consequences of such a decision and thus cannot really comment on that. We regularly import categories using bots and HarvestTemplates tool. In case we want to have a specific commons category only locally (eg. in cases of imprecise matches to Wikidata definitions), we set the parametr "lokální" as true so that it does not accumulate in our "import to Wikidata" maintenance category. As for the "tennis official", it would help if you could add English descriptions to both items so that we can actually see the definitions for each and decide where the commons category is appropriate. --Vojtěch Dostál (talk) 13:41, 6 February 2018 (UTC)[reply]

@Jura Yes I noticed that, some bot operators and other users doing mass-edits, treat P373 like a parent category, instead of equivalent page on Commons. In other words they might add category for a city to every building items in that city, instead of adding categories for each building (if they exist). Some of those edits are very old and maybe the role of P373 was not so clear years ago. Some of the users doing that in last couple years are user:Alicia_Fagerving_(WMSE) (see [2]), User:Nvitucci (see [3]), User:Polish Monuments/user:Yarl (see [4]). That is one of the reasons we have so many constraint violations for P373. --Jarekt (talk) 13:59, 6 February 2018 (UTC)[reply]

Below is a query I use to find duplicates. What you get is a list of items with the same P373 category. In each group there is likely one item that is a correct pair for the category and the rest can be removed. --Jarekt (talk) 15:04, 6 February 2018 (UTC)[reply]

SELECT ?itemLabel ?item ?commonscat WHERE { 
  hint:Query hint:optimizer "None" 
    {
      SELECT ?commonscat (COUNT(?item) AS ?count) WHERE {
          ?item wdt:P373 ?commonscat 
       } GROUP BY ?commonscat
       HAVING (COUNT(?item) > 10)
   }    
         
   ?item wdt:P373 ?commonscat .
   FILTER NOT EXISTS {?item wdt:P31 wd:Q4167836} .    
   FILTER NOT EXISTS {?item wdt:P31 wd:Q13406463} .    
   SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
} ORDER BY DESC(?count) ?commonscat

Try it!

I did some queries last night to get an idea of the duplicates. Long story short: It's n:1, so many items (correctly) referencing the same Commons category. The different types I came across: Timelines, lists, categories and of course articles. So you shouldn't focus on duplicates, most of these are correct, focus on things that are out of pattern like [5]. These groups of items that are all using the same Commons category (P373) should somehow be related if two items use the same Commons category (P373) and no relation, something is wrong. Multichill (talk) 21:41, 6 February 2018 (UTC)[reply]

It's nice to have a strategy for cleanup, but how do we avoid that bots add more? Are there cases where it's normal that bots add the same category multiple times other than when it's present on categories and some article?
--- Jura 14:17, 7 February 2018 (UTC)[reply]
This edit by @Edgars2007: bot/@Pasleim:'s tool would have prevent by the constraint.
--- Jura 14:46, 7 February 2018 (UTC)[reply]
- Ping didn't seem to have worked. Let's try again: @Edgars2007:
  --- Jura 14:47, 7 February 2018 (UTC)[reply]

Easily find items with unnecessary Commons categories

This query makes it easy to find and fix items that have too many categories, for instance "MapR" wrongfully having categories "Databases" and "Big data". Enjoy! Syced (talk) 08:21, 21 February 2018 (UTC)[reply]

Bot is adding more than one Commons category to an item

A bot added several categories to the item Sensenschmiede unter der Linde (Q1393861).

Commons category (P373) has a property constraint (P2302) of single-value constraint (Q19474404) ("this property generally contains a single value per item"), so for instance I am not sure adding category "Haindl-Kapelle" is the right thing to do, even if Haindl-Kapelle is within that town and does not have a Wikidata item on its own.

User:Alicia Fagerving (WMSE) is running that bot. Alicia, Commons category (P373) is for 1-to-1 matches and not for parent categories and Sensenschmiede unter der Linde (Q1393861) already had perfectly fine Commons category (P373). Could you remove parent categories from Commons category (P373) properties your bot added? --Jarekt (talk) 13:09, 21 February 2018 (UTC)[reply]

Any suggestions on how to identify values of P373 that should be copied to the commons sitelink?

I was experimenting with a query to try to do this last night (basically, has P373, does not have sitelink, does not have topic's main category (P910), does not have instance of (P31)=Wikimedia disambiguation page (Q4167410)), and I wasn't getting very far due to erroneous P373 values in random Wikidata items. Reading through the discussion above about the single value constraint, I now see why that is...

So, does anyone have a suggested query that would find useful commons sitelinks from P373 (that could then be added by the bot code I've been working on)? Maybe an adaption of @Jarekt's query above, except returning non-duplicated P373s? Or something else? Thanks. Mike Peel (talk) 18:44, 2 March 2018 (UTC)[reply]

I can not look at this right now but I do have bunch more queries related to P373 and sitelinks at User:Jarekt/queries#Related_to_categories. --Jarekt (talk) 19:31, 2 March 2018 (UTC)[reply]

@Mike Peel: The following query may be close to what you are looking for:

SELECT ?item ?commonscat ?commonspage
WITH {
   SELECT ?item ?commonscat WHERE {
       ?item wdt:P373 ?commonscat .
  } LIMIT 10000  OFFSET 20000
} AS %cats 
WHERE {
    hint:Query hint:optimizer "None".
    INCLUDE %cats .
    BIND(STRLANG(CONCAT("Category:", ?commonscat),"en") AS ?c1) .
    OPTIONAL {
         ?commonspage schema:name ?c1 .
         ?commonspage schema:isPartOf <https://commons.wikimedia.org/> .
         ?commonspage schema:about [] .
    }
    FILTER (!bound(?commonspage)) 
    FILTER NOT EXISTS {?item wdt:P31 wd:Q4167836}
    OPTIONAL {
        ?item2 wdt:P373 ?commonscat .
        ?item2 wdt:P31 wd:Q4167836
    }
    FILTER NOT EXISTS {
        ?item3 wdt:P373 ?commonscat .
        FILTER (?item3 != ?item) .
        FILTER (!(bound(?item2) && ?item3 = ?item2))
    }
}

Try it!

It doesn't check for topic's main category (P910) or instance of (P31)=Wikimedia disambiguation page (Q4167410) (though this could easily be added), but it should give a Commons category with only one article-type item with a P373, and no sitelink.

The OFFSET will need to be scanned, and I'm 100% sure how deterministic the SELECT is, so you might want to go through more than once; but this ought to generate a lot of sitelinks that could be added. Jheald (talk) 03:17, 20 March 2018 (UTC)[reply]

Here's a revised version of the query tinyurl.com/y85997sl, which does now check for topic's main category (P910), and with the output now suitably formatted to go straight into QuickStatements.

This particular version is specifically for painters, so I haven't added the check for instance of (P31)=Wikimedia disambiguation page (Q4167410), though that will be straightforward in future runs. First 5000 sitelinks now going in with QuickStatements -- so only about 595,000 to go! (data) Jheald (talk) 20:18, 24 March 2018 (UTC)[reply]

@Jheald: That seems to work quite well, thanks! Any idea of the purity of the query / how many false candidates it may include? I have some pywikibot code (example edit) and I could ask for bot approval to do this in bulk, or would you prefer to keep going with QuickStatements instead (or as well)? Thanks. Mike Peel (talk) 00:15, 25 March 2018 (UTC)[reply]

@Mike Peel: 600,000 is definitely a job for a bot! But the painters are done now I think, give or take maybe a very few that have evaded all the queries. The painters query was needing just over 3 groups of 10,000 with P373s to get through the set. A second pass over all of them was definitely needed (and a third beyond that), but the number of hits it was picking up fell from about 5000 on the first pass to 120 on the second, then about 30, then about 7, and now pretty much none. Quality looks good, at least as far as I can tell -- though of course it can only be as good as the P373s. There are three or four that won't go through because the Commons category page doesn't actually exist (though it may have some images in it!), eg Peter Brüning (Q1373454). Sometimes at the end there were a couple that had been done on a previous pass, and the query hadn't updated yet. And a couple of times the query timed out, but then worked fine when I tried a second time. But mostly I'd say I think it seems pretty good. Jheald (talk) 00:48, 25 March 2018 (UTC)[reply]

It may also be possible that when QuickStatements is going full tilt, that some of the WDQS instances don't update. (Though I don't think I was ever editing more than about 60-70 edits a minute maximum, which the systems ought to be able to cope with). But I've just run a re-query that had 15 hits come back, most of which in fact had had the sitelink added -- eg Louis-Mathieu Verdilhan (Q3260740) two hours earlier. So that is another potential problem that might come up. Jheald (talk) 00:54, 25 March 2018 (UTC)[reply]

On the above, see eg these returns on a Listeria query by User:Multichill, the first one at least of which is spurious. His query seems a lot simpler than mine, so I may have been over-complicating things! Jheald (talk) 01:03, 25 March 2018 (UTC)[reply]

On the latter: my query finds the target commons category and then sees whether it has any sitelink to it; Multichill's finds the category, then sees whether it has a link from the original item (and also whether there is any other P373 pointing there, which we both do). So if there was another item that had a sitelink to the category but not a P373, then the original item would be identified as a link target by Multichill's but not by mine. There's about 60,000 category items (out of 450,000 matched to Commons) that that could be the case for. But the worst case is that the system will just decline to make the sitelink because there's one there already, so that may not be such a big deal. Anyway, take whichever approach you prefer. Jheald (talk) 01:15, 25 March 2018 (UTC)[reply]

Hmm. My QS run may also have overwritten some gallery links. (eg diff). That's unfortunate. I should have filtered for that. Oh well, easy enough to find and reverse if the items have a Commons gallery (P935). Slightly more tricky if they don't. But I guess that's why we do pilot runs... Jheald (talk) 01:22, 25 March 2018 (UTC)[reply]

Damage assessment: yesterday there were 98,590 article-items sitelinked to galleries. Today this query tinyurl.com/y7tszd5b counts only 96,853.

Against that, there are 5280 items with Commons gallery (P935) that are now sitelinked to categories: tinyurl.com/y9sjxlph. That appears to include all but 4 of the items previously sitelinked to galleries.

54 currently appear to have category-items the sitelink could be shifted over to: tinyurl.com/y7pp4wqx. The others would need to be checked/created. Jheald (talk) 08:36, 25 March 2018 (UTC)[reply]

Revised query for category sitelinks to add, that now does check for an existing gallery sitelink: tinyurl.com/y9c3ogcb Jheald (talk) 09:07, 25 March 2018 (UTC)[reply]

@Jheald: I've posted the bot request at Wikidata:Requests for permissions/Bot/Pi bot 2. If you can continue revising the queries, that should be able to them implement them (without overriding existing values, see the checks in the code). Thanks. Mike Peel (talk) 21:57, 26 March 2018 (UTC)[reply]

More queries

840 instances where an item and its P279 parent both have the same Commons category:

SELECT ?item ?itemLabel ?parent ?parentLabel ?commonscat WHERE {
    ?item wdt:P373 ?commonscat .
    ?parent wdt:P373 ?commonscat .
    ?item wdt:P279 ?parent .
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} ORDER BY ?parentLabel ?itemLabel

Try it!

Probably these lower links should all be swept away.

But there may be an issue that people want to have Commonscat links from the corresponding Wikipedia articles, which would otherwise not have a Commonscat link.

Do people have thoughts on this? Jheald (talk) 00:58, 20 March 2018 (UTC)[reply]

Similar queries for other linking properties:

286 pairs of items connected by instance of (P31): tinyurl.com/y9gfhr8r
1789 pairs connected by part of (P361): tinyurl.com/yd7yfm6n
91 pairs connected by facet of (P1269): tinyurl.com/ycyn6nbb
4534 pairs connected by located in the administrative territorial entity (P131): tinyurl.com/yc4swaje
286 pairs connected by location (P276): tinyurl.com/y9lz6oav
405 pairs connected by is a list of (P360): tinyurl.com/ybalhlep

-- Jheald (talk) 01:16, 20 March 2018 (UTC)[reply]

Some of these have surely been created directly; but I'm wondering if others may have been created if a category has been deleted on Commons, and a P373 pointing to it has been shifted to a parent category that may already have had its own P373.

Overall, currently about 22,000 Commons categories with more than two items pointing to them:

SELECT ?commonscat (COUNT(?item) AS ?count) WHERE {
  ?item wdt:P373 ?commonscat .
} GROUP BY ?commonscat
HAVING (?count > 2)
ORDER BY DESC(?count)

Try it!

Though only about 6000 with more than three. Jheald (talk) 11:38, 20 March 2018 (UTC)[reply]

Editing tools and distinct value constraint

It seems that tools such as HarvestTemplates us the distinct value constraint to check if they can add the same value to several items. As there was no such constraint on the property, we keep getting the same statement added on multiple items, e.g. [6] and [7]. To avoid this, I restored the constraint. I think it's easier to bear in mind that there may be exceptions and ignore the contraint when appropriate, than to just let everyone assume that we add the same value hundreds of times.
--- Jura 08:18, 29 June 2018 (UTC)[reply]

I don't agree with this solution. Now we're getting constraint violation on valid items like Category:Haarlem (Q7427769) and in the previous discussion there was no consensus for adding this. Please discus here first and get consensus for adding it instead of the other way around. Multichill (talk) 11:59, 29 June 2018 (UTC)[reply]

It's to remain a non-mandatory constraint. The number of violations is mostly irrelevant, as long as one is sure what one is doing.

What solution do you suggest?

What shall we do with users who add duplicates to random items?
--- Jura 12:09, 29 June 2018 (UTC)[reply]

Is there a more complex constraint that can be applied - ideally something along the lines of 'maximum of 2 of the same value, and both items have to be linked to each other through category's main topic (P301) and topic's main category (P910)"? Thanks. Mike Peel (talk) 12:27, 29 June 2018 (UTC)[reply]

Constraint:Unique or dual value

This property cannot use a distinct-values constraint (Q21502410) because he commonscat is added to both articles and their corresponding category and there isn't a contraint for that. But a constraint could be created that will allow one normal item to be added and one category. This would correctly de the thing someone would add the unique value contraint to items that are not used on category items in addition to the normal item. - cycŋ - (talk • contribs • logs) 17:03, 29 June 2018 (UTC)[reply]

My opinion is that if you have created a separate Wikidata item for the Category on Commons then its associated wiki links are enough and you don't need to respecify its value in that last item: the category is named explicitly in "Other projects" under the "Commons" entry, So it is redundant to assign also there the property Commons category (P373).

Just keep the property Commons category (P373) in the main items for topics (not for categories).

That would require tens of thousands of category items to be stripped of this property. If we can have that done, then we can use a Unique value constraint for this property... - cycŋ - (talk • contribs • logs) 15:44, 12 November 2018 (UTC)[reply]

That can be done (I think I can code that up relatively straightforwardly using pywikibot) - I'd suggest focusing on whether it *should* be done. Thanks. Mike Peel (talk) 16:31, 12 November 2018 (UTC)[reply]

Well, if it is indeed decided it should be done (and I can see the argument) and, like you say, the bot can check (and will update where needed) the 1000000+ items, then this property should have the Constraint:Unique value. Before that it shouldn't. - cycŋ - (talk • contribs • logs) 06:37, 13 November 2018 (UTC)[reply]

I thing it is a bad idea making this property distinct-values constraint (Q21502410). Not only one item and one category can point to the same commonscat, multiple overlaping items can also link to the same commonscat, for example Bullerön (Q56852225) and Bullerö nature reserve (Q10437664). /ℇsquilo 08:57, 27 May 2019 (UTC)[reply]

My second opinion is that the property Commons category (P373) is old, and that there should be another property not linking directly to a Category page on Commons, but that you should use instead a property like topic's main category (P910) pointing to a Qnnnn subject item in Wikidata, with instance of (P31)="Wikimedia category". This Commons category (P373) looks like an old but insufficient property where you cannot navigate directly only in Wikidata to find the two relevant items. Verdy p (talk) 06:17, 10 November 2018 (UTC)[reply]

I feel that would be a different discussion that wouldn't really affect the other one. - cycŋ - (talk • contribs • logs) 06:39, 13 November 2018 (UTC)[reply]

May/June 2019 after introduction of suggestion constraint

@Jura1: I have reverted your edit adding a suggested distinct value constraint (diff), per the discussion in this section and the section immediately above. Adding a constraint like this is a complete pain, if it encourages users like User:Hsarrazin to make good-faith removals of P373s from category-type items (eg diff). There are downstream queries and software that rely on these statements being present. Jheald (talk) 09:28, 28 May 2019 (UTC)[reply]

@Jheald: That's a real shame, as during the brief time that constraint was available, I was already finding it to be very useful in identifying misplaced P373 statements, which were preventing pi bot from adding the commons sitelinks (it can't figure out which one should be added). How can we get those downstream users to use the sitelink instead of P373? In particular, there should not be any reason for downstream users of category items to use P373 rather than the commons sitelink. Thanks. Mike Peel (talk) 10:49, 28 May 2019 (UTC)[reply]

@Mike Peel: Agreed that the worst problem is not being able to rely on P373 for main-type items, which makes the item->commoncat function in a query like tinyurl.com/y36yojo4 so much more difficult than it would otherwise need to be. It should be easy enough to find the really bad cases of misplaced P373 statements without the constraint -- see eg the final query in the Property_talk:P373#More_queries section above, and some of the other queries in that section for some of the different types of cases. Jheald (talk) 11:06, 28 May 2019 (UTC)[reply]

Since the last time this was discussed, "suggested constraint" is now available as constraint status. It offers a even more toned-down message than the one for non-mandatory constraints. I set that for this constraint and I think it suits it well. Eventually the syntax "clarification" message should be displayed as well (phab:T219037). It's possible that occasionally the deletions like the one mentioned happen, but bots re-add them fairly soon and the advantage of being able to view the other items the same statement is available outweights that. I did find a few odd places and combinations in the time it was available. --- Jura 11:10, 28 May 2019 (UTC)[reply]

@Jheald: Have you tried talking to the developers about this? Perhaps they could provide some sort of shortcut for the complex case where the category sitelink is in the category rather than topic item, although that's what P373 in the topic item is nominally supposed to cover right now. Are there any practical reasons why we need to keep the P373 values in category items, though? I'm tempted to put together a bot to remove those (as per my comments above), which would then resolve most of the duplicate issues. For the others, I was finding it useful to see the constraints in the affected wikidata items when I came across the item via other queries. Thanks. Mike Peel (talk) 19:16, 28 May 2019 (UTC)[reply]

To conclude this discussion, given the new feature now available ("suggestion constraint"), I think we can set this up. --- Jura 10:11, 18 June 2019 (UTC)[reply]

@Jura1: This is going to create upwards of 300,000 false positives, each one gaining a constraint flag encouraging people to remove a statement that, actually, we don't want them to remove. What value do you see in adding this misleading constraint, against such an immense negative? Jheald (talk) 12:21, 27 July 2019 (UTC)[reply]

Is it OK to set this property to the "closest category"?

A particular research institute (Q31855) has a P373 of "Research Institutes".

I guess this category might be the closest available, but is this really the intended usage of this property? The definition "name of the Wikimedia Commons category containing files related to this item" is ambiguous ans does not forbid this explicitly.

Cheers! Syced (talk) 03:45, 3 December 2018 (UTC)[reply]

@Syced: Commons category (P373) = commons:Category:Research institutes makes sense at research institute (Q31855) and Category:Research institutes (Q9833888), but it's unlikely to be useful for items where instance of (P31)=research institute (Q31855). I'd suggest just removing it on sight if you see it in those cases (and tracing it back to the wiki where it came from to remove the source as well). Thanks. Mike Peel (talk)

I don't think one should add the same P373-value to multiple items just to try to point to the closest Commons category. It's true that the lack of corresponding constraints (or people deleting them) might suggest the contrary. --- Jura 11:57, 28 May 2019 (UTC)[reply]

But then, Kitakinki-Toyooka Expressway (Q6157667) can really have two "closest categories", one c:Category:Kitakinki Toyo-oka Expressway and one c:Route 483 (Japan). --Liuxinyu970226 (talk) 23:20, 14 June 2019 (UTC)[reply]

Datatype

Why the category changed its datatype?--Juandev (talk) 10:06, 28 September 2019 (UTC)[reply]

(*property) It never did. --Matěj Suchánek (talk) 11:57, 17 November 2019 (UTC)[reply]

@Juandev Or even there did, we can just start P373 deprecation from our server. Liuxinyu970226 (talk) 01:34, 11 January 2022 (UTC)[reply]

distinct-value

Was there any discussion on adding a distinct-value constraint? I think this is a bad idea because there are many cases where multiple items link to one category on commons. --GPSLeo (talk) 16:15, 24 May 2022 (UTC)[reply]

@GPSLeo: Please make some example. --Horcrux (talk) 08:36, 25 May 2022 (UTC)[reply]

I agree with @GPSLeo: I noticed this issue on tens of cities (example: city & city category). There are tens of thousands of places which show this issue now, while there's actually no issue. So I'll remove it until someone explains why it was added without discussion (@Multichill: please don't mind). --Orijentolog (talk) 01:29, 26 May 2022 (UTC)[reply]

In these cases can be link in one item as P373 and in the second as sitelink. JAn Dudík (talk) 11:16, 26 May 2022 (UTC)[reply]

And then a bot is comes around and copies the sitelink to the P373 value. This value is used for many upload tools on commons and the Infobox. The sitelink could link to a gallery page so it is very inconvenience for a tool use this link. In many cases multiple items share one category. On case is the distinct item for the category. Like at Berlin (Q64) and Category:Berlin (Q4579913). There are cases where two protected areas share one category like at Pfaueninsel (Q59780259) Pfaueninsel (Q59784477). As this is a huge change affecting many tools and scripts this needs to be discussed before implementation and not after. --GPSLeo (talk) 15:45, 26 May 2022 (UTC)[reply]

I find also cases where list-items are involved. This constraint mainly add warnings when subjects have 2 or more of the following: a normal item, a list or a category. Only in a very small number of cases this isn't the actual reason of the warning, so after dozens of bogus cases you just stop checking this warning making it useful. If this can be change not to check for Property:P31 Wikimedia category (Q4167836) and Wikimedia list article (Q13406463) (and maybe a few more} it would be useful, but now it isn't at all. - сyсn - (talk • contribs • logs) 05:43, 27 May 2022 (UTC)[reply]

I've reverted the change for now, since there is obvious opposition to it. Find consensus or, preferably, a working technical solution before re-implementing. — Huntster (t @ c) 05:29, 28 May 2022 (UTC)[reply]

Property talk:P373

Documentation

Constraints

Discussion

Context at time of creation

English property title

Galleries on Commons

Unique value violations

commons:Template:Disambig

commons:Category:Category redirects

Next step

Hindi constraint violation

Nominated for deletion

WD:PP

Shouldn't be allowed on Category items

constraint report relating to Wikimedia disambiguation page (Q4167410)

About external links

P373 "no value"

Commons category on Wikimedia category item

Why not linked?

Conflicts with constraint

Property values starting by the "commons:" interwiki prefix

automated creation/ update

Cleaning up Unique_value constraint violations

Doublon de cette propriété avec P910

Scribunto error

Linking multiple items to the same Commons category

Conflicts with "Wikimedia disambiguation page" is a problem

format constraint

format constraint: namespaces

distinct values constraint (Q21502410

Easily find items with unnecessary Commons categories

Bot is adding more than one Commons category to an item

Any suggestions on how to identify values of P373 that should be copied to the commons sitelink?

More queries

Editing tools and distinct value constraint

Constraint:Unique or dual value

May/June 2019 after introduction of suggestion constraint

Is it OK to set this property to the "closest category"?

Datatype

distinct-value

Navigation menu

Search