Page semi-protected from being moved
Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to: navigation, search

This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:

  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message in Village pump of the project.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request

On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.






for permissions


for deletions


for deletion

for comment

and imports



Please add a new request at the bottom of this section, using {{subst:Rfd|1=PAGENAME|2=REASON FOR DELETION}}.

doubles record (P555) and singles record (P564)[edit]

(delete | history | links | logs | discussion) (delete | history | links | logs | discussion)

Can be replaced by wins (P1355) and losses (P1356) with qualifiers. Even if it is not replaced, it should replaced by four properties with number datatype.--GZWDer (talk) 16:28, 2 February 2016 (UTC)

  • Delete per the nominator--these should be replaced since a wins/losses combined property is non-granular semantic information (indicated by the expected dash). --Izno (talk) 13:59, 8 March 2016 (UTC)
  • Delete. Thierry Caro (talk) 08:56, 12 March 2016 (UTC)
  • Symbol keep vote.svg Keep for now. Four properties make more sense, but this property should be kept until then. Qualifiers are not an appropriate substitute for sub-properties, though. --Srittau (talk) 02:45, 25 March 2016 (UTC)
    "but this property should be kept until then" - We have the replacement properties and just need to do the replacement. Voting keep based on the fact it's being used is not a valid reason for keeping. Lastly, sub-properties are a bad thing. --Izno (talk) 12:14, 28 March 2016 (UTC)
    What are those properties? I only see wins (P1355) and losses (P1356), we are still lacking "games won in singles/doubles", "games lost in singles/doubles". --Srittau (talk) 19:12, 28 March 2016 (UTC)
    @Srittau: something generic like wins of (P642) "singles tennis match" (which would be P31 types of tennis match (Q1967745) and P279 tennis match P279 competition or similar). --Izno (talk) 16:20, 26 April 2016 (UTC)
    @Izno: In your proposal, how should we then call-up the replacer for "win-loss balance in singles" in infoboxes (currently called-up as {{#property:P564}})? I have no clue as to how the code would look like that I would have to write in a tennis player's infobox. Vinkje83 (talk) 10:37, 5 July 2016 (UTC)
  • Symbol delete vote.svg Delete wins (P1355) and losses (P1356) can be used but we need a good qualifier to make the distinction between single/double/mixed matches. --Pasleim (talk) 10:05, 6 April 2016 (UTC)
    of (P642)? --Edgars2007 (talk) 10:31, 6 April 2016 (UTC)
  • Symbol keep vote.svg Keep These two properties are actively used on quite some languages, in tennis-infoboxes. Deletion will make it a lot more difficult to maintain the value of these items (that is changing basically every week for active players), as well as replacing those properties in the infoboxes. For tennis, this is just the way statistics are registered, and this is the only way this makes sense for tennis. For other sports, these properties should not be used. Maybe the name of the properties (or their explanation) should be changed to clarify that they are tennis only? Edoderoo (talk) 21:37, 2 July 2016 (UTC)
  • Symbol keep vote.svg Keep The concept of 'win/loss balance' is a natural phenomenon in tennis. A concept like 'number of matches won' in itself has no meaning there (neither has 'number of matches lost'). It's only the two numbers together that make sense. The inclusion of singles record (P564) and doubles record (P555) in tennis players' infoboxes is finally coming into use (more than just occasionally), and their wikidata values are actually getting updated by the international community. Replacing them by four new properties (two would not work, obviously) would cause more complicated code to include them in the infoboxes, and that will most probably arouse new objections against wikidata. Vinkje83 (talk) 23:31, 2 July 2016 (UTC)

comment (P2315)[edit]

(delete | history | links | logs | discussion)

This property is currently being used for (at least) three separate things, which I think is a bad idea because Wikidata is about structured data and storing comments as data only makes sense if the properties are well defined (i.e. we know what the comments are for, who they're aimed at and when they should be shown).

This property was originally added to store comments for property constraints and was not intended to be used just yet. Unfortunately, the original label and description were too vague. The description was then changed, which redefined the property and turned it a property for usage instructions instead (see also phab:T97566). The label is still vague, so it's also being used as a generic comment property whenever people want to add a comment to something (some of the ones I've seen appear to be people wanting to add custom edit summaries, which is covered by phab:T47224).

I'm proposing to delete this property as it is currently poorly defined and none of the uses are what it was actually created for. Instead, I suggest that we add a new property to replace the original approved property (with a better label and description, "Wikidata property constraint comment" might work) and create two new property proposals for the other uses. If the new proposals are accepted, the existing statements for this property should be migrated to the new properties. If they are rejected and this deletion request is accepted, the existing statements should be deleted.

- Nikki (talk) 16:03, 24 February 2016 (UTC)

See Wikidata:Property_proposal/Generic#Wikidata_usage_instructions and Wikidata:Property_proposal/Generic#comment for the two new proposals I mentioned. - Nikki (talk) 16:09, 24 February 2016 (UTC)
Pictogram voting comment.svg Comment Property Wikidata usage instructions (P2559) created as a result of this request, but no other new property. Original property is retained. -- LaddΩ chat ;) 22:57, 7 March 2016 (UTC)
  • Delete per the nominator. Clearly is not being used correctly, and the talk page suffices for a comment. --Izno (talk) 13:56, 8 March 2016 (UTC)
  • Symbol delete vote.svg Delete Overloaded property. --Srittau (talk) 02:46, 25 March 2016 (UTC)
  • Pictogram voting comment.svg Comment I cleaned up the most of the remaining uses. Going forward, usage instructions that are in descriptions, can use Wikidata usage instructions (P2559). Once the MediaWiki feature is available, this can be removed from descriptions. Notes that are in qualifiers, can continue to use this property. Obviously, it needs to be monitored to avoid that it isn't misused. To limit this, I changed the property label (the problem with the current label was already pointed out before it was actually created). Currently the bulk of inappropriate uses were those that should have been using P2559, but weren't converted when that property was requested and created. Seems like someone didn't follow up on the creation → fixed. There were a few cases liked this, where actual content was added in the property. It seems the property now works as it should.
    --- Jura 11:27, 25 March 2016 (UTC)
    • Please don't change labels of properties in substantive fashion while there is an ongoing deletion request. I should have but didn't realize that the edits I made earlier today were to this property. --Izno (talk) 12:12, 28 March 2016 (UTC)
      • Sorry about that, I thought I had cleared up the problematic uses and the only remaining ones are the ones where this covers a gap between the new property and the remaining uses. To avoid future problems, the label needs to be changed (as already suggested before creation, on first discussion, etc.). If there are no arguments against it, we can finish sorting this out and can close this discussion.
        --- Jura 10:20, 16 April 2016 (UTC)
  • Symbol delete vote.svg Delete obviously. Cdlt, VIGNERON (talk) 14:56, 8 April 2016 (UTC)
  • Symbol delete vote.svg Delete, has no connection with structured data.--ԱշոտՏՆՂ (talk) 21:13, 6 May 2016 (UTC)
  • Symbol delete vote.svg Delete Bad use Snipre (talk) 17:36, 25 May 2016 (UTC)
  • Pictogram voting comment.svg Comment @Lymantria: thanks for cleaning up the unstructured uses of this property, but could you do a plan for the remaining uses? Just deleting it when it's still in use isn't a good idea. Generally, we identify alternatives, then remove the the property, and, at last delete it.
    --- Jura 13:02, 2 June 2016 (UTC)
    • I don't see what you mean. Wikidata usage instructions (P2559) is instsalled to reflect the original scope of the property plus its first extension, while a property on comment, the unstructured data, was rejected. I am not aware of any other initiative to split parts off the original property. I removed all usage that IMHO shouldn't be there or could be replaced. Nothing left, so deletion was in my view the thing to do. Lymantria (talk) 13:12, 2 June 2016 (UTC)
      • There are about 222 uses left mainly by Laddo which don't fit P2559 nor the other proposed property. Probably some of the people commenting above made the same error as you did.
        --- Jura 13:17, 2 June 2016 (UTC)
        • I overlooked the usage in Porperty-namespacy. My apologies. Restored and removed decision. Lymantria (talk) 13:31, 2 June 2016 (UTC)
Thanks, I'm afraid I did not check this discussion in along time. -- LaddΩ chat ;) 14:11, 2 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Lymantria: New property syntax clarification (P2916) was created. Can you port qualifiers comment (P2315) on all format as a regular expression (P1793) to the new property? -- LaddΩ chat ;) 12:13, 19 June 2016 (UTC)

  • Symbol keep vote.svg Keep It's useful to have a way to document why a certain decision is made. If I read a biography and the it gives me an occuption of a person but there are two different ways I could model that occuption in Wikidata it's good to be able to leave a comment to explain why I chose A and not B. ChristianKl (talk) 19:44, 20 July 2016 (UTC)
    • That would probably be best done on the talk page, where the decision could be discussed if anyone wants. Thryduulf (talk) 22:24, 20 July 2016 (UTC)

ISO standard (P503)[edit]

(delete | history | links | logs | discussion)

Bad datatype. Should be item like ISO/IEC 80000 (Q568496) View with Reasonator See with SQID and this one should be deleted/redeployed with a domain of iso norms. For example I just put it on ISO/IEC 80000 (Q568496) View with Reasonator See with SQID ...--author  TomT0m / talk page 08:43, 18 May 2016 (UTC)

Well, we would need two properties: "ISO standard this is standardized in" and "this is the item for ISO standard #1234". This property could be repurposed for the latter. Also, we should have the replacement items first, before deleting this one. --Srittau (talk) 11:57, 18 May 2016 (UTC)
Were we to pursue the action of repurposing (which I think I support), I would suggest a rename as well to "standard number" or similar, so that we can apply this outside the realm of ISO with e.g. MIL-STD. --Izno (talk) 12:11, 18 May 2016 (UTC)
@TomT0m: I vaguely recall asking if this property existed a while ago, heh. It has the wrong domain for the question at the time. That said, oppose deletion per Srittau, and support a new property (if necessary) called "specification"/"specified in", for the same domain as P503 with item datatype. --Izno (talk) 12:11, 18 May 2016 (UTC)

property usage tracking category (P2875)[edit]

language of work or name (P407)[edit]

@Jura1: In case you didn't read the long discussion before just know that the discussion above was about merging 2 properties. But since the beginning of this discussion we have a new property so all votes are outdated due to the fact they were based on only 2 properties. If you assume that the above discussion can still continue please contact all contributors who took part to the discussion in order to ask them to reconsider their vote according to the new situation. New situation means new discussion in order to offer the possibility to everyone to change its previous position due to the new elements. Snipre (talk) 09:05, 7 June 2016 (UTC)

@Jura1: Can you reopen the discussion as the previous discussion was closed ? Snipre (talk) 16:22, 11 June 2016 (UTC)
This was already closed. If you think the other discussion had been closed prematurely, you might want to contact its closer. There isn't really much in your argument that hadn't been brought up before. If you duplicate discussions you are merely disrupting the project.
--- Jura 16:35, 11 June 2016 (UTC)
Again I have the impression you didn't understand the situation of the previous discussion so please have a look at it:
1) another contributor (Srittau) asked for new discussions mentioning the change of the situation
2) the admin who closed the previous discussion proposed to open new deletion requests too if desired. Three contributors having a similar position against you alone, I hope you agree this is not a me-against-you argument
3) the previous discussion was closed as undecided and not as keep it so reopening the discussion is not forcing to change a decision: to change a decision we should have a decision and this is not the case.
4) the situation is different from the previous discussion: the merge proposed in the first discussion implied to modify both properties. Now with the third property it is possible to keep untouched one of the two properties and to delete the other one. So this is a new possibility which was not analyzed by the contributors who gave their opinion. Snipre (talk) 12:57, 13 June 2016 (UTC)
It was explicitly asked to close the discussion Jura mentions as reason to close these requests. There was a good reason to indeed close that discussion, as situation between start and end of discussion was changed dramaticly. Initially there were two "language" items, but in between a third one was created, which could be seen as a merge of the two earlier ones. Discussion was contaminated by this change of circumstances. This can clearly be seen from the before last statement, asking for merging of the properties, while a merged property was already available. I think my closing statement was clear about no decision being taken. Although you may argue if a closure without decision can be allowed or should be interpreted as a "no consensus, so no deletion" decision. The latter was, as clearly stated, certainly not what I intended and no-one came to me to discuss about that point. From that point of view, I feel some disappointment about these speedy closures by @Jura1:. Lymantria (talk) 13:50, 13 June 2016 (UTC)
There isn't really much good to come from three open discussions on the same topic (which is why I closed two of them). It's really disappointing to suggest that we should hear the same arguments all over again ..
--- Jura 14:00, 13 June 2016 (UTC)
We now have zero of them left, so there may be opportunity to open one once again. Snipre may have been premature with his opening here before closure was done. Lymantria (talk) 14:19, 13 June 2016 (UTC)
Why didn't you take into account in your closure that the other property was created and discussed at length when the previous deletion was open? Snipre even intervened there. It might be that your closure was premature or incomplete.
--- Jura 14:30, 13 June 2016 (UTC)
What suggests you that I didn't take that into account? How can a closure of a discussion that turned into a mess be premature, if it does not contain a decision? Lymantria (talk) 15:16, 13 June 2016 (UTC)
@Jura1: Since when the mood of one contributor defines what can be discussed or not ? If you are tired of that discussion just leave and let the other people discussing. Your comment just proves that your action was not based on any good reason but only on your personal jugdment. So again 3 contibutors propose to discuss again ayou are until now the only one who raise an opposition to a new discussion based on your mood (It's really disappointing to suggest that we should hear the same arguments all over again). If you already have a solution please share with us your great knowledge and explain us how do we have to use the three properties.
Just try once to be a little consturctive and say me what I have to do when I have
  • language (P2439) defined as "any item that has or uses a language except works or persons, like names, words, phrases, proverbs."
  • language of work or name (P407) which according to its label can be used to describe the language of a work and a word like a name
Shouldn't we at least change the label of language of work or name (P407) to "Language of work" only to avoid any confusion ? Snipre (talk) 19:06, 23 June 2016 (UTC)

original language of work (P364)[edit]

@Jura1: Can you reopen the discussion as the previous discussion was closed ? Snipre (talk) 16:23, 11 June 2016 (UTC)

Property:P2932, Property:P2933, Property:P2934[edit]

See WD:AN. --Yair rand (talk) 18:05, 23 June 2016 (UTC)

  • Symbol delete vote.svg Delete No discussion and no explanation about the use of these properties. Snipre (talk) 18:33, 23 June 2016 (UTC)
  • Symbol delete vote.svg Delete all possible meanings of broader and narrower are covered by existing relations - subclass, instance, part of. ArthurPSmith (talk) 19:02, 23 June 2016 (UTC)

Deleted. Created out of process. We had a huge discussion the last time this happened and the consensus was that's it's not ok to create properties outside of the process because it denies the community the possibility to comment on property proposals. You're more that welcome to propose these properties. If consensus is reached that we need these properties, the properties can be undeleted. Multichill (talk) 13:18, 24 June 2016 (UTC)


(delete | history | links | logs | discussion)

country (P17) or located in the administrative territorial entity (P131) can be used instead. GZWDer (talk) 19:29, 23 July 2016 (UTC)