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.

Edit


Project
chat

Administrators'
noticeboard

Development
team

Translators'
noticeboard

Requests
for permissions

Interwiki
conflicts

Requests
for deletions

Property
proposal

Properties
for deletion

Requests
for comment

Partnerships
and imports

Request
a query

Bot
requests


Requests[edit]

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 | logs | discussion) singles record (P564): (delete | history | links | logs | discussion)

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

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

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 | 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)

ISO standard (P503)[edit]

ISO standard (P503): (delete | history | links | 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)

language of work or name (P407)[edit]


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

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

original language of work (P364)[edit]

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

Property:P500[edit]

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

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

Property:P1302[edit]

primary destinations (P1302): (delete | history | links | 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)

Property:P448[edit]

location of spacecraft launch (P448): (delete | history | links | 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)

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 September 2016 (UTC)

Property:P546[edit]

docking port (P546): (delete | history | links | 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)

Property:P1158[edit]

location of landing (P1158): (delete | history | links | 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)

Property:P2837[edit]

Wikidata month number (P2837): (delete | history | links | 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)

Property:P2570[edit]

Saros cycle of eclipse (P2570): (delete | history | links | 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 | 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)

NARA organization ID (P1223), NARA geographic ID (P1224), NARA specific records type ID (P1226) and NARA catalog record ID (P1231)[edit]

NARA organization ID (P1223): (delete | history | links | logs | discussion) NARA geographic ID (P1224): (delete | history | links | logs | discussion) NARA specific records type ID (P1226): (delete | history | links | logs | discussion) NARA catalog record ID (P1231): (delete | history | links | logs | discussion)

These ID's are essentially the same, as all links created redirect into https://catalog.archives.gov/id/$1. National Archives Identifier (P1225) seems to be the most used (although still not extensively) and most generic of these properties. The others can be merged into it. --Lymantria (talk) 20:53, 3 September 2016 (UTC)

  • Symbol support vote.svg Support the merge. --Fralambert (talk) 20:59, 3 September 2016 (UTC)
  • Symbol support vote.svg Support merge. --Pasleim (talk) 22:11, 3 September 2016 (UTC)
  • Symbol support vote.svg Support If the formatter URL is indeed the same for all, then I agree on merging them. Mbch331 (talk) 09:05, 4 September 2016 (UTC)
  • Symbol support vote.svg Support merge.--Jklamo (talk) 20:13, 18 September 2016 (UTC)

no label (P3164)[edit]

no label (P3164): (delete | history | links | logs)

Sorry, I created a property instead of an item.--— Ayack (talk) 15:31, 12 September 2016 (UTC)

deleted --Pasleim (talk) 15:49, 12 September 2016 (UTC)

number of awards (P2422)[edit]

number of awards (P2422): (delete | history | links | 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)

uses property (P3176)[edit]

uses property (P3176): (delete | history | links | logs | discussion)

It seems to me that this property was created without consensus; see Wikidata:Property proposal/property used--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:55, 18 September 2016 (UTC)

Please notify the involved people, there is no mention on the property talk page or proposal. Sjoerd de Bruin (talk) 16:47, 19 September 2016 (UTC)
  • Symbol keep vote.svg Keep if it wasn't clear on the original proposal page, I definitely supported the creation of this property. It has been used 7 times so far that I can see; perhaps Andy can explain how an alternative property would suffice for those 7 cases if he so strongly feels it should be deleted? His argument on the proposal page was simply incorrect - main subject is NOT the right solution here. ArthurPSmith (talk) 13:45, 22 September 2016 (UTC)
@Lymantria: --ValterVB (talk) 17:25, 22 September 2016 (UTC)
  • Symbol keep vote.svg Keep Disagree with Andy's conclusion about missing consensus. Furthermore I consider the property useful. Lymantria (talk) 21:24, 22 September 2016 (UTC)
  • Symbol keep vote.svg Keep I misunderstood the property proposal at first, but withdrew my opposition when that became clear. Now I've seen it in action I can clearly understand the value in it and would have explicitly supported (although maybe "uses Wikidata property" might be a better label). At e.g. Monitoring the Gender Gap with Wikidata Human Gender Indicators (Q26955946) it's clear that main subject (P921) is not an appropriate property for this use case, and I'm not aware of any other existing or proposed ones that are. Thryduulf (talk) 21:35, 22 September 2016 (UTC)

located at street address (P969)[edit]

located at street address (P969): (delete | history | links | 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)

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/NSWfl.pl?page=nswfl&lvl=sp&name=), 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)

Josve05a (talk)
FelixReimann (talk)
Infovarius (talk)
Daniel Mietchen (talk)
Soulkeeper (talk)
Brya (talk)
Klortho (talk)
Delusion23 (talk)
Andy Mabbett (talk)
Dan Koehl (talk)
Achim Raschka (talk)
TomT0m
Tinm
MPF
Abbe98
Rod Page
Joel Sachs
Prot D
Michael Goodyear
PhiLiP
pvmoutside
Faendalimas
Lymantria (talk)

Pictogram voting comment.svg Notified participants of Wikiproject Taxonomy --Succu (talk) 21:52, 29 September 2016 (UTC)

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

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

Also New York Times Semantic Concept: Organization (P2691), New York Times Semantic Concept: Location (P2692), New York Times Semantic Concept: Descriptor (P2693). 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)