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

a query



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]

doubles record (P555): (delete | history | links | entity usage | logs | discussion) singles record (P564): (delete | history | links | entity usage | logs | discussion)

Can be replaced by number of 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 number of 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 type 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 number of 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)
  • Symbol delete vote.svg Delete. Also, with number of wins (P1355) and losses (P1356) with qualifiers we can make some interesting queries. I can do the data conversion task here (I was anyway planning to update data from websites) and notify Wikipedias etc. @Edoderoo, Vinkje83: fyi, I created a simple Lua module to be used in tennis infoboxes. It maywill require some clean-up, but that is a different story. --Edgars2007 (talk) 19:37, 27 August 2016 (UTC)
    • @Edoderoo, Vinkje83: extra-ping, as I forgot to sign. --Edgars2007 (talk) 19:37, 27 August 2016 (UTC)
      • Unfortunately LUA is not (yet) accepted on some wiki's, like nl-wiki. Use of WikiData-data is actually not fully accepted yet, though "we" try to push it through in some areas where it makes most sense, like these two highly changing properties (updated weekly, in theory). But in theory LUA would indeed take away some of the issues, but for the moment I would prefer to keep these two properties, as without them some wiki's will simply loose the data completely right now. Edoderoo (talk) 19:43, 27 August 2016 (UTC)
        • Client decisions not to use Lua (really??) shouldn't affect our decisions. That's just, frankly, dumb. While they're welcome to their opinion, they're also welcome to the consequences of that opinion, and one of them is that they may not have access to the same power as other wikis do. --Izno (talk) 19:49, 27 August 2016 (UTC)
          • And we wouldn't delete number of wins (P1355) and losses (P1356), when converting data. At least, I was planning to do that. Once I would convert everything (keeping also old props), then is the work with Wikipedias. We can also have some logic in module - if there isn't the "new" properties, load the "old" ones. Yes, we would have extra work in maintaining data for some while, but with help of SPARQL queries that is pretty easily doable with python. --Edgars2007 (talk) 20:31, 27 August 2016 (UTC)
            • There is no official vote or something that lua shouldn't be used on nlwiki. Edoderoo is probably talking about nl:Module:Cycling race and the relevant discussion. It's not weird that a part of the community doesn't like pushing of "outsiders". Sjoerd de Bruin (talk) 12:10, 6 September 2016 (UTC)
  • Symbol keep vote.svg Keep Both properties are used in 40+ projects.--Jklamo (talk) 00:43, 23 January 2017 (UTC)

Skull and crossbones.svg Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of those projects! Please link to annoncment in ruwiki, lvwiki, itwiki, arwiki. Eran (talk) 12:23, 9 September 2016 (UTC)

comment (P2315)[edit]

comment (P2315): (delete | history | links | entity usage | 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)
  • For the original use case, please find a new proposal at Wikidata:Property proposal/Property constraint comment.
    --- Jura 11:30, 5 August 2016 (UTC)
  • Symbol delete vote.svg Delete - Even if in some cases can be useful for editors, it's too tempting for introducing unstructured data, which is totally useless for users. So should be removed, editor comments can always be written in the talk page. —surueña 11:21, 17 August 2016 (UTC)
  • Pictogram voting comment.svg Comment - I've been using this property in cases where I should have been using Wikidata usage instructions (P2559). My bad. --Arctic.gnome (talk) 15:48, 30 September 2016 (UTC)

Symbol keep vote.svg Keep: Comments linked with by this property are under CC0. Talk pages are given under CC-BY-SA. CC0 (talk) 19:31, 29 October 2016 (UTC)

@CC0: I don't see why one can't license one's talk page contributions under a less restrictive license than is required. Pppery (talk) 02:41, 26 December 2016 (UTC)
  • Symbol delete vote.svg Delete I think we created the necessary replacement/expanded its scope where needed.
    --- Jura 19:11, 15 January 2017 (UTC)

ISO standard (P503)[edit]

ISO standard (P503): (delete | history | links | entity usage | logs | discussion)

Bad datatype. Should be item like ISO 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 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)
Symbol keep vote.svg Keep I suggest using described by source (P1343) to indicate that an item is referred to in a particular ISO standard. Pixeldomain (talk) 05:00, 18 January 2017 (UTC)

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)


exclave of (P500): (delete | history | links | entity usage | logs | discussion)

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


primary destinations (P1302): (delete | history | links | entity usage | logs | discussion)

Propose to merge with place served by airport (P931) and rename it to "places served". GZWDer (talk) 20:42, 2 August 2016 (UTC)

@Thryduulf: You comment doesn't make sense in this section. Neither Rail Accident Investigation Branch (Q7283877) nor World Association of Zoos and Aquariums (Q60427) do use primary destinations (P1302). --Pasleim (talk) 08:46, 3 August 2016 (UTC)
Fair point, this shows the importance of reading what is written not what you assume is written. My appologies. Thryduulf (talk) 11:57, 3 August 2016 (UTC)

BA candidate.svg Weak oppose certainly on UK trunk routes "primary destinations" are a specifically defined subset of places served - e.g. M5 motorway (Q1824663) has 12 primary destinations but serves dozens to hundreds of places of various sizes depending how you look at it. I can see value in broadening place served by airport (P931) to something like "place served by port, airport or station" but I don't think merging it with a specific property is the best way forward. Thryduulf (talk) 20:53, 15 August 2016 (UTC)

  • Symbol keep vote.svg Keep Not convinced that the two mix well. P931 is for placed next an airport, the other for destinations. --
    --- Jura 19:11, 15 January 2017 (UTC)


location of spacecraft launch (P448): (delete | history | links | entity usage | logs | discussion)

Use start point (P1427). GZWDer (talk) 17:12, 3 August 2016 (UTC)

Symbol delete vote.svg Delete - launch point for a spacecraft is always the starting point for its journey so I support this merge ArthurPSmith (talk) 14:37, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per my comment on #Property:P546 --Pasleim (talk) 15:58, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:20, 4 August 2016 (UTC)
Symbol keep vote.svg Keep - launch point is a subproperty of starting point, the constraints are different are therefore is very useful to keep it. —surueña 11:08, 17 August 2016 (UTC)
Symbol delete vote.svg Delete I agree this is unnecessarily duplicative. Reguyla (talk) 21:09, 13 October 2016 (UTC)
Symbol keep vote.svg Keep, start point (P1427) for spacecraft is located somewhere on manufacturing company territory. Usually it is very far from launch pad. — Ivan A. Krestinin (talk) 20:28, 24 October 2016 (UTC)

Skull and crossbones.svg Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of those projects! Eran (talk) 12:19, 9 Septemberp 2016 (UTC)

Symbol delete vote.svg Delete MechQuester (talk) 16:45, 8 January 2017 (UTC)
Symbol delete vote.svg Delete. Keeping separate properties just so we can have different constraints seems very odd. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 14 January 2017 (UTC)
Symbol delete vote.svg Delete - yona b (talk) 12:38, 16 January 2017 (UTC)


docking port (P546): (delete | history | links | entity usage | logs | discussion)

Use via (P2825). GZWDer (talk) 17:13, 3 August 2016 (UTC)

Symbol keep vote.svg Keep "docking port" is more equivalent to the particular gate at a terminal that an aircraft uses, and I don't think you would ever assign that using 'via'. If there's another analogous property then I wouldn't object to merging, but I don't see these two as being anywhere close to equivalent. ArthurPSmith (talk) 14:39, 4 August 2016 (UTC)
Ok, I agree significant event (P793) is a good choice here. Fine with deleting P546 in that case. ArthurPSmith (talk) 18:41, 4 August 2016 (UTC)
Symbol delete vote.svg Delete but I prefer not to use via (P2825) but instead significant event (P793). A spaceflight has many key events, and it's excessive to create for each possible event a new property. On Q591584#P793 I demonstrated a while ago how this could work. Soyuz TMA-9 (Q591584) had two docking ports. With the current approach you don't know which port was served first and during which time they were served. Because there are a handful more properties describing key events of the spaceflight, it's in addition hard to extract a timeline of the flight. With significant event (P793) we gain a better overview and can model the whole journey. --Pasleim (talk) 15:58, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:21, 4 August 2016 (UTC)
Symbol keep vote.svg Keep per my comment on #Property:P446surueña 11:11, 17 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim. --Jklamo (talk) 23:39, 8 September 2016 (UTC)
Symbol keep vote.svg Keep, via (P2825) and significant event (P793) are too generic for effective usage. — Ivan A. Krestinin (talk) 20:31, 24 October 2016 (UTC)
Symbol keep vote.svg Keep seems to be in use.
--- Jura 19:11, 15 January 2017 (UTC)


