Wikidata:Property proposal/property constraint for Commons

From Wikidata
Jump to navigation Jump to search

property constraint for Commons[edit]

Return to Wikidata:Property proposal/Commons

   Under discussion
Descriptionconstraint applicable to this Wikidata property when used on Wikimedia Commons
Data typeItem
Example 1MISSING
Example 2MISSING
Example 3MISSING
See also

Motivation[edit]

The recent addition of qualifiers at depicts (P180) suggests that we shouldn't combine all of them in P2302. Commons could obviously use P2302 if nothing is defined with this property (Add your motivation for this property here.) --- Jura 09:38, 22 June 2020 (UTC)

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Salgo60
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
Pictogram voting comment.svg Notified participants of WikiProject property constraints --- Jura 09:38, 22 June 2020 (UTC)

Discussion[edit]

  • Pictogram voting question.svg Question I agree that commons might have slightly altered constraints from Wikidata, so some constraints are Commons-only some are Wikidata-only and most by default apply to both. So maybe we can have a qualifier to narrow down constraint's scope. We could call it "property constraint scope" and only allow Wikidata (Q2013) and Wikimedia Commons (Q565) values. --Jarekt (talk) 15:24, 22 June 2020 (UTC)
    • Could be a solution, but it would require to redo all Wikidata tools. Commons still needs to work on this and they could easily read this if present instead of P2302. --- Jura 16:04, 22 June 2020 (UTC)
At least for WikibaseQualityConstraints, I estimate that reading constraints from a new property will require more work than a kind of “scope” qualifier. (Note that constraint scope (P4680) already exists and could be generalized to support this notion, though I’m not yet sure if that would be a good or bad idea.) --Lucas Werkmeister (WMDE) (talk) 17:45, 22 June 2020 (UTC)
  • Pictogram voting question.svg Question What exactly is the proposed semantics of this property? Should Commons read only constraints defined using this property, and ignore property constraint (P2302)? Should both groups of constraint definitions be merged, somehow? --Lucas Werkmeister (WMDE) (talk) 17:45, 22 June 2020 (UTC)
    • It's up to them to decide (I'd use P2302 on Commons if this property isn't used). The idea is to avoid edits to P2302 only for Commons. --- Jura 19:01, 22 June 2020 (UTC)
  • I support it, but I don't think it is a proper long-term solution (especially given Commons is only one of federated repos). The proper long-term solution may be like "shadow entity", where a Wikidata property will have its Commons page and constraints are defined there.--GZWDer (talk) 02:28, 5 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose for now because several things are unclear. Seems that this is the wrong order of things. We first need to define what we want exactly. I think what we want is to limit the scope of a property constraint to only Wikidata or only Commons and default is both. Than we need to implement that. Starting point would be to file a Phabricator task for that. Out of the implementation maybe comes the requirement to add a new property. At that point the property should be proposed, not now. Did anyone already file a Phabricator task for this? Multichill (talk) 17:20, 6 July 2020 (UTC)
    • The wrong order would be to change property constraints on Wikidata to accomodate Commons. --- Jura 17:57, 6 July 2020 (UTC)
  • Pictogram voting comment.svg Comment To provide a bit of context – The recent addition of qualifiers at depicts (P180) presumably refers to this edit of mine, which I explained on the talk page but Jura1 has now reverted. (I would be happy to hear from others in that discussion.) --Lucas Werkmeister (talk) 21:21, 6 July 2020 (UTC)