Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to navigation Jump to search

Properties for deletion
This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:
  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message in Village pump of the project.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request


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






a query

for deletions

for comment


for permissions


for deletion

and imports




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

language of work or name (P407) and language of film or TV show (P364)[edit]

first flight (P606)/time of spacecraft launch (P619)/time of spacecraft landing (P620)/time of spacecraft orbit decay (P621)/spacecraft docking/undocking date (P622)[edit]

first flight (P606): (delete | history | links | entity usage | logs | discussion) time of spacecraft launch (P619): (delete | history | links | entity usage | logs | discussion) time of spacecraft landing (P620): (delete | history | links | entity usage | logs | discussion) time of spacecraft orbit decay (P621): (delete | history | links | entity usage | logs | discussion) spacecraft docking/undocking date (P622): (delete | history | links | entity usage | logs | discussion)

Overly specific time properties. Use instead, with qualifier point in time (P585):

--Swpb (talk) 18:19, 22 March 2017 (UTC)

Symbol oppose vote.svg Oppose. Specific properties are more user-friendly for new users than generic properties with qualifiers. New users may easily discover specific properties and put useful data in them. They are much less likely to work out how to use P793 with qualifiers. And it is easier for other wikis to work out to consume a specific property than to consume a generic property filtered by qualifiers. If we were to go down this path, should we not to be consistent also delete date of birth (P569) and place of birth (P19) since they too can also be replaced by P793 with qualifiers? Also, even for experienced users, specific property is easier than generic property+qualifier because it is less typing/clicking to enter. And it is easier for people writing SPARQL queries, since the syntax for querying on qualifiers is more advanced than just querying for specific properties so this would make the SPARQL learning curve steeper (and it is pretty steep already, in my opinion). SJK (talk) 08:46, 24 March 2017 (UTC)
@SJK: I have some doubt about the affirmation "New users may easily discover specific properties and put useful data in them". When you have more than 3000 properties it is difficult to say that a new user can easily find the right property especially when the numbering is not based on any logic. The most problem we have is from the people in WP who want to add one value in an infobox. Most of the time they access WD via the link between the article and the corresponding item. Then they add a new statement and they have to find the right property. They can be lucky by entering the correct words or not. If not what happens ? They don't want to extract all subproperties of significant event (P793) using a SPARQL query (most of wikipedians don't know anything about SPARQL) and they don't want to start any search to find the wikiproject responsible of managing the properties structure. So if the wikipedian doesn't find the correct property in the first search he won't continue to look for it and he will abandon. With one property there is a huge probability than the general property is already used in the item and it is easier to copy-paste the existing statements for a new addition. Even if they don't used the correct value for significant event (P793) like using maiden flight instead of first flight or the inverse, they can already add the location or the date and the error can be detected and corrected using the constraint violation reports. Snipre (talk) 15:29, 4 April 2017 (UTC)
start_date, end_date, point_in_time are intuitive qualifiers/properties.
Documentation of P793 could be improved to emphasize relevant qualifiers. d1g (talk) 15:35, 30 April 2017 (UTC)
Symbol delete vote.svg Delete per Snipre --Pasleim (talk) 11:44, 15 April 2017 (UTC)
Symbol keep vote.svg Keep first flight (P606). This one is well defined and used. This makes it very easy to query and use as well as to enter in the first place. The significant event (P793) method is not a problem, but also doesn't really offer an advantage over having first flight (P606) as a distinct property. Josh Baumgartner (talk) 20:24, 18 April 2017 (UTC)
Symbol delete vote.svg Delete P793/P31/P279*/<event in space> is easier to query than 5 distinct properties. It's better to create taxonomies of evens than a property for every event IMO.
Basic queries with P793 are both easy and narrow: significant event (P793)  docking and berthing of spacecraft (Q557450) d1g (talk) 15:29, 30 April 2017 (UTC)
Symbol keep vote.svg Keep working with separate properties is easier than prop+qualifier. Some another prop+qualifier schemes had moved to separate properties scheme already. So significant event (P793)/point in time (P585) will be deleted too as I think. — Ivan A. Krestinin (talk) 08:01, 20 May 2017 (UTC)
With birth/death events because every person dies... maybe.
It isn't obvious to have 2 properties per every event over events +3 qualifiers.
@Ivan A. Krestinin: almost 2 times less properties-or-events to find with P793.
We also need to create properties, when we don't need to create events in most cases with significant event (P793) d1g (talk) 01:26, 15 June 2017 (UTC)

Pictogram voting comment.svg Comment I checked the usage of each template. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)

Symbol keep vote.svg Keep first flight (P606) and time of spacecraft launch (P619) because they have almost (or over) 5000 uses [13] [14]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
Symbol delete vote.svg Delete time of spacecraft landing (P620), time of spacecraft orbit decay (P621) and spacecraft docking/undocking date (P622) because they have at most 350 uses [15] [16] [17]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
This doesn't really make sense - these properties form a coherent group for describing concepts and so we should either have them all, or put them all as "significant event" qualifiers. All spacecraft go up and so all will have a launch date; not all have come down yet so there will be fewer with landing/decay times. It's natural to expect an imbalance between the two groups, much as we have far more people with "born" than "died". Andrew Gray (talk) 11:27, 25 July 2017 (UTC)
Pictogram voting comment.svg Comment we shouldn't make decisions in any direction based on current usage. Maybe we don't have understanding what exactly is better, but we shouldn't make popularity-driven decisions. d1g (talk) 04:51, 10 August 2017 (UTC)
  • Symbol keep vote.svg Keep seems to be a working set of (sub-)properties.
    --- Jura 14:50, 9 July 2017 (UTC)

Refuse to consider until time of day and time zone issues with Wikidata Datetimes are resolved. Jc3s5h (talk) 23:32, 20 July 2017 (UTC)