location of landing (P1158): (delete | history | links | entity usage | logs | discussion)

Use destination point (P1444). GZWDer (talk) 17:14, 3 August 2016 (UTC)

  • Sounds reasonable, Voyager 1 (Q48469) already uses that for Jupiter and Saturnus. -- Innocent bystander (talk) 09:49, 4 August 2016 (UTC)
  • Symbol keep vote.svg Keep "landing" may refer to the return, not the destination of the mission - specifically this is how it has been used here for space shuttle flights. I don't think "start point" "Kennedy Space Center" "destination point" Vandenberg airforce base, is what you would expect for a description of a space shuttle flight. Leave location of landing (P1158) as it is. ArthurPSmith (talk) 14:42, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per my comment on #Property:P546 --Pasleim (talk) 15:59, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:21, 4 August 2016 (UTC)
Symbol keep vote.svg Keep per ArthurPSmith —surueña 11:12, 17 August 2016 (UTC)
Symbol keep vote.svg Keep I recommend keeping this one. The location of the landing of a spacecraft could differ from its destination point. For example, a Shuttle mission would have a location of landing of somewhere on Earth but could have a destination point of some point in space, the ISS or Earth depending on the mission and the definition. Reguyla (talk) 21:12, 13 October 2016 (UTC)
Symbol keep vote.svg Keep for the reason stated by Arthur. CC0 (talk) 19:22, 29 October 2016 (UTC)
Symbol keep vote.svg Keep agree with Arthur.
--- Jura 19:11, 15 January 2017 (UTC)


Wikidata month number (P2837): (delete | history | links | entity usage | logs | discussion)

No clear usage; can be replaced with series ordinal (P1545) GZWDer (talk) 17:47, 3 August 2016 (UTC)

Wrong datatype, should be integer, not quantity.
--- Jura 20:01, 3 August 2016 (UTC)
Symbol delete vote.svg Delete - no idea what Jura's referring to; it looks like series ordinal (P1545) is already being used on the months where they are described as subclasses so the data is there. I really don't think it is helpful to have a property like this that is entirely wikidata-internal and applies to only 12 items, there have to be other ways to do it. I would question the creation process on this one. ArthurPSmith (talk) 14:45, 4 August 2016 (UTC)
RE: "applies to only 12 items". You are aware such properties as Swedish county code (P507) never can have very widespread usage! -- Innocent bystander (talk) 15:24, 4 August 2016 (UTC)
@Jura1: during the property proposal, you mentioned that this property could be used by a (non-existent) script by me. As I don't plan to use this property, are there any other application where it is needed? --Pasleim (talk) 16:06, 4 August 2016 (UTC)
The property talk page links to a series of queries .. it works, but it would work better once integer datatype is available. Once it's available, I think we should convert it.
--- Jura 16:14, 4 August 2016 (UTC)
Why can't you use the series ordinal (P1545) qualifier on subclass of (P279) for the month instead of having a separate property? ArthurPSmith (talk) 18:44, 4 August 2016 (UTC)
Probably I'm just too weak with SPARQL or too slow to get it done in 30". Maybe you manage to re-write the query on Wikidata:WikiProject Q5/lists/people who died on their birthday.
--- Jura 11:54, 17 August 2016 (UTC)
@jura1: I rewrote that query such that it doesn't need P:P2837 --Pasleim (talk) 16:30, 12 September 2016 (UTC)
Thanks. I like the way you did the sections. BTW, it times out for me. Will we get integer-datatype anytime soon?
--- Jura 17:32, 12 September 2016 (UTC)
The ticket for the integer datatype is phab:T112247. It doesn't seem we will get it soon. --Pasleim (talk) 18:27, 12 September 2016 (UTC)
Symbol delete vote.svg Delete I don't see any further use cases of this property which couldn't be solved with series ordinal (P1545). --Pasleim (talk) 11:52, 12 October 2016 (UTC)
The change brought the query closer to time-out limit. I restored the use of this property. This should be converted to integer datatype once available.
--- Jura 19:11, 15 January 2017 (UTC)


Saros cycle of eclipse (P2570): (delete | history | links | entity usage | logs | discussion)

The datatype should be item. GZWDer (talk) 17:54, 3 August 2016 (UTC)

Symbol keep vote.svg Keep I don't understand the issue - the cycle value is a number, what benefit is there to making it an item? ArthurPSmith (talk) 14:51, 4 August 2016 (UTC)
ah, ok. The change makes sense then. Is it actually possible to change datatypes (other than what has been done with external identifiers?) I think a completely new property would need to be created to replace this one, and the entries migrated. ArthurPSmith (talk) 20:36, 5 August 2016 (UTC)
change. item datatype has the advantage that you can easily access more information about the specific cylce, especially because there are already Wikipedia articles about single cycles, e.g. Solar Saros 141 (Q7556002), Solar Saros 157 (Q7556018). --Pasleim (talk) 16:16, 4 August 2016 (UTC)
Symbol keep vote.svg Keep We can use the property to indecate what cycle the eclipse is, e.g., Solar eclipse of March 9, 2016 (Q1549112). --Kanashimi (talk) 06:23, 5 August 2016 (UTC)
@Kanashimi: It's not about deleting the property, it's about changing the datatype. Instead of saying it would be --Pasleim (talk) 07:47, 5 August 2016 (UTC)
change. Sorry, I have misunderstand the topic... --Kanashimi (talk) 08:18, 5 August 2016 (UTC)

metasubclass of (P2445)[edit]

metasubclass of (P2445): (delete | history | links | entity usage | logs | discussion)

The property is too difficult to apply and virtually not used anyway (only three times since its creation in January)--JakobVoss (talk) 19:06, 15 August 2016 (UTC)

For reference, the original proposal is here. --Srittau (talk) 19:20, 15 August 2016 (UTC)
What's interesting in this proposal is that ... it was said that there would actually be only a few statements with this property if I recall well. But community approved it knowing that. This makes this deletion proposal even more puzzling to me. author  TomT0m / talk page 20:31, 15 August 2016 (UTC)
Symbol oppose vote.svg Oppose A few use is not really a good reason to oppose. Plus I'm puzzled by Jakob gave another reason in Wikidata:Property_proposal/lower_rank_than : this would be a specific case of a more generic property. But the generic case would be more easy to apply ??? I'm puzzled. Where is the consistency ? author  TomT0m / talk page 20:06, 15 August 2016 (UTC)
It's much easier to tell whether A is somehow-hierarchically-below B than whether A is metasubclass of (P2445) of B. -- JakobVoss (talk) 20:31, 15 August 2016 (UTC)
Also, why launching this proposal before the discussion on the other one is not finished and the not-so-equivalent alternative is not even and might not be created ??? This gives me a really bad taste in the mouth. author  TomT0m / talk page 20:11, 15 August 2016 (UTC)
If a property is used only three times in half a year, I see little practical acceptance nor need of it. I would welcome a more general and less difficult to apply property, such as "subordinated", that subsumes the other proposal, the original intention of P2445 and other (too special or complicated) cases of hierarchical relationships. -- JakobVoss (talk) 20:28, 15 August 2016 (UTC)
No, that does not subsumes meta subclass of as there is information implied by meta subclass of. If A is a metasubclass of B then an instance of A is probably a subclass of an instance of B, which can't be known by this generalisation. And it was already known at the proposal times that there would be just a very few statements with this property. author  TomT0m / talk page 20:35, 15 August 2016 (UTC)
Current uses (2016--11-01): 4 -- JakobVoss (talk) 11:46, 1 November 2016 (UTC)
  • Symbol delete vote.svg Delete practically unused (down to 3 now?). Apparently no uses can be found for this.
    --- Jura 19:11, 15 January 2017 (UTC)
  • Symbol delete vote.svg Delete unused, not external use, difficult to apply.--Jklamo (talk) 00:51, 23 January 2017 (UTC)

number of awards (P2422)[edit]

number of awards (P2422): (delete | history | links | entity usage | logs | discussion)

Seems to be wholly redundant to quantity (P1114). Currently has no more than seven (7) uses. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 13 September 2016 (UTC)

