Wikidata:Properties for deletion/Archive/2017
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Contents
- 1 language of work or name (P407)
- 2 Onisep occupation ID (P3214)
- 3 image of grave (P1442)
- 4 member of political party (P102)
- 5 Property:P3474
- 6 ISO standard (P503)
- 7 Property:P500
- 8 Property:P1302
- 9 Property:P448
- 10 Property:P1158
- 11 Property:P2570
- 12 metasubclass of (P2445)
- 13 P969 (P969)
- 14 P2690 (P2690)
- 15 OpenStreetMap relation ID (P402)
- 16 contains the administrative territorial entity (P150)
- 17 Property:P3122
- 18 World Health Organisation international non-proprietary name numeric ID (P3350)
- 19 P1124 (P1124)
- 20 PORT film ID (P905) and PORT person ID (P2435)
- 21 Booking.com hotel ID (P3607)
- 22 Curlie ID (P998)
- 23 P794 (P794)
- 24 comment (DEPRECATED) (P2315)
- 25 station code (P296)
- 26 race time (P2781)
- 27 P907 (P907)
- 28 kinship to subject (P1039)
- 29 version type (P548)
- 30 designated as terrorist by (P3461)
- 31 P3873 (P3873)
- 32 taxon author (P405)
- 33 inventory number (P217)
- 34 doubles record (P555) and singles record (P564)
- 35 Property:P546
- 36 Yahoo! JAPAN Talent Database ID (P3284)
- 37 Property:P3417
- 38 NSW Flora ID (P3130)
- 39 ISO 639-6 code (P221)
- 40 number of elevators (P1301)
- 41 P3649 (P3649)
- 42 Q37846640
- 43 2-pentene (Q12871786) and 2-pentene (Q22051121)
- 44 Property:P1646
- 45 terminus location (P609)
- 46 Fotografen.nl ID (P3269)
- 47 P3688 (P3688)
- 48 BVMC place ID (P4098)
- 49 inception (P571)
- 50 Property:P796
- 51 Property:P402
- 52 Property:P4264
- 53 Property:P4174
- 54 category contains (P4224)
- 55 Property:P4420
- 56 P4492 (P4492)
- 57 P4205 (P4205)
- 58 Property:P2656
- 59 P1905 (P1905)
- 60 P2422 (P2422)
- 61 Open Funder Registry funder ID (P3153)
- 62 P4039 (P4039)
- 63 Property:P3084
- 64 P794 (P794)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- There is already a section for this above.
--- Jura 02:27, 7 June 2016 (UTC)
- There is already a section for this above.
language of work or name (P407): (delete | history | links | entity usage | logs | discussion) Currently we have 3 properties to describe languages of an item (language of work or name (P407), P2439 (P2439) and original language of film or TV show (P364)). This discussion aims to delete language of work or name (P407) in favour of an unique property for language P2439 (P2439).
There was already a discussion about deletion of these properties and decisions have to be taken on a logic way as properties are the ground of classification in Wikidata:
- If there is an original language, we have to keep a symetric classification with an original publisher, an original publication date,...
- FRBR system is the ground of the classification in wikidata for work and was adopted through a RfC Snipre (talk) 00:35, 7 June 2016 (UTC)
@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)
- 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.
- 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)
- 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 ..
- 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)
- 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.
- @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
- P2439 (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)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 19:06, 2 December 2016 (UTC)
P3214 (P3214): (delete | history | links | entity usage | logs)
Duplicate of IDEO Job ID (P1043)--Tubezlob (🙋) 12:22, 5 October 2016 (UTC)
- Delete after migrating data. One of the formatter URLs for P1043,
http://www.onisep.fr/http/redirection/metier/identifiant/$1
is the same as that for P3214. Good spot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 5 October 2016 (UTC)
- All the professions with Onisep ID have also an IDEO ID, so we don't need migrating data. Tubezlob (🙋) 16:33, 7 October 2016 (UTC)
- Delete obviously a duplicate --Pasleim (talk) 11:59, 12 October 2016 (UTC)
- @Pasleim: It's possible to delete this property, to prevent that editors add this property instead of IDEO Job ID (P1043)? Thank you, Tubezlob (🙋) 10:45, 23 October 2016 (UTC)
I'm sorry to push, but can we delete this property? Thank you! Tubezlob (🙋) 16:46, 6 November 2016 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:01, 11 January 2017 (UTC)
image of grave (P1442): (delete | history | links | entity usage | logs | discussion)
Every use of this property should be replaced by the creation of a dedicated item about the tomb with image (P18) for the image and linked from the item of of the person by place of burial (P119).--Léna (talk) 17:06, 3 November 2016 (UTC)
- That seems like a intensive task. It should be easier to make items while adding claims first. Is there more discussion about this? And please inform others on the property talk page. Sjoerd de Bruin (talk) 10:13, 7 November 2016 (UTC)
- Oppose In many cases the grave is just a simple stone. Does a simple stone warrants an item? — Finn Årup Nielsen (fnielsen) (talk) 16:51, 21 November 2016 (UTC)
- Keep I don't think we should make items for individual burial plots in cemeteries and you haven't provided any reason why we should. - Nikki (talk) 10:40, 10 December 2016 (UTC)
- Oppose Completely opposed. And for place of burial (P119) we traditionnaly use the item about the cimetery of the town to then display it in an infobox. Jérémy-Günther-Heinz Jähnick (talk) 17:29, 11 December 2016 (UTC)
- Keep As per Jérémy-Günther-Heinz -- LaddΩ chat ;) 00:39, 22 December 2016 (UTC)
- Keep As certain link to Commons file. - Kareyac (talk) 11:14, 29 December 2016 (UTC)
- Keep I believe usually (not always) it is not a good idea to create a dedicated entity for grave. P1442 is convenient for specifying an image in commons, and useful for distinguishing from P18 Eran (talk) 19:07, 31 December 2016 (UTC)
- Keep I document cemeteries and graves using P1442 see blog and I preffer a property - Salgo60 (talk) 01:55, 4 January 2017 (UTC)
- Keep As per Finn Årup Nielsen and Nikki. Ainali (talk) 06:33, 4 January 2017 (UTC)
- Comment I Oppose the motivation as such, it makes it more complicated than necessary. I see an option to add P18 as a qualifier to P119. But that denies us the option to add a "label" to that picture. -- Innocent bystander (talk) 10:34, 4 January 2017 (UTC)
- Keep Requiring a separate item for the graves of deceased people seems excessive. (In some cases it might be appropriate, such as if the person's grave is particularly noteworthy, but it shouldn't be necessary except in those exceptional cases.) SJK (talk) 04:29, 6 January 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Lymantria (talk) 15:17, 11 January 2017 (UTC)
member of political party (P102): (delete | history | links | entity usage | logs | discussion)
Wholly redundant to member of (P463), which is for membership of "a specific organization". That the organisation in question is a political party (or not) can be determined from its instance of (P31).
--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:37, 8 November 2016 (UTC)
- independent politician (Q327591) is not a political party/organisation.
- Yes, there are a lot of potential problems with P102. One is that the adding of this property into a database like Wikidata could be illegal where I live.
- Another is that if you have a seat in a national or local parliament for a political party, does not mean that you have to be a member of that party. -- Innocent bystander (talk) 11:05, 13 November 2016 (UTC)
- Can you explain the relevance of Q327591, or of the law in your local jurisdsiction? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 14 November 2016 (UTC)
- @Pigsonthewing: (Failed to see your Q until now.) The relevant law is Q10726917, which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the national railway company have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- Innocent bystander (talk) 08:31, 24 December 2016 (UTC)
- Frankly this is irrelevant for Wikidata. That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other). In both cases, that is public information that has been published in a source. Just the same as with data on religious belief, sexual orientation and so on. —Tom Morris (talk) 15:16, 3 January 2017 (UTC)
- @Tom Morris: That somebody is "standing for office" for a political party, does not prove that they are members of anything. It still happens in local elections here that some people got elected for a political party they are not a member of. In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates. It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years. On county-level that last thing has become a huge problem for the governing majority here. -- Innocent bystander (talk) 10:52, 4 January 2017 (UTC)
- @Innocent bystander: That seems a pretty niche problem. In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose. Apply Pareto's Principle: in most cases, if someone says "I'm a member of the Labour Party", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party. In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of "Vote money, get monkey". Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor. We can handle these kind of odd exceptions with other constructions rather than by deleting P102. —Tom Morris (talk) 11:44, 6 January 2017 (UTC)
- @Tom Morris: That somebody "steals" a seat in this manner is very unusual. But that somebody "represents" a party they are not member of is more common than most of us think. Sometimes you vote for a list of persons on a list with mixed persons. They represents "The conservatives", but "The conservatives" is not a political party. It is a technical cooperation between close related parties. The voting-system here favours large parties at the cost of the small ones. When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2. List D got 3 seats, 2 to H and 1 independent. When I moved here, SD had one seat in the local election, but no names could be found in the ballots. The seat became empty.-- Innocent bystander (talk) 12:19, 6 January 2017 (UTC)
- @Innocent bystander: That seems a pretty niche problem. In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose. Apply Pareto's Principle: in most cases, if someone says "I'm a member of the Labour Party", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party. In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of "Vote money, get monkey". Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor. We can handle these kind of odd exceptions with other constructions rather than by deleting P102. —Tom Morris (talk) 11:44, 6 January 2017 (UTC)
- @Tom Morris: That somebody is "standing for office" for a political party, does not prove that they are members of anything. It still happens in local elections here that some people got elected for a political party they are not a member of. In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates. It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years. On county-level that last thing has become a huge problem for the governing majority here. -- Innocent bystander (talk) 10:52, 4 January 2017 (UTC)
- Frankly this is irrelevant for Wikidata. That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other). In both cases, that is public information that has been published in a source. Just the same as with data on religious belief, sexual orientation and so on. —Tom Morris (talk) 15:16, 3 January 2017 (UTC)
- @Pigsonthewing: (Failed to see your Q until now.) The relevant law is Q10726917, which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the national railway company have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- Innocent bystander (talk) 08:31, 24 December 2016 (UTC)
- Can you explain the relevance of Q327591, or of the law in your local jurisdsiction? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 14 November 2016 (UTC)
- There are really two slightly different concepts wrapped up together here — a person choosing to be a (paying / voting / supporting) member of a political party (which can be an entirely private matter, but which some people make public: e.g. Suzy Eddie Izzard (Q254022) being a member of Labour Party (Q9630)), and an elected politician holding office as a representative of a party. Most of the uses of member of political party (P102) seem to be the latter, but I suspect it would be better to have that as a qualifier on position held (P39) instead (which would also better handle the cases where someone holds two different offices simultaneously on behalf of two different parties), leaving member of political party (P102) free for the former — and which would then probably be so infrequent as to be moved to member of (P463) per the suggestion. --Oravrattas (talk) 15:39, 1 January 2017 (UTC)
- Oppose Is it really a good idea to delete more specific properties and link to general properties. I don't see the reason. The more specific properties allow us to have the redundancy that is necessary to catch outliers/errors. In some instances any queries (SPARQL) will be simplier when we have specific properties. We also have member of sports team (P54). Should this property then also be deleted? — Finn Årup Nielsen (fnielsen) (talk) 17:29, 21 November 2016 (UTC)
- Oppose --Mikey641 (talk) 18:26, 29 November 2016 (UTC)
- Oppose This is more specific and that other one is quite generic. This one is much needed to identify which side then lean.MechQuester (talk) 04:30, 24 December 2016 (UTC)
- Keep divided from any other looking-like properities gives more concrete data. - Kareyac (talk) 11:19, 29 December 2016 (UTC)
- Keep Seems a reasonable subproperty of P463. Privacy concerns are no more reasonable than those that could be presented for religious affiliation, sexual orientation etc. —Tom Morris (talk) 11:46, 6 January 2017 (UTC)
- Keep. We should also have one such property for the labor union (Q178790) one might belong to. Thierry Caro (talk) 16:09, 8 January 2017 (UTC)
P3474 (P3474): (delete | history | links | entity usage | logs)
Wrong datatype, see Songkick artist ID (P3478) GZWDer (talk) 17:04, 15 January 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 16:10, 6 February 2017 (UTC)
ISO standard (P503): (delete | history | links | entity usage | logs | discussion)
Bad datatype. Should be item like ISO/IEC 80000 (Q568496) and this one should be deleted/redeployed with a domain of iso norms. For example I just put it on ISO/IEC 80000 (Q568496) ...--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)
- 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)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 22:23, 12 April 2017 (UTC)
exclave of (P500): (delete | history | links | entity usage | logs | discussion)
country (P17) or located in the administrative territorial entity (P131) can be used instead. GZWDer (talk) 19:29, 23 July 2016 (UTC)
- Looks like you have a point. -- Innocent bystander (talk) 06:20, 24 July 2016 (UTC)
- Delete Per GZWDer. Example of alternative use: ⟨ Neeltje Jans (Q2330240) ⟩ located in the administrative territorial entity (P131) ⟨ Veere (Q10083) ⟩. Lymantria (talk) 06:43, 26 July 2016 (UTC)
P794 Search ⟨ Q933394 ⟩ - Not sure if the right entity can be determined conclusively through checking a series of other items and properties.
--- Jura 16:24, 4 August 2016 (UTC) - Delete A bit too obscure for a property. --Rschen7754 21:49, 14 January 2017 (UTC)
- Keep per my open issue above above. --
--- Jura 19:11, 15 January 2017 (UTC) - Keep An exclave is a territory located separately from the administrative entity to which it belongs, but which does not belong to another administrative entity. For example, Llívia (Q13745) is a territory located in the interior of France, but that belongs to Catalonia and is administered by Catalonia. The property exclave of (P500) Catalonia, serves to indicate that it is a territory separated from Catalonia but that belongs administratively to this region. In the case of property located in the administrative territorial entity (P131), it serves to indicate where it is located, but not to which administrative entity it belongs or which is a separate territory. --Tximitx (talk) 22:39, 6 February 2017 (UTC)
- @Jura1, Tximitx: The value Catalonia (Q5705) and Spain (Q29) can be inferred from located in the administrative territorial entity (P131) chain. Cerdanya (Q15385) may be a value of located in the administrative territorial entity (P131) with qualifiers.--GZWDer (talk) 08:06, 8 February 2017 (UTC)
- @GZWDer: Property located in the administrative territorial entity (P131) indicates where it is located, but not to which administrative entity belongs, nor is it a separate territory of that administrative entity. For example, Alaska (Q797) is a exclave of (P500) United States of America (Q30) because it is separate. Property exclave of (P500) indicates that condition. --Tximitx (talk) 09:04, 8 February 2017 (UTC)
- See the usage notice of P131: "You only need to add the most local parent admin territory, but check that that item also has a P131, with the next level, and so on." For an exclave, the value of P131 is the most local parent admin territory where it is located. to indicate that is a separate territory we already have instance of (P31) and enclave within (P501).--GZWDer (talk) 19:52, 14 February 2017 (UTC)
- Keep as per Tximitx. One of the most important exclaves of the 20th Century was West Berlin (1949-1989). Martinvl (talk) 07:06, 3 April 2017 (UTC)
- Keep per user:Tximitx. Thryduulf (talk) 09:11, 12 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 16:10, 6 February 2017 (UTC)
primary destinations (P1302): (delete | history | links | entity usage | logs | discussion)
Propose to merge with place served by transport hub (P931) and rename it to "places served". GZWDer (talk) 20:42, 2 August 2016 (UTC)
Oppose This was suggested and rejected when operating area (P2541) was proposed. If it is merged "places served" is not a good label as P2541 includes areas that are not "served" - e.g. Rail Accident Investigation Branch (Q7283877) does not "serve" Channel Tunnel (Q10257) rather it is jointly responsible for investigating accidents that occur there, and World Association of Zoos and Aquariums (Q60427) doesn't serve world (Q16502) rather it is an umbrella organisation that supports its members wherever they are in the world. Thryduulf (talk) 00:40, 3 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)
- @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)
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 transport hub (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)
- 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)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 16:10, 6 February 2017 (UTC)
P448 (P448): (delete | history | links | entity usage | logs)
Use start point (P1427). GZWDer (talk) 17:12, 3 August 2016 (UTC)
- 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)
- Delete per my comment on #Property:P546 --Pasleim (talk) 15:58, 4 August 2016 (UTC)
- Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:20, 4 August 2016 (UTC)
- 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)
- Delete I agree this is unnecessarily duplicative. Reguyla (talk) 21:09, 13 October 2016 (UTC)
- 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)
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)
- Delete MechQuester (talk) 16:45, 8 January 2017 (UTC)
- 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)
- Delete - yona b (talk) 12:38, 16 January 2017 (UTC)
- Comment Could someone please provide links to where the projects using this property have been informed? - Nikki (talk) 11:58, 3 February 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 16:10, 6 February 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)
- 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)
- Delete per my comment on #Property:P546 --Pasleim (talk) 15:59, 4 August 2016 (UTC)
- Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:21, 4 August 2016 (UTC)
- Keep per ArthurPSmith —surueña 11:12, 17 August 2016 (UTC)
- 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)
- Keep for the reason stated by Arthur. CC0 (talk) 19:22, 29 October 2016 (UTC)
- Keep agree with Arthur.
--- Jura 19:11, 15 January 2017 (UTC) - Keep like Arthur --Adert (talk) 14:05, 18 February 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to change datatype --Pasleim (talk) 16:10, 6 February 2017 (UTC)
P2570 (P2570): (delete | history | links | entity usage | logs)
The datatype should be item. GZWDer (talk) 17:54, 3 August 2016 (UTC)
KeepI 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)
KeepWe 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)
- @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)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 22:23, 12 April 2017 (UTC)
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)
- 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)
- 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)
- Current uses (2016--11-01): 4 -- JakobVoss (talk) 11:46, 1 November 2016 (UTC)
- Delete practically unused (down to 3 now?). Apparently no uses can be found for this.
--- Jura 19:11, 15 January 2017 (UTC) - Delete unused, not external use, difficult to apply.--Jklamo (talk) 00:51, 23 January 2017 (UTC)
- Keep per TomTom above. It's worth reviewing first what the relationship is that this property tries to capture. Consider the following diagram. The P2445 'metasubclass' property, with A metasubclass of (P2445) B implies an arrangement like the following,
A ....> B ^ ^ | | | | ----> M ----> N
- so M is a subclass of N, but the classes M and N are also usually instances of items A and B -- something in itself quite rare; but even more rare if A is not a subclass of B. P2445 exists to present the connection between A and B in such a case, ie that instances of A are likely to be subclasses of classes that are instances of B; but A itself is not a subclass of B.
- So for example Boeing 747-100 (Q9384384) is a subclass of Boeing 747 (Q179); but Boeing 747-100 (Q9384384) is also an instance of aircraft model (Q15056995); and Boeing 747 (Q179) is an instance of aircraft family (Q15056993) (as well as a subclass of "aircraft"). There is a relationship between aircraft model (Q15056995) and aircraft family (Q15056993), but aircraft model (Q15056995) is not a subclass of aircraft family (Q15056993). Applying P2445 on Q15056995 notes that this structural relationship exists and is appropriate, and makes it easy to retrieve.
- Yes, the property is used on very few items. But this is not (really) because nobody has been bothered to populate it. The truth is, as TomTom noted above, there were only ever expected to be a handful of examples (the original property proposal in fact spun out of a discussion as to whether this kind of structure could exist at all).
- Having found such examples, the easiest way to record them is in the database itself, and so this property. It also acts as a prompt, that a class M that is an instance of item A should well perhaps have a subclass relationship with some class N that is an instance of item B.
- There may indeed only be a handful of items A of this kind, so only a very limited number of potential uses of the property. But that was known from the start, and seems not a particularly good reason to delete it. Jheald (talk) 21:34, 5 February 2017 (UTC)
- Keep I see (and have now added to property examples) that there is another place where this property is being well-used:
- isotope : metasubclass of : chemical element
- which succinctly represents dozens of relationships, of which here is one example:
- carbon c-14 : subclass of : carbon
- Why would we want to remove the ability to represent this "meta-relationship", unless someone knows a better way to represent it? Per postings above, subclass of already has a meaning that (even when applied to two metaclasses) is not equivalent to metasubclass of.
- DavRosen (talk) 15:31, 10 March 2017 (UTC)
- Comment (addding): Also, there's no real reason to remove it unless it were being misused a lot more than it is being used correctly, or unless it were causing serious problems (other than the purported "problem" that it might be used infrequently or that there are some people who won't use it because they don't understand it, while others will and do). DavRosen (talk) 15:43, 10 March 2017 (UTC)
- Keep per DavRosen. SJK (talk) 01:21, 12 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to change datatype --Pasleim (talk) 16:10, 6 February 2017 (UTC)
P969 (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)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete properties --Pasleim (talk) 16:10, 6 February 2017 (UTC)
P2690 (P2690): (delete | history | links | entity usage | logs)
Also:
- P2691 (P2691): (delete | history | links | entity usage | logs)
- P2692 (P2692): (delete | history | links | entity usage | logs)
- P2693 (P2693): (delete | history | links | entity usage | logs)
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 New York Times 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 New York Times 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 New York Times 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)
- {{Citation needed}} ArthurPSmith (talk) 19:38, 4 October 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)
- 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)
- 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)
- 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.
- 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)
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)
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)
- @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)
- You have simply rephrased what I said. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 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)
- 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)
- So there is no such policy; and all you have to offer is the "common sense" fallacy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 7 October 2016 (UTC)
- Stop Wikilawyering and start using common sense. Multichill (talk) 15:27, 7 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)
- 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)
- Delete practically unused. Apparently no uses can be found for this.
--- Jura 19:11, 15 January 2017 (UTC) - 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)
- Delete Unused, no external use of properties, closed database. --Jklamo (talk) 00:55, 23 January 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 22:23, 12 April 2017 (UTC)
OpenStreetMap relation ID (P402): (delete | history | links | entity usage | logs | discussion)
See discussion at https://phabricator.wikimedia.org/T145284 (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)
- 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) - 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 ID (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)
- 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)
- 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)
- Delete once data is migrated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 7 November 2016 (UTC)
- Delete Using of Overpass-API[1] makes P402 obsolete. --Kolossos (talk) 18:19, 7 November 2016 (UTC)
- 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 http://query.wikidata.org/ ? 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)
- 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 ID (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 ID (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 ID (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)
- @Jc86035: I cannot see any comparable alternative. OpenStreetMap relation ID (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 ID (P402) is used mostly for administrative boundaries and streets (see query). --Jklamo (talk) 00:06, 14 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)
- 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)
- Comment @Yurik, Pigsonthewing, Susannaanas, Abbe98, Kolossos, Jklamo: See 2016 Community Wishlist Survey. Jc86035 (talk) 10:07, 13 November 2016 (UTC)
- @Yurik, Pigsonthewing, Susannaanas, Abbe98, Kolossos, Jklamo: While the above linked proposal looks to have no chance of being accepted/noticed, there is a completely different proposal on the same page to automatically update external databases' identifiers which could affect this. Jc86035 (talk) 15:34, 2 December 2016 (UTC)
- Also pinging Jura1 and Maxsem. Jc86035 (talk) 15:36, 2 December 2016 (UTC)
- 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)
- 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).
- @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)
- That's still 4.5 million relations. We don't really have that many more items that could get coordinates/such identifiers.
- @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)
- 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)
- 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.
- 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)
- 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)
- There are actually quite a lot of relations available we could import.
- 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)
- Well, stating that it needs maintenance isn't really a good argument either.
- 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)
- 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.
- 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)
- 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)
- @Jura1: I don't think so, although it might be a good idea to notify either the OSM wiki's community portal(?) or the
- 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 Weak support from me. --Glglgl (talk) 16:04, 14 December 2016 (UTC)
- 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. 193.60.236.13 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)
- 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)
- @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)
- @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: 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)
- 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)
- @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)
- Comment, right now I'm leaning on 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 ID (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)
- @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)
- 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 ID (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 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)
- 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)
- Keep As per J Klamo.--Sascha GPD (talk) 17:57, 20 January 2017 (UTC)
- Keep It's all very well to say we can use Overpass to obtain the link for a single OSM relation. But what if one to do a query, to eg identify all the items in a particular group of classes (which could be quite big) which are currently missing an OSM relation? With this property in Wikidata, it's easy. Without this property it is significantly hard. Overpass can return 1 OSM relation. But can it return 10,000? And can it do it within the time-limit for a WDQS query? Jheald (talk) 08:46, 23 February 2017 (UTC)
- @Jheald: It is a cause for some concern, as the Wikidata and OSM databases are not really linked (no parser functions, limited querying outside the Kartographer extension's GeoJSON and the WD property, etc.). If it's a particular class of objects, you could search for OSM relations of that type which have wikipedia=/wikidata= tags and then compare them a list of Wikidata items. Maybe Overpass features could be ported over to WDQS, but I'm not really familiar with the latter. Jc86035 (talk) 08:06, 2 March 2017 (UTC)
- Keep I think it is best to have bidirectional links between Wikidata and other services where possible. So if another service links to Wikidata, I don't think that is any reason for Wikidata to not link back. The maintenance issues could be solved with a bot to sync the two (i.e. bot can scan OSM for links to Wikidata and add the backlink from Wikidata to OSM if it doesn't exist). With linking only from OSM to Wikidata, people browsing Wikidata might not become aware that OSM has useful information on the item they are looking at. SJK (talk) 01:11, 12 March 2017 (UTC)
- @SJK: I would agree in principle, but proposals for both a bot and node/way properties have already been rejected, and you'd need to find someone willing to devote their time to writing bot code for something minimally useful (both databases are publicly accessible and editable; the Kartographer MediaWiki extension already pulls data directly from OSM). We would also need the bot to edit on the OSM side, and as far as I'm aware there aren't any (approved) maintenance bots there yet. The best solution is probably to get the WMF/OSM developers to integrate the databases or provide more convenient links between them such as parser functions and automated display of data from the other database, but there's no guarantee that's ever going to happen. Jc86035 (talk) 13:55, 17 March 2017 (UTC)
- Keep Even if I see sensible points on both sides, my opinion is leaded by 2 considerations. There is no stable spatial database. It could be very nice for us, but it does not exist. This kind of stuff refers to present; biographical, historical databases, which concern the past, are not concerned by this issue. A database based on (even partially) the space of today fatally goes obsolete, and as far as my knowledge goes perfection and eternity are no goals in the project. And pass the hot potato to OSM would only sweep the dust under the rug. Second, how many users can use queries, how many can understand the idea of a property referring to a relation id? Kumkum (talk) 11:38, 23 March 2017 (UTC)
- Keep the current P402 while we create/populate a new property to contain "node/1" or "relation/1" values; then we Delete an old P402 as overly restricted. We need external links other than relations. d1g (talk) 12:48, 23 March 2017 (UTC)
- @D1gggg: The issue remains that you would need a bot operating on both Wikidata and OpenStreetMap to keep updating all the values (node/way properties have already been rejected due to being too unstable). Jc86035 (talk) 09:16, 27 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 16:10, 6 February 2017 (UTC)
contains the administrative territorial entity (P150): (delete | history | links | entity usage | logs | discussion)
Duplicates located 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: <http://www.bigdata.com/rdf/gas#>
SELECT ?item ?itemLabel ?itemAltLabel ?itemDescription ?linkTo ?depth WHERE
{
SERVICE gas:service {
gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
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
- 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) or User:Daniel Kinzler (WMDE), 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)
- 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) or User:Daniel Kinzler (WMDE), is there any way to solve this? Ideal case:
- 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)
- Comment personally, I think we should do away with this, but apparently there isn't really a way around it: Keep
--- Jura 19:11, 15 January 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:23, 12 April 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)
- 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) - 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) ⟩ OpenDomesday person ID (P3122) ⟨ 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)- The remarkable leap from what I wrote to what you concluded is staggering, and unwarranted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 19 January 2017 (UTC)
- So the only uses of this property is a speculation?
- 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)
- 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)
- See for example the blue-linked names at en:Devon Domesday Book tenants-in-chief and en:Cornwall Domesday Book tenants-in-chief. Jheald (talk) 18:22, 8 March 2017 (UTC)
- Keep. Wikidata is a work in progress, and this property has a clear use. That it isn't widely used yet is not a reason to prevent its use in the future. Thryduulf (talk) 09:20, 12 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:23, 12 April 2017 (UTC)
World Health Organisation international non-proprietary name numeric ID (P3350): (delete | history | links | entity usage | logs | discussion)
Duplicate of World Health Organisation international non-proprietary name (P2275) and holding zero instances--Marfi (talk) 11:34, 11 December 2016 (UTC)
- 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)
- 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)
- 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) - Keep as per ArthurPSmith. These are not the same thing. Frankly, World Health Organisation international non-proprietary name (P2275) seems like a better candidate for deletion. The ID indexes into their database and provides (among other things) all the names. So this is basically a controlled vocabulary (Q1469824) for disambiguation (i.e., document indexing (Q1167863)). The names themselves should likely just be entered as aliases on our own items. 50.53.1.33 22:29, 9 February 2017 (UTC)
- Keep. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 26 February 2017 (UTC)
- Question These IDs are assigned by the WHO or the FDA? Wostr (talk) 17:21, 5 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 22:23, 12 April 2017 (UTC)
P1124 (P1124): (delete | history | links | entity usage | logs)
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)
- 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 P1124 (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)
- 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)
- 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)
- Delete. No current use (and little evidence of past use). Use volume as quantity (P2234) + unit twenty-foot equivalent unit (Q488021). That property is officially labelled "volume as quantity" with alias "tonnage" so it's reasonable to use it for capacity. There may be a case of starting a new property called "Cargo capacity" which can take either volume, mass, TEU, or even dimensionless tonnage as units, but we can have that discussion later. Deryck Chan (talk) 12:36, 7 February 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:23, 12 April 2017 (UTC)
PORT film ID (P905): PORT-network film database: identifier for a film or television program: (delete | history | links | entity usage | logs)
Port.ro, port.rs, port.sk, port.cz, port.hr were closed between 5 and 11 January 2017 --Ionutzmovie (talk) 13:13, 12 January 2017 (UTC)
- Comment port.hu 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 archive.org Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 13 January 2017 (UTC)
- Keep for now as port.hu is still online.--Jklamo (talk) 23:14, 14 January 2017 (UTC)
- Then update them, right now we are sending people to offline pages.Ionutzmovie (talk) 00:20, 26 January 2017 (UTC)
- Keep what the hell? How have I not been notified? All IDs work with the Hungarian links, and huwiki heavily relies on them. It's the most popular film database here, check Alexa for Hungary. There are no plans to close the Hungarian edition too. – Máté (talk) 16:21, 2 March 2017 (UTC)
- Keep port.hu is still working --WikiDataMovieDB (talk) 10:40, 19 March 2017 (UTC)
- Keep must be some kind of unfunny joke. This is the most referenced Hungarian movie database. Also they were always been historically friendly towards Wikipedia, and have provided lots of data for us. --grin ✎ 11:42, 24 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:23, 12 April 2017 (UTC)
For me a clear case of advertising. --Succu (talk) 22:20, 10 February 2017 (UTC)
- Keep. When it comes to hotels, there is no better source for up-to-date information about the services and equipments on offer than websites such as booking.com (Q4035313) and the likes. Advertising is in the intent. We only judge the content. Thierry Caro (talk) 22:38, 10 February 2017 (UTC)
- Keep Why is the fact that there's a commerical interest a problem. I think the website has an interest in providing truthful information. ChristianKl (talk) 22:39, 10 February 2017 (UTC)
- Keep. I think this is useful for WV. We have property links to a great number of proprietary databases. As long as the IDs are stable it's fine to have them. Deryck Chan (talk) 13:04, 13 February 2017 (UTC)
- Keep. As per everybody else. The issue is whether the external database is one people might find useful to link to, and whether the identifier is stable. Jheald (talk) 20:55, 13 February 2017 (UTC)
- So the main purpose of pages like re/blue-margouillat-seaview.en-gb.html = Blue Margouillat (Q2907190) is not advertising (Q37038)? How does it helps us to provide more independent open data about the domain of hotel (Q27686)? Reloading the page serves me a popup „Save up to 50% in Saint-Leu Get exclusive access to member-only deals by email.” --Succu (talk) 22:36, 13 February 2017 (UTC)
- booking.com (Q4035313) and Blue Margouillat (Q2907190) are clearly independent from one another. Thierry Caro (talk) 23:19, 13 February 2017 (UTC)
- Delete Clearly a case of advertising, like it was said before. booking.com (Q4035313) collects to much personal information: [2]. I don't think WD should promote its use. --Pablísima (talk) 22:37, 15 February 2017 (UTC)
- Delete 1. Advertising. 2. it's not a reliable source of information (clearly it's a conflict of interest to provide neutral information and try to sell the product at the same time).--Zeroth (talk) 02:20, 17 February 2017 (UTC)
- Comment I'm not sure I'm understanding the objection here. So what if the site's purpose is to advertise/promote the facilities offered by the hotels? (And presumably to take a percentage of each booking made through it?) So what? Why should that be an objection? Jheald (talk) 09:15, 17 February 2017 (UTC)
- Keep 1. The criteria of advertising and conflict of interest in Wikivoyageis much lower than Wikipedia and Wikidata have no conflict of interest rescriction. 2. Not every Wikidata properties indicates reliable sources.--GZWDer (talk) 10:52, 17 February 2017 (UTC)
- Comment Has anyone sought the opinion of Wikivoyages on this matter? Part of our role is to support the wikis to have infoboxes, and if they use the id, then we should support it. Just like images/files in use at Commons by other wikis puts them within scope as long as licensing requirements are met. So if used by Voyages, then keep; if not used, then delete. — billinghurst sDrewth 23:59, 19 February 2017 (UTC)
- In the Russian Wikivoyage we do not use this property. One needs to ask at the English Wikivoyage, I do not know whether they use it.--Ymblanter (talk) 14:50, 20 February 2017 (UTC)
- In the German Wikivoyage we are planning to support this and similar properties. We already widely use Wikidata. In some cases we have several hundreds Wikidata calls per article. --RolandUnger (talk) 07:55, 4 March 2017 (UTC)
- Keep This is far from being advertising. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 26 February 2017 (UTC)
- Comment "collects to much personal information" - we shouldn't add/remove external ids in order to support/punish companies for their moves. d1g (talk) 08:55, 3 March 2017 (UTC)
- Keep count me as "keep" for any RFD of an active booking/publishing business: few of them would shoot their foot and allow inaccurate data for prolonged periods of time. d1g (talk) 08:55, 3 March 2017 (UTC)
- Keep Main goal of Wikivoyage is to support travelers as much as possible. Direct links to a booking service bring support not advertising. And it is the reader's decision to use this support or not. A property like booking.com hotel id means that we should have properties to other services like Ctrip and so on. Of course we cannot suppress any advertising. But Wikipedia cannot do it, too. --RolandUnger (talk) 07:55, 4 March 2017 (UTC)
- Keep - if the rationale for deletion is that Wikimedians doesn't approve of the business tactics of the organisation (e.g. that it collects personal information) or that it's a commercial organisation, then I don't see how that's relevant to this Authority Control property existing on Wikidata. We have Facebook username (P2013) property for example, and other equivalently commercial organisations without any problem. Wittylama (talk) 17:31, 8 March 2017 (UTC)
- Keep the fact that a website is commercial in intent is no reason not to link to it, so long as it has useful information. Provided the requirement for stable IDs is met, and there is some sort of useful information there, Wikidata can link to competing commercial websites too. The intentions of the web site owner shouldn't count, only how useful/reliable the data is (and data maintained for commercial purposes usually is reasonably reliable since it is in the commercial interests of the web site owner to keep their data current and accurate.) SJK (talk) 01:02, 12 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 22:23, 12 April 2017 (UTC)
Curlie ID (P998): (delete | history | links | entity usage | logs | discussion)
Per Wikidata:Project_chat#DMOZ shutdown and phab:T128326, it's no longer available, doable, senseful, and useful--Liuxinyu970226 (talk) 10:45, 17 March 2017 (UTC)
- Keep These IDs link into a useful dataset of significant historic value, and world be worth keeping even if DMOZ goes away completely. DMOZ also looks likely to be forked and resurrected elsewhere in the near future. The Related Sites extension can also be retargeted to the new continuity DMOZ fork when it is available: what matters is the data and the community supporting it, not the hosting entity. -- The Anome (talk) 11:00, 17 March 2017 (UTC)
- Keep yes, in general obsolete sites do not imply that their ID's are useless as they may have been correlated by others or may have attached data that is still available; if it had only been used a few times I might agree with deletion, but the DMOZ id has been used on over 11,000 items so I think it is definitely worth preserving. ArthurPSmith (talk) 14:34, 17 March 2017 (UTC)
- Keep per the snowball principle. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:03, 17 March 2017 (UTC)
- Keep per above and prior conversation that I started two weeks before OP. —Justin (koavf)❤T☮C☺M☯ 18:37, 17 March 2017 (UTC)
- Keep per The Anome and ArthurPSmith. Mahir256 (talk) 19:58, 17 March 2017 (UTC)
- Keep The DMOZ website has been shutdown but the dataset is still available. DMOZ made their data available for download as RDF and someone has mirrored the last copy here. Since the dataset still exists, even though it won't be updated and the official hosting is gone, I don't see why the property should be deleted. SJK (talk) 00:10, 18 March 2017 (UTC)
- Comment: a volunteer-run static mirror now exists at http://dmoztools.net , linked to by the holding page now at dmoz.org, and thus presumably unofficially endorsed by the old site maintainers. I've now added it as third-party formatter URL (P3303) for this property. There also seems to be some low-profile activity on cresting a read-write fork. -- The Anome (talk) 07:34, 18 March 2017 (UTC)
- Keep. Wikidata should record defunct identifiers used by notable organisations/projects as they are probably important for anyone learning about that organisation/project. Thryduulf (talk) 09:39, 12 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:23, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Please use existing section for this property. Do not confuse users by creating multiple discussions about the same topic.
--- Jura 17:29, 3 April 2017 (UTC)
- Please use existing section for this property. Do not confuse users by creating multiple discussions about the same topic.
P794 (P794): (delete | history | links | entity usage | logs | discussion)
@GZWDer, Jheald, Deryck Chan: Previous discussion agreed property should be deprecated before being removed. If I'm using the query tool right (that's a big if), the property is now deprecated. --Swpb (talk) 14:49, 30 March 2017 (UTC)
- @Swpb: I think you will find there are rather a lot more live uses than that (!):
tinyurl.com/mldypvu
- I am not entirely sure about the use of subject has role (P2868) as a substitute, but we'll see how it goes. Jheald (talk) 16:10, 3 April 2017 (UTC)
- @Jheald: I suspected that might be the case; any idea why my query didn't work? Swpb (talk) 16:57, 3 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:09, 12 April 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to delete.
The property is used less than 500 times, it doesn't have clear rules for usage and in most cases we have ways to replace, eg.: [3] (end cause (P1534)), [4] (object named as (P1932)), [5] (applies to part (P518)), [6] (age of subject at event (P3629)).
If you want to help with replacing, use this query. Matěj Suchánek (talk) 09:13, 15 May 2017 (UTC)
comment (DEPRECATED) (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)
- 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)
- Delete Overloaded property. --Srittau (talk) 02:46, 25 March 2016 (UTC)
- 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)
- 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.
- 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)
- Delete obviously. Cdlt, VIGNERON (talk) 14:56, 8 April 2016 (UTC)
- Delete, has no connection with structured data.--ԱշոտՏՆՂ (talk) 21:13, 6 May 2016 (UTC)
- Delete Bad use Snipre (talk) 17:36, 25 May 2016 (UTC)
- 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)
- 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.
- 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)
- Thanks, I'm afraid I did not check this discussion in along time. -- LaddΩ chat ;) 14:11, 2 June 2016 (UTC)
- Comment I agree not to add unstructured info in WD; most of the time, I used comment (DEPRECATED) (P2315) as a qualifier to clarify the cryptic meaning of format as a regular expression (P1793) on properties, after a short discussion with Ivan A. Krestinin and after someone else disagreed to use Wikidata usage instructions (P2559) for that purpose (I believe it was Nikki). See Yandex Music artist ID (P1553) for an example. There are still no other property to provide such info. -- LaddΩ chat ;) 14:11, 2 June 2016 (UTC)
- @Laddo: Propose a new property. I am skeptical that it would be declined. If it is declined, there is still the talk page for this information. --Izno (talk) 15:23, 2 June 2016 (UTC)
- I just proposed new property syntax clarification. Please comment :D -- LaddΩ chat ;) 21:57, 2 June 2016 (UTC)
- @Laddo: Propose a new property. I am skeptical that it would be declined. If it is declined, there is still the talk page for this information. --Izno (talk) 15:23, 2 June 2016 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Lymantria: New property syntax clarification (P2916) was created. Can you port qualifiers comment (DEPRECATED) (P2315) on all format as a regular expression (P1793) to the new property? -- LaddΩ chat ;) 12:13, 19 June 2016 (UTC)
- I ported the qualifiers. Now there are 15 items and 21 properties left using comment (DEPRECATED) (P2315). --Pasleim (talk) 15:22, 20 June 2016 (UTC)
- Thanks, Most of the items concern comments on errors in sources. I am thinking of proposing a property on that. Lymantria (talk) 05:18, 24 June 2016 (UTC)
- I think we have a property for that, but my memory is fuzzy. Not a string, I'm pretty sure. --Izno (talk) 11:23, 24 June 2016 (UTC)
- Thanks, Most of the items concern comments on errors in sources. I am thinking of proposing a property on that. Lymantria (talk) 05:18, 24 June 2016 (UTC)
- 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) - 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)
- 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)
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)
- Delete I think we created the necessary replacement/expanded its scope where needed.
--- Jura 19:11, 15 January 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
station code (P296): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep. ChristianKl (talk) 18:59, 30 May 2017 (UTC)
Zero instances. There are much more specified properties holding station codes.--Marfi (talk) 09:09, 20 December 2016 (UTC)
- 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)
- Keep It is good to keep a record of it. Plus usage is alot. MechQuester (talk) 03:59, 31 January 2017 (UTC)
- Delete 5536 missed qualifiers. So currently we have 5536 unknown codes. Separate properties will bring structure to this data hell. — Ivan A. Krestinin (talk) 19:05, 2 March 2017 (UTC)
- I'm torn. The fact that MTR station code (P1377) and China railway TMIS station code (P1378) etc exist means that this is somewhat redundant if we insist on having the mandatory qualifier. On the other hand, if we remove the mandatory qualifier constraint, this property can be used more liberally with various transport systems. Other properties of the station item can be used to tell us which transport system it's in. On balance I vote deprecate and Delete. Deryck Chan (talk) 18:10, 10 March 2017 (UTC)
- I'll be willing to change to keep if we relax the \w+ format requirement so that the Japanese and Norwegian uses of this property - which are the vast majority of uses not already covered by more specific properties - cease to be constraint violations. Deryck Chan (talk) 15:24, 22 March 2017 (UTC)
- Prefer Keep, unless if someone can tell me which property should be used for Japanese telegram code (Q11660285). --Liuxinyu970226 (talk) 12:33, 11 March 2017 (UTC)
- Keep In most case, the code system can easily be guessed by using connecting line (P81) or operator (P137). Deleting this property at this time is inappropriate, I think. --Okkn (talk) 19:51, 13 March 2017 (UTC)
- Keep unless and until all uses are migrated to more specific properties. Thryduulf (talk) 09:28, 12 April 2017 (UTC)
- Same, but there should finally be some decision on whether this should be done, or the more specific properties migrated to this one. --Nenntmichruhigip (talk) 13:32, 18 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
race time (P2781): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Already have duration (P2047) for values and match time of event (P1390) for qualifiers. GZWDer (talk) 18:29, 15 January 2017 (UTC)
Delete MechQuester (talk) 03:57, 31 January 2017 (UTC)
- Keep. This property is admittedly a bit out of form, but it is very useful to have something like that. In an event, duration (P2047) includes much more time than just the plain race/game time, and match time of event (P1390) is only useful in case of (more or less) fixed (game) durations. I would suggest to work on its definition on the property talk page (clearly define scope, maybe make it qualifier only, etc.). Btw. there was plenty of support for this property at Wikidata:Property proposal/Archive/50#P2781. Also ping @Jérémy-Günther-Heinz Jähnick as the original proposer. —MisterSynergy (talk) 10:15, 10 February 2017 (UTC)
- Info I started a discussion at Property talk:P2781#Improve definition and invite all interested users to participate. —MisterSynergy (talk) 10:59, 10 February 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
P907 (P907): (delete | history | links | entity usage | logs)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Clear consensus to delete. --Rschen7754 18:09, 30 April 2017 (UTC)
Only two uses and the database is shut down. --Pasleim (talk) 21:02, 17 January 2017 (UTC)
- Note: The proponent, User:Sven Manguard, announced his retirement in, and has not edited since, January 2015. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:40, 17 January 2017 (UTC)
- Hence Delete. --Succu (talk) 21:55, 17 January 2017 (UTC)
- Delete--Micru (talk) 19:55, 19 January 2017 (UTC)
- Delete because external database is shut down. Deryck Chan (talk) 12:24, 7 February 2017 (UTC)
- Delete as per nomination. 50.53.1.33 21:44, 9 February 2017 (UTC)
- Delete since database is shut down and only minimal uses. SJK (talk) 01:16, 12 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
kinship to subject (P1039): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep. ChristianKl (talk) 19:02, 30 May 2017 (UTC)
It is inconsistent that relative (P1038) uses this but superproperty significant person (P3342) uses P794 (P794) as qualifier. Propose to merge both usage to a new property "specifically" "object has role" (with alias "specifically" and "
type of kinship"). See also the deletion proposal of P794 (P794) above. (I don't support using instance of (P31) as it's still vague) Previous discussion at Wikidata:Property_proposal/Archive/20#specifically.--GZWDer (talk) 15:02, 13 February 2017 (UTC)
- "Specifically"? Really? No will find it, nor know how to use it. Too ugly for general users. So Keep as this named and used property is useful and user friendly. Far better to fix up the relationships of what exists rather than try to recreate what looks like a working wheel. — billinghurst sDrewth
- Delete, but keep P794 (P794). I actually want the latter to have an even broader use than what it has now. It is precisely the fact that it catches everything that makes it useful and easy to use. Thierry Caro (talk) 13:27, 14 February 2017 (UTC)
- @Thierry Caro: P794 (P794) is proposed for split to different properties. You may want to discuss this above.--GZWDer (talk) 15:54, 14 February 2017 (UTC)
- Prefer "object has role" per discussion above--GZWDer (talk) 13:58, 15 February 2017 (UTC)
- Keep For user friendliness. ChristianKl (talk) 17:47, 16 February 2017 (UTC)
- For user friendliness you may add aliases. Also kinship to subject (P1039) have no indication that the type of kinship is with respect of the relationship to the person item on the page where added, but "object has role" clearly have. Property_talk:P1039 also discussed the ambiguity.--GZWDer (talk) 10:42, 17 February 2017 (UTC)
- "Object has role" is no better and lacks clarity. I doubt that anyone is going to think of some other person as an "object", nor that a relationship of grandparent, or father-in-law as a "role". They are people and have relationships/kinships/... — billinghurst sDrewth 23:53, 19 February 2017 (UTC)
- For user friendliness you may add aliases. Also kinship to subject (P1039) have no indication that the type of kinship is with respect of the relationship to the person item on the page where added, but "object has role" clearly have. Property_talk:P1039 also discussed the ambiguity.--GZWDer (talk) 10:42, 17 February 2017 (UTC)
- Keep User friendly, enough specific, easier queryable.--Jklamo (talk) 21:24, 26 February 2017 (UTC)
- Keep significant person (P3342) is too generic and is not defined enough. — Ivan A. Krestinin (talk) 19:08, 2 March 2017 (UTC)
- Comment I would like to reduce number of basic properties to memorize: SPARQL/easier data entry, but I also understand comments about "Object has role". d1g (talk) 09:25, 3 March 2017 (UTC)
- Wait for the outcome of #as (P794), above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:31, 12 May 2017 (UTC)
- Keep Kinship doesn't lead to participation or importance, so significant person (P3342) and P794 (P794) are not applicable. --Infovarius (talk) 07:54, 19 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
version type (P548): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Clear consensus to keep. --Rschen7754 18:15, 30 April 2017 (UTC)
Once the "specifically" "object has role" property above is created, we should merge this too.--GZWDer (talk) 15:02, 13 February 2017 (UTC)
- KeepDeleting the property makes the relevant data less clear. ChristianKl (talk) 17:49, 16 February 2017 (UTC)
- We don't need seperate properties if one property don't not make confusion. location (P276) and part of (P361) is both already merged with (at least) 3 different properties.--GZWDer (talk) 10:45, 17 February 2017 (UTC)
- I don't like our "part_of" property and how it tries to do many different things either. ChristianKl (talk) 07:33, 18 February 2017 (UTC)
- We don't need seperate properties if one property don't not make confusion. location (P276) and part of (P361) is both already merged with (at least) 3 different properties.--GZWDer (talk) 10:45, 17 February 2017 (UTC)
- Keep With P:548, we know the value type of this qualifier (Q28530564); with the "global" property "object has role", we can't set this constraint and this property will be less well defined for this specific use than P:548 (notifying WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. because this property is about software version type). — Metamorforme42 (talk) 17:40, 2 March 2017 (UTC)
- Keep Specific properties are easier to use than a generic qualifier. The generic qualifier can't have constraints specific to this domain on it as Metamorforme42 points out. (Or, if there was some way to conditionally apply them to the generic qualifier, I think that would get very unwieldy quickly if generic qualifiers have dozen of domain-specific conditional constraints on them.) SJK (talk) 01:14, 12 March 2017 (UTC)
- Keep For the time being the specific property has big usability benefits as pointed out before while the disadvantages are marginal. ---- (talk) 16:04, 24 March 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
designated as terrorist by (P3461): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- No consensus to delete. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:20, 12 May 2017 (UTC)
May use instance of (P31) terrorist organization (Q17127659) with "statement supported by" instead.--GZWDer (talk) 17:13, 18 February 2017 (UTC)
- Delete this is only used once (and as GZWDer points out, on an organization not a person, so P31 is fine) - ArthurPSmith (talk) 13:45, 21 February 2017 (UTC)
- Note: This was only created on 15 January 2017. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 26 February 2017 (UTC)
- Keep. At least two reasons: first, instance of (P31) is used as an inherent property, whatever the following statements; history shows very clearly the qualification as "terrorist" strongly depends of who, what and why (French Communist Party (Q192821) is designated as terrorist by (P3461) by Nazi Germany (Q7318)), more than the intrinsic nature of thing. Second, designated as terrorist by (P3461) should be use with a bunch of qualifiers such as start time (P580), end time (P582), legal citation of this text (P1031)... without P3461 this data were qualifiers of a qualifier. Kumkum (talk) 19:59, 5 March 2017 (UTC)
- Keep per Kumkum's persuasive reasoning. SJK (talk) 00:58, 12 March 2017 (UTC)
- Keep per Kumkum. It's very important that we don't combine properties that record a POV with those that record statement of fact. Thryduulf (talk) 09:36, 12 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
P3873 (P3873): (delete | history | links | entity usage | logs)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to delete. --Rschen7754 18:17, 30 April 2017 (UTC)
Property proposer. I did not check if any similar properties existed, and it appears that P3873 (P3873) substantially duplicates daily patronage (P1373). Since it was created 20 minutes ago, it does not have any uses yet.—Jc86035 (talk) 14:11, 18 April 2017 (UTC)
Pinging ArthurPSmith, ChristianKl, Izno and Nikki, who commented on the property proposal. Jc86035 (talk) 14:38, 18 April 2017 (UTC)
- Oops. Yup Delete. ArthurPSmith (talk) 14:47, 18 April 2017 (UTC)
- Should the domain of daily patronage (P1373) be expanded to include other establishments and facilities, since it currently only applies to transportation stations and services? Jc86035 (talk) 14:52, 18 April 2017 (UTC)
- I agree to Delete and expand the scope of daily patronage (P1373) as proposed by Jc86035. ChristianKl (talk) 15:19, 18 April 2017 (UTC)
- Delete exact duplicate, right? d1g (talk) 15:47, 30 April 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
taxon author (P405): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep as it doesn't replicate named by (P3938) directly and has other semantics. ChristianKl (talk) 19:03, 30 May 2017 (UTC)
taxon author (P405) is rendered redundant by the recent creation of named by (P3938). That said, P405 is widely used, so it may be better to merge the new property into P405, and update its label, description, and constraints.--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:46, 12 May 2017 (UTC)
- Keep taxon author (P405) is a widely used property, named by (P3938) is a qualifier. Also @Succu: as one of the more active taxon people. Multichill (talk) 20:34, 15 May 2017 (UTC)
- Hence the final sentence of my nomination, which you appear to have overlooked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 15 May 2017 (UTC)
- Keep because Mr. Mabbett's proposal is not very well grounded. --Succu (talk) 20:59, 15 May 2017 (UTC)
- Succu's objection (he having been selectively canvassed) contains no substance; and certainly offers no reason why two properties are needed. It appears to be merely an arbtrary prefence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 15 May 2017 (UTC)
- „selectively canvassed”, Mr. Andy Mabbett? Why should we use the new property. Please give some arguments. Thanks --Succu (talk) 21:32, 15 May 2017 (UTC)
- Your reading powers are awesome, "selectively canvassed" is indeed what I wrote. Now please apply those powers to the proposal I made at the start of this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:18, 15 May 2017 (UTC)
- Your primary proposal is to delete taxon author (P405) in favor of named by (P3938)
- Your secondary proposal is to broaden the context of taxon author (P405) in favor of deleting named by (P3938)
- Your argument is „taxon author (P405) is rendered redundant by the recent creation of named by (P3938)“
- So what is „rendered redundant“ by the creation of this new property? Please be more talkative, Mr. Mabbett. Thanks. --Succu (talk) 20:16, 17 May 2017 (UTC)
- Your reading powers are awesome, "selectively canvassed" is indeed what I wrote. Now please apply those powers to the proposal I made at the start of this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:18, 15 May 2017 (UTC)
- „selectively canvassed”, Mr. Andy Mabbett? Why should we use the new property. Please give some arguments. Thanks --Succu (talk) 21:32, 15 May 2017 (UTC)
- Succu's objection (he having been selectively canvassed) contains no substance; and certainly offers no reason why two properties are needed. It appears to be merely an arbtrary prefence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 15 May 2017 (UTC)
PS: WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Succu (talk) 21:56, 15 May 2017 (UTC)
- I would prefer that taxonomy would also use the qualifier solution with named by (P3938) but I see no reason to delete this existing property as long as the data isn't moved over. ChristianKl (talk) 10:13, 23 May 2017 (UTC)
- In nomenclature it's not important which of several authors coined the name. There is no one to one relationship between these two qualifiers. See also ex taxon author (P697). --Succu (talk) 15:34, 23 May 2017 (UTC)
Keep A taxon author does much more than just naming the taxon, that property also includes aspects of discoverer or inventor (P61) Ahoerstemeier (talk) 22:23, 23 May 2017 (UTC)
- I have been convinced to Keep. ChristianKl (talk) 15:54, 24 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
inventory number (P217): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep. ChristianKl (talk) 19:01, 30 May 2017 (UTC)
Duplicates catalog code (P528), as can be seen, for example, on Munimenta antiqua: or, observations on antient castles (Q27308080). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:16, 12 May 2017 (UTC)
- Keep no, it's not the same. inventory number (P217) is used with collection (P195) and catalog code (P528) with catalog (P972). Multichill (talk) 20:37, 15 May 2017 (UTC)
- That can easily be resolved by merging collection (P195) and catalog (P972). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:21, 15 May 2017 (UTC)
- Keep Not the same thing at all. A catalogue code is a specific code signed to an object when it appears in an exhibition. An inventory number is a number assigned by the institution where the object resides. They are two totally different things (and this is what I spent $80k getting into debt to learn... ;-) Missvain (talk) 20:44, 15 May 2017 (UTC)
- That distinction does not appear to be made on Wikidata. Not least since galaxies and other astronomical bodies, for example, are rarely exhibited, nor kept in institutions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:21, 15 May 2017 (UTC)
- Sounds like galaxies should not be using inventory numbers then and just catalogs. When it comes to paintings or other movable heritage, however, we need both. Jane023 (talk) 22:01, 15 May 2017 (UTC)
- AFAICT, they do use "catalogue" (despite not being exhibited). Why do we need both? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:20, 15 May 2017 (UTC)
- Because a painting can be lent out for an exhibition, whereupon its exhibition catalog number is not the same as its inventory number in the lending institution. They are two disctinct concepts that should not be confused. An inventory number refers to a collection, while a catalog number generally refers to a page in a printed book. Jane023 (talk) 15:56, 16 May 2017 (UTC)
- The fact that "a painting can be lent out for an exhibition" in no way precludes the combining of these two properties. Nor does the fact that some catalogues exist on dead tree media. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 16 May 2017 (UTC)
- Because a painting can be lent out for an exhibition, whereupon its exhibition catalog number is not the same as its inventory number in the lending institution. They are two disctinct concepts that should not be confused. An inventory number refers to a collection, while a catalog number generally refers to a page in a printed book. Jane023 (talk) 15:56, 16 May 2017 (UTC)
- AFAICT, they do use "catalogue" (despite not being exhibited). Why do we need both? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:20, 15 May 2017 (UTC)
- Sounds like galaxies should not be using inventory numbers then and just catalogs. When it comes to paintings or other movable heritage, however, we need both. Jane023 (talk) 22:01, 15 May 2017 (UTC)
- That distinction does not appear to be made on Wikidata. Not least since galaxies and other astronomical bodies, for example, are rarely exhibited, nor kept in institutions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:21, 15 May 2017 (UTC)
There are very few museums that have kept their numbering consistently for longer than two decades, besides some fossilized 19th-century royal collections and other slowly-changing collections. There are many many inventory numbers that have thus never been printed in an official catalog with their inventory numbers at the point in time they had that inventory number. This is generally information only kept at the institution itself. It would be detrimental to the project to remove this needed identifier for collections. As far as merging the identifier with the collection property, I am also against this, as most collections do not have identifiers (private families, small collections, etc). Jane023 (talk) 08:27, 17 May 2017 (UTC)
- "It would be detrimental to the project to remove this needed identifier for collections" is simply a rephrasing of "we need both"; not an argument as to why both are needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:27, 17 May 2017 (UTC)
- To track paintings in collections on Wikidata, whenever possible, we like to use inventory numbers of institutions, because we can easily cross-reference these with other publications and online resources. The visual image and measurements are not enough to determine the uniqueness of a painting and other characteristics are needed. The inventory number is just one piece of the puzzle. Catalogs of works in an institution may or may not be published by institutions themselves, but are also an important piece of the puzzle. Art auction data is also important; in that case, a painting may be assigned a lot number and this is often used in art provenance records in combination with the date, place, and name of the auction house, whether or not that specific painting made it into the printed sale catalog (if a sale catalog was even printed at all). At a following auction, the same lot number can be re-used, so to refer to a specific painting in any auction you need the number in combination with the other references. The exact same thing is true for collections, except the accessioning and deaccessioning process happens a lot more slowly. Catalogs, on the other hand, are assembled at the discretion of the author, and sometimes the author is well versed in provenance methodology, and sometimes not. So a catalog might be recorded by number, number + page number, catalog number, footnote number or illustration number in addition to catalog number, etc. So the idea of using an inventory number for a collection is a lot cleaner than using a catalog number, which can be quite messy. Museums produce catalogs regularly for exhibitions, and from time to time they may produce highlight catalogs (which sometimes do and sometimes don't include the inventory numbers). They very rarely produce catalogs on paper of the entire collection. Probably less often than once every 15 years or so. Merging these fields would making tracking much more difficult, in addition to confusing the number assigned to a painting by an institution in its inventory and the number assigned to a painting by the institution in one of its printed catalogs. Jane023 (talk) 12:11, 18 May 2017 (UTC)
- Keep I don't think we have to call everything a catalog whether or not it is a catalog. ChristianKl (talk) 10:17, 23 May 2017 (UTC)
- Keep --Marsupium (talk) 09:47, 25 May 2017 (UTC)
- Keep per Missvain, not the same thing at all. Lankiveil (talk) 04:33, 28 May 2017 (UTC).
- Keep I first ran into catalogue code and inventory number in connection with paintings. To me the inventory number is special from a catalogue code in that it entails an ownership and it is the owner that makes the inventory number and there is usually only one. Catalogues may be made by anyone and every exhibition or "reasoned catalogue" (catalogue raisonné (Q1050259)) may have there own numbering scheme. For most painting we would expected that there is always an inventory number. There may be zero or more catalogue numbers. I also concur with the arguments of Jane023. collection (P195) and catalog (P972) to me are also distinct. — Finn Årup Nielsen (fnielsen) (talk) 18:14, 29 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:41, 30 May 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 07:36, 2 June 2017 (UTC)
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 number of 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)
- 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 number of 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)
- @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)
- What are those properties? I only see number of wins (P1355) and number of losses (P1356), we are still lacking "games won in singles/doubles", "games lost in singles/doubles". --Srittau (talk) 19:12, 28 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)
- Delete number of wins (P1355) and number of 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)
- 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)
- 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)
- Delete. Also, with number of wins (P1355) and number of 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 number of 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)
- And we wouldn't delete number of wins (P1355) and number of 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)
- 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)
- 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)
- @Edoderoo, Vinkje83: extra-ping, as I forgot to sign. --Edgars2007 (talk) 19:37, 27 August 2016 (UTC)
- Keep Both properties are used in 40+ projects.--Jklamo (talk) 00:43, 23 January 2017 (UTC)
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)
- Delete per above as splittable into two propereties. Pppery (talk) 02:50, 3 February 2017 (UTC)
- Why has this discussion stayed open for over a year? Pppery (talk) 02:49, 3 February 2017 (UTC)
- Keep Per Vinkje83 and Edoderoo, these properties are widely used in tennis infoboxes in this combination (win/loss).--Wolbo (talk) 01:31, 22 February 2017 (UTC)
- Keep used in many Wikipedia templates, can't be removed. Stryn (talk) 11:59, 19 March 2017 (UTC)
- Delete--Chris XC3000 (talk) 11:43, 27 March 2017 (UTC)
- Keep (for now) because I can't see (nobody's demonstrated it here) how the properties would be replaced. Matěj Suchánek (talk) 14:34, 20 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:55, 7 July 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 07:38, 2 June 2017 (UTC)
docking port (P546): (delete | history | links | entity usage | logs | discussion)
Use via (P2825). GZWDer (talk) 17:13, 3 August 2016 (UTC)
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)
- 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)
- Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:21, 4 August 2016 (UTC)
- Keep per my comment on #Property:P446 —surueña 11:11, 17 August 2016 (UTC)
- Delete per Pasleim. --Jklamo (talk) 23:39, 8 September 2016 (UTC)
- Keep, via (P2825) and significant event (P793) are too generic for effective usage. — Ivan A. Krestinin (talk) 20:31, 24 October 2016 (UTC)
- Keep seems to be in use.
--- Jura 19:11, 15 January 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:55, 7 July 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- No consensus to delete. --Rschen7754 18:52, 3 June 2017 (UTC)
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)
- 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) - Delete as per nomination. Having an identifier that points into a database that is no longer available is of questionable value. 50.53.1.33 22:19, 9 February 2017 (UTC)
- Keep We don't need an external site for an identifier to be useful. We should not be discarding such data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 26 February 2017 (UTC)
- Keep via Pigsonthewing. ChristianKl (talk) 17:52, 23 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:55, 7 July 2017 (UTC)
Quora topic ID (P3417): (delete | history | links | entity usage | logs | discussion)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep in the present form. ChristianKl (talk) 14:53, 12 June 2017 (UTC)
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: https://konklone.com/post/quora-keeps-the-worlds-knowledge-for-itself 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. hashtag (P2572). For me Quora topic ID (P3417) is pretty similar to 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 Support to move this property from external-id to string datatype. --Pasleim (talk) 10:59, 26 December 2016 (UTC)
- The claim that "They don't identify concepts" is patently false; a few examples have been used to suggest that it is true, but they are a small and atypical minority. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 26 December 2016 (UTC)
- It's not an atypical minority. Many topics are simply ill defined, e.g. Kernel-1 added to kernel (Q9662) is about Kernel in operating systems but also about popcorn kernels and kernel in mathematics. Westfalia added to Westphalia (Q8614) is about the term, the region and a campmobile. Some more flaws from the Q10000-Q12000 range: Solothurn on Solothurn (Q11929), 1100-1 on 1100 (Q10660), Pool-2 on pool (Q11020), United-Nations-Headquarters on Headquarters of the United Nations (Q11297). --Pasleim (talk) 17:46, 26 December 2016 (UTC)
- Mis-application of a topic by a tiny number of individuals (there were just three for popcorn, out of 204 questions) does not invalidate the correct usage. This is no different to Wikipedia or Wikimedia Commons categories, for example, or other external IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 26 December 2016 (UTC)
- Commons categories are indeed not better than quora topics, thats why Commons category (P373) has string datatype. --Pasleim (talk) 19:50, 26 December 2016 (UTC)
- No, it is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:25, 27 December 2016 (UTC)
- Impressiv: 701 units follow a not existing question about the United Nations Headquarters which renders to a related question Can I just stroll into the ECB or the UNHQ? Matched by @Pigsonthewing:. Thus Delete --Succu (talk) 22:43, 26 December 2016 (UTC)
- There were acutally more questions on United Nations Headquarters. Pigsonthewing has now fixed all the issues I pointed out above. This is positive for Quora but it covers up the issue. --Pasleim (talk) 22:57, 26 December 2016 (UTC)
- I'm not clear whether Succu's reason for wanting to overturn the consensus that saw this property created is that 701 people (Too many? Too few?) follow a single specific topic; or that it was me who made the valid match between that single topic and the equivalent item in Wikidata. Which is it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:29, 27 December 2016 (UTC)
- I'm not willingly to guess a concept behind United Nations Headquarters. For me there is simply nothing noteworthy we should link to. --Succu (talk) 19:00, 27 December 2016 (UTC)
- I wasn't asking you to guess anything; I was asking for clarification of your stated reason for wanting to overturn the consensus that saw this property created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:04, 27 December 2016 (UTC)
- Again: Please keep in mind the context of this subthread. Danke. --Succu (talk) 19:13, 27 December 2016 (UTC)
- I wasn't asking you to guess anything; I was asking for clarification of your stated reason for wanting to overturn the consensus that saw this property created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:04, 27 December 2016 (UTC)
- I note that my question was not answered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 6 March 2017 (UTC)
- I'm not willingly to guess a concept behind United Nations Headquarters. For me there is simply nothing noteworthy we should link to. --Succu (talk) 19:00, 27 December 2016 (UTC)
- Commons categories are indeed not better than quora topics, thats why Commons category (P373) has string datatype. --Pasleim (talk) 19:50, 26 December 2016 (UTC)
- Mis-application of a topic by a tiny number of individuals (there were just three for popcorn, out of 204 questions) does not invalidate the correct usage. This is no different to Wikipedia or Wikimedia Commons categories, for example, or other external IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 26 December 2016 (UTC)
- It's not an atypical minority. Many topics are simply ill defined, e.g. Kernel-1 added to kernel (Q9662) is about Kernel in operating systems but also about popcorn kernels and kernel in mathematics. Westfalia added to Westphalia (Q8614) is about the term, the region and a campmobile. Some more flaws from the Q10000-Q12000 range: Solothurn on Solothurn (Q11929), 1100-1 on 1100 (Q10660), Pool-2 on pool (Q11020), United-Nations-Headquarters on Headquarters of the United Nations (Q11297). --Pasleim (talk) 17:46, 26 December 2016 (UTC)
- The claim that "They don't identify concepts" is patently false; a few examples have been used to suggest that it is true, but they are a small and atypical minority. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 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)
- 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.
- 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)
- Keep Since string and external-id have the same structure this should not be "delete"; so the real question is whether a conversion is merited. If I am understanding the original external-id conversion arguments, I believe this should be external-id over string. The differentiating factor seems to be whether the value has peer review (Q215028) as a unique controlled vocabulary (Q1469824). Virtually all identifiers are used for grouping (e.g., all of authority file (Q36524) and document indexing (Q1167863)). Though hashtag (P2572) is certainly used for grouping it is not a peer reviewed controlled vocabulary (so it is very easy to come up with different hash tags that essentially cover the same concept). This is why I see it differently than this one. 50.53.1.33 22:07, 9 February 2017 (UTC)
- I prefer it to be external id. ChristianKl (talk) 11:24, 11 February 2017 (UTC)
- Keep with external ID. If someone finds it useful, and it's not causing any direct harm to our project, then by all means let it be. Icebob99 (talk) 15:50, 5 March 2017 (UTC)
- Keep; no opinion about datatype or references. d1g (talk) 15:41, 30 April 2017 (UTC)
- Support migration, unfortunately keep such claims under external-id could sometimes make problems that may or not about "language variants"-related markers (e.g.
-{}-
), cf. mw:Parsoid/Language_conversion/Preprocessor_fixups/20170501/sister-other#wikidatawiki. --Liuxinyu970226 (talk) 15:28, 18 May 2017 (UTC)- It's hard to determine any relation between the link you provide and P3417. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 23 May 2017 (UTC)
- @Pigsonthewing: I added your Phabricator account as a subscriber to phab:T166429 so that you know what's wrong within those items now. --Liuxinyu970226 (talk) 13:06, 6 June 2017 (UTC)
- That appears to eb about a parser bug. There is nothing wrong with this property, which is not mentioned there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 6 June 2017 (UTC)
- @Pigsonthewing: I added your Phabricator account as a subscriber to phab:T166429 so that you know what's wrong within those items now. --Liuxinyu970226 (talk) 13:06, 6 June 2017 (UTC)
- It's hard to determine any relation between the link you provide and P3417. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 23 May 2017 (UTC)
- It's time this benighted proposal was closed. We have 161K uses of the property, and growing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 23 May 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 22:55, 7 July 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to change data type --Pasleim (talk) 20:31, 11 August 2017 (UTC)
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
- families (
href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=fm&name=
, e.g. Acanthaceae - genera (
href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=gn&name=
, e.g. Avicennia - infraspecific taxa (
href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=in&name=
, e.g. Avicennia marina subsp. australasica
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)
- 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)
- Mind to repeat them? --Succu (talk) 18:38, 26 September 2016 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --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)
- 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)
- Brya: Could you express your concerns about datatype URL a little bit more please? --Succu (talk) 19: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 Oppose to deletion and change into URL-datatype. Lymantria (talk) 07:22, 3 October 2016 (UTC)
- A part of an URL (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 URL (Q42253) may not be an identifier (Q853614), an identifier (Q853614) may become part of a URL (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 (primary 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)
- Of course not. formatter URL (P1630) is a shortcut for an external id e.g. for an internal database table id (primary key (Q934729)). Saying 0-9538134-4-5 could be identified by International Standard Book Number (Q33057)=
- 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)
- Yes: A part of an Uniform Resource Identifier (Q61694) is not an ID. A part of International Standard Book Number (Q33057) like
- 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)
- So a part of an ID makes it an ID of its own? --Succu (talk) 20:02, 4 October 2016 (UTC)
- My point is that I disagree with you that
- Lymantria: Please, could you provide more details? I do not understand what your point is. --Succu (talk) 19:45, 4 October 2016 (UTC)
- A part of a URL (Q42253) may not be an identifier (Q853614), an identifier (Q853614) may become part of a URL (Q42253). Lymantria (talk) 19:40, 4 October 2016 (UTC)
- A part of an URL (Q42253) like
- Looks like that Italian Senate of the Republic ID (P2549) was later misused ([7]). --Succu (talk) 19:51, 4 October 2016 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:31, 11 August 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 20:32, 11 August 2017 (UTC)
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)
- Comment see w:ISO 639-6.
--- Jura 14:19, 13 December 2016 (UTC) - Delete Not used, deprecated, better avoid to import useless data. Snipre (talk) 17:13, 13 December 2016 (UTC)
- 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)
- 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 Keep: how to store the 639-6 code without this property? Cdlt, VIGNERON (talk) 11:20, 11 January 2017 (UTC)
- 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)
- Delete as per nomination. With the specification withdrawn and the data no longer available this seems to be of little usefulness. There are several other ISO 639 identifiers that can be used in lieu of this one. 50.53.1.33 22:16, 9 February 2017 (UTC)
- Keep Given that Wikipedia import the data into their infoboxes. We should delete data that get's used in infoboxes without good reason. ChristianKl (talk) 11:18, 11 February 2017 (UTC)
- @ChristianKl: deletion of parameters from infoboxes can just be a bot work, iirc. --Liuxinyu970226 (talk) 11:10, 2 March 2017 (UTC)
- @Liuxinyu970226: Whether the individual Wikipedias want to delete the paramater from their infobox is an editorial decision on their side and not something that a Wikidata approved bot can decide.
- @ChristianKl: So please provide another online resource, that we could still query ISO 639-6 to make values correct. --Liuxinyu970226 (talk) 00:07, 12 July 2017 (UTC)
- Why do you believe that the present values aren't correct? ChristianKl (talk) 11:12, 12 July 2017 (UTC)
- Keep as in use. Yes a bot could delete the parameters from the infoboxes, but then that would result in the data currently present in the article disappearing - if we want Wikipedias to use Wikidata as a source for infobox information it is very important that we don't delete the information they are using without their consensus. Separately I don't see why Wikidata has to restrict itself to currently used identifiers, surely our mission includes representing the world as it was rather than just as it is (otherwise why have entries for entities like German Democratic Republic (Q16957) or properties like end time (P582) instead of deleting the no-longer valid data). Thryduulf (talk) 09:27, 12 April 2017 (UTC)
- Question according to Wikipedia this has been withdrawn, but was it replaced with anything? If a newer, better standard exists then we should replace this identifier with the newer version, and Wikipedia infoboxes should follow suit. Laurdecl talk 06:08, 15 May 2017 (UTC)
- Keep as useful and meaningful
- This section was archived on a request by: --Pasleim (talk) 20:32, 11 August 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 20:33, 11 August 2017 (UTC)
number of elevators (P1301): (delete | history | links | entity usage | logs | discussion)
Should use has part(s) (P527) -> elevator (Q132911), qualified with a quantity. There are currently 851 uses, which is low compared to the potential use.--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:18, 24 February 2017 (UTC)
- Oppose specific enough, 850+ uses, used by two templates.--Jklamo (talk) 18:40, 24 February 2017 (UTC)
- The issue isn't whether it's used, but whether it's needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:24, 4 March 2017 (UTC)
- Oppose Using a specific property as opposed to a generic property with a qualifier is more user-friendly. It is less clicking/typing, easier for new users to understand, etc. I think qualified generic properties should only be used if no specific property exists, and specific properties should only be deleted if they are useless (and 851 uses proves this isn't useless.) SJK (talk) 00:57, 12 March 2017 (UTC)
- Delete "number of ..." (lifts) belong to units. I see "lits" as units. One property or qualifier is enough to describe "totals". I don't understand why do we enter units, when we can explode property count for every unit. Do we need units or do we need specific properties instead of units? d1g (talk) 15:13, 30 April 2017 (UTC)
- Oppose This is utilised in templates already, and seems like a reasonable use, which would be much harder to reproduce with the qualifier. fr:Catégorie:Page_utilisant_P1301. --99of9 (talk) 06:40, 28 June 2017 (UTC)
- Oppose Used in https://tools.wmflabs.org/listeria/dynamic.html#list=204&lang=fr Manu1400 (talk) 22:50, 5 July 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:33, 11 August 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 20:34, 11 August 2017 (UTC)
P3649 (P3649): (delete | history | links | entity usage | logs)
Duplicate of RePEc Short-ID (P2428), just a different URL to the same information.--Bamyers99 (talk) 18:58, 27 February 2017 (UTC)
- That seems true, so let's Delete the new one. ChristianKl (talk) 19:16, 27 February 2017 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Is it? The link in the example for P3649 is:
For P2428, the URL is:
The respective values are f/pal207 and psh93; the formats of which do not match. Another URL for P3649 is https://ideas.repec.org/e/pfr10.html, so the letter prefix is significant. These prefixes are used in |repec_prefix=
in en:Template:Infobox economistAndy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 27 February 2017 (UTC)
- The examples on the property pages are for different people. Andrei Shleifer (Q502557) vs Alberto Alesina (Q1387534) The prefix is only significant if using the ideas url. The same information, the list of papers, is available from the authors.repec.org url, which doesn't need the prefix. --Bamyers99 (talk) 22:53, 27 February 2017 (UTC)
- I can see that they are for diferent people. I referred to the formats not the values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:04, 28 February 2017 (UTC)
- I found the url for displaying the IDEAS interface without having to know the e/f prefix: https://ideas.repec.org/cgi-bin/h.cgi?h=psh93 --Bamyers99 (talk) 01:39, 28 February 2017 (UTC)
- In that case, Delete. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:25, 28 February 2017 (UTC)
- After migrating data; that is - there are now over 500 uses. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:49, 6 March 2017 (UTC)
- I already copied all enwiki infobox uses to P2428. Evidently Thierry Caro didn't see the deletion notice on the P3649 talk page. --Bamyers99 (talk) 15:13, 6 March 2017 (UTC)
- Sorry. I didn't know the deletion was being debated. Feel free to do what's best. Thierry Caro (talk) 15:55, 6 March 2017 (UTC)
- I already copied all enwiki infobox uses to P2428. Evidently Thierry Caro didn't see the deletion notice on the P3649 talk page. --Bamyers99 (talk) 15:13, 6 March 2017 (UTC)
- After migrating data; that is - there are now over 500 uses. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:49, 6 March 2017 (UTC)
- In that case, Delete. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:25, 28 February 2017 (UTC)
- IDEAS is a particular site based on RePEc`s data. Since the identifiers are the same, it is bad to keep both in Wikidata, because data entry efforts split up between the two, and it would be cumbersome trying to keep them in sync. RePEc Author links are meant to be permanent (see the note on the bottom of, e.g., https://authors.repec.org/pro/pal207/), whereas IDEAS URLs don't claim that. -- That said, the IDEAS page contains more information (about ranking, download statistics and so on), so there is value in linking to it. Is there something like computed fields in Wikidata, which would allow us to offer only P2428 for input, but to display an additional computed link link to IDEAS? Jneubert (talk) 13:56, 12 May 2017 (UTC)
- As of just now, there are 14 items which have P3649 and no P2428, while 1787 items have P2828 and no P3549. Jneubert (talk) 14:14, 12 May 2017 (UTC)
- From time to time I check for P3649 and update P2428, if not present. So as of just now, there are no such items. Jneubert (talk) 16:51, 11 July 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 20:34, 11 August 2017 (UTC)
Dietmar Rabich (Q37846640): German photographer and mathematician: (delete | history | links | entity usage | logs)
Sorry, already created with another ID. It's twice now. (Q34788025)--XRay (talk) 06:04, 24 August 2017 (UTC)
- Wrong page and request. Merged Matěj Suchánek (talk) 07:39, 24 August 2017 (UTC)
- Sorry. Every Wiki with it's own way. I'll try my very best. --XRay (talk) 08:12, 24 August 2017 (UTC)
- Already done. Thank you. --XRay (talk) 08:16, 24 August 2017 (UTC)
- This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 12 September 2017 (UTC)
2-pentene (Q12871786) and 2-pentene (Q22051121)
- Please, delete one of them... I prefer Q22051121 to be deleted, because it haa no link at all. But before deletion, please transfer all usefull data what missed from the other...
--Vchorozopoulos (talk) 18:37, 9 September 2017 (UTC)
- Wrong page and request. Merged Matěj Suchánek (talk) 18:42, 9 September 2017 (UTC)
- This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 15 September 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
P1646 (P1646): (delete | history | links | entity usage | logs)
Not used in documentation and succeeded by property constraint (P2302). GZWDer (talk) 17:01, 23 July 2017 (UTC)
- Delete Per Property talk:P1646#Convert to new scheme and delete. Matěj Suchánek (talk) 10:16, 29 July 2017 (UTC)
- Delete in order to maintain only one property (property constraint (P2302)) for all constraint-related questions.
- P1646 can be derived from P2302. d1g (talk) 12:34, 30 July 2017 (UTC)
- Migrate and then Delete. --Yair rand (talk) 23:36, 11 September 2017 (UTC)
- Migrate and then Delete. --Marsupium (talk) 12:53, 15 September 2017 (UTC)
- Migrate then Delete. Deryck Chan (talk) 09:22, 22 September 2017 (UTC)
Ok. delete it is. @GZWDer, Matěj Suchánek, D1gggg, Yair rand, Marsupium, Deryck Chan: go ahead and migrate the property and please report back here when it is done so the property can be deleted. Multichill (talk) 09:19, 23 September 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 17:45, 26 September 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 21:49, 10 October 2017 (UTC)
terminus location (P609): (delete | history | links | entity usage | logs | discussion)
Merge with terminus (P559). The distinction between these two properties is fuzzy and not worth distinguishing. terminus (P559) supposedly indicates a "feature", meaning a road, station, etc., at the end of a linear feature, whereas terminus location (P609) supposedly indicates the city, town, or other administrative entity at a terminus, but their use overlaps significantly: see Hallandsås Tunnel (Q493063).--Swpb (talk) 16:38, 29 March 2017 (UTC)
- Strongly agree the deletion reason, I'm just confused with such unnecessary splitting. --Liuxinyu970226 (talk) 12:05, 6 April 2017 (UTC)
- Delete --Pasleim (talk) 11:43, 15 April 2017 (UTC)
- Delete, confusing and unnecessary. Jc86035 (talk) 11:51, 18 April 2017 (UTC)
- Keep Per Wikidata:Property_proposal/Archive/8#P609. terminus (P559) and terminus location (P609) are bit confusing, but they are used distinctively (both 10,000+ uses). Separate terminus location (P609) property is better solution than located in the administrative territorial entity (P131) qualifier. – The preceding unsigned comment was added by Joshbaumgartner (talk • contribs).
- Keep Just because people aren't using it properly doesn't mean it should be deleted. Please see where it is properly used, like California State Route 78 (Q19183). --Rschen7754 01:56, 20 April 2017 (UTC)
- Alexis900 (talk • contribs • logs) Asqueladd (talk • contribs • logs) BeneBot* (talk • contribs • logs) Detcin (talk • contribs • logs) Dough4872 (talk • contribs • logs) Gz260 (talk • contribs • logs) Happy5214 (talk • contribs • logs) Imzadi1979 (talk • contribs • logs) Jakec (talk • contribs • logs) Labant (talk • contribs • logs) Liuxinyu970226 (talk • contribs • logs) Ljthefro (talk • contribs • logs) mxn (talk • contribs • logs) naveenpf (talk • contribs • logs) Puclik1 (talk • contribs • logs) Rschen7754 (talk • contribs • logs) Scott5114 (talk • contribs • logs) SounderBruce (talk • contribs • logs) TCN7JM (talk • contribs • logs) TimChen (talk • contribs • logs) Bodhisattwa (talk • contribs • logs) Daniel Mietchen (talk • contribs • logs) Tris T7 TT me Izolight (talk • contribs • logs) Gnoeee (talk • contribs • logs)Notified participants of WikiProject Roads since the first one didn't go through. --Rschen7754 01:56, 20 April 2017 (UTC)
- Keep The distinction between the two properties is made in the infoboxes on Wikipedia also. --Labant (talk) 02:24, 20 April 2017 (UTC)
- Keep I'll concede that this split model doesn't work particularly well with the given tunnel example. However, it is the best solution for road items, for reasons spelled out in the property proposal linked above. -happy5214 18:34, 25 April 2017 (UTC)
- Keep, subtle differences, even though people do not use it properly. MechQuester (talk) 19:55, 16 June 2017 (UTC)
- Delete I think it would be helpful to have P276 qualifier in P559 - we have to use direction qualifier anyway. P609 is specific but adds no new information over P559 and P276. And we need to qualify P609 anyway using same qualifiers. d1g (talk) 05:47, 10 August 2017 (UTC)
- It seems apparent that the problem here is that the railways community and the highways community use terminus (P559) differently:
- Highways: terminus (P559) for connections to other highways at end of a highway; terminus location (P609) for the wider geographical area where the end of the highway is located
- Railways: terminus (P559) for the station / depot / feature which marks the end of the railway line.
- We're clearly using terminus (P559) for two different purposes. To deal with this situation I suggest split the "connection at terminus" use of terminus (P559) to a new property and Keep for the roads use; and keep the "feature at terminus" use of terminus (P559) for railways use. Deryck Chan (talk) 10:48, 22 September 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 21:49, 10 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 21:48, 10 October 2017 (UTC)
Fotografen.nl ID (P3269): (delete | history | links | entity usage | logs | discussion) was created as a spin-off of RKDartists ID (P650). The Fotografen.nl ID (P3269) and RKDartists ID (P650) id's are exactly the same. This turned out to be a temporary project. The website at http://www.fotografen.nl/ just contains a banner to go to RKDartists (where all data is available) and all links are broken. This property is completely redundant now. Multichill (talk) 10:40, 15 April 2017 (UTC)
- Keep with modified formatter URL for those photographers where the pages were archived at archive.org, at least until the same information from that archived page is actually also available elsewhere. The fotografen.nl had some quite valuable information that was (and still is) not available on the RKDartists website (sample photos by the photographer, a bibliography, sometimes a short written biography and information about memberships and management of copyrights). And it turns out that the Wayback Machine has partly archived fotografen.nl. I therefore suggest to keep the property and change the formatter URL to
https://web-beta.archive.org/web/*/http://fotografen.nl/nl/component/nfm_fotografen/fotograaf/id/$1
Examples for checking that fotografen.nl indeed had more information: - Comment The 'web-beta.archive.org' URL at Internet Archive gives better results than the 'web.archive.org' version.
- Comment A quick test seems to show that this only works for some photographers whose oeuvres are managed by the Nederlands Fotomuseum. I'm willing to inventorize their list and remove the values for those statements that don't link to working archive.org pages. Spinster 💬 17:17, 15 April 2017 (UTC)
- keep per Spinster (but do not delete values for pages not archived by archive.org; other arhcives may exist). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:48, 12 May 2017 (UTC)
- Comment We have archive URL (P1065) for linking to archived pages. If the outcome is to keep the property, I think adding qualifiers for known archived pages would be better than changing the formatter URL. - Nikki (talk) 17:37, 9 August 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 21:48, 10 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Unused property, deleted. Matěj Suchánek (talk) 15:36, 13 August 2017 (UTC)
P3688 (P3688): (delete | history | links | entity usage | logs)
As noted by Indeed, the identifiers used by the International Canoe Federation (Q684857) have changed. There is now a single formatter URL (P1630) for both canoe sprint (Q1141850) and canoe slalom (Q31874) athletes. I have merged everything in ICF canoer ID (P3689), making P3688 (P3688) obsolete, as it is not used anymore. There were only two items using it before. --Thierry Caro (talk) 14:20, 13 July 2017 (UTC)
Delete seems clear this isn't needed now. ArthurPSmith (talk) 16:58, 24 July 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 21:45, 10 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no consensus to delete --Pasleim (talk) 21:44, 10 October 2017 (UTC)
BVMC place ID (P4098): (delete | history | links | entity usage | logs | discussion)
All the values for this property are simply GeoNames ID (P1566).
- 10228306: BVMC / Geonames
- 1690570: BVMC / Geonames
- 1701668: BVMC / Geonames
- 2509538: BVMC / Geonames
- 2510112: BVMC / Geonames
- 3126031: BVMC / Geonames
- ... and the remaining ~655
The original proposer has already been contacted about this. Personally, I would like Wikidata to support auto-derivative properties at its technical level; however, as this feature is still not available, editors have been avoiding this kind of (duplicate) properties until now. --abián 21:17, 22 July 2017 (UTC)
- Delete duplication. - yona b (talk) 05:04, 23 July 2017 (UTC)
- Keep we need custom formatter URL.
- We don't have another property or alternative way to get custom URL for specific items from Geonames
- 1000 values are harmless, even if duplicates d1g (talk) 06:58, 23 July 2017 (UTC)
- Delete we have third-party formatter URL (P3303) for 3rd party formatters.--GZWDer (talk) 14:28, 24 July 2017 (UTC)
- Delete per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 25 July 2017 (UTC)
- Comment The problem with third-party formatter URL (P3303) is that most of the time the third party does not use all the identifiers available in the first database and we have no way to know this before we actually click on the link and discover this very one is not covered. With this in mind, I've come to believe that third-party formatter URL (P3303) in its current form is a bad thing, and that we should have a standalone property every time the formatter URL varies, even when most of the IDs it points to are shared. Thierry Caro (talk) 00:59, 7 August 2017 (UTC)
- Keep per this comment. - Nikki (talk) 17:30, 9 August 2017 (UTC)
- That's not a reason to keep this property; the use-case is what response headers are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:56, 29 September 2017 (UTC)
- Keep I'd say keep for now. I agree with Thierry Caro third-party formatter URL (P3303) is not a solution.
- This thing worries me, for example, with Directory of Open Access Journals (Q1227538), as the "identifier" there is the ISSN (P236): example. A way of storing this data (that journal being indexed there) is using catalog (P972)->Directory of Open Access Journals (Q1227538) (see Anuario de Estudios Medievales (Q15751449)).
- But "catalog (P972)->-BVMC PLACE "CATALOG" ITEM" would be kind of a reach, so P972's scope would need somehow to be expanded.. And after we wouldn't even have a "click-able link" here.
- Anyway, if we are gonna have these properties, a specific constraint like «if P4098 exists, then its value has to be equal to P1566's»... would be nice. Strakhov (talk) 17:56, 9 August 2017 (UTC)
- I don't think it can be done with normal constraints right now, but it would be easy to do with a complex constraint, using something like this query. - Nikki (talk) 10:21, 25 August 2017 (UTC)
- Keep per Thierry Caro too, @GZWDer: the property that you suggested, third-party formatter URL (P3303), should be the actual property for deletion as its value can be confusing. --Liuxinyu970226 (talk) 01:12, 28 August 2017 (UTC)
Note that, in this case, the issue exposed by Thierry Caro doesn't apply. The BVMC lets you use any identifier available in Geonames (example, example) and retrieves the information on the fly. However, all your comments are being very enriching, thank you! --abián 18:27, 2 September 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 21:44, 10 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Looks like a mistake, closing this one as invalid. Multichill (talk) 10:57, 1 October 2017 (UTC)
inception (P571): (delete | history | links | entity usage | logs | discussion)
Photo does not match property--MalBarrows (talk) 13:21, 29 September 2017 (UTC)
- @MalBarrows: Please clarify your problem more. I think this request is a mistake. Matěj Suchánek (talk) 14:04, 29 September 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 21:44, 10 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 21:46, 10 October 2017 (UTC)
P796 (P796): (delete | history | links | entity usage | logs)
Use relative to (P2210). GZWDer (talk) 16:21, 25 June 2017 (UTC)
- Delete A nonsense property. --Liuxinyu970226 (talk) 01:21, 30 June 2017 (UTC)
- Delete per nom (currently only has two uses),. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:18, 4 July 2017 (UTC)
- Comment currently has 388 uses. --Pasleim (talk) 09:57, 8 July 2017 (UTC)
- Delete two qualifiers for the same purpose, older one had more specific labels. d1g (talk) 04:17, 8 July 2017 (UTC)
- Keep These properties have not the same purpose. See écluse de Mayenne (Q29043286) for example, if you replace P796 (P796) by relative to (P2210), you lose the meaning of the statement. (@EdouardHue, Sfan00 IMG, Tobias1984, Paperoastro, Mushroom:) — Ayack (talk) 14:54, 24 July 2017 (UTC)
- @Ayack: By "the meaning of the statement" are you asking local field names? If yes, those can be locally modified, no needed to absolutely use Property names. --Liuxinyu970226 (talk) 15:25, 25 July 2017 (UTC)
- @Liuxinyu970226: Sorry but I don't understand your question: what do you mean by "local field names"? What I want to say is that when you look at the statement located on linear feature (P795):Mayenne (Q280650) in écluse de Mayenne (Q29043286), you understand the meaning of the qualifiers. If you replace (in French at least, but it seems the same in English) "point d'origine" by "relatif à", you cannot understand what it means. — Ayack (talk) 18:45, 25 July 2017 (UTC)
- @Ayack: By "the meaning of the statement" are you asking local field names? If yes, those can be locally modified, no needed to absolutely use Property names. --Liuxinyu970226 (talk) 15:25, 25 July 2017 (UTC)
- écluse de Mayenne (Q29043286) shouldn't use "geo datum", but P2210 "reference point".
- Most users don't know what Geo datum is.
- Most users only need one datum in their life World Geodetic System (Q215848). d1g (talk) 12:19, 30 July 2017 (UTC)
- Geodatums should be where they make sense the most (e.g. geopoint properties, geoshape properties). d1g (talk) 12:21, 30 July 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 18:25, 11 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 15:47, 20 October 2017 (UTC)
OpenStreetMap relation ID (P402): (delete | history | links | entity usage | logs | discussion)
Relation ids representing given OSM object frequently change. For practical matching wikidata tags on OSM objects are used ( http://wiki.openstreetmap.org/wiki/Key:wikidata ), due to lack of stability of OSM ids. For reference - I am active OSM contributor who recently focused on cleaning up wikidata/wikipedia links (see for example https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/42385 ). I considered also making Wikidata bot that would update/create Property:P402 claim but decided against it as this property would be highly unstable. Sorry if I did something wrong or missed some steps but I am new to nominating things for deletion on Wikidata. Mateusz Konieczny (talk) 09:27, 1 October 2017 (UTC)
- I notified author, editor who proposed it and editor who supported it during creation. Should I notify ones listed in "This property is being used by:" at https://www.wikidata.org/wiki/Property_talk:P402#Documentation ? Mateusz Konieczny (talk) 09:31, 1 October 2017 (UTC)
- It seems that https://www.wikidata.org/wiki/Wikidata:Property_proposal/Archive/5#P402 was at least partially based on misunderstanding - relation ids may not only be deleted, the may also change meaning (this type of OSM edit would not be considered ideal, but nobody would complain about changing meaning of relation id) Mateusz Konieczny (talk) 09:33, 1 October 2017 (UTC)
- See also https://phabricator.wikimedia.org/T145284 that ended as "Declined" Mateusz Konieczny (talk) 09:45, 1 October 2017 (UTC)
- Keep Wildely used property. The relation seem at enough stable for Wikidata. I don't think the relation of Quebec (Q176) or United States of America (Q30) will change in time. --Fralambert (talk) 14:09, 1 October 2017 (UTC)
- Keep Of course, the content of OSM relations can be changed, the content of Wikidata items too. Delete Wikidata! No, don't do that. Be aware things can bechanged and deal with it. Many important OSM objects are monitored and maintained. As an OSM contributor I have a look at many objects and find them in good condition, stable enough for Wikidata. --Quarz (talk) 16:15, 1 October 2017 (UTC)
- Keep Very useful. I don't have seen any changes in my workspace from OSM so where this "figures" comming from. About how many % we're talking from? --Derzno (talk) 17:11, 1 October 2017 (UTC)
- Keep Nothing fundamental has changed since Wikidata:Requests for deletions/Archive/2017/Properties/1#OpenStreetMap Relation identifier (P402). No need to discuss it again and again.--Jklamo (talk) 20:48, 1 October 2017 (UTC)
- Sorry, I expected older deletion discussion to be linked from the talk page of property (like it is done on Wikipedia) Mateusz Konieczny (talk) 21:32, 1 October 2017 (UTC)
- Comment The correct way to do OSM would be linking to the tags and not to the id and in this case it would be the Wikidata tag (OSM permanent id). However the problem that needs to be solved before P402 can be deprecated is how to check in template/Lua if the wikidata tag exists. Currently this is not possible and without any external information stored in WD it prevents autozooming to the area in mapframes and automatic linking to the correct OSM relation. Until this happens one solution is to sync OSM wikidata tag values and P402 values with a bot like Mateusz Konieczny considered and I wrote my take on this: Wikidata:Mapframe-autozoom Zache (talk) 05:39, 2 October 2017 (UTC)
- I made a template which links to OSM using wikidata-tags:
{{Overpasslink|Q539324}}
→ Ludwigskirche (Q539324) in OpenStreetMap --Zache (talk) 00:52, 3 October 2017 (UTC) - Keep --ChristianSW (talk) 14:17, 11 October 2017 (UTC)
- Keep. Thierry Caro (talk) 15:35, 16 October 2017 (UTC)
- Keep. Already used for Kartographer maps in different projects. --RolandUnger (talk) 15:32, 20 October 2017 (UTC)
I think that this discussion is resolved and can be archived. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 20 October 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 15:47, 20 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep --Pasleim (talk) 15:49, 20 October 2017 (UTC)
LinkedIn company or organization ID (P4264): (delete | history | links | entity usage | logs | discussion)
Premature closure
--- Jura 15:52, 12 October 2017 (UTC)
- Keep Jura's unanswered question was whether the ID's were stable; it certainly would have been nice to have an answer. Perhaps @ChristianKl: would like to comment on why he ignored the question in closing this? Nevertheless I think this is a useful property (and as far as I can tell the ID"s are stable). ArthurPSmith (talk) 16:07, 12 October 2017 (UTC)
- Keep Useful property for company disambiguation, and as a source for insights upon it. The process to change an ID is complicated (you have to manually file a request to LinkedIn), making the property rather stable. Teolemon (talk) 14:35, 14 October 2017 (UTC)
- At this stage, I think we only need to discuss if the closure was premature or not. If yes, the property can be deleted.
--- Jura 06:10, 16 October 2017 (UTC)- ?huh? I don't think that's wikidata policy at all. ArthurPSmith (talk) 15:10, 16 October 2017 (UTC)
- Most administrators and property creators try to follow the applicable process. I noticed that ChristianKl mostly ignores it, but this isn't a reason to let these slip through. It can be created later, once everything is sorted out. --
--- Jura 20:26, 18 October 2017 (UTC)- @Jura1:: If you think ChristianKl ignore the simple rule for the property creator, it would be more productive to go directly to the Wikidata:Administrators' noticeboard and ask to revoke his right. --Fralambert (talk) 22:00, 18 October 2017 (UTC)
- Most administrators and property creators try to follow the applicable process. I noticed that ChristianKl mostly ignores it, but this isn't a reason to let these slip through. It can be created later, once everything is sorted out. --
- ?huh? I don't think that's wikidata policy at all. ArthurPSmith (talk) 15:10, 16 October 2017 (UTC)
- Keep. A disruptive deletion nomination, with no valid rationale. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 18 October 2017 (UTC)
- Keep - LinkedIn is a prominent service and a property for this is justified. -- Fuzheado (talk) 22:48, 19 October 2017 (UTC)
I think that this discussion is resolved and can be archived. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 20 October 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 15:49, 20 October 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep, given that it's not in quality different than storing Facebook username (P2013) and similar identifiers. The property is not to be used to reveal the identity of users who didn't disclose their identity publically and doing so would be subject to sanctions as explained in the usage instructions of the property. ChristianKl (talk) 17:28, 4 November 2017 (UTC))
Wikimedia username (P4174): (delete | history | links | entity usage | logs | discussion)
Lack of consensus for creation at Wikidata:Property proposal/Wikimedia user name. --- Jura 03:18, 25 August 2017 (UTC)
- Delete "note that you may be blocked from editing WMF sites, if you add this property to an item about somebody else than yourself". -- Innocent bystander (talk) 06:58, 25 August 2017 (UTC)
- Delete - created while several unresolved Strong oppose - real problem with https://wikimediafoundation.org/wiki/Privacy_policy --Hsarrazin (talk) 08:07, 25 August 2017 (UTC)
- There were no "unresolved" opposes; the opposition based on WMF privacy policy was addressed and refuted: the data was already held using website account on (P553); the new property makes it easier to monitor such use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 26 August 2017 (UTC)
- Keep Otherwise items like Shi Zhao (Q9147313) will be nonsense. --Liuxinyu970226 (talk) 13:33, 25 August 2017 (UTC)
- Also ping supporters @Thierry Caro, NMaia, Tubezlob, Mahir256, VIGNERON:@Mr. Ibrahem, Sadads, OwenBlacker: --Liuxinyu970226 (talk) 13:39, 25 August 2017 (UTC)
- Keep. But delete the warning message. There is no reason to have for Wikimedia a special policy that we don't have for Facebook or Instagram. Thierry Caro (talk) 13:41, 25 August 2017 (UTC)
- Neutral this property shouldn't have been created until a consensus had been reached on how to use it but now that is has been created, I see no real reason to delete it. PS: I have no illusion, the property is not really the issue here, with or without this property, the exact same data can, were and will be stored (prior to this property creation there was already a hundred of wikimedia user name store in various ways). Cdlt, VIGNERON (talk) 13:44, 25 August 2017 (UTC)
- Keep per my arguments made in the creation conversation — not least that the information is already held; at least this way it can be monitored more sensibly. — OwenBlacker (talk) 13:56, 25 August 2017 (UTC)
- Keep. Arguments of Thierry Caro are right: there is no difference between a Wikimedia username and an other username in an other website (for example Twitter, where a lot of people also use a pseudonym). Tubezlob (🙋) 15:18, 25 August 2017 (UTC)
- Are you saying that you wont be respecting WMF policies even in fields where it's applicable?
--- Jura 15:34, 25 August 2017 (UTC) - oh yes, there is an enormous difference - on Facebook, you have to use your real name (per FB rules) ; there is NO privacy of FB, per FB rules - on wikimedia, there is an official Privacy policy !! - it is totally different --Hsarrazin (talk) 22:50, 25 August 2017 (UTC)
- I challenged you in the property proposal to cite any part of WMF policy which means we can't have this property. You failed to do so. You cannot do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 26 August 2017 (UTC)
- Are you saying that you wont be respecting WMF policies even in fields where it's applicable?
- Delete: I'm really worried about the privacy part. If people keep adding sexual orientation (P91) and ethnic group (P172) without source, who says they will do it for this one? Our policies and tools are not good enough for something like this. Attempts to get better policies were useless so far. Sjoerd de Bruin (talk) 17:12, 25 August 2017 (UTC)
- Delete useless with current "usage instructions". Encouraging users to create items about themselves is not a good idea.--Jklamo (talk) 21:05, 25 August 2017 (UTC)
- Keep without this property, the data just gets stored in website account on (P553)/website username or ID (P554). For privacy concerns, this doesn't make any difference. --Pasleim (talk) 21:15, 25 August 2017 (UTC)
- After this is deleted, I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before.
--- Jura 10:52, 26 August 2017 (UTC)- @Jura1: I guess the Template:Connected contributor (Q7646869) template should use this property? So let's withdraw so-called "privacy" problems. --Liuxinyu970226 (talk) 02:52, 28 August 2017 (UTC)
- After this is deleted, I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before.
- Keep As every properties, this one is intended for public and referenced information. If it used differently, we have a policy for the disclosure of non-public personal information (with oversighters to remove such data and administrators to ban transgressors). As noticed by VIGNERON, this property allows to store Wikimedia usernames in a single place, making possible to monitor and detect bad usage much more easily than the actual situation. I also agree with Tubezlob: Wikimedia usernames don't differ from X username (P2002) or Instagram username (P2003), and I see no one stating that they were created to doxx Twitter and Instagram users... -- Envlh (talk) 21:33, 25 August 2017 (UTC)
- Keep per many of the above. Furthermore, this property passed a property proposal in the last few days. PfD should not be used to circumvent that process; the claim of "lack of consensus " is false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:43, 26 August 2017 (UTC)
- Well, that "it passed a property proposal" is a strongly disputed claim here. -- Innocent bystander (talk) 10:42, 26 August 2017 (UTC)
- That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:36, 26 August 2017 (UTC)
- Well, that "it passed a property proposal" is a strongly disputed claim here. -- Innocent bystander (talk) 10:42, 26 August 2017 (UTC)
- Keep - the arguments on the property proposal page against this were unconvincing, as the concerns could be solved with policy and simple queries to keep things in check. We should not be outright deleting a property because it might be a problem, when the utility is clearly demonstrated. -- Fuzheado (talk) 13:48, 26 August 2017 (UTC)
- @Fuzheado: could you demonstrate such a simple query that would "keep things in check"?
--- Jura 14:12, 26 August 2017 (UTC)
- @Fuzheado: could you demonstrate such a simple query that would "keep things in check"?
- wrt to this thing being the same as twitter or facebook or instagram, it is an undisputable truth in those social networks users can protect their accounts with a lock, not allowing common people to scrutinize their actions, pictures or vapid fantasies. In Wikimedia projects all your contributions are open, with the exact time you saved them, every topic, every comment in every discussion. We even offer tools to stalk user's edits. And it's not possible to hide any of that under a little tiny lock. It's not even possible to delete your account here. It's not exactly the same. Strakhov (talk) 23:38, 26 August 2017 (UTC)
- thanks Strakhov, this is exactly the problem : this makes too easy scrutinizing edits of a user, by persons who, without this property, would not be able to link the username to the real-life identity… only voluntary disclosure by concerned users should be allowed to avoid risks for contributors in their private and/or professional life --Hsarrazin (talk) 17:14, 28 August 2017 (UTC)
- keep as any personal identifier it makes no sense to allow home page, but prohibit social media accounts (incl this). Personal web pages are not replacement to other accounts (e.g. youtube cannot replace homepage and vice versa).
- We could improve any description in order to follow any policy - it is strange to remove property. d1g (talk) 04:20, 27 August 2017 (UTC)
- Comment many lawbreaking things could be entered in Help:Description - should we remove them?.. Please don't make this slippery slope argument every time. This is not specific to properties or even specific property. d1g (talk) 04:37, 27 August 2017 (UTC)
- Delete until issues on "only the account owner is able to..." are resolved. We are not in a hurry, since people willing to disclose their Wikimedia alias already discovered how to store this data circumventing previous refusal and, after all, there are not so many legitimate uses. Strakhov (talk) 11:12, 27 August 2017 (UTC)
- By the way, our labour here is about constructing a collaborative database, not losing or winning proposals. Strakhov (talk) 11:19, 27 August 2017 (UTC)
- Comment First, I'd like to see a comment from WMF's legal staff or quotation of privacy policy that states that this property should not exist. Second, this property had actually existed as website account on (P553)/website username or ID (P554) before this one was created, so in my opinion there didn't have to be any discussion about its existence. Matěj Suchánek (talk) 16:47, 27 August 2017 (UTC)
- @Jalexander-WMF: Would you be able to have an official viewpoint from WMF from the appropriate staff member? Thanks. — billinghurst sDrewth 03:59, 28 August 2017 (UTC)
- Also @Mdennis (WMF): the leader of m:Support and Safety. --Liuxinyu970226 (talk) 09:59, 28 August 2017 (UTC)
- Maggie and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. Jalexander-WMF (talk) 22:47, 29 August 2017 (UTC)
- Keep: I'm for keeping it, but to use it only when a profile page on any Wikimedia project already discloses this information. This profile page should then be added as reference URL. -- Maxlath (talk) 15:06, 28 August 2017 (UTC)
- Keep if a bot can actively revert all changes involving this property by non-autoconfirmed users (on the assumption that all autoconfirmed users are aware of and adhere to the WMF's privacy policy). Mahir256 (talk) 16:15, 28 August 2017 (UTC)
- Keep property similar to properties for other social network. Same policy should be applied. Pamputt (talk) 16:30, 28 August 2017 (UTC)
- Keep We have properties for user accounts on other sites that are less relevant than Wikimedia.--Micru (talk) 17:47, 28 August 2017 (UTC)
- Keep per @Thierry Caro, @Pasleim and @Envlh. --Waldir (talk) 08:19, 29 August 2017 (UTC)
- Keep Wikidata has many properties for things that count as sensitive personal data: birth date, gender, sexual orientation, union membership and online account are examples. A breach of privacy comes when people use these inappropriately, adding speculative or inappropriately obtained data. The fact that Wikidata can represent such data is not the fault. Hence it is a fallacy to argue against the existence of the property on grounds of possible misuse. None of the arguments for removal seem solid. MartinPoulter (talk) 14:07, 29 August 2017 (UTC)
- Keep. Valid identifier with unique values. Deryck Chan (talk) 21:11, 18 September 2017 (UTC)
- Keep --Ogoorcs (talk) 20:13, 19 October 2017 (UTC)
- Keep under @Thierry Caro's terms. ~★ nmaia d 00:50, 2 November 2017 (UTC)
I think that this discussion is resolved and can be archived. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 20 October 2017 (UTC)
- @Pigsonthewing: Just close it by you, the petition above is successed. --Liuxinyu970226 (talk) 12:31, 27 October 2017 (UTC)
- @Liuxinyu970226: I can't determine what you mean. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:53, 28 October 2017 (UTC)
- @Pigsonthewing: 5*vote delete - 17*vote keep - 2*neutral, isn't enough to close as clearly no consensus (maybe this must be closed by an uninvolved sysop, but who)? --Liuxinyu970226 (talk) 09:07, 31 October 2017 (UTC)
- @Liuxinyu970226: I can't determine what you mean. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:53, 28 October 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:31, 10 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to keep. ChristianKl (talk) 17:29, 4 November 2017 (UTC))
category contains (P4224): (delete | history | links | entity usage | logs | discussion)
This new property replaces content that is actively used in Reasonator. There is no real benefit compared with the use of "is a list of"--GerardM (talk) 21:22, 30 September 2017 (UTC)
- Then Reasonator should be adjusted. Sjoerd de Bruin (talk) 21:31, 30 September 2017 (UTC)
- There is no benefit in this property anyway. Thanks, GerardM (talk) 21:46, 30 September 2017 (UTC)
- Keep This property passed recently a property proposal. PfD should not be used to circumvent that process. --Pasleim (talk) 02:48, 1 October 2017 (UTC)
- Comment It is an in-crowd that is involves in property proposals. When their work cannot be objected to it means that their work is to be considered infallible. This argument expresses a superiority that is not warranted. There is damage so I ask for a speedy deletion. Thanks, GerardM (talk) 06:04, 1 October 2017 (UTC)
@Jheald, ArthurPSmith, Swpb, YULdigitalpreservation: @ChristianKl, Joshbaumgartner, Jura1, TomT0m, Micru: who participated in the property proposal discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:45, 1 October 2017 (UTC)
- Keep but I don't understand GerardM's point with regard to Reasonator, can you provide a link to a case where the new property causes a problem? ArthurPSmith (talk) 14:48, 1 October 2017 (UTC)
- Look at what "list of" does .. Thanks, GerardM (talk) 15:17, 1 October 2017 (UTC)
- as opposed to this case with the new property? I agree with folks above, we should urge Magnus to support this in Reasonator. Maybe the migration to the new property should wait until that's done. I don't see this as a reason to delete the property though - it's simply wrong to say that a category "is a list" of something, categories are not organized that way. ArthurPSmith (talk) 15:13, 1 October 2017 (UTC)
- Keep per ArthurPSmith and Sjoerddebruin. "is a list of" is absolutely not the same thing. It's Reasonator that needs to adjust. Swpb (talk) 12:23, 2 October 2017 (UTC)
- Humour me and explain why it is not a list. The fact that this list is part of a category is already in the type of the P31. It does not need further refinement imho. Thanks, GerardM (talk) 06:00, 4 October 2017 (UTC)
- That was more abuse of the system to enforce something you like. It was messy and I'm glad we're fixing it. Sjoerd de Bruin (talk) 12:42, 4 October 2017 (UTC)
- I do not understand your answer. Thanks, GerardM (talk) 13:39, 4 October 2017 (UTC)
- @GerardM: I would say en:List of Cornell University alumni and en:Category:Cornell University alumni are quite different things. For one thing, the former is in the latter category. For another, the category has a lot of sub-categories. ArthurPSmith (talk) 14:17, 4 October 2017 (UTC)
- In both instances the content of the list at Wikidata is the same. It has little to do with what is actually in an English list or category as it is a combination of what is in German, Russian, Dutch etc categories and lists as well. Thanks, GerardM (talk) 14:45, 4 October 2017 (UTC)
- That was more abuse of the system to enforce something you like. It was messy and I'm glad we're fixing it. Sjoerd de Bruin (talk) 12:42, 4 October 2017 (UTC)
- Humour me and explain why it is not a list. The fact that this list is part of a category is already in the type of the P31. It does not need further refinement imho. Thanks, GerardM (talk) 06:00, 4 October 2017 (UTC)
I think that this discussion is resolved and can be archived. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 20 October 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:31, 10 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Deleted Matěj Suchánek (talk) 19:40, 4 November 2017 (UTC)
P4420 (P4420): (delete | history | links | entity usage | logs)
Duplicated at Property:P3180 ~★ nmaia d 22:59, 29 October 2017 (UTC)
- @ديفيد عادل وهبة خليل 2, Pigsonthewing, ChristianKl, Pamputt: ping user involved in the proposal discussion and creation. --Pasleim (talk) 23:10, 29 October 2017 (UTC)
- My apologies. I proposed the duplicated property unaware of the old one. They should be merged as much as that is feasible. ~★ nmaia d 01:06, 30 October 2017 (UTC)
- Delete. I did not check whether a similar property already existed when I created this one. Pamputt (talk) 06:26, 30 October 2017 (UTC)
- Delete - only 3 uses, they should be moved over to P3180. Good catch NMaia! ArthurPSmith (talk) 07:13, 30 October 2017 (UTC)
- Delete ChristianKl (talk) 08:18, 30 October 2017 (UTC)
- Delete per above, duplication is just duplication. --Liuxinyu970226 (talk) 09:12, 31 October 2017 (UTC)
- Delete. - yona b (talk) 10:18, 31 October 2017 (UTC)
- Speeedy delete (and redirect if possible). No need for disussion of routine housekeeping of this kind. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 4 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:31, 10 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Deleted Matěj Suchánek (talk) 07:58, 6 November 2017 (UTC)
P4492 (P4492): (delete | history | links | entity usage | logs)
Wong datatype, it sould be external-id, not quantity.--Fralambert (talk) 23:40, 5 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:31, 10 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Consensus to delete --Pasleim (talk) 08:01, 26 November 2017 (UTC)
P4205 (P4205): (delete | history | links | entity usage | logs)
Hi. I did not pay attention when I proposed this property but it seems it is a duplicated property of Foursquare City Guide venue ID (P1968).--Pamputt (talk) 05:16, 8 September 2017 (UTC)
- Delete sorry from me too, I'm a bit new to property creation and didn't check this one well enough. --99of9 (talk) 09:12, 8 September 2017 (UTC)
A little Keep, shouldn't this for personal detail like https://foursquare.com/user/123456 ? --Liuxinyu970226 (talk) 23:34, 8 September 2017 (UTC)- Ah! Indeed, it could be used from user. Pamputt (talk) 11:50, 10 September 2017 (UTC)
- @Pamputt: Well, my comment above in theory shouldn't be a reason to withdraw this pfd, since I still don't see how an example could be happened, really the 4sq staffs should consider a better way to search *public* user details. --Liuxinyu970226 (talk) 05:50, 18 September 2017 (UTC)
- UPDATE 2017-10-27 I now changed my vote to Delete, as no body is interesting in that url schema. --Liuxinyu970226 (talk) 12:33, 27 October 2017 (UTC)
- Delete -- JakobVoss (talk) 09:11, 10 November 2017 (UTC)
- Comment I don't doubt the validity of this property, but I doubt its usefulness. In what situation will this be useful for curating public knowledge? Deryck Chan (talk) 09:24, 22 September 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:01, 26 November 2017 (UTC)
P2656 (P2656): (delete | history | links | entity usage | logs)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 08:02, 26 November 2017 (UTC)
According to Wikidata:Property proposal/UEFA ranking and Wikidata:Project chat/Archive/2017/10#UEFA ranking--Xaris333 (talk) 18:40, 18 October 2017 (UTC)
- Delete as I believe this should simplify things a little. However, there are hundreds of P2656 entries now, so first they should be migrated to the alternate format? ArthurPSmith (talk) 13:16, 19 October 2017 (UTC)
- I have added the latest ranking without the property to all national men teams. For example, see Czechia national football team (Q483868) --> ranking (P1352). Xaris333 (talk) 15:08, 17 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:02, 26 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 08:04, 26 November 2017 (UTC)
P1905 (P1905): (delete | history | links | entity usage | logs)
Following this discussion, I propose to delete P1905 (P1905). Here is a summary of the reasons:
- It is only used 6 times despite being more than 2 years old
- It is marked as Wikidata property to identify organizations (Q21745557) and is therefore indirectly an identifier despite having monolingual texts as values
- Two other properties can be used to link to the same dataset: Open Funder Registry funder ID (P3153) and DOI (P356)
- It was proposed to use it as a qualifier on DOI (P356) to indicate the name, but if we actually want to store these names there I think we should rather use a generic property for that ("name in registry" or something like that), so that it could be used on other identifiers in the same way.
− Pintoch (talk) 11:05, 28 October 2017 (UTC)
- Delete I think object named as (P1932) would be suitable for showing the name in the Crossref Funder DB. ArthurPSmith (talk) 11:41, 28 October 2017 (UTC)
- Delete -- JakobVoss (talk) 11:35, 2 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 08:04, 26 November 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 00:16, 5 December 2017 (UTC)
P2422 (P2422): (delete | history | links | entity usage | logs)
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)
- Keep 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 P2422 (P2422). Also, P2422 (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, but the inductees numbers would need to be merged to "membership" property, although it's not as a good as keeping P2422 (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)
- 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)
- Delete per Andy − Pintoch (talk) 15:22, 15 September 2017 (UTC)
- Delete per Andy Mateusz Konieczny (talk) 11:51, 27 September 2017 (UTC)
- @Pintoch, Mateusz Konieczny, Amqui: Please use {{Keep}}, {{Vote_delete}} to make it more clear whether you support or oppose this property existing or support or oppose it's deletion. ChristianKl (talk) 14:47, 6 November 2017 (UTC)
- So it means I would put "Quantity: 0" to the Canadian Victoria Cross because it has never been awarded since its inception, but that would mean it doesn't exist with a quantity of 0, but at the same time I can take a picture of it since it does physically exist... How does it make sense? I support renaming it to "quantity awarded" to make it more clear though. Amqui (talk) 15:53, 6 November 2017 (UTC)
- Keep. It seems to be used in the meantime.
--- Jura 08:41, 11 November 2017 (UTC)- It is indeed currently used. But since the nomination explains how such use is redundant, and can thus be replaced, an objection on that basis is irrelevant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 18 November 2017 (UTC)
- Delete In use ≠ cannot be deleted, we can just mark it as DEPRECATED, find a migration way and finally (i.e. migration is done) delete it. --Liuxinyu970226 (talk) 03:38, 19 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 00:16, 5 December 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to keep --Pasleim (talk) 15:46, 5 December 2017 (UTC)
Open Funder Registry funder ID (P3153): (delete | history | links | entity usage | logs | discussion)
Following this discussion, I propose to delete Open Funder Registry funder ID (P3153). Here are the three reasons:
- it is virtually unused
- it is redundant with DOI (P356)
- its formatter URL is confusing (it goes to the list of publications associated with this funder id)
− Pintoch (talk) 11:16, 28 October 2017 (UTC)
Notifications for this nomination and its twin:
ArthurPSmith
Vladimir Alexiev (talk)
Toniher
Runner1928
Daniel Mietchen (talk)
Satpal Dandiwal (talk)
Asdfghjohnkl
Sushma Sharma (talk)
John Samuel OdileB(talk)
Ivanhercaz
Mlemusrojas
Jjfloyd
Kippelboy
Germartin1
Benjamenta
Simon Cobb
Mathieu Saby
Kiwi2020
Saethydd
Epìdosis
Gengrubber (talk) 04:40, 10 December 2019 (UTC)
Blue Rasberry (talk)
Walkuraxx
Sdkb (talk)
IbiloyeAC2 talk
Paul Jason Perez (talk)
Waydze (talk)
Pru.mitchell (talk) 21:32, 24 May 2021 (UTC)
Keystone18
María Sacristán
Il Lupa (talk)
Athayahisyam
Kippelboy
Soufiyouns
- @Pigsonthewing, DarTar, Daniel Mietchen, Afandian, ArthurPSmith, YULdigitalpreservation: participants in the original creation of Open Funder Registry funder ID (P3153) or P1905 (P1905)
- @Vladimir Alexiev: participant in the discussion linked above
− Pintoch (talk) 11:30, 28 October 2017 (UTC)
- Delete given that this has hardly been used, and DOI works for the same function, I don't think we need this property now. ArthurPSmith (talk) 11:43, 28 October 2017 (UTC)
- Keep I agree the property has not been used as much as it could, however I don't think this should be a reason to delete it. I'd suggest we focus on a pilot to meaningfully populate it and showcase its use. I also don't fully understand the second reason: a funder ID is not the same as a DOI, even though a funder can be uniquely referenced via a combination of its ID and a dedicated DOI prefix. Finally, the formatter URL is the one provided by Crossref as part of the funder ID specs, but we could change it to take the same value as the RDF URI scheme (http://data.crossref.org/fundingdata/funder/10.13039/$1).--DarTar (talk) 02:35, 4 November 2017 (UTC)
- Keep per DarTar. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 4 November 2017 (UTC)
- Keep The values of the property Open Funder Registry funder ID (P3153) can be written as one simple number, e.g. 501100000831, or as a DOI with fixed prefix, e.g. 10.13039/501100000831. This was already discussed in the property creation, but voted aggainst using simply DOI. The Mix'n'Match catalogue #338 does not respect that. I also think that it is better to have different properties for DOI, which are mostly used for publications, and this funder's ID. Thus we should change the Mix'n'Match catalogue and additionally replace all DOIs starting with 10.13039 by the corresponding funder's ID. This will then immediately increase the number of times this properties is used to several thousands. Moreover, change the resolving url as suggested above, or simply the DOI resolver. --Zuphilip (talk) 09:04, 5 November 2017 (UTC)
- @DarTar, Pigsonthewing, Zuphilip: Again I am responsible for a good chunk of these DOI uses - simply because I knew that Fundref IDs were part of the DOI system, and I was not aware of this property (as it was unused)… that really stresses the importance of actually using the properties you create within a reasonable amount of time. Once the excitement of the proposal is gone, please do not abandon your brainchildren like this, as they want to rise and shine! Feel free to carry out the replacement that you propose. − Pintoch (talk) 15:42, 6 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 15:46, 5 December 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 14:20, 19 December 2017 (UTC)
P4039 (P4039): (delete | history | links | entity usage | logs)
It's fully replaced by Rock.com.ar artist ID (P4040). We don't have any reason to keep it.--Mr. Moonlight (talk) 18:07, 10 November 2017 (UTC)
- Delete as you proposed it and it's practically unused.
--- Jura 08:51, 11 November 2017 (UTC)
- This section was archived on a request by: --Pasleim (talk) 14:20, 19 December 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --ValterVB (talk) 13:01, 28 December 2017 (UTC)
P3084 (P3084): (delete | history | links | entity usage | logs)
Unused. Seems impractical. No objections to suggested deletion, when raised on project chat. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 4 December 2017 (UTC)
Delete It seems oddly named and defined in any case. If something cannot legally be photographed I would think a more direct "photography disallowed" property would be better. ArthurPSmith (talk) 19:29, 4 December 2017 (UTC)
Delete Unused. Freedom of panorama is complicated issue with many minor differences in different countries, so it is simply impossible to record it this way.--Jklamo (talk) 20:59, 4 December 2017 (UTC)
Delete: overly specific and unused. − Pintoch (talk) 10:10, 5 December 2017 (UTC)
Delete. This got disused by most of the items (countries / jurisdictions) that are supposed to use them. Deryck Chan (talk) 16:07, 6 December 2017 (UTC)
Delete bogus property. --Liuxinyu970226 (talk) 10:12, 10 December 2017 (UTC)
Delete not used, bogus, different of all properties. Manu1400 (talk) 03:28, 22 December 2017 (UTC)
- This section was archived on a request by: --ValterVB (talk) 13:01, 28 December 2017 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to delete --Pasleim (talk) 14:11, 19 December 2017 (UTC)
P794 (P794): (delete | history | links | entity usage | logs | discussion)
Incredibly vague property described only as a "generic qualifier". Most instances should be replaced with the better-defined subject has role (P2868).--Swpb (talk) 18:23, 10 February 2017 (UTC)
- Delete and split to different properties.--GZWDer (talk) 07:06, 13 February 2017 (UTC)
For{{Statement|QXXX|PYYY|QZZZ}}
:
- If we want to specify X, use subject has role (P2868).
- If we want to specify Y, use <new property "specifically">. (previously we use P31 but I think P31 is still vague)
- If we want to specify Z, use <new property>. (position held (P39) Governor of X P794 (P794) acting governor (Q4676866))
- If we want to qualify the whole statement (de facto (Q712144)), use <new property>.
- If we want to indicate that X, Y or Z is "being" W for some kind of purpose (P794 (P794) Chinese Taipei (Q216923), author pseudonyms), use <new property, item version of object named as (P1932)>. (Is one property enough? Or is it still vague so that we need three properties?)
Totally we need four (or six) new property to indicate this. --GZWDer (talk) 07:30, 13 February 2017 (UTC)
- @GZWDer: Your new properties are very unclear to me. Please provide example statements using these new properties. I see the vast majority of instances of P794 (P794) being replaced with subject has role (P2868), a very small number being replaced with object named as (P1932) or similar, and I don't see a need for any other new properties. If you can identify statements currently using P794 (P794) that cannot be replaced with subject has role (P2868) or object named as (P1932), I'd like to see them. --Swpb (talk) 17:37, 13 February 2017 (UTC)
- @Swpb: I'm collecting the current usage of the property. It is much more complex than I have thought. I will post it here once I have done the work.--GZWDer (talk) 18:27, 13 February 2017 (UTC)
- For author pseudonyms, WikiProject Books is recommending using subject named as (P1810), which might work for other cases where the value in question is actually a name. On the P1810 talk page I have suggested using P1810 as a qualifier to show the preferred name for something in an external database that we have an ID for -- see for example Jan Vermeer van Haarlem the Elder (Q3159680) for how different databases prefer to name the same artist. Jheald (talk) 17:53, 13 February 2017 (UTC)
- How is P794 (P794) used externally? Deryck Chan (talk) 12:49, 13 February 2017 (UTC)
- I am not sure how the following couple of current uses would fit the cases above
- Glasgow (Q4093)located in the administrative territorial entity (P131)Strathclyde (Q124661) P794 (P794) local government area of Scotland 1975 to 1996 (Q383493), where the qualifier clause indicates the whole structure of local government that both X and Z were elements of, under which relation P131 held.
- Bedfordshire (Q23143) Vision of Britain unit ID (P3615) 10166561 P794 (P794) registration county (Q7309443)
- Does subject has role (P2868) work for this case? Or do we risk simply transferring all the ambiguity of P794 (P794) and dumping it on subject has role (P2868), if we stretch and stretch the uses of that property ? Jheald (talk) 16:02, 13 February 2017 (UTC)
- For your Glasgow example, I'd use of (P642) and maybe add a valid in period (P1264). For your Bedfordshire examples, I'd use criterion used (P1013) or applies to part (P518), or even turn it around and use Vision of Britain unit ID (P3615) as the qualifier:
- --Swpb (talk) 17:46, 13 February 2017 (UTC)
- @Swpb: I think the latter would be very counter-intuitive for anyone trying to write searches. For a property that's almost always used as an external ID to not be present as an ID, but as a qualifier on something else, would (I suspect) almost always be missed. criterion used (P1013) is an interesting idea, but I think it's value should usually be a question not an answer. As for applies to part (P518) I get a bad feeling every time I see it used for something which is not a physical part, or at least a subdivision (of events in time). Applied to a county I would expect P518 to have the value of a geographical area. Perhaps we need a property "applies to facet", or "applies to aspect". Jheald (talk) 17:56, 13 February 2017 (UTC)
- @Jheald: Valid point about the latter. As for criterion used (P1013), I've never seen it as limited to geographic or temporal use, and I don't think it would need to be altered to serve this purpose, but I wouldn't oppose a property like you suggest. --Swpb (talk) 18:08, 13 February 2017 (UTC)
- Sorry, I meant to write 518 instead of 1013. (I think you did too). Hope I wasn't too confusing! I've gone back and changed it. Jheald (talk) 18:14, 13 February 2017 (UTC)
- That makes more sense. I can see that case for 518; I still think 1013 would be a valid alternative. --Swpb (talk) 18:31, 13 February 2017 (UTC)
- Sorry, I meant to write 518 instead of 1013. (I think you did too). Hope I wasn't too confusing! I've gone back and changed it. Jheald (talk) 18:14, 13 February 2017 (UTC)
- @Jheald: Valid point about the latter. As for criterion used (P1013), I've never seen it as limited to geographic or temporal use, and I don't think it would need to be altered to serve this purpose, but I wouldn't oppose a property like you suggest. --Swpb (talk) 18:08, 13 February 2017 (UTC)
- @Swpb: I think the latter would be very counter-intuitive for anyone trying to write searches. For a property that's almost always used as an external ID to not be present as an ID, but as a qualifier on something else, would (I suspect) almost always be missed. criterion used (P1013) is an interesting idea, but I think it's value should usually be a question not an answer. As for applies to part (P518) I get a bad feeling every time I see it used for something which is not a physical part, or at least a subdivision (of events in time). Applied to a county I would expect P518 to have the value of a geographical area. Perhaps we need a property "applies to facet", or "applies to aspect". Jheald (talk) 17:56, 13 February 2017 (UTC)
Table of use cases
This is the list of some of current uses of the property:
Added Hans Franken (Q13653571) to discuss seperated, as @Multichill: doesn't agree sourcing circumstances (P1480) as replacement. --Liuxinyu970226 (talk) 04:02, 17 November 2017 (UTC)
- @Liuxinyu970226: Actually this one is a classic position held (P39) or object of statement has role (P3831) use case. Q21006159 is an item for "interim court clerk", not "interim status". But I've also seen other use cases of employer (P108)
P794 so it's a good idea to add it to the table. Deryck Chan (talk) 15:19, 24 November 2017 (UTC) - This query shows 159 professions ("W") on 822 items ("X") that can be migrated. There are another ~300 other statements of a similar structure which we can deal with after I migrate all of those 159 professions from P794 (P794) to position held (P39). Deryck Chan (talk) 15:43, 24 November 2017 (UTC)
- @swpb: Good luck with trying to port anything to sourcing circumstances (P1480). The folks that maintain sourcing circumstances (P1480) got very angry when I tried to port "de facto" and "interim" to it. I think applies to part (P518) is being used for "maximum", "minimum", "upper bound", "lower bound". Deryck Chan (talk) 00:20, 30 November 2017 (UTC)
- @Deryck Chan: I though that might happen, so I've switched to using determination method (P459) for those. I don't think applies to part (P518) generally works for the job – take Grenfell Tower fire (Q30274958): minimum (Q21067468) is not a part or aspect of "80", nor a part or aspect of Grenfell Tower fire (Q30274958) ("the lower bound of Grenfell Tower fire" is ambiguous, since it's used for both dead and injured). For "de facto" and "interim", I think
subject has role (P2868)object of statement has role (P3831) works well. Swpb (talk) 20:20, 30 November 2017 (UTC)- @swpb: I think you're right that applies to part (P518) isn't correct in this case. I've been wondering what "applies to part" means - is it part of the subject, part of the object, or part of the relationship? The description says it's part of the subject. In fact when I started going through the use cases of P794, I realised we needed three new properties. Two of them we have already proposed: identity of object and identity of subject. We really need a third one for "applies to aspect", alias "status of statement" - "maximum", "minimum", "interim" etc. It's like applies to part (P518) but it's part of the relationship not part of the item, and like sourcing circumstances (P1480) but qualifies the accuracy of the statement, not the accuracy of the sourcing. I'm quite busy today so won't be writing the proposal yet, but will try to do over this weekend. Deryck Chan (talk) 12:10, 1 December 2017 (UTC)
- I don't know, I think that may be slicing use cases too thinly. I've already expanded the description of applies to part (P518) to cover "aspects" and the description of determination method (P459) to cover things like minima and maxima, I think object of statement has role (P3831) works well for statuses like "interim" and "acting", and I think sourcing circumstances (P1480) currently covers the accuracy of the statement as well as the accuracy of the sourcing. Can you give an example of a case where none of those existing properties works? Swpb (talk) 13:51, 1 December 2017 (UTC)
- @swpb: I think you're right that applies to part (P518) isn't correct in this case. I've been wondering what "applies to part" means - is it part of the subject, part of the object, or part of the relationship? The description says it's part of the subject. In fact when I started going through the use cases of P794, I realised we needed three new properties. Two of them we have already proposed: identity of object and identity of subject. We really need a third one for "applies to aspect", alias "status of statement" - "maximum", "minimum", "interim" etc. It's like applies to part (P518) but it's part of the relationship not part of the item, and like sourcing circumstances (P1480) but qualifies the accuracy of the statement, not the accuracy of the sourcing. I'm quite busy today so won't be writing the proposal yet, but will try to do over this weekend. Deryck Chan (talk) 12:10, 1 December 2017 (UTC)
- @Deryck Chan: I though that might happen, so I've switched to using determination method (P459) for those. I don't think applies to part (P518) generally works for the job – take Grenfell Tower fire (Q30274958): minimum (Q21067468) is not a part or aspect of "80", nor a part or aspect of Grenfell Tower fire (Q30274958) ("the lower bound of Grenfell Tower fire" is ambiguous, since it's used for both dead and injured). For "de facto" and "interim", I think
Discussion
I also found many other use of this property, some of them are incorrect:
- Many uses of this property with value song (Q7366), film (Q11424), etc should be removed by spliting the item to new items [8]
- Usage of this property as a qualifier of main subject (P921) should be replaced by another value of main subject (P921)[9]
- The property is also uses with Wikidata property example (P1855) meaning "scope of example" (decays to (P816)). This can either be removed or replaced by a new property.[10]
--GZWDer (talk) 19:47, 13 February 2017 (UTC)
- Minor point, but I am a little confused when you're talking about "W is a subclass of Y", when Y appears to be a property. Jheald (talk) 20:49, 13 February 2017 (UTC)
- This is somewhat another kind of subproperty, where P794 (P794) is used like kinship to subject (P1039) and version type (P548).--GZWDer (talk) 21:06, 13 February 2017 (UTC)
- I have made a couple of tweaks to the table diff. I hope these are all right. Jheald (talk) 12:51, 14 February 2017 (UTC)
- Here's a query for the most commons classes of X, Z, W, with an example of X :
tinyurl.com/zn6rj8z
- I haven't gone through the whole list yet, but we should perhaps list all the types of proposed "specifically" replacements, and make sure we're happy with them, eg
- 2010 Tour de France (Q217287) participant (P710) Adriano Malori (Q375923) "specifically" Lanterne rouge (Q1315624) (70 similar uses)
- There's also quite a lot of potential "has role" replacements, where the role would be quite generic eg "antagonist" etc, for the purpose of the character's appearance in the film. But that may be okay. Jheald (talk) 15:40, 14 February 2017 (UTC)
- Minor point, but I am a little confused when you're talking about "W is a subclass of Y", when Y appears to be a property. Jheald (talk) 20:49, 13 February 2017 (UTC)
- @GZWDer, Jheald: Thanks for that detailed tableǃ I would like to see how many instances of each usage there are, to illuminate the evaluation of the need for new properties. As for specific rows:
- Louis XI of France (Q8058), Nationaal Songfestival 1956 (Q14924305), lightweight class (Q26211786) – I see subject has role (P2868) as reasonably suited to each of these roles. In particular, I would not use criterion used (P1013) for lightweight class (Q26211786). If the concern is that subject has role (P2868) is sometimes referring to the subject, and sometimes to the object, then we could split it into "subject has role" and "object has role" (what you're calling "specifically").
- Israel (Q801), Bělá pod Bezdězem (Q1019942) Thai (Q9217), Mauro Fiore (Q926054) – these qualifications don't make any sense to me, and don't seem to add any real information – could they just be dropped?
- Chinese Taipei at the 2016 Summer Olympics (Q18204509), Italian Navy (Q833040) – maybe the two new properties you're suggesting, "under the name of" and "originally as", could be one? Or maybe not, just spitballing.
- Nimrod Fortress (Q1404704) – I would use criterion used (P1013) here.
- Basically, I think there may be a need for a couple of new properties, but I think their description and scope need more fleshing out, and we need to look first to existing properties that may be able to do the job without overly stretching their scope. --Swpb (talk) 16:44, 14 February 2017 (UTC)
- Agreed. Clearly "subject has role" and "object has role" are not the same thing, For example if we didn't have child (P40) and kinship to subject (P1039) but have P794 (P794) and relative (P1038)/significant person (P3342), you may represent the relationship of Elizabeth II (Q9682) and Charles III of the United Kingdom (Q43274) as Elizabeth II (Q9682)relative (P1038)Charles III of the United Kingdom (Q43274), with qualifier "subject has role" mother (Q7560) or "object has role" son (Q177232) (though we mean the latter if we use kinship to subject (P1039)). Currently "subject has role" is represented by either P794 (P794) or subject has role (P2868), and "object has role" is represented by five different properties (P794 (P794), subject has role (P2868), kinship to subject (P1039), version type (P548) and instance of (P31)), we should clean them up. Maybe subject has role (P2868) itself also needs discussion.--GZWDer (talk) 06:18, 15 February 2017 (UTC)
- Here is an updated query for the most common joint combinations of Y and (class of W):
tinyurl.com/hdx3axc
. For each it gives an example X and corresponding example W. (Thanks due to User:MartinPoulter for clueing me into the use of "named subqueries" through his example here). - Also this alternative ordering of the same query, showing all the classes of W for a particular Y together:
tinyurl.com/hn8fey9
- Splitting "as" and "has role" into "subject has role" and "object has role" could go a long way towards clarifying most of these. It tends to follow fairly closely whether Y is one-to-many or many-to-one. In turn the uses on "subject has role" and "object has role" could then be examined to see if any uses could or should be further cascaded down to more specific properties. Jheald (talk) 09:54, 15 February 2017 (UTC)
- Later we may want to write a new help page indicating the differents between them and how to use them.--GZWDer (talk) 15:02, 15 February 2017 (UTC)
- As we're agreed, I've created the proposal. --Swpb (talk) 15:41, 15 February 2017 (UTC)
- If you believe the data that's contained should be moved depending on circumstance to different more specific properties, first move the data and then come back when the property is empty. As long as it isn't Keep. ChristianKl (talk) 07:37, 18 February 2017 (UTC)
- Keep agree with ChristianKl. SJK (talk) 01:15, 12 March 2017 (UTC)
- Keep in the short term but deprecate. I've updated a few items of the table to show where they should go. Deryck Chan (talk) 15:34, 22 March 2017 (UTC)
- Delete Too hard to translate in some asian languages. --Liuxinyu970226 (talk) 13:28, 27 May 2017 (UTC)
- Without understanding all of the technicalities above, I thought of using this property to better reflect the parameter "founded" in some infoboxes. "inception (P571):1647" is not much of information actually. Was it then founded as a populated place, a village, a city with certain status or whatever? A single entity can be founded several times in that aspect. A city can be burned and founded again! I agree, that this is very difficult to turn into descent language, but I think it at least makes sense semantically. -- 16:14, 7 August 2017 (UTC)~
- Just to let you all know that I'm working on these and have built a tool to gradually migrate them. Deryck Chan (talk) 16:40, 3 November 2017 (UTC)
- There seems to be a lot of Pokemon using P31 + P794 to indicate type changes: [11]
- @swpb, GZWDer, Jheald, Liuxinyu970226: We're now getting to the long tail of unusual use cases (see status report below). Can you help finding appropriate qualifiers to migrate the remaining statements? Deryck Chan (talk) 16:51, 28 November 2017 (UTC)
- Sure thing. I'll add use cases I come across to the table if they don't seem to match anything there already. Swpb (talk) 19:39, 28 November 2017 (UTC)
- @Deryck Chan, GZWDer, Jheald, Liuxinyu970226: I've come across a few more cases that fit the "identity of subject in relation to statement" mold, so I've gone ahead and proposed the property, though I'm thinking it might be met by modifying the description of subject has role (P2868) or applies to part (P518). Swpb (talk) 14:22, 29 November 2017 (UTC)
- @swpb: Thanks so much for proposing the "identity of subject" property. I think we have slightly different views on where we should draw the boundary between this new property and subject has role (P2868), though we agree on a large proportion of use cases where it is clear that we need a new qualifier for this purpose. Deryck Chan (talk) 23:40, 29 November 2017 (UTC)
- Yes, by all means, adjust the boundaries as needed. You have my approval to edit the proposal itself as you see fit. Swpb (talk) 13:49, 30 November 2017 (UTC)
- @swpb: Thanks so much for proposing the "identity of subject" property. I think we have slightly different views on where we should draw the boundary between this new property and subject has role (P2868), though we agree on a large proportion of use cases where it is clear that we need a new qualifier for this purpose. Deryck Chan (talk) 23:40, 29 November 2017 (UTC)
- @swpb: While we're on the case, I've proposed Wikidata:Property proposal/identity of object in relation to statement too. Deryck Chan (talk) 11:46, 30 November 2017 (UTC)
- @Deryck Chan: So, to clarify, it looks like you want these new properties to only take items that refer specifically to the subject/object in question, right? And for cases like Lucy Westenra (Q2404481), where the "identity" is generic, you want to use subject has role (P2868)/object of statement has role (P3831)? That's fine with me if that's the case, just want to clarify. Swpb (talk) 14:02, 30 November 2017 (UTC)
- @swpb: I think so, except when applies to part (P518) is more appropriate! Deryck Chan (talk) 14:57, 30 November 2017 (UTC)
- @Deryck Chan: So, to clarify, it looks like you want these new properties to only take items that refer specifically to the subject/object in question, right? And for cases like Lucy Westenra (Q2404481), where the "identity" is generic, you want to use subject has role (P2868)/object of statement has role (P3831)? That's fine with me if that's the case, just want to clarify. Swpb (talk) 14:02, 30 November 2017 (UTC)
- I think Helmut Kalex (Q1603729)academic degree (P512)habilitation (Q308678)
"identity of object"Promotion B (Q15841081) will be another appropriate use of the new property. habilitation (Q308678) is an academic qualification and Promotion B (Q15841081) is a more specific form of it. Deryck Chan (talk) 16:13, 30 November 2017 (UTC)
- Delete - too language dependent to be genuinely semantic. Thanks to everybody involved in the migration, that seems to be a lot of work. − Pintoch (talk) 09:35, 2 December 2017 (UTC)
Status update
The properties that use P794 (P794) are shown below, alongside with the number of items (X) that use each combination of property and P794 (P794) and the number of targets (W) of P794 (P794):
Latest table
As of 9 Dec 2017:
Property | Number of items | Number of targets |
---|---|---|
occupation (P106) | 31 | 19 |
employer (P108) | 22 | 19 |
publisher (P123) | 2 | 2 |
owned by (P127) | 9 | 9 |
operator (P137) | 36 | 25 |
based on (P144) | 3 | 3 |
follows (P155) | 4 | 5 |
killed by (P157) | 1 | 3 |
award received (P166) | 102 | 12 |
country (P17) | 15 | 5 |
depicts (P180) | 55 | 21 |
instance of (P31) | 59 | 56 |
capital (P36) | 14 | 7 |
official language (P37) | 45 | 5 |
author (P50) | 7 | 1 |
director (P57) | 1 | 1 |
screenwriter (P58) | 1 | 1 |
noble title (P97) | 2 | 1 |
editor (P98) | 1 | 1 |
product or material produced or service provided (P1056) | 6 | 6 |
total produced (P1092) | 37 | 12 |
participant in (P1344) | 1 | 2 |
capital of (P1376) | 8 | 5 |
official name (P1448) | 16 | 23 |
has characteristic (P1552) | 3 | 3 |
consecrator (P1598) | 30 | 4 |
work period (start) (P2031) | 3 | 4 |
solubility (P2177) | 2 | 2 |
part of (P361) | 32 | 16 |
presenter (P371) | 17 | 4 |
member of (P463) | 40 | 19 |
academic degree (P512) | 1 | 1 |
has part(s) (P527) | 50 | 60 |
inception (P571) | 65 | 82 |
dissolved, abolished or demolished date (P576) | 5 | 2 |
publication date (P577) | 28 | 18 |
characters (P674) | 23 | 11 |
participant (P710) | 2 | 1 |
candidate (P726) | 4 | 9 |
given name (P735) | 48 | 8 |
main subject (P921) | 1 | 1 |
inspired by (P941) | 35 | 11 |
- Anyway, is there anyone who knows Armenian to modify hy:Կաղապար:Տեղեկաքարտ_Ռազմական_ստորաբաժանում, the only one template which is still using p794? --Liuxinyu970226 (talk) 03:37, 30 November 2017 (UTC)
- Gave it a shot with Google Translate – they were using P794 (P794) for a parameter "function" of a military unit; I changed it to use has use (P366). Swpb (talk)
@Deryck Chan: Hey, can we get an updated status? I'm not sure how you've been producing the table, otherwise I'd do it myself. Thanks! Swpb (talk) 19:53, 8 December 2017 (UTC)
- @Swpb: I wrote a PAWS tool to do this. More details here: User:Deryck Chan/Property migration tool --Deryck Chan (talk) 13:09, 9 December 2017 (UTC)
- For Pokémons, applies to part (P518) is enough, I boldly changed only one remain property namespace usage (in given name (P735), which psst is a qualifier property (P2306) value of property constraint (P2302) allowed qualifiers constraint (Q21510851)) to two values object of statement has role (P3831) and subject has role (P2868).
- The Océan (Q3357220) is the last one I'm interesting, because that usage (in notable work (P800)) isn't a qualifier but used as source?! --Liuxinyu970226 (talk) 03:57, 17 December 2017 (UTC)
Discussion (2)
Continued from #Discussion above.
- Keep per Wikidata:Property_proposal/Archive/12#P794 this was as a generic qualifier.
From the discussion at Property_talk:P1480#de_facto,_interim,_acting and the subsequent edits, it appears that even for people who regularly edit this group of qualifier, it's not possible to determine the exact qualifier reliably. As the information included as value still needs to be in Wikidata in a structured way, there is still a need for a generic qualifier. Obviously, if/when a better qualifier is identified, values can be moved there. To query both, use "|".
--- Jura 15:45, 13 December 2017 (UTC)
- The "generic qualifier" is problematic precisely because it can mean so many different things, and relies on human intelligence to determine which meaning applies, and I think there's broad agreement that this is a problem. Fortunately, the vast majority of use cases have been migrated to more precise properties with no real disagreement. The fact that the few remaining use cases have caused minor disagreement does not justify giving up on the whole endeavor and leaving this "generic (read vague) qualifier" to re-accrue uses of the types that have already been migrated to better properties. I'm absolutely sure we'll come together on the handling of the few remaining cases, and make sure the descriptions of the various qualifiers don't leave room for ambiguity – if the process that's been working well for nearly a year is allowed a very reasonable amount more time to wrap up. Swpb (talk) 21:22, 13 December 2017 (UTC)
- Anyway the "To query both, use "|"" can sometimes result Lint problems (e.g. some template arguments just ended as patchwork because of your "|" usage in WQS codes). --Liuxinyu970226 (talk) 04:00, 17 December 2017 (UTC)
- @ChristianKl, SJK: You voted to keep the property till it is empty. P794 (P794) is empty. What is your verdict? --Pasleim (talk) 17:32, 17 December 2017 (UTC)
- I'm okay with deleting it now. ChristianKl (✉) 17:36, 17 December 2017 (UTC)
- It's really unfortunate how this was handled. This was deleted before a correct replacement was found. Now we have many statements moved to qualifiers people agree that they are wrong: Property_talk:P1480#de_facto,_interim,_acting . The correct approach would be move them back and delete later if possible.
--- Jura 15:01, 19 December 2017 (UTC)
- That's just a complete mischaracterization of a very deliberative process. Replacements were found for all use cases, 99% of the time with no controversy at all. In the tiny subset where there was disagreement, no one said that the qualifiers being used were wrong, only that another qualifier might be better (which can still be addressed), and no one but you expressed the thought that the old, generic qualifier would be better, even temporarily. So no, this property was absolutely not "deleted before a correct replacement was found", and it was deleted after extremely thorough discussion and solid consensus. Swpb (talk) 13:56, 20 December 2017 (UTC)
- I don't recall anyone supporting the solution of using sourcing circumstances (P1480) at Property_talk:P1480#de_facto,_interim,_acting. Unfortunately I didn't check last month if the contributor had fixed all uses after some were actually moved to a suitable qualifiers. Given this negligent approach, I'm not really confident that the reminder of the changes have been done correctly.
--- Jura 14:48, 20 December 2017 (UTC)- If you want to query uses of sourcing circumstances (P1480) and make sure they're all to your approval, go ahead. Or talk to @Deryck Chan: directly and tell him how "negligent" you think he is, and then see if he's interested in helping you. Whining and being dishonest about a very decisive closure you don't happen to like is accomplishing nothing but making yourself undesirable to interact with. Swpb (talk) 18:09, 20 December 2017 (UTC)
- I don't recall anyone supporting the solution of using sourcing circumstances (P1480) at Property_talk:P1480#de_facto,_interim,_acting. Unfortunately I didn't check last month if the contributor had fixed all uses after some were actually moved to a suitable qualifiers. Given this negligent approach, I'm not really confident that the reminder of the changes have been done correctly.
- That's just a complete mischaracterization of a very deliberative process. Replacements were found for all use cases, 99% of the time with no controversy at all. In the tiny subset where there was disagreement, no one said that the qualifiers being used were wrong, only that another qualifier might be better (which can still be addressed), and no one but you expressed the thought that the old, generic qualifier would be better, even temporarily. So no, this property was absolutely not "deleted before a correct replacement was found", and it was deleted after extremely thorough discussion and solid consensus. Swpb (talk) 13:56, 20 December 2017 (UTC)
Undeletion of Property:P794
It appears that many qualifiers have been replaced with in incorrect sourcing circumstances (P1480) and still need to be corrected/reverted. Subsequent discussions for a better solution haven't be productive.
--- Jura 10:29, 7 January 2018 (UTC)
- Oppose If there's clear replacement then use that replacement, no more harrasement, otherwise I just will make a fire request aganist your administrator right. --Liuxinyu970226 (talk) 15:04, 7 January 2018 (UTC)
- Anyway, if you would love to open a ≥1km high discussion thread, please do so on WD:RFC rather than here, thank you for regarding. --Liuxinyu970226 (talk) 15:18, 7 January 2018 (UTC)
Cleanup discussion
item | itemLabel | property | propertyLabel | value | valueLabel | asObject | asObjectLabel |
Frank-Walter Steinmeier (Q76658) | Frank-Walter Steinmeier | P39 | position held | Q29576752 | chairman of the Social Democratic Party | Q4676846 | acting |
Pietro Badoglio (Q200085) | Pietro Badoglio | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Charles Dupuy (Q356032) | Charles Dupuy | P39 | position held | Q191954 | President of the French Republic | Q4676846 | acting |
Ferruccio Parri (Q471315) | Ferruccio Parri | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Ferruccio Parri (Q471315) | Ferruccio Parri | P39 | position held | Q39415052 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Antonio Starabba di Rudinì (Q605268) | Antonio Starabba, Marquess of Rudinì | P39 | position held | Q26305375 | minister of Justice of the Kingdom of Italy | Q4676846 | acting |
Igor Radojičić (Q609400) | Igor Radojičić | P39 | position held | Q6594693 | President of Republika Srpska | Q4676846 | acting |
Wendy Chamberlin (Q2559277) | Wendy Chamberlin | P39 | position held | Q27832358 | United Nations High Commissioner for Refugees | Q4676846 | acting |
Giuseppe de Nava (Q3770441) | Giuseppe de Nava | P39 | position held | Q27136108 | minister of Maritime and Railway Transports of the Kingdom of Italy | Q4676846 | acting |
Willem Frederik van Reede (Q14519538) | Willem Frederik van Reede | P39 | position held | Q251747 | President of the Senate of the Netherlands | Q4676846 | acting |
Felice Merlo (Q25938587) | Felice Merlo | P39 | position held | Q25938572 | minister for Ecclesiastical Affairs and Justice of the Kingdom of Sardinia | Q4676846 | acting |
Félix Pachano (Q26741229) | Félix Pachano | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Adolfo de Cucco (Q26761712) | Adolfo de Cucco | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Adolfo Vieyra Latorre (Q26761714) | Adolfo Vieyra Latorre | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Johannes Rau (Q2551) | Johannes Rau | P39 | position held | Q29576752 | chairman of the Social Democratic Party | Q4676846 | acting |
Franz Amrehn (Q96399) | Franz Amrehn | P39 | position held | Q641159 | Governing Mayor of Berlin | Q4676846 | acting |
Alcide De Gasperi (Q153832) | Alcide De Gasperi | P39 | position held | Q28798093 | minister of Italian Africa | Q4676846 | acting |
Alcide De Gasperi (Q153832) | Alcide De Gasperi | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q26877864 | minister of the Navy of the Kingdom of Italy | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q25936389 | minister of Interior of the Kingdom of Sardinia | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q26844985 | minister of War of the Kingdom of Italy | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q26084477 | minister of Finance of the Kingdom of Sardinia | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q26084496 | minister of War of the Kingdom of Sardinia | Q4676846 | acting |
Camillo Benso di Cavour (Q166092) | Camillo Benso, Count of Cavour | P39 | position held | Q26084477 | minister of Finance of the Kingdom of Sardinia | Q4676846 | acting |
Jim Wallace, Baron Wallace of Tankerness (Q333807) | Jim Wallace, Baron Wallace of Tankerness | P39 | position held | Q1362216 | First Minister of Scotland | Q4676846 | acting |
Jim Wallace, Baron Wallace of Tankerness (Q333807) | Jim Wallace, Baron Wallace of Tankerness | P39 | position held | Q1362216 | First Minister of Scotland | Q4676846 | acting |
Giovanni Lanza (Q674128) | Giovanni Lanza | P39 | position held | Q26084477 | minister of Finance of the Kingdom of Sardinia | Q4676846 | acting |
Giovanni Lanza (Q674128) | Giovanni Lanza | P39 | position held | Q26084477 | minister of Finance of the Kingdom of Sardinia | Q4676846 | acting |
Giovanni Lanza (Q674128) | Giovanni Lanza | P39 | position held | Q26084477 | minister of Finance of the Kingdom of Sardinia | Q4676846 | acting |
Cesare Alfieri di Sostegno (Q1054500) | Cesare Alfieri di Sostegno | P39 | position held | Q26085299 | minister of Agriculture and Trade of the Kingdom of Sardinia | Q4676846 | acting |
Bernardino Grimaldi (Q3638716) | Bernardino Grimaldi | P39 | position held | Q26457103 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Francesco Tedesco (Q3750727) | Francesco Tedesco | P39 | position held | Q26457103 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Li Zongren (Q20297) | Li Zongren | P39 | position held | Q887003 | President of the Republic of China | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26277644 | minister of Public Works of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q33205128 | minister of Corporations of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26277644 | minister of Public Works of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26877864 | minister of the Navy of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26844985 | minister of War of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q33205128 | minister of Corporations of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Benito Mussolini (Q23559) | Benito Mussolini | P39 | position held | Q26911615 | minister of Air Force of the Kingdom of Italy | Q4676846 | acting |
Giovanni Giolitti (Q297190) | Giovanni Giolitti | P39 | position held | Q26277644 | minister of Public Works of the Kingdom of Italy | Q4676846 | acting |
Giovanni Giolitti (Q297190) | Giovanni Giolitti | P39 | position held | Q26305375 | minister of Justice of the Kingdom of Italy | Q4676846 | acting |
Giovanni Giolitti (Q297190) | Giovanni Giolitti | P39 | position held | Q26877864 | minister of the Navy of the Kingdom of Italy | Q4676846 | acting |
Antonio Salandra (Q354715) | Antonio Salandra | P39 | position held | Q26877864 | minister of the Navy of the Kingdom of Italy | Q4676846 | acting |
Luigi Facta (Q431330) | Luigi Facta | P39 | position held | Q27131271 | minister of Reconstruction of the Lands Liberated From the Enemy | Q4676846 | acting |
Frédéric François-Marsal (Q459212) | Frédéric François-Marsal | P39 | position held | Q191954 | President of the French Republic | Q4676846 | acting |
Enrico Morin (Q3725932) | Enrico Morin | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Enrico Morin (Q3725932) | Enrico Morin | P39 | position held | Q26877864 | minister of the Navy of the Kingdom of Italy | Q4676846 | acting |
Giovanni Cuomo (Q3767072) | Giovanni Cuomo | P39 | position held | Q33206661 | minister of Popular Culture of the Kingdom of Italy | Q4676846 | acting |
Simonetta Pozzoli (Q24260682) | Simonetta Pozzoli | P39 | position held | Q30185 | mayor | Q4676846 | acting |
Walter Scheel (Q2571) | Walter Scheel | P39 | position held | Q4970706 | Federal Chancellor of Germany | Q4676846 | acting |
Alain Poher (Q12950) | Alain Poher | P39 | position held | Q191954 | President of the French Republic | Q4676846 | acting |
Alain Poher (Q12950) | Alain Poher | P39 | position held | Q191954 | President of the French Republic | Q4676846 | acting |
André Blattmann (Q120004) | André Blattmann | P39 | position held | Q25212272 | Chief of the Armed Forces | Q4676846 | acting |
Agostino Magliani (Q139839) | Agostino Magliani | P39 | position held | Q26457103 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Agostino Magliani (Q139839) | Agostino Magliani | P39 | position held | Q26457103 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Francesco Saverio Nitti (Q367132) | Francesco Saverio Nitti | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Urbano Rattazzi (Q449387) | Urbano Rattazzi | P39 | position held | Q26456736 | minister of Finance of the Kingdom of Italy | Q4676846 | acting |
Bill Skate (Q719336) | Bill Skate | P39 | position held | Q1073440 | Governor-General of Papua New Guinea | Q4676846 | acting |
Carlo Bon Compagni di Mombello (Q1054496) | Carlo Bon Compagni di Mombello | P39 | position held | Q26083910 | minister of Public Education of the Kingdom of Sardinia | Q4676846 | acting |
Federico Pescetto (Q1400532) | Federico Pescetto | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Federico Seismit-Doda (Q1400564) | Federico Seismit-Doda | P39 | position held | Q26457103 | minister of Treasury of the Kingdom of Italy | Q4676846 | acting |
Agustín B. Gambier (Q16527578) | Agustín B. Gambier | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Andries Hudde (Q20857991) | Andries Hudde | P39 | position held | Q1162163 | director | Q4676846 | acting |
Eufemio Alcayaga (Q26761707) | Eufemio Alcayaga | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Juan Alsina (Q26761713) | Juan Alsina | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Samuel Saraví Hardy (Q26761784) | Samuel Saraví Hardy | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Alfredo Sarquisse (Q26761815) | Alfredo Sarquisse | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Jorge Falcone (Q26761816) | Jorge Falcone | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Jorge Falcone (Q26761816) | Jorge Falcone | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Ivanoe Bonomi (Q313717) | Ivanoe Bonomi | P39 | position held | Q27136108 | minister of Maritime and Railway Transports of the Kingdom of Italy | Q4676846 | acting |
Ivanoe Bonomi (Q313717) | Ivanoe Bonomi | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Ivanoe Bonomi (Q313717) | Ivanoe Bonomi | P39 | position held | Q28798091 | minister of Italian Africa of the Kingdom of Italy | Q4676846 | acting |
Ivanoe Bonomi (Q313717) | Ivanoe Bonomi | P39 | position held | Q26248695 | minister of Foreign Affairs of the Kingdom of Italy | Q4676846 | acting |
Bettino Ricasoli (Q519900) | Bettino Ricasoli | P39 | position held | Q26305375 | minister of Justice of the Kingdom of Italy | Q4676846 | acting |
Ubaldino Peruzzi (Q1079356) | Ubaldino Peruzzi | P39 | position held | Q26456736 | minister of Finance of the Kingdom of Italy | Q4676846 | acting |
Ferdinando Acton (Q1406068) | Ferdinando Acton | P39 | position held | Q26844985 | minister of War of the Kingdom of Italy | Q4676846 | acting |
Filippo Cordova (Q3071888) | Filippo Cordova | P39 | position held | Q26305375 | minister of Justice of the Kingdom of Italy | Q4676846 | acting |
Pietro De Rossi di Santarosa (Q3388107) | Pietro De Rossi di Santarosa | P39 | position held | Q26085299 | minister of Agriculture and Trade of the Kingdom of Sardinia | Q4676846 | acting |
Guido Jung (Q3779346) | Guido Jung | P39 | position held | Q37981911 | minister of Trade and Currencies of the Kingdom of Italy | Q4676846 | acting |
Roberto Hurtado (Q26741581) | Roberto Hurtado | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Alfredo Paz (Q26761708) | Alfredo Paz | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Luis Doyhenard (Q26761710) | Luis Doyhenard | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Juan Carlos Parodi (Q26761823) | Juan Carlos Parodi | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Andrew G. McCabe (Q27734885) | Andrew G. McCabe | P39 | position held | Q1057168 | Director of the Federal Bureau of Investigation | Q4676846 | acting |
Matteo Renzi (Q47563) | Matteo Renzi | P39 | position held | Q27991508 | Minister of Economic Development | Q4676846 | acting |
Matteo Renzi (Q47563) | Matteo Renzi | P39 | position held | Q6092845 | Italian Minister of Transports and Infrastructures | Q4676846 | acting |
Roberto Etchepareborda (Q2159496) | Roberto Etchepareborda | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
José de Carvajal y Hué (Q6294279) | José de Carvajal y Hué | P39 | position held | Q21192262 | Minister of Governance | Q4895105 | interim |
Adrián Fernández Casco (Q21694115) | Adrián Fernández Casco | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Guillermo Cranwell (Q1230972) | Guillermo Cranwell | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Manuel Obarrio (Q5993921) | Manuel Obarrio | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Manuel Obarrio (Q5993921) | Manuel Obarrio | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Saturnino García Anido (Q21694111) | Saturnino García Anido | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Eduardo Bergalli (Q21694126) | Eduardo Bergalli | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Rudolf Anthes (Q2172342) | Rudolf Anthes | P39 | position held | Q22132694 | museum director | Q4895105 | interim |
Juan José Montes de Oca (Q21694009) | Juan José Montes de Oca | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Enrique Palacio (Q21694098) | Enrique Palacio | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Virgilio Tedín Uriburu (Q21694113) | Virgilio Tedín Uriburu | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Tomás José Caballero (Q6148525) | Tomás José Caballero | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Martín Biedma (Q21694034) | Martín Biedma | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Eduardo Crespi (Q5559260) | Eduardo Crespi | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Alfonso La Marmora (Q471272) | Alfonso Ferrero La Marmora | P39 | position held | Q25936261 | minister of Foreign Affairs of the Kingdom of Sardinia | Q4676846 | acting |
Benito Lynch (Q817347) | Benito Lynch | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Carlos Monsalve (Q17995988) | Carlos Monsalve | P39 | position held | Q26741444 | Mayor of La Plata | Q4676846 | acting |
Albert Bessemans (Q18612682) | Albert Bessemans | P39 | position held | Q27016924 | Q27016924 | Q4676846 | acting |
Juan Debenedetti (Q21693712) | Q21693712 | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
Leopoldo Frenkel (Q21693724) | Q21693724 | P39 | position held | Q21693213 | Mayor of Buenos Aires | Q4895105 | interim |
- Could you give a few examples of the incorrect sourcing circumstances (P1480) you see? ChristianKl ❪✉❫ 23:48, 7 January 2018 (UTC)
- @ChristianKl: please see above. There is a query for them on the talk page of sourcing circumstances (P1480). The contributor who converted them almost immediately realized his error and, as I saw them doing some correctly, I assumed initially that everything had been fixed. Unfortunately, this hasn't moved since and it would be bad practice if we would let them linger there a further couple of months, until an acceptable alternative was determined.
--- Jura 16:19, 8 January 2018 (UTC)- @Deryck Chan: How do you think about them? --Liuxinyu970226 (talk) 04:44, 10 January 2018 (UTC)
- Thanks for pinging me. Let's continue the discussion at Wikidata:Requests for comment/Close-out of statements formerly using P794. Deryck Chan (talk) 17:10, 11 January 2018 (UTC)
- Whatever change may be decided in 6 months, we still need to clean up this part. As you did the bulk edits, it's expected that you'd clean it up. If you can't do it or don't have the time to do it, please say so.
--- Jura 17:25, 11 January 2018 (UTC)
- Whatever change may be decided in 6 months, we still need to clean up this part. As you did the bulk edits, it's expected that you'd clean it up. If you can't do it or don't have the time to do it, please say so.
- I'm of the opinion that we're better off parking these statements with a sub-optimal qualifier than to return them to P794. I disagree with your description that I "realized his error", but I accept that you and a few other editors disagree with me and some other participants of the discussion above who desired to move those qualifiers to sourcing circumstances (P1480), and offered to move the qualifiers again when a better choice of P than both P794 and P1480 is agreed upon. Deryck Chan (talk) 12:38, 22 January 2018 (UTC)
- Thanks for pinging me. Let's continue the discussion at Wikidata:Requests for comment/Close-out of statements formerly using P794. Deryck Chan (talk) 17:10, 11 January 2018 (UTC)
- @Deryck Chan: How do you think about them? --Liuxinyu970226 (talk) 04:44, 10 January 2018 (UTC)
- @ChristianKl: please see above. There is a query for them on the talk page of sourcing circumstances (P1480). The contributor who converted them almost immediately realized his error and, as I saw them doing some correctly, I assumed initially that everything had been fixed. Unfortunately, this hasn't moved since and it would be bad practice if we would let them linger there a further couple of months, until an acceptable alternative was determined.
- This section was archived on a request by: --Pasleim (talk) 17:29, 27 March 2018 (UTC)