Symbol keep vote.svg Keep All of these properties seem to be useful and working with them is much easier than using qualifiers with significant event (P793). --Sintakso (talk) 22:56, 26 July 2017 (UTC)
@Sintakso: in SPARQL difference is in 1 triple, 1 is less than 2, but I wouldn't call it "much".
Can you show example how one property is far better than event?
What happens when one needs to specify a qualifier for this property?
But it takes more time to maintain individual property (create, translate in every language)
Date-related properties aren't specific to space.
< Honeycrisp (Q3140024) View with Reasonator View with SQID > start time (P580) View with SQID < ... >
location (P276) View with SQID < ... >
3(4 with location) qualifiers are free from "...location of ..." "...time of..." restrictions and much faster to enter data by humans. You only need to know 4 properties, not 5-10-300-1000. There is nothing to "discover" because so few options to make mistakes between. d1g (talk) 04:51, 10 August 2017 (UTC)
@D1gggg: I didn't mean just the use of the properties in SPARQL queries. I believe that the users are much more likely to find a distinct property than they are to notice the existence significant event (P793), read it's documentation and remember that they can use it for inserting date of landing, docking etc. Distinct properties are easy to search, so the users don't even have to know/remember the property exists and they can still find it easily. The use of significant event (P793) wouldn't probably spare any time at all, because it would still be needed to translate labels of the items used with it and to check constraint violations regularly (so that users wouldn't be using eg. docking (Q22988075) instead of docking and berthing of spacecraft (Q557450)). The only change I would support would be to delete spacecraft docking/undocking date (P622) and replace it with two properties for docking and undocking. --Sintakso (talk) 06:52, 10 August 2017 (UTC)
@Sintakso: because it would still be needed to translate labels of the items used with it
Only for events never described in Wikipedia as separate article (something rare).
E.g.: burial (Q331055) baptism (Q35856).
We don't have specific properties to both of them, we will spend time on property creation.
300-1000 distinct events aren't stretched at all.
Furthermore, when we use Q1764062, Q331055 and Q35856 in 793 users could read Wikipedia articles if they never heard about such event. d1g (talk) 20:32, 10 August 2017 (UTC)
@Sintakso: we are using this approach in award received (P166)
Point in time is not something we need to know every time, but additional information.
E.g. "was it ever sequenced?" "how many times burial ceremony happened?"
Where and when should be qualifiers d1g (talk) 20:42, 10 August 2017 (UTC)
@D1gggg: I agree that the significant event (P793) + qualifiers approach might be more useful for rare events. However, I believe that in case of common events the time spent with the property creation is outweighted by the user-friendliness of distinct properties. Also, I don't see any point in deleting properties which are already in use and replacing them with significant event (P793) as it doesn't seem to have any major advantages. --Sintakso (talk) 10:06, 11 August 2017 (UTC)
Symbol delete vote.svg Delete Not user-friendly for new users at all, because you must know these property before adding them, and don't forget to check if they exist! There are too many dates properties. This method (creating new properties) is very painstaking: if you want to add and event that doesn't have its own property, you must ask for a property creation, wait weeks... "Good" events have their own properties, "bad" have not... And why do we a have a "date of (event)" property and not others? For example, a "first flight" might be described not only by a date, but by the airport(s), the crew (pilot(s) and so on), important people who attended... Are we going to split each event into multiple properties? Please, have a look at YF-16 (Q17372279). El Caro (talk) 15:06, 20 August 2017 (UTC)
Symbol delete vote.svg Delete per El Caro's arguments --Hsarrazin (talk) 08:13, 25 August 2017 (UTC)
Symbol delete vote.svg Delete. Consistency is important. Storing data so many different ways makes it difficult to use. --Yair rand (talk) 23:40, 11 September 2017 (UTC)
  • Symbol keep vote.svg Keep. They are used by several Wikipedias using the {{#Property:P622}} etc syntax. Deleting these properties will break those infoboxes and there is no easy replacement solution in the proposed migration scheme that doesn't involve bespoke, locally hosted Lua scripts to let the infoboxes find the relevant significant event (P793) + point in time (P585) dates. Until parser functions become sufficiently advanced that these can be migrated by changing wikitext alone, we'll need to keep these properties. Deryck Chan (talk) 15:53, 24 September 2017 (UTC)
  • Symbol keep vote.svg Keep As Joshbaumgartner. Keep first flight (P606) and delete the rest. /ℇsquilo 14:02, 30 October 2018 (UTC)
This is a drive of complex problems, and at the moment I don't think keep all or delete all are good either. If there's some spikes that prevents us to safety use P793, as well as other properties, then those are just bugs, we should actually fix em.
And @Deryck Chan: isn't {{#Property:}} somewhat deprecated now? What's the technical block on migrating usages to be {{#statements:}} (at least, as you're a Cantonese user, what's problem on Cantonese Wikipedia (Q1190962))?

--Liuxinyu970226 (talk) 12:41, 27 October 2017 (UTC)

@Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and Q25936424 don't currently have that functionality either. So I think we should keep these properties until that becomes possible. Deryck Chan (talk) 14:47, 7 December 2017 (UTC)
Some versions of Q25936424 can read out statements based on qualifiers, e.g. the version on frwiki. Moreover, spacecraft docking/undocking date (P622) also requires qualifiers. Infoboxes need to select statements based on qualifier values to properly display the data of spacecraft docking/undocking date (P622). --Pasleim (talk) 06:43, 8 December 2017 (UTC)

Symbol keep vote.svg Keep I vote to keep. There is no such thing as "too much specific". We have "subproperty" property for a reason. --Ogoorcs (talk) 01:56, 8 September 2018 (UTC)

Pokédex number (P1112) + Pokémon browser number (P1685)[edit]

Pokédex number (P1112): (delete | history | links | entity usage | logs | discussion) Pokémon browser number (P1685): (delete | history | links | entity usage | logs | discussion)

It's too specific and get's used to justify other very specific property proposals. Existing data should be moved to catalog code (P528).--ChristianKl (talk) 19:36, 4 November 2017 (UTC) @Legoktm, Jakob:

  • I initially wanted to answer with {{vote_keep}} because I think wikidata should also provide space for very specific types of data. I like the approach you have with catalog code (P528) though. Lets find something similar for Stardate 😀 --Shisma (talk) 20:04, 4 November 2017 (UTC)
  • Pictogram voting comment.svg Comment additional properties like this should not be created but this looks like a special exception. Pokémon seem to get sorted by this value in different lists. Before proposing a deletion we should come up with more detailed alternatives and examples. catalog code (P528) alone is not enough, how about the existing qualifiers? -- JakobVoss (talk) 08:22, 10 November 2017 (UTC)

@Ju gatsu mikka, Ebe123, Airon90, MGChecker: What do you think about this? You have edited Pokemon species items. --Okkn (talk) 10:08, 16 April 2018 (UTC)

I agree P1685 is too specific, however I agree with user:Okkn that a specific property for Pokédex number has major benefits for data integrity. How would you like to specify similar constraints with P642? --MGChecker (talk) 19:40, 17 April 2018 (UTC)
Symbol delete vote.svg Good bye as Pokedexes can also be different between series (don't surprise, PM anime also have characters that ruled different dexes), I can't see a neutral way to create a lot of properties in order to sync something that ≤1000 usages. --Liuxinyu970226 (talk) 13:21, 25 April 2018 (UTC)
Pictogram voting comment.svg Comment I don't understand what's the problem with an unambiguous property used hundreds of times. It's very specific, and so? Personally, I don't have nothing against specific properties:
  • are often more intuitive than broader ones and therefore they make it easier for new editor to contribute;
  • can be linked with external properties as specific as them;
  • can be linked with broader properties via "subproperty of" and so they don't cause any problem in the ontology;
  • are easier to manage for Quickstatement, bots and other third party tools than qualifiers.--Malore (talk) 08:13, 28 November 2018 (UTC)

download link (P4945)[edit]

download link (P4945): (delete | history | links | entity usage | logs | discussion)

Created not trough property proposal process--Edgars2007 (talk) 11:35, 14 March 2018 (UTC)

  • I'm not sure deletion is the right response here, as it maybe useful to have this. Although I believe there were previous discussions for similar properties that had a number of reason to oppose having download URL's as part of our data. But I'm more concerned that one of our property creators, MichaelSchoenitzer appears not to be aware of Wikidata:Property creators. How did that happen? ArthurPSmith (talk) 15:19, 14 March 2018 (UTC)
    • I got the right at at time when there rules haven't existed yet. I knew Property Proposal and used this process but didn't thought it's a "no exceptions"-rule. (The site also does not sound like that.) I proposed splitting the property streaming media URL (P963) and no one disagreed. When someone renamed the old property I paniced because so we now have a few thousand wrong statements in Wikidata. I'm sorry I broke rules I didn't knew, I won't do again but I still think that we should clean this up quickly but that's on other people to decide now. -- MichaelSchoenitzer (talk) 21:49, 14 March 2018 (UTC)
  • @MichaelSchoenitzer: The argument that another property is being abused to support this is a good one for creating it. However, there is quite a bit of history here - here are previous discussions along these lines where the proposal was rejected or at least not yet approved: Wikidata:Property proposal/download link, Wikidata:Property proposal/external image URL (which links to older proposal discussions in the "see also" section). @NMaia, Pintoch, Mahir256, ChristianKl: @Pigsonthewing, ديفيد عادل وهبة خليل 2, Strakhov, Pasleim, Jura1: what do you think on this now? ArthurPSmith (talk) 14:24, 15 March 2018 (UTC)
  • Symbol delete vote.svg Delete agree with nominator.
    --- Jura 09:26, 19 April 2018 (UTC)
    • Pictogram voting comment.svg Comment Somehow I missed that we actually had a proposal for this at Wikidata:Property proposal/download link (see comment below by Jasc PL) and the conclusion of that was not to create this.
      --- Jura 06:55, 8 May 2018 (UTC)
  • Symbol keep vote.svg Keep, or delete - if a property proposal process is the absolute rule for us; move this discuss to Wikidata:Property proposal/download link, then recreate download link (P4945) (I hope) with this exact name. There are several important arguments for having this property. BTW, I see that computing items needs are much insufficient represent in the WD. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)

Ruud Koot
Daniel Mietchen
Giovanni Alfredo Garciliano Diaz
Jasc PL
Pictogram voting comment.svg Notified participants of WikiProject Informatics I would like to be able to use a property like download link (P4945) on open source software items to list the download URL of particular software versions (sourced from the official website, source control systems of Linux distribution package repositories, etc). In many cases, the qualifier checksum (P4092) could and should be included, sourced from either official website and/or Linux distribution package repositories. file format (P2701) should also be a mandatory qualifier. What I am not clear on, is what is the difference between download link (P4945) and full work available at (P953)? Could the scope of full work available at (P953) simply be expanded to include software source distributions, binaries, etc? If so, how would one determine which URL is for a source tarball, and which is a binary package? How would one handle software which has multiple binary packages (either for different CPU architectures or different Linux distribution packaging systems)? Dhx1 (talk) 14:15, 20 April 2018 (UTC)

Full Symbol support vote.svg Support for Dhx1 arguments. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)
  • Symbol delete vote.svg Delete Needs to come through proper property proposal process.--Jklamo (talk) 07:57, 31 May 2018 (UTC)
  • Symbol keep vote.svg Keep --Niridya (talk) 14:47, 16 August 2018 (UTC)
    @Niridya: for what reason? --Liuxinyu970226 (talk) 23:04, 13 September 2018 (UTC)
    @Liuxinyu970226: : sometimes it can be useful. For example to create a link to the download page of a software. --Niridya (talk) 18:01, 14 September 2018 (UTC)
  • Symbol keep vote.svg Keep Germartin1 (talk) 12:56, 12 October 2018 (UTC)
  • Symbol keep vote.svg Keep per above, given that there are many different usages of this property, I think there's no fair way to migrate. --Liuxinyu970226 (talk) 15:13, 14 January 2019 (UTC)

Nobel prize ID (P3188)[edit]

Nobel prize ID (P3188): (delete | history | links | entity usage | logs | discussion)

Hello. On the base on Pigsonthewing's suggestion, I propose that we delete the generic identifier for Nobel laureates in other to split it into more specific ones. It would help us to classify more precisely our properties with instance of (P31) (Physics under Wikidata property related to physics (Q22981316), literature under Wikidata property related to literature (Q29561722), etc.). It would also be useful for completing easily specific external links templates such as Template:Research links (Q54913733) on French WP.--Nomen ad hoc (talk) 15:38, 31 July 2018 (UTC)

Of course, the deletion would be immediately followed by the creation of the specific properties. Nomen ad hoc (talk) 15:39, 31 July 2018 (UTC).
  • Symbol delete vote.svg Delete. Thierry Caro (talk) 15:48, 31 July 2018 (UTC)
  • Comment Deletion should not "be immediately followed by the creation of the specific properties"; once there is consensus to delete this property, the deletion should be put on hold; the new properties should then be created, and once done, the data be copied (or moved) across. Only then should the current property be deleted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 31 July 2018 (UTC)
  • Symbol keep vote.svg Keep Symbol oppose vote oversat.svg Strong oppose Even with this change the ID's would still consist of at least a "year/name" format, I don't think that's a significant simplification. And I believe it's better to treat the prizes as a whole than split them up for several reasons: (1) the number of ID"s is not large as it is so making this change would drop each of them to at most about 300, (2) there is not that large a distinction among the science fields - chemists have won in physics and in medicine as well as chemistry (and also the peace prize). Maybe there's a legitimate reason to treat the literature and peace prizes differently, but I am strongly opposed to splitting up the science prizes into separate ID's. ArthurPSmith (talk) 17:17, 31 July 2018 (UTC)
    ArthurPSmith: I changed my mind and then agree with you. 3 distinct properties (science - including physics, chemistry and medicine.-, peace, and literature) would suffice. Hence could you please support it? Nomen ad hoc (talk) 08:19, 13 August 2018 (UTC).
  • Symbol keep vote.svg Keep I still see no valid reason for splitting the current property. Cdlt, VIGNERON (talk) 07:23, 14 August 2018 (UTC)
  • Symbol keep vote.svg Keep but clean it up and maybe change formatter URL. We have now a federated search see discussion Property_talk:P3188 ==> that we get all Nobel Prize winners defined see list. My understanding is that has redesigned the web so someone needs to spend some time and find matching pages. I have tried communicate with with no success see T203915 - Salgo60 (talk) 07:30, 7 October 2018 (UTC)
  • Pictogram voting comment.svg Comment I'm wondering to what extent this can really be regarded as an ID. I just tried to get from William Nordhaus (Q562481) to his entry on the Nobel side via Q562481#P3188, and it did not work, since the corresponding formatter URL (P1630) and format as a regular expression (P1793) do not fit with the actual , although they work for the property examples given. --Daniel Mietchen (talk) 00:33, 9 October 2018 (UTC)
  • Pictogram voting comment.svg Comment @Mietchen: I have a dialogue with Nobel data and has done some federated searches T200668 / Listeria lists and my understanding is that they are migrating the old web to a new and miss a timeplan. I have asked to get updated of the status maybe we should have a depreciated status?!?!- Salgo60 (talk) 13:25, 11 October 2018 (UTC)

located at street address (P969)[edit]

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

Per Liuxinyu970226, this property should have the monolingual-text datatype because there are places which are bilingual and/or use multiple writing systems, such as Hong Kong (zh/en), Macau (zh/pt), Morocco (ar/ber/fr), most of Xinjiang (zh/ug), parts of Switzerland (de/fr/it/rm), and most of India (en/hi/bn/te/...). If deleted the property would need automatic conversion to a new property with that datatype with the language set based on the writing system of the text and the local language of the located in the administrative territorial entity (P131) or country (P17). —Jc86035 (talk) 16:35, 15 August 2018 (UTC)

I haven't notified any of the many projects which use this property, partly because I'm not sure exactly how I'm supposed to do it. Notifying all talk page contributors of this discussion. Ahoerstemeier, Bcoh, Danrok, Esquilo, Fnielsen, Fralambert, Giftzwerg 88, GZWDer, Ivan A. Krestinin, Jeremyb, Jhertel, Jura1, Kolja21, Laddo, Michiel1972, Napoleon.tan, Pasleim, SPQRobin, Syced, VicVal, Zolo. Jc86035 (talk) 16:50, 15 August 2018 (UTC)

Notifying all contributors to the property in the last two years. Alfonso Márquez, Avatar6, ChristianKl, Edoderoo, Geertivp, Herzi Pinki, İncelemeelemani, J budissin, JakobVoss, JMagalhães, Kareyac, Laura Marianne, Maitsavend, Mormegil, NMaia, Nvrandow, Obaid Raza, Oriciu, Otets, Pyro z, Red Winged Duck, Renamerr, Romaine, Ryanag, Sannita, Sigwald, Sjoerddebruin, Soued031, Susannaanas, Venkisrimba, Zeroth, Zyksnowy, Спасимир, আফতাবুজ্জামান. Jc86035 (talk) 16:53, 15 August 2018 (UTC)

I also need these users who joined former two RFD discussions for this property to join here: @VIGNERON, -revi, Jianhui67, Amqui, Pigsonthewing:@Billinghurst, Rana24news, Jsamwrites, Pustekuchen2014, ArthurPSmith:@Oursana, Srittau, Edgars2007, Jklamo, RolandUnger:@Jheald, Anvilaquarius, JerryL2017, Diggr, Okkn:. --Liuxinyu970226 (talk) 05:41, 18 August 2018 (UTC)
  • I think we already had this before, I found some at
    @Jura1: The first proposal for deletion is on the basis that the property duplicates located on street (P669), which is irrelevant here. The second only has one actually relevant comment (by Billinghurst), while the other comments are irrelevant to the topic at hand (anyone can change a property label, and there is no officially formalized process for replacing a widely-used property with another one of a different data type). The property proposal for the P969 replacement is about as bad, since the only opposes are from you (I disagree with your oppose vote, but only because qualifiers can't themselves have qualifiers) and Srittau (who wasn't aware that the property had already been unsuccessfully proposed for deletion). The other comments are complaints about the content of the data, even though it is made clear that the property has the same purpose as the old one. Jc86035 (talk) 07:12, 16 August 2018 (UTC)
  • Pictogram voting comment.svg Comment The replacement property before de deletion request? --Fralambert (talk) 17:15, 15 August 2018 (UTC)
    • The royal route would be to create a new property -> move the data -> delete the old property. Yes, this will take time, but that should be no issue. Edoderoo (talk) 19:37, 15 August 2018 (UTC)
    • Well, obviously I'm not proposing that P969 be deleted immediately if the discussion is closed as delete/replace, and the discussion has to go somewhere. Not a lot of people watch the property proposals subpages. Jc86035 (talk) 07:16, 16 August 2018 (UTC)
  • Symbol delete vote.svg Delete As said before, let's do this replacement. --Liuxinyu970226 (talk) 22:42, 15 August 2018 (UTC)
  • Pictogram voting comment.svg Comment If I understand properly, you want to create a new (multilingual) property, do the migration, then delete this property? If you will do all of this, then yes I agree. Syced (talk) 03:00, 16 August 2018 (UTC)
  • Pictogram voting comment.svg Comment Total items with P969 - 813000, items without P131 - 16700, items without P17 - 1450, items without P17 & P131 - 950. --Voll (talk) 08:28, 16 August 2018 (UTC)
    @Voll: Does the count of 950 include statements in which located at street address (P969) is used as a qualifier? I guess those would have language added based on the object/value rather than the subject/item. Jc86035 (talk) 11:30, 16 August 2018 (UTC)
    It counts only real statements, no qualifiers. I wanted to say that using P17 in the migration is better, then P131. --Voll (talk) 15:03, 16 August 2018 (UTC)
    @Voll, Jc86035: I would love to know how this property is used on items that neither have P17 nor P131, are they mis-used this as e.g. IP addresses? --Liuxinyu970226 (talk) 06:02, 18 August 2018 (UTC)
    Is it enough for the investigation?
    SELECT ?item ?itemLabel ?street
      ?item wdt:P969 ?street.
      MINUS {?item wdt:P131 ?where}.
      MINUS {?item wdt:P17 ?country}.
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
    Try it! --Voll (talk) 13:24, 19 August 2018 (UTC)
  • Pictogram voting comment.svg Comment the property is used as a qualifier outside of the the above examples, eg. to qualify births and death addresses, and to require those in multiple languages does not seem relevant, and in fact would seem detrimental to the available data if it is language particular. So maybe it useful for the major uses that you envisage, I do not see it universally advantageous where I add it. This aspect needs to be addressed as many places do not have multiple languages in place, and it appears that you are just making data addition harder. This has been raised previously, and again the proponents are not offering solutions.

    It would be useful to see reports of where the property is used as a qualifier and to see the scenarios where it would be an advantage, and where it is a disadvantageous.  — billinghurst sDrewth 06:03, 18 August 2018 (UTC)

    @billinghurst: For places of birth/death, we already have place of birth (P19) and place of death (P20) for several decades years, why they still wanna full addresses for them, to reflect what things? Using monolingual text datatype can also introduce a stable way to sync translations of addresses, at least zhwiki users always translate foreign addresses in infoboxes of place articles, nothing is hard in this topic area by translating. I also believe that the Jc86035 is helping to find solution of this stable way, and if you think digging more and more property usage is indeed on this page, feel free to ping me in any free time, as I'm online here at least 8 hours per day. --Liuxinyu970226 (talk) 06:12, 18 August 2018 (UTC)
    Truly asking that? Specific information that is regularly added to biographical articles now and in the 19thC, has been captured here as a qualifier and you are saying that it isn't pertinent? Why would ask for me to justify that? With burial data, we collect a place. Saying we ignore the cemetery? ignore the plot data?  — billinghurst sDrewth 06:25, 18 August 2018 (UTC)
    Fwiw, such informations that are about fictional things, are called as dōjin (Q1272707) in Asian countries, and how these "dojin"s are also needed here? --Liuxinyu970226 (talk) 06:35, 18 August 2018 (UTC)

Template:Vote not delete to see language it should have qualifier('s) language of work or name (P407), otherwise the language is default for local postal service. Monolingual property, instead of it is for now, would overuse the purpose of "postal address" by localizations that is not necessary in wikidata, that localisations should be done in local projects .--Avatar6 (talk) 17:32, 18 September 2018 (UTC)

@Avatar6: Please see what I said before at Wikidata:Project_chat/Archive/2018/08#P969 concern, there are really a number of Wikipedias which don't have function to query qualifiers, thus P407 can't actually work for them. --Liuxinyu970226 (talk) 04:56, 19 September 2018 (UTC)
Symbol delete vote.svg Delete This property should learn How official name works. -- 02:15, 22 September 2018 (UTC)
  • Caution Concerns similar to User:Billinghurst above. I am currently using this as a qualifier to place of publication (P291) based on catalogue records for some 18th century maps, using data from MARC field 264 in the library records. Once all the data is in, it will be valuable to be able to see and sanity-check what different addresses are given for the same person, and how these may correlate to other information in the records. I can guess that the language of that statement corresponds to the language of the work, but I can't be sure (in some cases, it may have been added by the cataloguer, for example). Jheald (talk) 16:52, 28 September 2018 (UTC)
    @Jheald: Why not just specify them as Latin (la)? --Liuxinyu970226 (talk) 04:04, 30 September 2018 (UTC)

Symbol delete vote.svg Delete I really can't agree some opinions like @Avatar6:'s "otherwise the language is default for local postal servic", Avatar6 I must tell you that the post stations in Canada always use both English and French for each place AT SAME TIME! Thus we the Canadian really wanna show the languages of addresses that a random place has. -- 23:32, 1 November 2018 (UTC)

  • Symbol delete vote.svg Delete A nonsense pure-string property, can be migrated to a translateable format, will this fall under snowball closure? -- 07:23, 24 December 2018 (UTC)
  • Symbol keep vote.svg Keep The application was to change the property type from string to monolingual-text not to delete the property itself. A bot can add the missing languages from the country property. The property is used in several wikis which means huge efforts in changing scripts and copying addresses by bots or manually. --RolandUnger (talk) 09:03, 6 January 2019 (UTC)
@RolandUnger: Then why official name (P1448) can be a monolingual text and this cannot be? -- 03:21, 8 January 2019 (UTC)
It is very simple: At the phase of application of located at street address (P969) the English-speaking contributors had no idea about this problem. We discussed the type change to monolingual text several times at Wikidata but the discussions had no effect. --RolandUnger (talk) 05:33, 8 January 2019 (UTC)
Really? At least Canadian people still have concerns against this per, where Canada is, as well as we the people around the world know, an en-fr bilingualism country. -- 01:14, 9 January 2019 (UTC)
Additionally, @RolandUnger, Avatar6: Are you both supporting the United States-only, in fact *vetoed by many other English-speaking countries*, the English-only movement (Q2719842)? If yes, then you both can strike your votes right now, because Wikidata is a Multilingualism project, not a XXX language-only project. --Liuxinyu970226 (talk) 15:36, 14 January 2019 (UTC)

analog or derivative of (P5000)[edit]

analog or derivative of (P5000): (delete | history | links | entity usage | logs | discussion)

Property represents analog (Q50824047) which is ambiguous and inaccurate and so it's incorrect from a chemistry perspective. It mixes different concepts of functional analog, structural analog, derivative and molecular similarity and some others; concepts that are neither synonymous nor similar, concepts that shouldn't be equated with each other. Problem of chemical classification is one of the most important and most challenging in WD's chemistry scope, but Wikiproject Chemistry hasn't been notified about this proposal and I found this property by accident. Fortunately, there is only one use of this property.

This property should be deleted as it's incorrect and importing data from the indicated sources can lead to addition of a huge collection of chaotic and inaccurate data. Discussion about chemical classification should be continued in Wikiproject Chemistry and such bypass solutions should not be created.

Jasper Deng
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
Devon Fyson
Samuel Clark
Tris T7
Pictogram voting comment.svg Notified participants of WikiProject Chemistry, pinging participants of the property proposal discussion: @Andrew Su, YULdigitalpreservation, Okkn, ديفيد_عادل_وهبة_خليل_2, Andrawaag, Gstupp:. —Wostr (talk) 13:21, 23 September 2018 (UTC)

  • Symbol keep vote.svg Keep I see it is useful and has no problem.The description can be improved David (talk) 14:03, 23 September 2018 (UTC)
    • Could you explain how this property is useful? Wostr (talk) 14:42, 23 September 2018 (UTC)
    • I have to ping you, David, as I would like to know the answer or some argument for keeping this property. Especially in the light of my comment of September 24 (below, the long one beginning with I'm not sure), in which I pointed out major problems with the sources that were to be used to populate this property. Wostr (talk) 20:34, 12 November 2018 (UTC)
  • I understand your concern. Do you have any plans to create more specific properties replacing this property? Or should we force this property to be used with a qualifier of object has role (P3831) (functional analog (Q25205085), structural analog (Q485014), Substrate analog (Q7632163), or Transition state analog (Q17087414))? Actually, the term "analog" is used ambiguously in molecular biology and in medicine, such as nucleic acid analogue (Q15057699) and Insulin analog (Q742283). Also, I'd like to hear what is the chemically correct relationships between 2-chlorodiazepam (Q15408412) and diazepam (Q210402), or between fexofenadine hydrochloride (Q27255526) and fexofenadine (Q415122). Regards, --Okkn (talk) 09:10, 24 September 2018 (UTC)
    • I'm not sure that properties are needed here at all. We had in Wikiproject Chemistry some initial discussions about chemical classification (e.g. here), but these discussions are not finished, as we in WP Chemistry have a lot to do before this (e.g. determining what we already have in WD and cleaning up after mass bot imports). From my POV the basic chemical classification should be based on classes of chemical compounds using instance of/subclass of (e.g. diazepam has a benzodiazepine, chloroaromatic classes; these classes are subclasses of more general classes etc.; this way diazepam and 2-chlorodiazepam are a member of the same classes). But this is my POV that has not been accepted (as any other) to be used in WD; and that's not the only option that can be present in WD. With the analogs, derivatives and so on there are IMHO too many problems: one can say that 2-chlorodiazepam is an analogue of diazepam, but there are really no clear and objective boundaries – methanol is an analog of methane? one can say that; diazepam is a structural analog of methane? some may argue that this is also true, really, I had that kind of discussions in, because we have 'derivatives' and 'similar compounds' parameteres in infoboxes...
      The problem here is also that we would have several thousands of statements imported to WD and that's it. Many users like to import data to WD, but no one likes to curate that data, no one is checking whether imported data is correct or not. And in this case it would certainly be incorrect: just look what is the purpose of 'analogs & derivatives' in MeSH: It is used when the specific chemical heading is not available and no appropriate group heading exists i.e. it is used where there is no chemical class to be used for classification, so this is a kind of a substitute property, a replacement for something that is missing right now. ChEBI 'functional parent' have more sense (A has_functional_parent B if and only if given any a, a instantiates A , has molecular graph ag and a obo: has_part some functional group fg, then there is some b such that b instantiates B, has molecular graph bg and has functional group fg’ such that bg is the result of a graph transformation process on ag resulting in the conversion of fg into fg'.), but I don't think that such relationships are needed in WD, at least not right now.
      My point is that: classification should be thoroughly discussed first and there should not be mass imports before that, because there are always people who wants to import something (no matter if this is correct or not), but there are no volunteers for cleaning this up. Wostr (talk) 14:06, 24 September 2018 (UTC)
  • I understand that a property like this makes interesting browsing, but I think it can be done differently. I agree with the point that analog and derivative are not so well defined, but my worries stems particularly from the fact that it is unbound and will lead to many links between chemical structures. I'm slightly in favor of removing. --Egon Willighagen (talk) 16:45, 25 September 2018 (UTC)
  • Symbol delete vote.svg Delete or at least rename based on a more specific relation. We already discussed the problem in WikiProject Chemistry and only relations based on a clear definition have to be used. Snipre (talk) 23:18, 7 October 2018 (UTC)

Soccerway player ID (P2369)[edit]

Soccerway player ID (P2369): (delete | history | links | entity usage | logs | discussion)

This property retrieves the same data from the same database as the Scoresway soccer person ID (P3043). When a player becomes a coach, his statistics disappear on Soccerway[21][22][23], but it still remains on Scoresway[24][25][26]. —Сидик из ПТУ (talk) 11:12, 18 October 2018 (UTC)

Commons category (P373)[edit]

Commons category (P373): (delete | history | links | entity usage | logs | discussion)

Systematically redundant property, merge with topic's main category (P910). For an item which has a direct interproject link to Commons category, this property is duplicate of the interproject link and it requires redundant maintenance work to keep the two linking forms consistent. For items which have a property topic's main category (P910), the property Commons category (P373) is redundant because the linked Commons category should be joined by an interproject link with the P910 target category. Before deletion of P373 property, all P373 data should by transformed to interproject links, either directly, or through the P910 target item. —ŠJů (talk) 15:42, 2 November 2018 (UTC)

  • Request for clarification: Wikidata went against the general consensus of Commons users by favoring gallery (main space) pages on Commons over the Category pages, which most of us on Commons consider primary. That means there are a lot of items that are sitelinked to an (often useless) Commons gallery (main space) page in preference to a meaningful Commons category.
  • If I understand correctly, your rationale is that in those cases there will always be a corresponding item on Wikidata for the category in question linked via topic's main category (P910) and that the Commons category will always be sitelinked from that item for the category, or that if it is not we can solve that with a bot before eliminating this property. Have I understood you correctly? - Jmabel (talk) 19:08, 2 November 2018 (UTC)
    @Jmabel: Generally, gallery pages never were a real equivalent of articles. The fact that both of them have no prefix at their projects doesn't mean that they have anything in common. While categories and articles should be unique for its items, one item can have more various gallery pages in one project. Commons gallery (P935) is similar to image (P18). Gallery pages should have no interproject links, such as file pages have no interwikis and no interproject links at Wikidata. Gallery pages are something like a collage image, in principle. Unique relations to item-unique pages should be linked through interproject/interwiki links, while 1:N links or links to examples or digests (selected images or galleries) should be properties.
    As long as some items have two item-pages on Wikidata (one for article pages and one for category pages), we should to keep the existing preferences: if the item have its own category on at least one Wikipedia project, the Commons category should by linked with the Wikipedia category and category item page. If the item has no category at non-Commons projects, the Commons category should be joined to the basic Wikidata item page (i.e. directly with articles of that item), unless it is blocked by Commons gallery page. In such case, we are forced to use two Wikidata item pages: first one for article and gallery pages, second one for Commons category page. --ŠJů (talk) 01:01, 3 November 2018 (UTC)
    • I agree entirely that Wikidata's preference for gallery pages is misguided, and is based on a misapprehension of their nature.
    • I think where you are headed with this is reasonable: just so long as Commons categories are understood to be the main relevant sitelink to Commons, and they won't ever be omitted entirely in favor of something else on Commons. - Jmabel (talk) 06:43, 3 November 2018 (UTC)
  • Symbol oppose vote.svg Oppose Commons category (P373) would be useless if Wikidata hadn't preferred the useless galleries over category pages. Therefore, the fix shouldn't be going through a two-step path to find the meaningful Commons category but to have it as preferred option when it comes to an interproject link. --Discasto (talk) 19:23, 2 November 2018 (UTC)
    @Discasto: There are two basal problems. The first of them is that one item has two item pages on Wikidata, in some cases. The second one is a incomprehension of character of gallery pages. You mention only the second problem, while the first problem is more urgent to be treated and compensated. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
  • Symbol keep vote.svg Keep topic's main category (P910) has a different datatype and merging would only be possible in the way described by Jmabel which isn't nice outlook. --Marsupium (talk) 21:17, 2 November 2018 (UTC)
    @Marsupium: It is rather a bug that topic's main category (P910) has a different datatype than Commons category (P373). The proposed merge can solve the bug elegantly. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
    @ŠJů: I don't think I'd consider to create ~2M – wild guess, you might want to calculate it – single-sitelink Wikimedia category (Q4167836) items to be elegant. --Marsupium (talk) 01:24, 3 November 2018 (UTC)
  • Pictogram voting comment.svg Comment I support this in the long run, but this request is probably a bit early. For background info, Pi bot (talkcontribslogs) has added hundreds of thousands of commons sitelinks over the last year, as the sitelinks are used by commons:Template:Wikidata Infobox. That was primarily based on Commons category (P373) values, but other matches have also been used (IDs and image (P18) values in particular). And as a temporary measure, the bot updates P373 values where they differ from the sitelink and they point to a commons category redirect. However, there are still quite a few P373 values that need manually resolving/the correct sitelink adding. Plus the gallery vs. category issue that Jmabel mentions above (although @Jheald: mostly fixed that by creating new category items for those cases, which are linked by topic's main category (P910)/category's main topic (P301)). And then there are all of the uses of this property outside of Wikidata ... I would however Symbol support vote.svg Support marking this property as deprecated, and resolving the remaining issues so that we can move over to using the sitelinks instead - but that will probably still take some time to accomplish. Thanks. Mike Peel (talk) 22:58, 2 November 2018 (UTC)
  • Symbol support vote.svg Support marking as deprecated and cleaning up as needed. No definite opinion on the best route to clean up, but I support the effort to reduce redundant maintenance of data. Kaldari (talk) 00:41, 3 November 2018 (UTC)
  • I don't think P373 can be deprecated as long as there's no official solution to the gallery sitelink problem. There was no consensus to prefer Commons category sitelinks to gallery links, last time I asked, and category items with only a sitelink to Commons are still prohibited by Wikidata:Notability. I'd also like to know if the Wikimedia software, when creating toolbar links in other projects, actually checks for a linked category item with a Commons sitelink. It's possible that a lot of links to Commons in other projects would be lost (or category links replaced with links to galleries). Ghouston (talk) 04:35, 3 November 2018 (UTC)
    I agree. All steps must be taken successively so that no information is lost.--ŠJů (talk) 11:18, 3 November 2018 (UTC)
    Unfortunately, the page Wikidata:Notability is completely out of reality and out of real consensus.
    • It e.g. claims that "a sitelink cannot point to a redirect" and ignores consensually existing and useful item-pages for Wikimedia disambiguation page (Q4167410).
    • It claims that "items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites" while such relations were massively, consensually and effectively used long before the start of Wikidata and there was no consensus to destroy such relations or to make them unfunctional.
    • It claims that a Wikidata item-page "contains at least one valid sitelink", while really, there was and is a consensus to import monuments from monument lists (even for monuments which have no separate page – as an analogy of the external tool Commons:Monuments database) or streets from official street registers (even for streets which have no image uploaded and no category or article created yet). (I would be glad if this note did not inspire anyone to destroy this great work.) --ŠJů (talk) 11:45, 3 November 2018 (UTC)
  • Sort of. I don't think your 3rd point is valid, since an item only needs to meet one of the 3 criteria, and the monuments can meet 2) instead of 1). For your first point, there's a footnote that says "Currently, the community has chosen to have redirects allowed, although the necessary changes have yet to be deployed on Wikidata." The second point is a problem though. I tried a while ago to change it (Wikidata_talk:Notability/Archive_4#Category_items) but there was some opposition and it just got archived without reaching consensus. Ghouston (talk) 22:38, 3 November 2018 (UTC)
  • Symbol keep vote.svg Keep Per Ghouston. Not the proper channel IMHO. Choosing how Wikidata should model its relation with Commons should not happen in a Property deletion request but... in a RFC. Additionally, I may add es.wikipedia (at least) is using P373 to fill two highly used templates. strakhov (talk) 22:31, 3 November 2018 (UTC)
  • Pictogram voting comment.svg Comment Interesting proposal, but a couple of points: (1) P373 is currently being used massively by the MediaWiki configuration on most Wikipedias to determine what sitelink to show to Commons. Re-tooling to see whether (i) there is a topic's main category (P910), (ii) with a sitelink, (iii) that goes to Commons would need to be investigated and proven first. (2) That three-step process is significantly slower for big queries than looking up a P373 -- so, for example, in WDQS it is currently possible to count the number of uses of P373; but it is not (I think) possible to count the number of sitelinks within the query time-out. (eg: query to get total number of Commons categories with sitelinks already takes 40 seconds; query to see how many of those have P910 times out). This can have implications for various sorts of maintenance queries. Jheald (talk) 10:47, 4 November 2018 (UTC)
Another long-standing issue with P373 is that there are many categories on Commons that are the target of P373 statements from more than one main-type Wikidata item. See this query for some of the most popular: Some further queries to try to identify some of the Wikidata items which may not be primary matches to the Commons category can be found here: Property_talk:P373#More_queries. The community would need to definitively think about the desirability (or not) of these multi-matches, and which one to choose, or whether to take some other action, before retiring P373. Jheald (talk) 11:39, 4 November 2018 (UTC)
  • @Multichill: fyi--- Jura 12:01, 4 November 2018 (UTC)
  • Symbol keep vote.svg Keep massive usage, not a good alternative. Multichill (talk) 12:33, 4 November 2018 (UTC)
  • Delete. I have long supported deletion of this property in favor of storing the categories with topic's main category. Let's do that and use Wikidata for the power the property provides us. Yes, we add a few million items, but we're already at 50M. We can figure out which ones are the best targets for creation if we want, or we can take them all. (I'm inclined to take them all TBH; there will be value when we get around to SDC Soon.) Let's get WD:N fixed regarding those category items while we're at it. --Izno (talk) 13:39, 4 November 2018 (UTC)
  • Symbol oppose vote.svg Oppose too soon, show me the migration plan, with some examples of a process. Slowking4 (talk) 23:55, 7 November 2018 (UTC)
  • Can we at least agree on removing all interproject links to Commons galleries, as they were never supposed to be used that way?--DarwIn (talk) 21:10, 16 December 2018 (UTC)
I would vote for that proposal. --Jarekt (talk) 03:09, 18 December 2018 (UTC)
I'm OK with removing gallery sitelinks from everywhere, after copypasting them to Commons gallery (P935). strakhov (talk) 12:58, 19 December 2018 (UTC)
If so, it would be needed to verify they are not pseudo-galleries (I mean, "redirects to categories"). In that case, they should be replaced by the category sitelink. strakhov (talk) 13:02, 19 December 2018 (UTC)
  • Symbol keep vote.svg Keep W use it a lot and for a lot of items there is no way of storing this connection in any other way, without creating massive number of additional items. --Jarekt (talk) 03:09, 18 December 2018 (UTC)
Symbol delete vote.svg Delete Used by two many items shouldn't be a keep reason, we deleted P794 (P794) before. -- 07:19, 20 December 2018 (UTC)
Symbol neutral vote.svg Neutral Before planning of deleting P373 we should find solution for cases, when one categori is linked form more items. [Wikidata:Database_reports/Complex_constraint_violations/P373#Two_category_items_linking_to_the_same_Commons_category|example 1]], "Unique_value"_violations 2. JAn Dudík (talk) 19:57, 4 January 2019 (UTC)
  • Symbol keep vote.svg Keep. Commons category is a serviceable compromise solution to the problem described above: Commons uses namespaces differently from Wikipedia, and the Wikidata community doesn't want to cross namespaces among the sitelinks of an item, nor does Wikidata wants items with a Commons category as its sole sitelink. This property sidesteps the issue and has worked for some time, so until we can agree on an alternative way to represent the relationship between a Wikipedia article topic and its relevant Commons category, we should let this property stay. Deryck Chan (talk) 14:37, 10 January 2019 (UTC)

demonym (P1549)[edit]

demonym (P1549): (delete | history | links | entity usage | logs | discussion)

I think this property could be replaced with one that links to senses (e.g. sense 1 of Kenyan (L35249)); this would be especially useful for words with lots of conjugations. I have not created a new property proposal because it would be more appropriate to have the discussion in one place.

I've already created 161 English noun lexemes which would be able to replace current uses; it would also be necessary to create equivalent items for adjectives, as well as to create the relevant senses for the noun and adjective lexemes (I've only added a sense to L35249 so far). —Jc86035 (talk) 10:33, 4 November 2018 (UTC)

Notified 94 contributors to the property and its talk page: User:Nikki User:Abián User:Jura1 User:VIGNERON User:Tubezlob User:Jheald User:Lockal User:Infovarius User:Putnik User:Laddo User:Kalogeropoulos User:Innocent bystander User:Event User:Jakec User:Vinhtantran User:MaGa User:Labant User:K175 User:Autom User:Robin van der Vliet User:Matěj Suchánek User:Janezdrilc User:Ctschiebout User:Kevin Scannell User:Maria zaos User:Horcrux User:Soued031 User:Metsavend User:Obaid Raza User:İncelemeelemani User:Pinky sl User:Andreasmperu User:Рөстәм Нурыев User:Pmt User:Gustavo Rubén User:Oriciu User:Mr. Ibrahem User:زكريا User:ToJack User:Renessaince User:Arnaugir User:MisterSynergy User:AmaryllisGardener User:Beta16 User:Mahir256 User:Спасимир User:Asierog User:Avatar6 User:Wylve User:Şêr Jc86035 (talk) 10:39, 4 November 2018 (UTC) User:Krupolskiy Anonim User:YMS User:ಶಿವಕುಮಾರ್ ನಾಯಕ್ User:Hibm98 User:GAllegre User:Epìdosis User:Jklamo User:David1010 User:SR5 User:Máté User:Ślimaczek User:HakanIST User:FocalPoint User:Allen4names User:Mbch331 User:Zygimantus User:Fnielsen User:Peppepz User:Geraki User:Supaplex User:Thierry Caro User:NMaia User:Loischantada User:ANDROBETA User:Marklar2007 User:Kikos User:Raid5 User:Doostdar User:Palapa User:Octahedron80 User:Милан Јелисавчић User:Frokor User:Rippitippi User:Conny User:Qllach User:Miguillen User:יונה בנדלאק User:Liuxinyu970226 User:桂鷺淵 User:Bjankuloski06 User:Thomas11 User:Ayack User:Чаховіч Уладзіслаў User:Александр Сигачёв Jc86035 (talk) 10:41, 4 November 2018 (UTC)

I would like to note that the property is used as label for country of citizenship (P27) at huwiki. If the property is deleted, the current data needs to be imported into the newly accepted structure, and huwiki needs to be notified to create a workaround to the new structure if possible. Ideally, the new structure should make it possible. – Máté (talk) 12:10, 4 November 2018 (UTC)

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
  • Symbol delete vote.svg Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)
  • Symbol delete vote.svg Delete The property demonym of (P6271) has been created. This one can now be deleted (first declare obsolete, move content, then delete).--Micru (talk) 17:30, 19 December 2018 (UTC)
  • Pictogram voting comment.svg Comment If this property is being used in an infobox or by a Lua module, it will need to be retained and to go on having its values added to and extended, at least and until such time as inverse property values become obtainable via Lua - as at present they are not. Jheald (talk) 18:09, 19 December 2018 (UTC)
  • Time2wait.svg On hold. I agree with Jheald that we need a place -> demonym property to keep infoboxes working. We should keep this property until we have a new Item -> Lexeme "demonym" property, migrate all existing uses and infoboxes, then delete P1549. Deryck Chan (talk) 15:52, 11 January 2019 (UTC)


attributed to (P1773): (delete | history | links | entity usage | logs | discussion)

Apparently this shouldn't be used per Wikidata:WikiProject Visual arts/Item structure#Use of creator (P170) in uncertain cases. So we might as well delete it. --- Jura 14:46, 5 November 2018 (UTC)

  • Symbol delete vote.svg Delete, but deletion is the easiest part, migration has to be done first. --Marsupium (talk) 17:25, 7 November 2018 (UTC)
  • Are we sure no other domains are using it besides art? I would like to first complete the migration to the new model. I don't think that can be done fully automatic because it needs a bit of checking and sourcing. When the property is no longer in use it can probably be deleted. Multichill (talk) 12:35, 10 November 2018 (UTC)
  • @Trivialist: This guy usually use this, let's ask him? --Liuxinyu970226 (talk) 15:09, 20 November 2018 (UTC)
  • Symbol keep vote.svg Keep I think it is very important! I use it frequently for literary works - literary work (Q7725634). It is necessary for many ancient & medieval works. I even built a template in Hebrew Wikisource that uses it. שילוני (talk) 22:07, 22 November 2018 (UTC)
  • Symbol keep vote.svg Keep but add a constraint to written works. Standards for visual and written works are different here. Circeus (talk) 03:27, 23 December 2018 (UTC)

participant of (P1344)[edit]

participant of (P1344): (delete | history | links | entity usage | logs | discussion)

Is an inverse statement really necessary? It seems to contain a lot of duplicate data. Alternatively, participant (P710) should be removed. —U+1F360 (talk) 16:42, 10 November 2018 (UTC)

There may be situations where one or the other is useful as a qualifier. I agree that it's an unfortunate duplication when they are used directly in statements and are redundant inverses. Perhaps participant (P710) could be marked for use in qualifiers only. Ghouston (talk) 00:50, 11 November 2018 (UTC)
  • Clear Symbol keep vote.svg Keep. This property is predominantly used as main value in the field of sportspersons. For sportpersons, this property including its qualifiers is the place to look at when filling an infobox with their participations/successes in Wikipedia. It would be very difficult to retrieve all this information from somewhere else, as we cannot use queries while building infoboxes; the same more or less holds for the inverse participant (P710) (and participating team (P1923)). —MisterSynergy (talk) 07:05, 11 November 2018 (UTC)
    • The inverse thing is unfortunate. When querying data, you'd actually need to run the query in both directions and merge the results, since the inverses are often missing. Some properties, like employer (P108), exist without inverses, and isn't participant of (P1344) similar to that? Ghouston (talk) 22:07, 12 November 2018 (UTC)
      • I don’t care about the inverse character of the property, I just want to have this property kept for use in infoboxes. Together with participating team (P1923) and participant (P710) it forms kind of a triangle which can’t fully inverse all statements anyway. —MisterSynergy (talk) 12:28, 13 November 2018 (UTC)
  • Abstain: I'd favour not storing inverse data, in general, but we need a project-wide policy on when and when not to do so, rather than case-by-case deletion proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 13 November 2018 (UTC)
  • Comment: I've just replaced P1441 by P1344. Nothing is wrong with P1344, sadly bots can't decide which "inverse of P710 or P1923" has to be used if it is missingeven bots can figure out human vs. team. – 01:37, 30 December 2018 (UTC) (updated inspired by a Project chat. – 01:07, 4 January 2019 (UTC))
  • Symbol keep vote.svg Keep both. One serves infoboxes about people; the other serves infoboxes about events. While these properties are inverses of each other in terms of truth value, the two statements may have different ranks (e.g. a competition is important to a particular player, but the player isn't super-important for that competition). Deryck Chan (talk) 15:54, 11 January 2019 (UTC)

NSZL name authority ID (P3133)[edit]

NSZL name authority ID (P3133): (delete | history | links | entity usage | logs | discussion)

The Hungarian Szechenyi Könyvtár has the maintenance this database closed. You find no any data on this links not now and not in the future. —Texaner (talk) 08:59, 13 November 2018 (UTC)

The data is still available via the Wayback Machine (example) and so I have updated the formatter URL accordingly; but for just 36 IDs, it is probably not worth keeping. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 13 November 2018 (UTC)
Hi, I have checked after you changes the Wayback Machine, but there also no any links. This seems to be a really dead thing. Texaner (talk) 15:50, 13 November 2018 (UTC)
VIAF has these IDs stored (HuBpOSK), so we can still potentially add these IDs and use the Wayback link. – Máté (talk) 12:38, 13 November 2018 (UTC)

GINCO ID (P3905)[edit]

GINCO ID (P3905): (delete | history | links | entity usage | logs | discussion)

This property is covered by Thésaurus de la désignation des objets mobiliers ID (P4979) and Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980) and I think it is better to have those seperate. —Lymantria (talk) 13:19, 19 November 2018 (UTC)

@Zolo, Shonagon, VIGNERON, Pigsonthewing, Gzen92, ChristianKl: Pinging those involved in the discussion on the property proposal of GINCO ID (P3905). Lymantria (talk) 12:06, 10 December 2018 (UTC)

  • @Lymantria: could we have some more in-depth explanations? I think it's better to have one property for one database on one website. Just because this database has subparts means we need to have differents property (see. IMDb ID (P345) for an other example of a database with subparts). Plus, if we would use Thésaurus de la désignation des objets mobiliers ID (P4979) and Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980), then some fixing seems to be needed (I fixed the formatter URL (P1630) already). Also @Ayack: who did the proposal for P4979 and P4980 (who were accepted with only 2 votes each). Cheers, VIGNERON (talk) 12:49, 10 December 2018 (UTC)
    • The main reason I think that it is better to have two seperate properties, is that for instance balcony (Q170552) has an entry in both and now yields a constraint violation for GINCO ID (P3905). Lymantria (talk) 13:11, 10 December 2018 (UTC)
      • Oh, good point, thanks Lymantria. Is there a lot of case like that? by design, there should be few so they could easily be dealt with exceptions on the constraint (like I did Special:Diff/809146141), but if there is a lot (more than 10% of the total?) then indeed we should maybe have separate properties. @Ayack: signaled me that there is indeed a problem with the identifiers for P4979 and P4980 (what I thought was a fix caused some problems…), does someone has more informations (or even better specifications) on how this database(s) works? Cdlt, VIGNERON (talk) 15:06, 10 December 2018 (UTC)
        • I have not really investigated if there are many of those cases, but I assume less than 10%. Still, the property now combines two thesauruses, which I think is not wise. Lymantria (talk) 17:34, 10 December 2018 (UTC)
  • Pictogram voting comment.svg Comment based on the explanations given, I'd delete either the above or the two other ones. --- Jura 06:14, 20 December 2018 (UTC)

translation (P5972)[edit]

translation (P5972): (delete | history | links | entity usage | logs | discussion)

@Tubezlob, Denny, Micru, Infovarius, Runner1928, Duesentrieb: @Sintakso, Jura1, Deryck Chan, Mfilot, TomT0m, ArthurPSmith:@Njardarlogar, Liamjamesperritt, fnielsen, Jc86035, Rua:

translation (P5972) requires every sense to be linked to every other sense with the same meaning. It scales very badly and it's difficult to maintain. Using item for this sense (P5137) is better because every sense needs only a link to the Q-item that represents its meaning.

The two objections to this approach are:

  • it will create items whose meanings are only slightly different because some senses differ only in nuances;
  • it will create items for verbs, adverbs, prepositions and adjectives.

IMO, the latter is not a problem because we already have adjectives (Orwellian (Q2156379)) and verbs (google (Q1156923). As regards prepositions, they are very few.

Previous similar discussions:

--Malore (talk) 05:04, 14 December 2018 (UTC)

  • Before we can limit its scope, the community still needs to decide whether adding thousands of Senses to the Main namespace is a good idea. I believe it is an important direction to move towards, but there is yet to be any consensus on the issue. Liamjamesperritt (talk) 21:16, 15 December 2018 (UTC)
  • BA candidate.svg Weak oppose. I agree with Jura and Denny here. Translations aren't necessarily symmetric so linking to an item doesn't automatically solve all our problems. I see this as the centralized equivalent of the translation table on Wiktionary. Storing these in the Sense entry may make it unwieldy in Wikidata view, but seems to be what Wiktionary requires. Deryck Chan (talk) 10:31, 14 December 2018 (UTC)
    It’s not necessarily an easy task, but the fact that translations differs just a little bit is also an opportunity to describe the relationship between them by statements. author  TomT0m / talk page 10:37, 14 December 2018 (UTC)
    @Deryck Chan: To me it seems unnecessary to think of this in terms of translation. I think sense entities (i.e. items in the existing main namespace or in a dedicated sense namespace) can handle this perfectly if we leave minimal room for ambiguity. That is, if two languages have slightly different concepts for the colour blue, we create two separate sense entities for these two concepts and mark one as a subset of the other, or both as overlapping - whichever is correct.
    An important property of this implementation is that it is up to the user that queries for translations what counts as a "translation": should the translated word be a virtually exact match (i.e. uses the same sense entity), could the word have a broader or narrower meaning, and could it have an overlapping meaning? --Njardarlogar (talk) 11:53, 14 December 2018 (UTC)
    @Jura1, Denny, Deryck Chan: The current description says word in another language that corresponds exactly to this meaning of the lexeme. "corresponds exactly" suggests that the property is symmetrical.--Malore (talk) 17:48, 14 December 2018 (UTC)
    Change to Symbol neutral vote.svg Neutral. It seems that this property is (badly) trying to solve a different problem as what I expect it to solve. Maybe we need to wait till Wiktionary can transclude Lexemes and then figure this out. Deryck Chan (talk) 22:41, 14 December 2018 (UTC)
  • My view is - I think we need translation (P5972) for now, but it should be reserved for cases that can't obviously be handled by item for this sense (P5137), and we should be actively figuring out how to migrate all uses of the first property to the second in some manner... ArthurPSmith (talk) 13:52, 14 December 2018 (UTC)
  • Symbol oppose vote.svg Oppose I think in current shape of lexemes we need it, but use it only where item for this sense (P5137) does not work. KaMan (talk) 16:07, 16 December 2018 (UTC)

e-mail (P968)[edit]

e-mail (P968): (delete | history | links | entity usage | logs | discussion)

Change data type to string. According to this RFC, this property can't be used correctly in it.voy as they want to show the email with a link to mailto: URI and you can't do [mailto:EMAILADDRESS EMAILADDRESS] right now. —Micru (talk) 18:37, 26 December 2018 (UTC)

Symbol oppose vote.svg Oppose - We shouldn't change the datatype here because 1 re-user (it.voy) can't handle the default output. In this case it.voy should adapt their module:wikidata so it does render the output they want. For some projects other properties may be hard to handle because of their current datatype if they use the data as outputted by default. If the data output doesn't suit you, you need to make a script/module (or ask for help with a script/module) so it renders the way you want. Mbch331 (talk) 14:39, 27 December 2018 (UTC)
  • Pictogram voting comment.svg Comment the it.voy usage aside, I think it's just plainly redundant. Using a string with the formatter URL mailto:$1 seems a much more logical choice. phone number (P1329) does it that way already. Lewis Hulbert (talk) 19:30, 4 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose - The property is used in many wikis. To change this means a comparatively high effort. It is very simple to remove mailto: from the string. --RolandUnger (talk) 08:54, 6 January 2019 (UTC)
  • Symbol support vote.svg Support I support changing the datatype, but we should likely first create a new one, copy over the values and then slowly deprecate the old one.
It will be easier to enter data when the user doesn't have to write mailto: in front of every email address and making it easier to enter data is valuable. ChristianKl❫ 10:11, 6 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose - It is not a big deal to make [mailto:email email]. I don't know which tool are you retrieving the email from Wikidata, in my following example, I use Módule:WikidataIB:
{{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}} →
[{{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}} {{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}}]
And you can use some subst's as well. Sorry for the long coding. Ederporto (talk) 16:12, 6 January 2019 (UTC)
@Ederporto: I'm so sorry, but this format can't work if a wiki has wiki with script conversion (Q36509592) support, in that case, your example will wrongly shown as "man-{@}", where @ is enclosed by "-{}-". --Liuxinyu970226 (talk) 01:38, 12 January 2019 (UTC)
@Liuxinyu970226: Wouldn't {{#invoke:String|replace|source=man-{@}|pattern=-{@}-|replace=@}} solve it? Ederporto (talk) 14:52, 12 January 2019 (UTC)

The Guardian article ID (P6085)[edit]

The Guardian article ID (P6085): (delete | history | links | entity usage | logs | discussion)

Per ChristianKl and Dominic's comments at Wikidata:Property proposal/New York Times short URL, it might be better to either have a single property for unique short URLs, or to not have any special properties for short URLs at all. The property has, regardless, not seen any adoption aside from the three example values that I used in the property proposal form, so deleting it would not currently result in any significant loss of data. —Jc86035 (talk) 13:19, 7 January 2019 (UTC)

Notifying the other property proposal participants: Germartin1, Visite fortuitement prolongée, ArthurPSmith, MartinPoulter, eru, Pigsonthewing, Thierry Caro. Jc86035 (talk) 13:22, 7 January 2019 (UTC)

No strong feelings on this. ArthurPSmith (talk) 15:18, 8 January 2019 (UTC)
(Note: I created both property proposals. I forgot to mention this.) Jc86035 (talk) 17:22, 8 January 2019 (UTC)


female form of label (P2521): (delete | history | links | entity usage | logs | discussion)

Given that we now have Lexemes, there's no good reason to store this information in the item namespace ChristianKl❫ 12:59, 14 January 2019 (UTC)

  • Symbol oppose vote.svg Oppose Until an alternative is proposed (which should be a requirement when proposing a deletion). As far as I know, this property is currently being used at least in the French Wikipedia, so it would be a good idea to start with understanding the rational of the property creation. Going in that direction, maybe @Jura1: could elaborate on that in order to move forward. Andreasm háblame / just talk to me 13:58, 15 January 2019 (UTC)
Symbol delete vote.svg Delete The frwiki usage should be modified, they should query Lexemes. --2409:8902:9301:B6A9:5CB3:E6FD:4195:E1F7 04:48, 16 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose Eventually maybe but there's no replacement now. Data access to lexemes is not possible yet. The same applies to demonym (P1549). Matěj Suchánek (talk) 08:41, 16 January 2019 (UTC)


male form of label (P3321): (delete | history | links | entity usage | logs | discussion)

Per #Property:P2521 above, given that we now have Lexemes, we should also drop this property to just say "male form", but no other infos. --Liuxinyu970226 (talk) 15:06, 14 January 2019 (UTC)