Symbol oppose vote.svg Oppose It is different from quantity (P1114). There could be a quantity X of a particular medal that have been produced which corresponds to quantity (P1114), while only a quantity Y has been awarded, which corresponds to number of awards (P2422). Also, number of awards (P2422) is also used for "number of inductees", so if there is a deletion, some would need to be merged to "quantity" as stated above by Pigsonthewing (talkcontribslogs), but the inductees numbers would need to be merged to "membership" property, although it's not as a good as keeping number of awards (P2422). Thanks, Amqui (talk) 16:42, 19 September 2016 (UTC)
In the unlikely event that we know that a specified number of medals have been made but only some have been awarded, use, say, quantity (P1114) with an "applies to part" = "unissued award" qualifier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:36, 26 September 2016 (UTC)
  • Pictogram voting comment.svg Comment the current English label is ambiguous in the first place, and more akin to "quantity awarded", as by its current label it could be interpreted to the number of awards a person has, eg. number of Grammies won. I tend to favour deletion and stop the propagation of "specialist" labels that can suitably covered by something like "quantity". The more specialist labels makes things more difficult for contributors to have to know or guess, and means that when we come to infoboxes people just get it wrong. Our purpose is to help get it right and easier for infoboxes!  — billinghurst sDrewth 06:53, 5 November 2016 (UTC)

located at street address (P969)[edit]

located at street address (P969): (delete | history | links | entity usage | logs | discussion)

To be replaced with a property "located at street address" (to be created) with a datatype asking for the language of the entry. The same street address is different in different languages. See Wikidata:Project chat#located at street address (P969). Thanks, Amqui (talk) 15:04, 19 September 2016 (UTC)

This should not be deleted, until a new property has been created, and data migrated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 19 September 2016 (UTC)
Process for this should be made clear somewhere, on the Project Chat I have been told the first step for this is to propose the deletion. Requests and procedures on Wikidata seem to be all over the place and very unorganized. Amqui (talk) 16:40, 19 September 2016 (UTC)

See Wikidata:Property proposal/located at street address. Amqui (talk) 16:48, 19 September 2016 (UTC)

  • I do not favour the deletion of this property and its replacement with the alternate proposed property. This property is simple and easy for the addition of a general street address to qualify a birth or death location, and additional components just complicates for no expressed benefit.  — billinghurst sDrewth 06:43, 5 November 2016 (UTC)

I read this request as a difficult way to actually rename the existing property. Moving the contents to a new property will not improve anything. And yes, for me address and located at street address is the same. Are there occasions where it's different? Edoderoo (talk) 19:08, 21 November 2016 (UTC)

There looks to have been an update to the label so that it now reflects the proposal. Can it be closed as unactioned?  — billinghurst sDrewth 04:35, 16 January 2017 (UTC)

NSW Flora ID (P3130)[edit]

Pictogram voting info.svg Info The initial discussion started at Wikidata:Bot_requests#NSW Flora IDs.

@Pigsonthewing, YULdigitalpreservation, ChristianKl: At the moment this property works only for species (formatter: href=/cgi-bin/, but the website has

too. This is simmilar to GRIN URL (P1421) or AlgaeBase URL (P1348). So the datatype of this property should be changed to URL. --Succu (talk) 08:13, 2 September 2016 (UTC)

The problem with Url's is that it makes the data easy to break if they switch away from the php formatted links. ChristianKl (talk) 18:26, 26 September 2016 (UTC)
Not really. See GRIN urls changed. It's also easy to apply URL constraints. --Succu (talk) 18:38, 26 September 2016 (UTC)
  • Oppose deletion until the alternative solutions (plural) I put to Succu on the bot requests page have been properly discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:31, 26 September 2016 (UTC)
    Mind to repeat them? --Succu (talk) 18:38, 26 September 2016 (UTC)
    There's a link to the discussion in the first line of this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:42, 26 September 2016 (UTC)
    Obviously it matters to you... (colons too) --Succu (talk) 18:49, 26 September 2016 (UTC)

Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Michael Goodyear
Andy Mabbett (talk)
Prot D
Rod Page
Soulkeeper (talk)
Tommy Kronkvist (talk)
Pictogram voting comment.svg Notified participants of WikiProject Taxonomy --Succu (talk) 21:52, 29 September 2016 (UTC)

I am not a big fan of URL's in Wikidata (unwieldy), and actually I would be in favour of switching GRIN from URL to external identifier (should be quite doable). Having said that, this particular case is a very poor candidate for an external identifier, as it apparently would lead to "in&name=Avicennia~marina+subsp.~australasica" as a external identifier, which is just as unwieldy as a full URL. - Brya (talk) 10:49, 30 September 2016 (UTC)
Brya: Could you express your concerns about datatype URL a little bit more please? --Succu (talk) 19:19, 30 September 2016 (UTC)
My unease consists of two points: 1) if one checks an item the URL's are in a place where one does not expect them (GRIN is in a different block from GBIF, ITIS and other such databases). 2) readability of a URL is very poor (too long). - Brya (talk) 19:28, 30 September 2016 (UTC)
Thanks. So both of your concerns are about the handling by the Wikidata UI I think. The migration to external ID resulting into the rendering it in a separated section has a lot of pro and cons but was leaving the datatype URL behind. I'd like to see them united. I'm not sure how this could be done, but I'am sure that declaring fragments of an URL as an external ID is the wrong way. --Succu (talk) 20:19, 30 September 2016 (UTC)
There are adjacent solutions:
  • P:P2772, P:P2773, P:P2774, P:P2775, P:P2776, P:P2777, but I would not propagate that for taxon items like this one.
  • P:P2549 having indeed a combination of two parts in the ID. I don't see much objection in using something similar here for the identifier, hence having "lvl=fm&name=Acanthaceae" as the identifier, which indeed is the identifying part.
Therefore Symbol oppose vote.svg Oppose to deletion and change into URL-datatype. Lymantria (talk) 07:22, 3 October 2016 (UTC)
A part of an Uniform Resource Locator (Q42253) like lvl=in&name=Avicennia~marina+subsp.~australasica is not an identifier (Q853614). An Uniform Resource Identifier (Q61694) like URL is. --Succu (talk) 18:39, 3 October 2016 (UTC)
A part of a Uniform Resource Locator (Q42253) may not be an identifier (Q853614), an identifier (Q853614) may become part of a Uniform Resource Locator (Q42253). Lymantria (talk) 19:40, 4 October 2016 (UTC)
Lymantria: Please, could you provide more details? I do not understand what your point is. --Succu (talk) 19:45, 4 October 2016 (UTC)
My point is that I disagree with you that lvl=in&name=Avicennia~marina+subsp.~australasica cannot be considered an identifier. The actual fact that the identifier is made part of a URL is hardly an argument. Lymantria (talk) 19:49, 4 October 2016 (UTC)
So a part of an ID makes it an ID of its own? --Succu (talk) 20:02, 4 October 2016 (UTC)
Nope. And that is neither what I said, nor what I meant. But the ID has become part of the URL. Do you suggest that the part does not identify the database entry uniquely? Lymantria (talk) 20:14, 4 October 2016 (UTC)
Yes: A part of an Uniform Resource Identifier (Q61694) is not an ID. A part of International Standard Book Number (Q33057) like 0 is not an ID. --Succu (talk) 20:47, 4 October 2016 (UTC)
You seem to state that you want to delete Property:P3035 and Property:P3097? That would take a new deletion request. But what you say about the general case, would mean that ID's with a formatter URL cannot be ID's, because the URL is already an ID. I fail to understand that. Lymantria (talk) 05:33, 5 October 2016 (UTC)
Of course not. formatter URL (P1630) is a shortcut for an external id e.g. for an internal database table id (unique key (Q934729)). Saying 0-9538134-4-5 could be identified by International Standard Book Number (Q33057)=0 alone makes no sense to me. A Compound key (Q5156838) should not treated this way. --Succu (talk) 22:29, 5 October 2016 (UTC)
But then, the actual problem is that - just like International Standard Book Number (Q33057) - its identifier consists of two parts, one describing "lvl" (somewhat similar to "level"), and one pointing to the actual taxon. There is even a third, "page=nswfl" pointing to the database. The mere fact that the UI does not allow multiple part entries for ID's does IMHO not disqualify these to be identifiers, combined into a single identifier.
Would we switch to URL, then there is the interesting fact that there is no reason to not insert a shortcut like lvl=in&name=Avicennia, which interestingly is functioning, but in fact gets close to your mentioning about 0-9538134-4-5 identified by International Standard Book Number (Q33057)=0. I would not be in favour of that kind of use. Lymantria (talk) 14:12, 6 October 2016 (UTC)
Looks like that Italian Senate of the Republic ID (P2549) was later misused ([1]). --Succu (talk) 19:51, 4 October 2016 (UTC)

New York Times Semantic Concept: Person (P2690)[edit]

New York Times Semantic Concept: Person (P2690): (delete | history | links | entity usage | logs | discussion)


These each have been used at most twice (on example cases); the formatter URL does not work as given (requires an additional key parameter) and there is a new property NYT topic ID (P3221) that covers the same ground.--ArthurPSmith (talk) 17:31, 29 September 2016 (UTC)

  • Keep This is a very different concept to the new property, and the values are not compatible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 29 September 2016 (UTC)
  • For reference, I extracted the original proposal to Wikidata:Property proposal/New York Times Semantic Concept. I won't oppose the deletion, it was a very borderline decision to create those properties in the first place and they have gained no traction in the half year since then. But Andy is correct in pointing out that NYT topic ID (P3221) is a very different property from this one. These properties link to the (half-hearted) semantic data initiative of the New York Times, while NYT topic ID (P3221) just links to topical pages, not semantic information. --Sebari (Srittau) (talk) 21:46, 29 September 2016 (UTC)
    • I'm not sure I see a practical difference between "topical page" and "semantic information" at least in this case - basically both are controlled vocabularies that define a subject area on which the NY Times has published. Wikidata items are semantic concepts in themselves, so however we link NY Times data to wikidata in practice what we're doing is linking it in to the semantic web. ArthurPSmith (talk) 14:18, 30 September 2016 (UTC)
      • They are not strictly equivalent, topic pages appear to be a subset of Semantic API Concepts. Thinkcontext (talk) 15:48, 4 October 2016 (UTC)
  • Pictogram voting comment.svg Comment The formatter URL for these properties is not working. If the properties stay, it should be fixed.
    --- Jura 08:17, 1 October 2016 (UTC)
    • I mentioned that in my initial deletion comment. I don't believe the formatter URL is fixable, there doesn't seem to be a way to access these concepts without the developer key. ArthurPSmith (talk) 18:21, 3 October 2016 (UTC)
      • An external identifier doesn't need a formatter url. The property could exist without a formatter URL. There are obviously other reasons why this property could be deleted.
        --- Jura 06:05, 6 October 2016 (UTC)

Regarding formatter URLs, an issue which will recur, please see Wikidata:Project chat#Formatter URLs requiring API keys. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 4 October 2016 (UTC)

Symbol delete vote.svg Delete: Obviously an unfit closed Dataset. --Succu (talk) 21:00, 4 October 2016 (UTC)

  • The data set is not closed; it is open to anyone with an API key. Please point to a policy requiring the data sets to which we link to not have that requirement. And please justify your "unfit" claim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 5 October 2016 (UTC)
    • The dataset is closed with a personal API key. You can not link to the information without your personal API key. --Succu (talk) 16:05, 5 October 2016 (UTC)
      • You have simply rephrased what I said. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 5 October 2016 (UTC)
        • @Succu: perhaps the main concern is the terms of use? Though I haven't read carefully, I assume we can't just register a key for "wikidata" and insert that into all the formatter URL's for everybody to use? Do the terms of use even allow extracting the concepts into wikidata? Not clear to me what the licensing constraints actually are. ArthurPSmith (talk) 13:16, 7 October 2016 (UTC)
          • Sharing a key would be a violation of their terms of use. I can say anything to the other questions. --Succu (talk) 15:15, 7 October 2016 (UTC)
  • Symbol delete vote.svg Delete only used in about 5 items. Closed data. This is not going to work. Multichill (talk) 19:10, 5 October 2016 (UTC)
    • ITYM "only used in about 5 items so far". Please point to a policy requiring the data sets to which we link to not require an API key. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 6 October 2016 (UTC)
      • Stop Wikilawyering and start using common sense. Multichill (talk) 15:27, 7 October 2016 (UTC)
  • Symbol delete vote.svg Delete we should only link to open databases. A database which requires an API key to read the data is against the spirit of providing free knowledge to everyone. --Pasleim (talk) 11:57, 12 October 2016 (UTC)
    • There is no policy nor precedence for this. We record several identifiers with no formatter URL, nor even any online presence at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:04, 13 October 2016 (UTC)
  • Symbol delete vote.svg Delete practically unused. Apparently no uses can be found for this.
    --- Jura 19:11, 15 January 2017 (UTC)
  • Symbol delete vote.svg Delete in its current state. If they open it (more) widely, ie. suitable organisational access, then we can review. We should be encouraging open datasets! To "Pigsonthewing" this is not case of looking for prescriptive "blackletter policy", it is about usability and functionality, and the project's ability to make a reasoned determination where a dataset is functionally closed for the purposes of our project. If they want in, they can read this discussion and look at what they want to do.  — billinghurst sDrewth 04:55, 16 January 2017 (UTC)
  • Symbol delete vote.svg Delete Unused, no external use of properties, closed database. --Jklamo (talk) 00:55, 23 January 2017 (UTC)

Onisep occupation ID (P3214)[edit]

image of grave (P1442)[edit]

OpenStreetMap Relation identifier (P402)[edit]

OpenStreetMap Relation identifier (P402): (delete | history | links | entity usage | logs | discussion)

See discussion at (pinging Yurik, Jura1, MaxSem and Kolossos). Wikidata item IDs can already be found in OpenStreetMap (and can be pulled by an API), and since OSM IDs are more flexible there's no point in having the information here as well because it's more likely to become outdated. In addition, only relations can be linked to with the property (because of volatility of other OSM objects), which is another inherent drawback. —Jc86035 (talk) 14:27, 5 November 2016 (UTC)

  • Symbol delete vote.svg Delete 100% agree, we should encourage Wikidata ID usage on OSM side, and possibly even help with our bot running prowess to convert all existing "wikipedia" tag to "wikidata" tag.
    P.S. the data should be moved to OSM before being deleted. --Yurik (talk) 14:46, 5 November 2016 (UTC)
  • Symbol delete vote.svg Delete To start, I must say that I agree on the subject matter, and have kept it as my guideline over the years. However, I see great difficulties for non-coders, to make a combined query in OSM and Wikidata. What if OpenStreetMap Relation identifier (P402) was automatically, regularly updated by a bot? Perhaps both ways, also the Wikidata ID in OSM with fresher data from Wikidata. I fear that playing around with this data will only be available for few. --Susanna Ånäs (Susannaanas) (talk) 15:09, 5 November 2016 (UTC)
    Susanna Ånäs (Susannaanas), if I understand you correctly, your objection is about tooling, not the database storage. And tooling can be greatly improved without the need to duplicate data. Data duplication produces inconsistencies and errors, as you will no longer know which data is authoritative, and some changes may be introduced in both. I suspect that it would be relatively easy for the overpass API to support Wikidata. Moreover, I would insist we should improve all other OSM-related tooling to natively support Wikidata, as that will allow much richer meta-information querying. The US governor map example is exactly that - a mixture of OSM and Wikidata that the less technical (SPARQL-only) community can use. We should do more of this kinds of tools. --Yurik (talk) 18:47, 5 November 2016 (UTC)
    I would be more than happy to vote for deletion, if the connection would work ubiquitously. I am however one of those less technical, and I possibly cannot make fool-proof arguments. When I was creating the Wikidata IDs for Finnish municipalities in OSM for a classroom assignment (they are still not all there), I would have needed a combination of Overpass + SPARQL to sort out which links between Wikidata and OSM were missing. That was beyond my skills. I could have used the Wikipedia data of the municipalities and made a query for those with a missing OSM id. But thinking how I would do it in OSM, or programmatically add those in OSM would be far too complex. So yes, it's about tooling, but in many ways. --Susanna Ånäs (Susannaanas) (talk) 20:31, 5 November 2016 (UTC)
    I have changed my vote to delete, with the idea that the connection must work ubiquitously without the need for the ID. --Susanna Ånäs (Susannaanas) (talk) 10:14, 13 November 2016 (UTC)
  • Symbol delete vote.svg Delete P402 have never made sense to me because it's only in rare cases there is a actual relation in OSM and not a node or way. Using the Overpass API is a much better solution. --Abbe98 (talk) 17:58, 5 November 2016 (UTC)
  • Symbol delete vote.svg Delete once data is migrated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 7 November 2016 (UTC)
  • Symbol delete vote.svg Delete Using of Overpass-API[2] makes P402 obsolete. --Kolossos (talk) 18:19, 7 November 2016 (UTC)
Pictogram voting comment.svg Comment Made up queries ("The original search was: “wikidata=Q874373”) make no sense, who would query the Eiffel Tower by wikidata=Q243.
Few users would know id of Effel Tower in Wikidata. It is hardly usable, unless you know every id in Wikidata.
Then, how overpass can replace current ? It makes querying Wikidata more complex, not simpler.
IMO it is too early to speak of replacement, until users are okay with implied penalty when it comes to federated SPARQL services. d1g (talk) 15:33, 28 November 2016 (UTC)
  • Symbol keep vote.svg Keep There is no viable alternative. OSM relation ID are pretty stable, for example for Prague (Q1085) ID is 6 years old (see history) and it is unlikely to be changed. Many of databases having its own property on WD will not exist after 6 years. On cswiki we use these IDs for long time without any problem, so now we use OpenStreetMap Relation identifier (P402) in multiple templates. Simplest Template:OSM relation (Q6177348) exists on 28 projects. KML file (P3096) is very bad alternative. --Jklamo (talk) 23:06, 7 November 2016 (UTC)
    • @Jklamo: See below; we can query their database for each item instead. As a counterexample to administrative boundaries, public transport relations are often deleted or even repurposed (since there are two different schemas, one deprecated). In addition, even if other databases link back to Wikidata, any Wikidata editor can also edit OpenStreetMap and vice versa, making it useless to have two copies of the same data by two overlapping groups of editors. Jc86035 (talk) 10:52, 13 November 2016 (UTC)
      • @Jc86035: I cannot see any comparable alternative. OpenStreetMap Relation identifier (P402) allows simple direct link from wiki to OSM without need of querying, 3rd party tool/services, gadgets or mw extensions. OSM relations may be unstable if they are incomplete, so mergers are sometimes necessary, but once relations are complete, they are pretty stable. Even for public transport relations - just random example from my country here - osm relation of Prague tram line no. 3 is 5 years old. Note also that at the moment OpenStreetMap Relation identifier (P402) is used mostly for administrative boundaries and streets (see query). --Jklamo (talk) 00:06, 14 November 2016 (UTC)
        • @Jklamo: But what's the point of having it if our dataset is only about one-quarter the possible size of theirs and we can easily access theirs? It's kind of like having old-style interwiki links, but only having them for one namespace on one of the wikis. Jc86035 (talk) 05:13, 14 November 2016 (UTC)
Pictogram voting comment.svg Comment > but once relations are complete, they are pretty stable. ... osm relation of Prague tram line no. 3 is 5 years old
Completely agree with @Jklamo:, I have same experience with objects I edit or watch. Tram/metro infrastructure is very stable.
"Keep history" is a good practice in OSM. Experienced users won't change ids every time they touch objects (nodes/ways/relations).
Since 2015 JOSM provides a feature where to keep "history" of the slitted way.
Bus schedules and detours change frequently sometimes. Discussions stability of bus route id (both in WD or in OSM) won't lead to any meaningful results to the end users (both WD or OSM users).
Public transport schema was established in 2011 (route_master=*). We can't retag objects quirkier than what we have or we don't have local knowledge.
d1g (talk) 15:07, 28 November 2016 (UTC)
    • As of January 2017 the property is used in 24 templates at 7 projects.--Jklamo (talk) 00:40, 23 January 2017 (UTC)
  • Pictogram voting comment.svg Comment @Yurik, Pigsonthewing, Susannaanas, Abbe98, Kolossos, Jklamo: See 2016 Community Wishlist Survey. Jc86035 (talk) 10:07, 13 November 2016 (UTC)
  • Symbol keep vote.svg Keep From the users' comments above, I take it that these links are stable. That OSM links to Wikidata is a good thing. There are several other databases that link to Wikidata, but we still don't remove them from here.
    --- Jura 10:23, 13 November 2016 (UTC)
    • @Jura1: Even if relations are stable, it doesn't change the fact that in OSM relations make up about 0.1% of objects, and we can't link to any of the others because they get deleted all the time. They can link to our database, and here items get merged much less (and redirects are kept). Jc86035 (talk) 10:46, 13 November 2016 (UTC)
      • That's still 4.5 million relations. We don't really have that many more items that could get coordinates/such identifiers.
        --- Jura 17:07, 13 November 2016 (UTC)
        • @Jura1: Using more useful data, there are three times as many nodes and ways with Wikipedia/Wikidata tags as there are relations (see Key:wikidata). If they have a more complete dataset, we may as well just use theirs. Jc86035 (talk) 05:13, 14 November 2016 (UTC)
          • I'm not saying that for your non-Wikidata specific application, you can't use a third party service for better coverage. For many identifiers, the source site holds more data than Wikidata. This isn't a problem as such. Besides, in this case, it's not possible that there be three times as many items linked once we have 4.5 million relations: Wikidata simply doesn't have 1,000,000,000 items to start with (in case you wanted to link every node to a Wikidata item).
            --- Jura 08:36, 14 November 2016 (UTC)
            • @Jura1: The fact remains that many objects, like almost all villages and towns which don't have administrative boundaries (as well as most buildings, beaches, small islands, parks, forests, lakes, rivers and sports grounds), are never going to get their own relations because there's no need for that to happen. Of course, it might end up being the norm for relations to be created entirely for the purpose of linking from Wikidata to them, but that'd just be a massive waste of time because we can already link the other way. Jc86035 (talk) 13:44, 20 November 2016 (UTC)
  • Symbol delete vote.svg Delete, volatile and leads users to technical innards that are unlikely to be useful for them. MaxSem (talk) 22:34, 21 November 2016 (UTC)
    • That is the question that was at the beginning of this request. The conclusion is that it's actually stable. A third party service is offered as replacement, however, I don't know about its stability.
      --- Jura 22:40, 21 November 2016 (UTC)
      • @Jura1: I literally just had to change the relation ID of a route because an OSM editor changed the relation referring to the entirety of it with another one. If we had a bot to go around and check for these changes (like the old interwiki bots), then ideally we would have properties for OSM nodes and ways as well, but there obviously isn't such a bot right now and I'm not sure how much support making one would have. Jc86035 (talk) 12:35, 27 November 2016 (UTC)
  • BA candidate.svg Weak oppose (changed from "Keep") I would like for us to link to OSM too, not just the other way around, as it makes some queries simpler from Wikidata. But I don't sufficiently grok the different properties needed for that, and I have the feeling that some people in the OSM community seem to be opposed to have datasets uploaded. Before these datasets are lost, I'd like to see them added to Wikidata and preserved. But I have not sufficient background on the relation between Wikidata and OSM, and how OSM is doing things. (The rest is old comment) OSM seems to be reluctant to accept Wikidata IDs and, even if in, rather quick in deleting them again, which leads to a loss of information. Even if the IDs are not 100% stable, we can at least save them here. The important thing is that these IDs are not reused, even when they change, so that we don't accidentally link to the wrong thing. I would suggest to keep this property here and to extend its coverage considerably. --Denny (talk) 22:51, 28 November 2016 (UTC)
    • OSM is not reluctant to accept Wikidata IDs. One OSM editor has recently thrown his toys out of the proverbial over a set of automated edits that, he claims, broke the letter (not intent), of OSM's automated edit policy, but other such edits have not been problematical, and the number of Wikidata IDs in OSM is growing steadily and at an accelerating rate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 2 December 2016 (UTC)
    • @Denny: OSM does not seem reluctant to accept Wikidata IDs to me. In fact, the default editor on their website (iD) automatically adds Wikidata tags whenever someone links to Wikipedia (see this blog post for a demonstration). It's mass automated edits that (some) OSM people don't like. - Nikki (talk) 18:01, 2 December 2016 (UTC)
  • Symbol delete vote.svg Delete I am in favour of changing the current situation, either by deleting P402, or by adding properties for linking to ways and nodes (which has been rejected multiple times). Anyone who wants to get links between Wikidata and OSM can't rely on our data because it deliberately omits most of them and so will need to query OSM anyway. The data for this property is unreliable too, because people keep using it to add IDs of nodes and ways (e.g. Special:Diff/409526821, Special:Diff/398588794). - Nikki (talk) 18:01, 2 December 2016 (UTC)
    • If we delete all properties where our data might not be perfect and some other source provides a link to Wikidata, we might and up deleting most of our properties.
      --- Jura 11:39, 10 December 2016 (UTC)
      • Slippery slope arguments are rarely good arguments. Nobody (except maybe you) is going to propose deleting everything just because one thing is judged to better handled in a different way, so that does not seem like a valid argument for keeping the property. - Nikki (talk) 12:50, 10 December 2016 (UTC)
        • Well, stating that it needs maintenance isn't really a good argument either.
          --- Jura 13:08, 10 December 2016 (UTC)
          • I did not argue that we should remove it because it needs maintenance and if you think I did, you've misunderstood what I said. My argument is that the current status - disallowing most links while allowing a small subset - is fundamentally flawed and that would not change even if our data were perfectly maintained. - Nikki (talk) 12:32, 14 December 2016 (UTC)
            • There are actually quite a lot of relations available we could import.
              --- Jura 19:11, 15 January 2017 (UTC)
  • Symbol delete vote.svg Delete We are steadily adding Wikidata identifiers to OSM, and extracting information from OSM to build a service is way easier (the WMF services are already doing it I believe). IDs aren't guaranteed to be stable (the argument "it's stable since x years" is invalid IMHO, because it covers only a small fraction of possible Point of Interests: museums could be represented either as nodes, ways or relations, and moving the information from a node to a way it's a common operation which changes the ID). Having a process that runs on the current OSM data could also help mantain Property:P625 with a bot --Sabas88 (talk) 17:23, 10 December 2016 (UTC)
  • Pictogram voting comment.svg Comment Are people supporting deletion coming here based on some invitation on OSM?
    --- Jura 18:09, 12 December 2016 (UTC)
    • @Jura1: I don't think so, although it might be a good idea to notify either the OSM wiki's community portal(?) or the talk mailing list, as I haven't done that yet. However, many of the participating editors, including myself, are also OSM mappers. Jc86035 (talk) 06:55, 14 December 2016 (UTC)
  • Symbol keep vote.svg Keep. That OSM has its own system is not our business. Thierry Caro (talk) 10:08, 14 December 2016 (UTC)
    • @Thierry Caro: But you are aware that keeping data which might be outdated unnoticedly might not be a good idea? For example, say the building of a reputated organization which has a Wikidata entry consists of a (multipolygon) relation. Consider further that someone then thinks that a MP is not the way to go, because the building has a quite simple shape and turns it into a way, discarding the multipolygon. And voilà – the data inconsistency is gone. Thus a GA candidate.svg Weak support from me. --Glglgl (talk) 16:04, 14 December 2016 (UTC)
  • Pictogram voting comment.svg Comment OpenStreetMap regular here - Wikidata IDs have been added to OSM objects en masse in the past weeks without the requisite discussion on OSM side; more than 100,000 by Yurik alone. These additions have been overwhelmingly been automatic (based sometimes on existing Wikipedia links, sometimes on name/type/coordinate matching) and are of sub-standard quality for OSM (because they have been mostly done by people without local knowledge who did't understand the difference between two similarly named administrative entities that share a Wikipedia but not a Wikidata entry etc). It is therefore not a given that these links will be allowed to remain in OSM, and if they are, it is quite possible that data consumers will shy away from using them because of the sub-standard quality. 15:19, 14 December 2016 (UTC)
    • Hi, just to clarify - I have posted about it to the OSM talk list, and I only converted existing Wikipedia links into their corresponding Wikidata IDs. I know others might have done more "risky" edits such as auto-discovering corresponding Wikipedia article, but in this case, each Wikidata item corresponds to exactly one Wikipedia link, so this is more like locking the WP link in place, in case the article gets renamed. Similarly named places don't really relate to this issue, unless both places link to the same Wikipedia article, so, by extension, they will link to the same Wikidata item. On the other hand, having Wikidata items allow for much better cross-site quality validation, because you can compare tags on the element with the statements in Wikidata. --Yurik (talk) 18:51, 14 December 2016 (UTC)
    • Further to Yurik's response: The IP's comment is ambiguous. When they say "not a given that these links will be allowed to remain in OSM" they refer to the specific subset of Wikidata IDs in OSM described in their comment, not to Wikidata IDs in general. The "sub-standard quality" bar is pure FUD. I too, speak as an OSM regular. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:27, 14 December 2016 (UTC)
  • Symbol keep vote.svg Keep. I think it's useful to have links to OSM from Wikidata, even if the reverse link is also present in OSM, partly because it's easier for data-consumers of Wikidata to use (not having to call a separate API), and partly because there might be some legitimate disagreement about what the 'right' concordance should be (e.g. Wikidata editors might link two different items to the same OSM relation, but OSM might only consider that a single Wikidata item should be linked back). OSM relation IDs are roughly as stable as Wikidata IDs (which can change, for example, if two items are merged, or one is mistakenly deleted and then re-added). The fact that some OSM nodes and ways don't belong to a relation shouldn't stop us having the property, particularly as I don't think there's any rule in OSM against adding a single way to a relation, for the purposes of adding semantic information to the relation. Frankieroberto (talk) 09:44, 6 January 2017 (UTC)
    • @Frankieroberto: I don't think there's a way of putting the information of a single node into a relation, because aside from this very narrow scope it would be completely pointless. This might be rather annoying for places that don't have exact boundaries, as well as things like trees which can't be tagged as areas. Jc86035 (talk) 09:13, 8 January 2017 (UTC)
      • A relation is simply an object which contains other nodes, ways and/or relations. You can have a relation with just one object (in fact, you can have a relation which contains no objects at all) but creating a relation for something which can already be represented by a single node or way is redundant (nodes and ways can have tags, so you don't need a relation to add semantic information) and doesn't add any value to OSM, so it's not something we should encourage people to do. - Nikki (talk) 11:56, 8 January 2017 (UTC)
        • @Nikki: I meant as in there isn't a valid relation type which could do that. You could have a multipolygon containing a single way, but there's no such way (AFAIK) to do that for a node. Jc86035 (talk) 01:17, 11 January 2017 (UTC)
          • @Jc86035: Ah, I think what you're saying is that there's no established use for a relation with a single node? (I wouldn't use "valid" to describe that, you're allowed to come up with new tags if you can't find any existing tag that fits). - Nikki (talk) 13:40, 11 January 2017 (UTC)
            • @Nikki: Whilst it might often be redundant in OSM to create a relation containing a single node or way, I don't think there's any specific rule or guidelines against it, and in practice it probably happens quite a bit. Eg the stop area tag is almost always applied to a relation, and whilst that normally covers at least two nodes (one for the stop on either side of a road), this isn't always the case. Frankieroberto (talk) 21:07, 16 January 2017 (UTC)
              • @Frankieroberto: I meant as in for general use cases (there's no multipolygon equivalent for nodes), for things like trees and other nodes which can't be mapped as areas. I suppose it's possible that we could make (for example) metadata relations where the only tags are type=metadata and wikidata=Qxxx, but it seems like a confusing waste of time. Jc86035 (talk) 02:38, 17 January 2017 (UTC)
  • Pictogram voting comment.svg Comment, right now I'm leaning on Symbol keep vote.svg Keep. I don't really see the problem with this property. Redundancy: 100 % of Wikidata is redundant (we even give the link in reference to tell from where it's redundant). Pull from OSM: not really easy and you need a different tool (a lot of people have trouble using Query, learning yet another tool is not a good idea and - I find - overpass turbo to be particularly slow and complex to use; see my recent examples on Wikidata talk:OpenStreetMap). Unstable: all link outside (and even some inside) Wikidata are unstable, and OSM relations are quite stable. In the end, the deletion doesn't seems the appropriate answer for the question here, can't a tool/script/bot periodically check is the link is still ok? (like I said, it could be useful for other properties too). Cdlt VIGNERON (talk) 16:23, 9 January 2017 (UTC)
    • @VIGNERON: I think there are APIs aside from overpass which can pull OSM data, such as the one used in Kartographer, but in my experience Overpass is sufficient, if a bit clunky and slow. I believe there have been proposals to update data with bots before, but they did not pass and that's why we don't have properties for ways and nodes. A proposal to keep Wikidata synched with external databases (which would include OSM) is #36 on Meta's Community Wishlist Survey, but it's not likely to receive much attention. Jc86035 (talk) 01:17, 11 January 2017 (UTC)
      • Yes, Overpass is nearly almost ok and yes, there is probably hundreds of ways to pull from OSM, but that's beside the point ; I've got a problem with the « pull » itself; if you split the date in two places, it's way more complicated to do query on both of them. Update data by bots is at best complicated and often kind of stupid and I'm glad it did'nt pass, I asked for a « check » not for an update (and not only for OpenStreetMap Relation identifier (P402) but for all properties that generate links since most URL aren't stable, even less stable than OSM relations). Finally, Wikidata ID are not stable either, is someone checking on OSM side if the link are still valid? Cdlt, VIGNERON (talk) 11:10, 11 January 2017 (UTC)
        • @VIGNERON: I think you're better off asking someone else for most of the details, as I don't primarily edit Wikidata and don't run bots, but I think OSM editors are assuming that Wikidata QIDs stay there for basically forever and that redirects from item merges won't be deleted or usurped. Do Wikidata items get split often? Jc86035 (talk) 13:55, 11 January 2017 (UTC)
          • Not often but it happens (I don't know if there is stats on this matter, when I look in the deletion log - Special:Log - most of them seems just non-sense being rightfully deleted but I've seem some case where users delete instead of merging or even reuse and change completely an item, the latter won't show on logs and would be hard to track, impossible for a bot). Cdlt, VIGNERON (talk) 14:19, 11 January 2017 (UTC)
  • Symbol keep vote.svg Keep What is the problem of having OSM relations numbers here??? It takes so little storage space in DB that the discussion about deleting the property seems to be largely irrelevant here... This is more of a chicken/egg problem - should Wikidata have OSM relations numbers or OSM relations have wikidata IDs on them??? An extreme resolution could be these would be deleted on both sides and then we would end up having NOTHING at all! Is this what you want? Or rather a little redundancy in having the information on both sides? Redundancy is never bad (it is actually desirable!!!) if one can bear the storage costs (the cost is negligible in this case). So strong keep from myself. --Kozuch (talk) 09:29, 17 January 2017 (UTC)
    • @Kozuch: it makes a lot more sense to only bother adding Wikidata IDs to OSM, because (a) Wikidata has only one type of entity which should be linked, and (b) you can't use the Wikidata property to pull OSM objects through Extension:Kartographer (which is why I started this discussion). Until we have bots to scour OSM for Wikidata IDs and conflicts/errors (and vice versa), the property's data is likely to slowly become outdated as well as polluted with way and node IDs. Your "extreme resolution" is a pointless strawman argument. I would argue that it's not necessarily good to have redundancy right now, because it's a waste of editors' time to have to add data to both projects (manually or semi-automatically). Jc86035 (talk) 10:59, 17 January 2017 (UTC)
  • Comment Made a bot request which affects this discussion. Jc86035 (talk) 11:52, 17 January 2017 (UTC)
  • Symbol keep vote.svg Keep As per J Klamo.--Sascha GPD (talk) 17:57, 20 January 2017 (UTC)

member of political party (P102)[edit]

contains administrative territorial entity (P150)[edit]

contains administrative territorial entity (P150): (delete | history | links | entity usage | logs | discussion)

Duplicates in the administrative territorial entity (P131) - creating two way links is always error prone - there are 71,857 of P150, and 3,520,325 of P131, which means most of the time we only link one way, from child to parent. We can easily query the whole tree top to bottom using this query:

PREFIX gas: <>
SELECT ?item ?itemLabel ?itemAltLabel ?itemDescription ?linkTo ?depth WHERE
  SERVICE gas:service {
    gas:program gas:gasClass "" ;
                gas:in wd:Q145 ;
                gas:traversalDirection "Reverse" ;
                gas:out ?item ;
                gas:out1 ?depth ;
                gas:out2 ?linkTo ;
                gas:maxIterations 2 ;
                gas:linkType wdt:P131 .
  FILTER EXISTS { ?item wdt:P31/wdt:P279* wd:Q56061 }
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" .
ORDER BY ?depth

Try it!--Yurik (talk) 05:09, 24 November 2016 (UTC)

I agree that it should be deleted, but it is currently being used by the French Wikipedia (see fr:Catégorie:Page utilisant P150) and I don't think it would be fair to delete it until there is another way to fetch the data. - Nikki (talk) 19:39, 25 November 2016 (UTC)
Sigh, this is a very fair point. Plus I can totally see the value in editing them all in one place (linked from the WP article) rather than editing all the different subdivisions one by one. User:Lydia Pintscher (WMDE) (talkcontribslogs) or User:Daniel Kinzler (WMDE) (talkcontribslogs), is there any way to solve this? Ideal case:
  • In the infobox, show the list of { ?item P151 Qnnnnn } subjects, but with additional condition (e.g. only those that are subclusses of an administrative district.
  • Easy to edit multiple items to add a property pointing to the given subject (editing the foreign key on subjects so they all link to the current one). This way info boxes would contain the list, but users can change it easily. TBD: what if that property is already set, but points somewhere else?
--Yurik (talk) 07:43, 26 November 2016 (UTC)
The only suggestion I have for doing this is to write a gadget that provides this kind of editing interface would be two write a Gadget that does what you suggest.
However, this isn't just about editing, it's also about showing a list of things in a single place. This is easy to do with an outside tool based on a SPARQL query, but we currently have no way to show the result on a wikitext page, now somehow on a data item. -- Daniel Kinzler (WMDE) (talk) 19:08, 26 November 2016 (UTC)
  • keep - Czech Wikipedie uses this in its template Části české obce. We don't know any method of displaying settlements which are located in a municipality other than using this property.--Vojtěch Dostál (talk) 00:48, 10 December 2016 (UTC)
  • keep. P131 is used not only for administrative entities but for any geographic entities, for example: monument, building and so on. That's way there can be many "P131" links for some division but only a few direct P150 links. --Infovarius (talk) 15:33, 19 December 2016 (UTC)
Pictogram voting comment.svg Comment personally, I think we should do away with this, but apparently there isn't really a way around it: Symbol keep vote.svg Keep
--- Jura 19:11, 15 January 2017 (UTC)


OpenDomesday person ID (P3122): (delete | history | links | entity usage | logs | discussion)

Seems to be useless
--- Jura 20:28, 2 December 2016 (UTC)

  • Keep Identifier for people named in Domesday Book (Q19867), the famous "manuscript record of the 'Great Survey' of much of England and parts of Wales completed in 1086 by order of King William the Conqueror", and so clearly useful. The target site offers linked, open data in JSON format. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 5 December 2016 (UTC)
  • Pictogram voting comment.svg Comment It's still practically unused and generates maintenance. If it might eventually be needed, people probably still end up proposing it again: something we had just now at Wikidata:Property proposal/Denkmalliste Brandenburg.
    --- Jura 11:37, 10 December 2016 (UTC)
  • Pictogram voting comment.svg Comment it is unused (which is no reason for deletion) but probably not useless. @Pigsonthewing: I've looked into this database to see what can be done but I ended up a bit confused, the example is :
    < Drogo de la Beuvrière (Q23018840) View with Reasonator See with SQID > OpenDomesday person ID (P3122) See with SQID < 150950/drogo-of-la-beuvriere/ >
    but there is nine ID for people with this name, why is that and how do you tell which is which? and in particular : how can a bot or a tool add the right ID to the right item? Cdlt, VIGNERON (talk) 15:02, 11 January 2017 (UTC)
    • If they are shown to be for the same person, add them to the item; they will eventually be merged & redirected. If not, leave them. This is no different to, say, VIAF ID (P214). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 11 January 2017 (UTC)
      • So the only uses of this property is a speculation?
        --- Jura 19:14, 15 January 2017 (UTC)
  • Keep WD has a fair number of entries for 11th century Anglo-Saxons and Anglo-Normans. In many cases they are identified as holders or tenants of particular lands in Domesday. Yes, the property still needs to be populated (and IMO we may need to be quite careful to restrict to only identifications that have reasonable certainty). But it will then be quite valuable to see where the lands held by a particular individual we have an article on actually were; or, in the opposite direction, where individuals in the OpenDomesday database can be linked to Wikipedia articles. (And/or to other databases we may have identifiers for). Jheald (talk) 16:18, 17 January 2017 (UTC)

WHO international non-proprietary names ID (P3350)[edit]

WHO international non-proprietary names ID (P3350): (delete | history | links | entity usage | logs | discussion)

Duplicate of World Health Organisation International Nonproprietary Name (P2275) and holding zero instances--Marfi (talk) 11:34, 11 December 2016 (UTC)

Symbol keep vote.svg Keep Marfi please check the property proposal discussion before making these recommendations - in this case see Wikidata:Property_proposal/WHO_international_non-proprietary_names_ID. This is an ID vs the other property which is a name, this was known when it was proposed. ArthurPSmith (talk) 14:12, 12 December 2016 (UTC)
Symbol delete vote.svg Delete I see, thanks for the clarification. Still the property holds exactly 0 instances and points to the wrong subject item. --Marfi (talk) 15:40, 12 December 2016 (UTC)
Pictogram voting comment.svg Comment it was created just last month. If it's still not used in February, I think we should double-check it.
--- Jura 18:11, 12 December 2016 (UTC)

Yahoo! Japan Talent Database ID (P3284)[edit]

Yahoo! Japan Talent Database ID (P3284): (delete | history | links | entity usage | logs | discussion)

Service end dead link --Rain night (talk) 04:38, 13 December 2016 (UTC)

  • Pictogram voting comment.svg Comment if the links aren't working any more, you can set the formatter URL to "deprecated rank".
    --- Jura 14:14, 13 December 2016 (UTC)

ISO 639-6 code (P221)[edit]

ISO 639-6 code (P221): (delete | history | links | entity usage | logs | discussion)

The ISO 639-6:2009 standard was withdrawn in 2014, and it never caught up. Its use here in WD is testimonial with just a few entries. It is not available online, and it is unlikely that the codes are imported unless there is some special interest. Ping: @GerardM, Visite fortuitement prolongée, Infovarius, Pamputt, Kolja21:--Micru (talk) 13:49, 13 December 2016 (UTC)

  • Pictogram voting comment.svg Comment see w:ISO 639-6.
    --- Jura 14:19, 13 December 2016 (UTC)
  • Symbol delete vote.svg Delete Not used, deprecated, better avoid to import useless data. Snipre (talk) 17:13, 13 December 2016 (UTC)
  • Pictogram voting comment.svg Comment I do not object to deleting, or keeping. However, I would like to understand why the standard was withdrawn - the ISO language codes are certainly useful for a lot of what we do here, is there a plan to replace it with something else? ArthurPSmith (talk) 19:00, 13 December 2016 (UTC)
    • @ArthurPSmith: Its current status is "withdrawn, no replacement", but of course ISO 639-3 and others remain operational. I haven't found the official reasons behind the withdrawal, however on this paper they shed some light on the inconvenience of using language codes for language classification and the lack of consensus on the topic, as language are fuzzy living entities and it is quite hard to find boundaries, even more so for variants. On this email on the ietf-languages mailing list hint towards a lack of usefulness, plus that the agency that was designated as registration authority ceased its operation.--Micru (talk) 08:22, 14 December 2016 (UTC)
  • Symbol keep vote.svg Keep While I have doubts about how useful or verifiable the data is, several Wikipedias include this in their infoboxes and some are even using the data from this property. - Nikki (talk) 17:13, 27 December 2016 (UTC)
  • I'd rather Symbol keep vote.svg Keep: how to store the 639-6 code without this property? Cdlt, VIGNERON (talk) 11:20, 11 January 2017 (UTC)
  • Symbol delete vote.svg Delete The only non-WMF resource of ISO 639-6, GeoLang, is even no longer providing the list, and only says "No Results Found", for the existing usage of codes, we should announce all the local communities, to run a bot script to remove em from Template:Infobox language (Q7217946). --Liuxinyu970226 (talk) 04:16, 16 January 2017 (UTC)

station code (P296)[edit]

station code (P296): (delete | history | links | entity usage | logs | discussion)

Zero instances. There are much more specified properties holding station codes.--Marfi (talk) 09:09, 20 December 2016 (UTC)

Symbol keep vote.svg Keep Are you looking at the same property? It's been used 4500+ times. It was proposed for deletion 3 years ago and decided not to - see discussion here. Yes there are more specific properties that should be used if they apply, but this one is suitable for generic use with a qualifier indicating what system the code is for, I seem no reason to delete. ArthurPSmith (talk) 13:32, 22 December 2016 (UTC)


Quora-United Nations Headquarters.png

Quora topic ID (P3417): (delete | history | links | entity usage | logs | discussion)

Is this datatype correct? Shouldn't it be string?
--- Jura 12:30, 24 December 2016 (UTC)

  • I don't understand what's the value of knowing what tag is used for a certain topic on a closed, private and proprietary website, especially one which works actively against public dissemination of knowledge and even archival: Nemo 13:03, 24 December 2016 (UTC)
  • A ridiculous nomination, and a very pointy one just after this. Speedy keep. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 24 December 2016 (UTC)
  • The property uses IDs for an external source, so the data type is valid IMHO. Keep --Magnus Manske (talk) 13:25, 24 December 2016 (UTC)
  • When the external-id datatype was introduced, we had long discussions about which properties should have external-id datatype. Consensus was somehow that an external-id should uniquely identify a concept, that's why certain string-properties weren't converted to external-id, e.g. Twitter hashtag (P2572). For me Quora topic ID (P3417) is pretty similar to Twitter hashtag (P2572) as it was introduced to group together posts and ease searching. They don't identify concepts but group together ideas like Exams and Career Advice, Tips and Hacks, Concrete and Cement. Therefore I Symbol support vote.svg Support to move this property from external-id to string datatype. --Pasleim (talk) 10:59, 26 December 2016 (UTC)
  • The data type is according to my opinion correct. Keep. Wesalius (talk) 19:45, 26 December 2016 (UTC)
  • For me it isn't clear: this proposal is for delete the property, or for delete this property and recreate it with a different data type? --ValterVB (talk) 18:02, 27 December 2016 (UTC)
    • It's to delete it and recreate it with string datatype. We can only do the opposite change without deleting. For the full deletion of the property, a second section would need to be started.
      --- Jura 18:36, 27 December 2016 (UTC)
      • That is not correct. We can convert both ways, since the two datatypes use the same internal representation. Daniel Kinzler (WMDE) (talk) 20:05, 20 January 2017 (UTC)
  • Symbol support vote.svg Support conversion to string datatype. In addition the problem that came up on Project Chat which prompted me to start this thread, there seems to be also a stability issue with these strings. As the explanations we get to the contrary are comments like "ridicule" and acts conver up instead of explain possible issues that come up, these links seem highly problematic.
    --- Jura 15:01, 31 December 2016 (UTC)
    • Yet again, I need to remind you that adding "support" to your own proposal is double !voting. Your nomination was described as "ridiculous", which is not "ridicule". No evidence of a "cover up" has been shown. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:26, 31 December 2016 (UTC)

TEU (P1124)[edit]

TEU (P1124): (delete | history | links | entity usage | logs | discussion)

Only four uses, and can be replaced by a generic "capacity" property, with twenty-foot equivalent unit (Q488021) used as the units.--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 29 December 2016 (UTC)

Symbol delete vote.svg Delete I don't think we need a new capacity property - volume as quantity (P2234) or maybe net tonnage (P2790) can handle the cases where this is already used. I assume TEU (P1124) was proposed because quantities with units weren't available at the time; in any case I agree it isn't needed now. ArthurPSmith (talk) 17:50, 29 December 2016 (UTC)
Symbol delete vote.svg Delete. Use the other properties available. Thierry Caro (talk) 16:14, 8 January 2017 (UTC)
Note I have replaced all current uses of this property with volume as quantity (P2234). I believe it can just be deleted. ArthurPSmith (talk) 19:16, 17 January 2017 (UTC)
Pictogram voting comment.svg Comment @ArthurPSmith: Volume and capacity are not the same thing, e.g. a lift with a capacity of 8 persons is not a measure of the lift's volume, same applies to TEU capacity, it is not a measure of a ship's internal volume. So, replacing this with volume as quantity (P2234) is somewhat muddled up.  – The preceding unsigned comment was added by Danrok (talk • contribs) at 21:25, 17 January 2017‎ (UTC).
feel free to replace with something better. All current uses can be found by following the "What links here" link for twenty-foot equivalent unit (Q488021). ArthurPSmith (talk) 15:00, 18 January 2017 (UTC)

PORT film ID (P905) and PORT person ID (P2435)[edit]

(delete | history | links | entity usage | logs),,,, were closed between 5 and 11 January 2017 --Ionutzmovie (talk) 13:13, 12 January 2017 (UTC)

Pictogram voting comment.svg Comment is still online --Pasleim (talk) 13:41, 12 January 2017 (UTC)
That may be, but the items that contain the domains I marked might require cleanup.Ionutzmovie (talk) 21:35, 12 January 2017 (UTC)
Keep As I've said in similar cases previsouly, we should not delete data when this kind of thing happens. Just remove or deprecate the formatter URLs, or update them to an archive like Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 13 January 2017 (UTC)
Symbol keep vote.svg Keep for now as is still online.--Jklamo (talk) 23:14, 14 January 2017 (UTC)


no label (P3474): (delete | history | links | entity usage | logs)

Wrong datatype, see Songkick artist ID (P3478) GZWDer (talk) 17:04, 15 January 2017 (UTC)


race time (P2781): (delete | history | links | entity usage | logs | discussion)

Already have duration (P2047) for values and match time of event (minutes) (P1390) for qualifiers. GZWDer (talk) 18:29, 15 January 2017 (UTC)

allgame ID (P907)[edit]

allgame ID (P907): (delete | history | links | entity usage | logs | discussion)

Only two uses and the database is shut down. --Pasleim (talk) 21:02, 17 January 2017 (UTC)

Hence Symbol delete vote.svg Delete. --Succu (talk) 21:55, 17 January 2017 (UTC)
  • Symbol delete vote.svg Delete--Micru (talk) 19:55, 19 January 2017 (UTC)