Wikidata:Properties for deletion/Archive/2020

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Property:P3722

P3722 (P3722): (delete | history | links | entity usage | logs)

All values have now been migrated over to its replacement property, category for maps (P7867) - for background, see Wikidata:Property proposal/Commons map category V2. Thanks. Mike Peel (talk) 11:12, 1 February 2020 (UTC)

@Mike Peel, Tinker Bell: Please start the discussion here before marking the property as obsolete and migrating values. Otherwise this page will become a farce. --Pasleim (talk) 14:39, 1 February 2020 (UTC)
@Pasleim: Sorry, did I get the process for this wrong? I though the way to do this was to propose a new property first, and then bring the old one to this page later. Thanks. Mike Peel (talk) 14:46, 1 February 2020 (UTC)
If everything has already been decided elsewhere, you can request deletion on WD:AN right away. This page here is to discuss whether or not to delete a property. But to have such a discussion about a property that is already marked as obsolete is pointless. --Pasleim (talk) 15:20, 1 February 2020 (UTC)
@Mike Peel: I've requested its deletion at Administrators Noticeboard. --Tinker Bell ★ ♥ 17:12, 19 March 2020 (UTC)
✓ Deleted --DannyS712 (talk) 18:20, 19 March 2020 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 06:30, 31 March 2020 (UTC)

Property:P598

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) 12:37, 14 April 2020 (UTC)

commander of (DEPRECATED) (P598): (delete | history | links | entity usage | logs | discussion)

Seems redundant with position held (P39). Wouldn't P39 commanding officer (Q11247470) statements (with qualifier of (P642)) suffice? —Nomen ad hoc (talk) 09:09, 7 September 2019 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:37, 14 April 2020 (UTC)

Property:P6433

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) 12:41, 14 April 2020 (UTC)

Global Species ID (P6433): (delete | history | links | entity usage | logs | discussion)

All links yield "global species has been shutdown" —Lymantria (talk) 08:36, 11 September 2019 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:41, 14 April 2020 (UTC)

P7478 (P7478)

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) 12:46, 14 April 2020 (UTC)

P7478 (P7478): (delete | history | links | entity usage | logs)

The property was created in a premature state where it didn't even had a property description. While the property description might be fixable, the data type isn't and there's no case made in the property discussion why the property should be created as a string property and not an item property the way properties like Filmiroda rating (P2747), ClassInd rating (P3216) or CERO rating (P853) are designed. —ChristianKl ❪✉❫ 12:18, 30 October 2019 (UTC)

I didn't propose the string datatype. I think item makes more sense as it allows us to store information about what a given rating means (and which we do in other rating properties).ChristianKl ❪✉❫ 07:57, 5 November 2019 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:46, 14 April 2020 (UTC)

Property:P7777

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 consensus to keep as examples provided shows the difference between two. ‐‐1997kB (talk) 15:16, 29 April 2020 (UTC)

AdoroCinema film ID (P7777): (delete | history | links | entity usage | logs | discussion)

Dup of AlloCiné film ID (P1265) --- Jura 10:44, 20 January 2020 (UTC)

WikiProject Movies has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. —Eihel (talk) 09:17, 23 January 2020 (UTC)

  •  Keep and  Not OK with this request. Uh no, it's not a duplicate of Allociné, it's another language. AdoroCinema is a collaborative site. This does not remind you of anything, a collaborative site in another language: we are not going to say that fr.wikipedia.org must be deleted because it is a duplicate of en.wikipedia.org. I just created this property 20 days ago; the proposal had the support of the community by 8 votes (no opposition and additional support after creation). If Jura1 didn't want this property, he could vote, but with better reason. Jura1 is in a hurry to create properties and delete others, why ?! Best regards. —Eihel (talk) 09:12, 23 January 2020 (UTC)
    • The idea of property proposals is to discuss the proposal, review various aspects and build a consensus on that. The aspect was raised in the discussion, but the discussion was cut off before a consensus could emerge on that aspect. Unfortunately, I didn't get to comment on the proposal.
Personally, I added these identifiers with P1265. As there is no use of adding the same identifier twice hence this request.
--- Jura 09:23, 23 January 2020 (UTC)
  • What is the difference between information on AdoroCinema and information on Allociné, besides the language? Mbch331 (talk) 09:30, 23 January 2020 (UTC)
    @Mbch331: There remain differences inherent in the countries represented by these 2 sites which I quote below: dubbing, distribution, character name in the language and maybe others. —Eihel (talk) 01:35, 28 January 2020 (UTC)
  •  Delete Just compare http://www.adorocinema.com/filmes/filme-2166/ and http://www.allocine.fr/film/fichefilm_gen_cfilm=2166.html. Same database, same identifier, just translation. Note that adorocinema is already set up as formatter URL (P1630) with language of work or name (P407) at AlloCiné film ID (P1265). Having different property for each language version of same database is not a good idea.--Jklamo (talk) 09:31, 23 January 2020 (UTC)
    A little clarification for everyone. Albert Einstein's page on enwiki probably has about the same information as on frwiki. This means that it is a unique identifier (Albert Einstein). Let's also delete this page on enwiki, it's redundant! Do not Portuguese or Brazilians have the right to have information in their language, whether it is the same identifier or similar information? I have no link with these sites. It is not only a translation: there are differences by Internet users, press reviews, spectator reviews, media, posters in the language, etc. The 2 links on Farenheit 451 are not exactly the same, sorry Jklamo. Cordially. —Eihel (talk) 10:08, 23 January 2020 (UTC)
    sitelinks to Wikipedia are based on MediaWiki page title (Q83336425). These are different for every language.
    Maybe a better comparison could be Wiktionary .. sitelinks there are automatically generated for all languages. --- Jura 10:04, 23 January 2020 (UTC)
    @Eihel: « The 2 links on Farenheit 451 are not exactly the same » indeed but what Wikidata stores *is* exactly the same. If the identifier is the same everytime then there is no reason to have 2 properties (or more). Cdlt, VIGNERON (talk) 10:17, 23 January 2020 (UTC)
    @VIGNERON: There are many other properties that store the same identifiers on Wikidata (still recently), but with different content. I just cited differences in content, but it is not for us to judge the use of identifiers from third-party sites. The bulk may be copied to all Webedia sites (Filmstarts, etc.), but other additions are independent, specially made for language. —Eihel (talk) 11:00, 23 January 2020 (UTC)
    Webedia offers information that the 2 sites do not share. I just watched 3 movies. Apart from the title and the poster of course, I found differences on name of the character role (P4633), on voice actor (P725) or on distributed by (P750). —Eihel (talk) 14:25, 23 January 2020 (UTC)
    @Eihel: is there? I know no properties that are exact duplicate, out of curiosity: could you give an example? Content is not really relevant, we don't store the content, just linking to it. As I said before, the question is very simple: is there a difference in the identifier? If yes, then  Keep if no then  Delete. Cheers, VIGNERON (talk) 11:20, 23 January 2020 (UTC)
  •  Neutral two different websites in different languages but indeed AdoroCinema database seems to be a copy of AlloCiné database. The, the important question here is: is it a full copy and only a mirror or is there differents identifier between the two? Like identifiers in one database and not the other (and to what extent) that would justify to keep both properties (just like we have Mérimée ID (P380) and Gertrude ID (P1529) for instance), all other questiosn is irrelevant or at least secundary. Cheers, VIGNERON (talk) 10:10, 23 January 2020 (UTC)
  • Well, hard to say... Most of references are both identical indeed. However, some films on AlloCiné are not listed on AdoroCinema (for instance some French short films). I dont' know if the opposite is true, maybe we should check if films released only in Brazil are also present on AlloCiné or not (I don't have any title in mind for now, but I'll try to think about it.). --- ʂɤɲ ✉ 10:33, 28 January 2020 (UTC)
    Can you link the French examples you found as well please ? V!v£ l@ Rosière /Murmurer…/ 10:54, 31 January 2020 (UTC)
    Hi @Vive la Rosière: Hi!
    Sure! Here are some examples of titles that are not listed on AdoroCinema:
    # BoOzy’ OS and the Cristal Gem (Q17622139), on AlloCiné here;
    # Sigma, on AlloCiné here;
    # Monstrus Circus, on AlloCiné here.
    And so on. The list is long, I could give you tons of other examples. Additionally, please note that directors for those movies are not listed on AdoroCinema as well, contrary to Allociné. But here is a detail that could be important: these examples are only small works (short or middle-length films that were not internationally released).
    Conversely, it would be wise to check whether exclusively brazilian films that are listed on AdoroCinema, are also present on Allociné or not. Unfortunately, I don't have any title in mind. For short films, I think the answer is no: unless I'm mistaken, I cannot find a short films section on AdoroCinema.
    Hope this helps Smile
    --- ʂɤɲ ✉ 14:25, 31 January 2020 (UTC)
    Thanks a lot, it is. And here the proof that AdoroCinema have their own unique movie ID too. Ed Mort (Q10270125) a brasilian movie title Ed Mort long-lenght but seems not internationally released. It has a page on AdoroCinema here but the ID used give an Error 404 on AlloCiné. So I join the advice of Liuxinyu, we should keep AdoroCinema property. V!v£ l@ Rosière /Murmurer…/ 17:26, 31 January 2020 (UTC)
    Great job! I'm convinced we should  Keep it now. A funny fact is that the director of Ed Mort (Q10270125) (Alain Fresnot (Q9593668)) is French (and lives in Brazil). We find him both on AlloCiné and AdoroCinema, but his filmography is really much important on AdoroCinema (those films are therefore other examples) Clin d'œil
    --- ʂɤɲ ✉ 21:30, 31 January 2020 (UTC)
  • I would rather say  Keep, if some films can be queried by one source, but not another, then this one source has benefit to keep separately. --Liuxinyu970226 (talk) 01:24, 29 January 2020 (UTC)
  •  Delete merge with AlloCiné film ID (P1265) and add AdoroCinema title as alias if the difference is only movies content's side and all IDs are sames since it's means it's the same database and so the same concept, both sites could be use as source. Language isn't relevant here, since ID is canonical and can be use in both site indistinctly (the purpose of WikiData).
     Delete if some movies are only missing from AdoroCinema site, keep merging with P1265 but add a flag like AdoroCinema=yes/no (to include their site or no during query) because it's means the database is duplicated and then parsed from AlloCiné. So IDs are the same but only somes results are omitted by AdoroCinema site, so here again no need nor purpose to duplicate the IDs imho.
    But  Keep if the situation like "some movies are presents in one site but not the other" occures in both sites then, yes I agree with Liu because it means that even if the database was widely dumped from AlloCiné then AdoroCinema somehow customized it (and not just parsed it like just above but add some custom IDs). We must list separately then, since some IDs can be only found on one-side from the two-site, with the possibility in distant future that same IDs refers to different results on the two sites since the database may differ. V!v£ l@ Rosière /Murmurer…/ 10:54, 31 January 2020 (UTC)
    The scenario n°3 is tested and confirmed by links provided by WikiSyn, Eihel and me, both sites have their own unique movie entries. Maybe we should contact them both in order to know if they follow a common ID's creation politics, in that case only we could merge. But at the moment we should keep the property. V!v£ l@ Rosière /Murmurer…/ 17:26, 31 January 2020 (UTC)
  • Hello @Jura1, Mbch331, Jklamo, WikiSyn, Liuxinyu970226, Vive la Rosière:,
Contrary to what VIGNERON writes, if identifiers are identical, but there are differences in content, a property can be kept, in the idea of the propagation of knowledge, the key word of WM. There is nothing in the rules that talk about identical IDs. To reassure everyone, there are also titles specific to Adoro that are not present in Allociné, examples:
and many others… But to satisfy VIGNERON, there is The Boy and the World (Q16246692) :
So the two sites are different. Cordially. —Eihel (talk) 17:08, 31 January 2020 (UTC)
[Edition conflict] Thanks, I found out the same, so I change my votes, we must kept the property. V!v£ l@ Rosière /Murmurer…/ 17:26, 31 January 2020 (UTC)
 Keep Apparently there are differences between the two and the identifier isn't always the same at the two sites. Mbch331 (talk) 18:06, 31 January 2020 (UTC)
Oui. Et j'espère qu'on recommencera pas le même… cinéma avec SensaCine, Beyazperde ou Filmstarts Sorry, it sounds better in French. —Eihel (talk) 20:08, 31 January 2020 (UTC)
  •  Comment A little parenthesis: If a single piece of information, for example the director, is complementary to the other site, a property can be deleted by adding item-requires-statement constraint (Q21503247) on the property still in production. But it is not the case here. —Eihel (talk) 13:46, 30 March 2020 (UTC)
  •  Question Hello, @VIGNERON:. Jklamo and Jura1 haven't changed their vote on the facts given in the last lines. Before I close this request on P7777 in Keep (after 2 months : 2d 5k 1n), would you like to give another opinion for proven proof that it is not a "Dup of P1265"? Cordially. —Eihel (talk) 02:37, 31 March 2020 (UTC)
  •  Question do we know something about the differences between the two? Is it just a random film or are there systematic differences? In the first case, it's sufficient to add this to the identifier statement. There are also differences between Wikidata and Wikidata Query Server for the same QID, but I don't think anybody would use different identifiers for that. --- Jura 04:34, 31 March 2020 (UTC)
    Jura, Each site hosts many indigenous films, as I wrote. nb. Notify the user who originally proposed the property and the property creator for it on their respective talk pages. —Eihel (talk) 09:23, 31 March 2020 (UTC)
    Let's double-check that. --- Jura 11:54, 4 April 2020 (UTC)
    Hello Jura1, I don't understand your last intervention. What do you want to double-check? It had been 2 months of presence, I notified the project concerned and the voters, no more movement was noticeable, I also contacted the neutral voter for a change of position. You had a questioning before the closing of discussion to which you received a reply. In short, the opinions are frozen and the observation is the conservation of this property by 5 votes to 2. Your opposition has been recorded. Now, it is time to close this request as I did, without deletion. Here I notify a sysop-participant, Mbch331, to check if what I note makes sense and maybe see with his community what it is worth doing. Cordially. —Eihel (talk) 18:48, 6 April 2020 (UTC)
    We need to double-check if there is actually a difference. I'm not really comfortable with you saying this or that, nor closing deletion requests for properties you created yourself. --- Jura 08:06, 10 April 2020 (UTC)
    Hello Jura1,
    For these sites, the differences still exist. The examples given above still work. You could check it yourself instead of blocking the inevitable. The goal is not to save my creation, but to simply follow the opinion of the community. Wouldn't it rather be you who want to keep your proposal for deletion that will not succeed? As I wrote, the situation has been frozen for a long time, the opinion of the community has been given: 2 delete, 5 keep, 1 neutral. As stated in the header: If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard, I ask the administrators to decide on this proposal and to close it, one way or the other, here. Best regards. —Eihel (talk) 13:33, 28 April 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. —Eihel (talk) 19:49, 29 April 2020 (UTC)

iHeart artist ID (P7317)

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) 09:36, 30 April 2020 (UTC)

iHeart artist ID (P7317): (delete | history | links | entity usage | logs | discussion)

The site doesn't seem to have any information on artists any more, under this or another id, instead any of these pages redirects to https://www.iheart.com/podcast/ —Andre Engels (talk) 12:07, 10 January 2020 (UTC)

Seems like @Trivialist: does not want me to redirect the formatter URL to the internet archive. --Trade (talk) 00:51, 11 February 2020 (UTC)
  • The site is working the same as it always has for me. I'm not sure where you all are located, but maybe there's some geoblocking going on? Trivialist (talk) 01:22, 11 February 2020 (UTC)
  •  Keep Value still works for me leading to a page for the artist with list of songs, albums, similar artists, bio, etc. I am USA based if this could be a geo thing as to why others aren't seeing the same page. Jeanjung212 (talk) 06:08, 30 March 2020 (UTC)
  •  Comment 1) Could you give me ALL the archives concerning ALL the Items containing this property, please? 2) Wikidata is only made for the United States, because with me, it doesn't work? I find it difficult to understand all these opinions. —Eihel (talk) 13:19, 30 March 2020 (UTC)
  • I wonder, what should I say? All the three keep votes above are claiming things like "hey there are archive.org archive records of these identifiers." Are there any professors of archive.org can tell me if there are archives of P7317 values or not? --Liuxinyu970226 (talk) 06:39, 31 March 2020 (UTC)
    @Liuxinyu970226, Jeanjung212, Trivialist, Trade: I have not tried with a proxy, since it does not interest WD. My last comment in 2 points was purely rhetorical. Archives exist if someone creates them, QED. Out of more than 300 IDs, if 100 IDs remain, it's miraculous. As a reminder, 100 IDs is the threshold for creating a property. The artist pages on this site are updated with each news (Latest Release, Top Songs, Albums, article, etc.). So the archives are useless (new archive on a new date and change of ID). In addition, IDs on the archive can be of the form \d* or preceded by the artist name and a dash. Since the site doesn't want to share these pages, they no longer concern WD. Contributors who want to have this property because they see the pages can fork WD. Conservation votes are irrelevant. For others, important changes should be discussed beforehand. Txs. Cordially. —Eihel (talk) 08:49, 31 March 2020 (UTC)
    • The site *is* accessible, without using proxies, to a large number of users, so I don’t see why the property should be deleted. Surely there are other properties that link to things that aren’t available to everyone, like sites behind paywalls or requiring membership. Trivialist (talk) 11:05, 31 March 2020 (UTC)
      @Trivialist: A little doubted, because I recently visited that site, and at same time I ran the Wireshark software, the console of Wireshark told me that I have met 3 times of 403 redirects and a 421 misdirected request, no idea why an "accessible" website can result those on my Wireshark, bug? --Liuxinyu970226 (talk) 04:58, 6 April 2020 (UTC)
      @Liuxinyu970226: If you access the site from outside of North America, you are redirected to their podcasts page. I am guessing that is why you and others have been getting errors. Trivialist (talk) 20:59, 6 April 2020 (UTC)
    proxy = *rest of the world (Q61029267)* —Eihel (talk) 01:23, 8 April 2020 (UTC)
  •  Keep (just realized that I never actually voted). Site is still accessible and useful to a large number of users. Trivialist (talk) 11:07, 31 March 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 09:36, 30 April 2020 (UTC)

Scoresway ice hockey person ID (archived) (P6064)

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) 09:27, 30 April 2020 (UTC)

Scoresway ice hockey person ID (archived) (P6064): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as scoresway.com is defunct. I already removed the few usages it had. Pelmeen10 (talk) 12:36, 2 April 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 09:27, 30 April 2020 (UTC)

Scoresway baseball person ID (archived) (P6062)

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) 09:29, 30 April 2020 (UTC)

Scoresway baseball person ID (archived) (P6062): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as scoresway.com is defunct. I already removed the few usages it had. Pelmeen10 (talk) 12:36, 2 April 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 09:29, 30 April 2020 (UTC)

Scoresway basketball person ID (archived) (P6063)

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.

Property kept: The only reason to delete that has been provided has been addressed, and there is no consensus to delete. --Kostas20142 (talk) 10:16, 22 April 2020 (UTC)

Scoresway basketball person ID (archived) (P6063): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as scoresway.com is defunct. Pelmeen10 (talk) 19:56, 2 April 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 09:30, 30 April 2020 (UTC)

P8154 (P8154)

I recently created this with the wrond datatype. Thierry Caro (talk) 16:34, 29 April 2020 (UTC)

✓ Done. --Epìdosis 07:43, 30 April 2020 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 09:32, 30 April 2020 (UTC)

Property:P1016

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 --Kostas20142 (talk) 10:38, 5 May 2020 (UTC)

asteroid taxonomy (P1016): (delete | history | links | entity usage | logs | discussion)

Too specific; may be replaced with determination method (P459). GZWDer (talk) 18:05, 6 January 2020 (UTC)

Notified participants of WikiProject Astronomy --Liuxinyu970226 (talk) 05:27, 7 January 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 04:52, 6 May 2020 (UTC)

P727 (P727)

P727 (P727): (delete | history | links | entity usage | logs)

The property has already been proposed for deletion here. Multichill took care of the deletion. However, Property_talk:P727 remains. I talked about it on User_talk:Multichill#Property:P727, but got no response. I repeat what I wrote to him: Why does this page remain? With Recoin, the display is bizarre: the property is displayed, but without Label. Is there any use in keeping this page? —Eihel (talk) 04:39, 18 May 2020 (UTC)

Notification of participants in the old discussion : @GZWDer, ArthurPSmith, Liuxinyu970226, Michael FV, Jura1, DannyS712: and @Epìdosis, Mike Peel, Multichill: —Eihel (talk) 04:52, 18 May 2020 (UTC)

✓ Deleted the talk page --DannyS712 (talk) 05:00, 18 May 2020 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Eihel (talk) 10:22, 18 May 2020 (UTC)

Property:P8252

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) 11:13, 19 August 2020 (UTC)

P8252 (P8252): (delete | history | links | entity usage | logs)

This property was created last week as a result of this proposal. Unfortunately it was created with "string" datatype, rather than "item". Using strings for commons category links has several significant drawbacks compared to sitelinks through a category item: in particular, it's not possible to access the Wikidata item back from the Commons category, and it does not automatically update when the category is renamed. This is why category for people born here (P1464), category for pictures taken with equipment (P2033), category for recipients of this award (P2517), category for the interior of the item (P7561), category for ship name (P7782) and category for maps (P7867) are all "item" datatype, linking to items like Category:Maps of Berlin (Q15143387).

I think we need a replacement property that is of "item" format; I am happy to bot-migrate existing cases over to category items so we don't lose any data, in the same way that I did for category for maps (P7867). I apologise for not noticing the property proposal here. Pinging those involved in the property discussion: @Dominic, Jheald, Arbnos, Kwj2772, Ahmad252, Dispe: Thanks. Mike Peel (talk) 19:00, 28 May 2020 (UTC)

If this is really better to use item instead of string, I guess one should also "convert" Commons category (P373). Pamputt (talk) 20:18, 28 May 2020 (UTC)
@Pamputt: See Wikidata:Properties_for_deletion#Property:P373 above... The equivalent to link to category items there is topic's main category (P910), although category sitelinks also go in the topic items unless there is an existing category item or a gallery. Thanks. Mike Peel (talk) 20:21, 28 May 2020 (UTC)
As you can see from the proposal, I modeled this on P373, which I did not realize was controversial. Having read the discussions, though, I am just left confused, as it doesn't seem like any of the options are really an improvement. I see the problem, but I think introducing a system that requires users to create a new item with the correct sitelink statement as a prerequisite to adding the P8252 statement to the original item is a pretty ugly user experience. You say you would migrate the existing ones, but that doesn't help the workflow for future uses. I don't think I even understood that was how Commons category properties worked before now, and I have a million Wikidata edits, so I'm not new.Dominic (talk) 21:11, 28 May 2020 (UTC)
@Dominic: Unfortunately I haven't found a better solution to this yet. The core problem is that you can't have multiple sitelinks to Commons from the same item, and that's unlikely to change (the assumption is built into the Wikidata data model). I come at this from the Commons side of things, where the sitelinks are essential for the Wikidata Infobox to work without it becoming a maintenance nightmare of manually defined QIDs everywhere. For the workflow in the future, it is a pain to do it manually for a lot of cases, but I think QuickStatements can do it in bulk, and if there's a list of QIDs and categories then I can always run pywikibot through a batch. For background, the bot code I used for the map categories is at [1], which is QuickStatements-esq (the 'newitem' function creates the item, "wd_item.addClaim" adds the link). Thanks. Mike Peel (talk) 06:59, 29 May 2020 (UTC)
@Mike Peel: Is there a Phabricator ticket for this? It seems like the ideal solution is to have a data type that allows us to link a page in a Wikimedia project, rather than having to create an item for each one we might want to refer to. Dominic (talk) 20:44, 1 June 2020 (UTC)
@Dominic: Probably. meta:Community Wishlist Survey 2017/Multimedia and Commons/Improve support of interwiki links on Commons using Wikidata might be a good starting point. It quickly goes into wider issues like phab:T54971. Any solution needs to be bi-directional, not just linking from here to Commons, but also having the reverse link back from Commons to here. Thanks. Mike Peel (talk) 21:41, 1 June 2020 (UTC)
@Pasleim: Re [2], did I do it correctly this time? Thanks. Mike Peel (talk) 17:38, 29 May 2020 (UTC)
I would say so. Now users can decide without being presented with a fait accompli. --Pasleim (talk) 15:18, 2 June 2020 (UTC)
  •  Delete use item datatype as every other similar property we created recently. --- Jura 07:08, 29 May 2020 (UTC)
  •  Delete Seems too prematurely created. --Liuxinyu970226 (talk) 11:11, 30 May 2020 (UTC)
    • @Liuxinyu970226: Just to defend Pamputt a bit here, properties are commonly created with fewer supports than that (as long as there is not opposition), and the proposal was open for over 2 months. I don't think it was premature to create it, just that no one objected when the discussion was held. Dominic (talk) 20:44, 1 June 2020 (UTC)
      •  Delete The problem isn't premature creation but lack of sanity checking which Pamputt should have done. It's fine when people who don't know a lot about how properties get constructed sometimes created proposals that need improvement but those shouldn't be created in the problematic state by property creators. ChristianKl ❪✉❫ 23:15, 3 June 2020 (UTC)
        • I don't view this as @Pamputt's fault at all, given the available information and the existence of Commons category (P373), the creation of the property in this form would seem reasonable. And as it stands, the property works as intended - I just think it could have been done better using the 'item' format. I really should have noticed this property proposal earlier and commented on it, and again, apologies for not doing that. Thanks. Mike Peel (talk) 18:57, 5 June 2020 (UTC)
          • Thanks for pinging me :). Mike Peel has indeed well explained what happened in my mind. I wonder whether the datatype was good and indeed I have taken the example of Commons category (P373) which is by far the most used similar item. Moreover, the property was proposed on March 5th and I created it on May 22nd. So it remained visible for debate for more than 2 months and no one noticed the "wrong" type either. Considering the debate about Commons category (P373) above, it seems that the community does not have a unanimous opinion on the best way to model the Commons categories. Anyway, I do not understand really the debate here (if there is one). This property is not widely used yet so we can easily delete it and create a new one with another type; it is not a big deal. Pamputt (talk) 19:09, 5 June 2020 (UTC)
  • Just to note, it may look like it is not widely used yet, but data from this field is being displayed in over 700,000 pages on Commons already (via transclusions of commons:Template:DPLA), and any changes may require us to update the template and run a bot to purge them all to update the category links. This should be kept in mind when making changes, and weighing the costs of that. Dominic (talk) 15:53, 8 June 2020 (UTC)
  •  Delete use standard datatype Vojtěch Dostál (talk) 07:44, 22 June 2020 (UTC)

@Dominic, Jheald, Arbnos, Kwj2772, Ahmad252, Dispe: @Pasleim, Jura1, Liuxinyu970226, ChristianKl, Vojtěch Dostál: I just created content partnership category (P8464) to replace P8252 (P8252). The latter is currently used on 237 items. So we should move all the use of P8252 (P8252) to the new content partnership category (P8464). I have created a [[Wikidata:Bot_requests#Move_P8252 (P8252)_to_content partnership category (P8464)|bot request]] for this task. Then, once the migration will be done, we will need to replace the property in c:Template:DPLA. Then I think everything will be good. Pamputt (talk) 20:17, 18 July 2020 (UTC)

@Pamputt: Thanks! I can run through these this evening per Wikidata:Requests for permissions/Bot/Pi bot 12, unless you'd prefer to do it. Thanks. Mike Peel (talk) 18:01, 21 July 2020 (UTC)
Also, I've created Wikimedia content partnership (Q97580368) as the category combines topics (P971) value to use, demo at Category:Media contributed by the Digital Public Library of America (Q97487619). Thanks. Mike Peel (talk) 18:09, 21 July 2020 (UTC)
... and bot demo at Category:Images from the Rijksmuseum (Q97580921) and [3]. Thanks. Mike Peel (talk) 18:12, 21 July 2020 (UTC)
Hi Mike Peel, sorry for missing the ping :S. No problem, you can do it with your bot. Thanks a lot. Pamputt (talk) 18:42, 21 July 2020 (UTC)
@Pamputt, Dominic: The bot is running, please check to make sure that there aren't any problems. I also changed commons:Template:DPLA to use the new property. If everything looks OK, then once the bot run is complete then P8252 (P8252) can go. Thanks. Mike Peel (talk) 19:23, 21 July 2020 (UTC)
Most of the cases have now been bot-migrated, please check the remaining ones. Thanks. Mike Peel (talk) 20:54, 21 July 2020 (UTC)
@Mike Peel: nothing remains. There is just Mex'n'match 3588. Is it possible to delete this catalog and create a new one with content partnership category (P8464), or something else (@Dominic:)? Pamputt (talk) 11:48, 22 July 2020 (UTC)
@Dominic: obviously, Mix'n'match is still adding the old property. As far as I know, it is not possible to delete a catalogue in Mix'n'match. So, should we tag all remaining entries to N/A in order to be pretty sure that P8252 (P8252) will not be used anymore in the future and so we can delete it? Pamputt (talk) 18:14, 30 July 2020 (UTC)
I've run the bot through the new cases to migrate them over. I've also tweeted Magnus about the mix'n'match catalog to see if he can help remove/update/disable it. Thanks. Mike Peel (talk) 15:01, 8 August 2020 (UTC)
@Pamputt: The mix'n'match catalog has been disabled, and there are no more uses of it. I think this property is ready to go away now. Thanks. Mike Peel (talk) 13:03, 11 August 2020 (UTC)
Thanks Mike Peel. I've just deleted the property. Pamputt (talk) 15:10, 11 August 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

country (P17)

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.

 Not deleted: the consensus is that we should keep this property, even though it may not be perfect. Hazard-SJ (talk) 04:15, 13 September 2020 (UTC)

country (P17): (delete | history | links | entity usage | logs | discussion)

Unsystematical property, duplicating located in the administrative territorial entity (P131). There is no reason why just this one level of administrative division should be entered directly, when we derive all other levels from the lowest administrative level given by located in the administrative territorial entity (P131). For some topics, another level may be more important, such as a city or town or a province/region/land/state etc.

Similarly, continent (P30) is also redundant to part of (P361), located in/on physical feature (P706) etc. if we derive the geographical division from the lowest specified level. When it is specified that a mountain is in the Alps, then it is redundant to directly specify that it is also in Europe.

Of course, it is necessary to develop stronger tools that would make it possible to find out with a simple question: in which municipality, in which country, on what continent, is this object located? —ŠJů (talk) 23:19, 11 July 2020 (UTC)

This is a very widely used property. Migrating off of it would be very difficult without losing information. There are cases where it's very unclear what to transition to. For example a company might be "American" but have multiple HQs. Should we use country of origin? It's not clear. I say we need to keep at least until there is a transition plan and a long deprecation period. BrokenSegue (talk) 02:39, 12 July 2020 (UTC)
Does not make sense to me. States are not administraiton areas. The latter never has sovereignity over its area. I d' like to recommend to read reelevant literature on what a state is. Keep --Matthiasb (talk) 09:18, 14 July 2020 (UTC)
  •  Keep Hugely useful for efficient querying (eg as a pre-filter) -- the time and complication and memory expense of having to have a query create a whole P131 tree can be very expensive, and would break many queries that currently can run within the time. Also very important for many items that have a country association, but often no sharp geographical localisation. Jheald (talk) 10:54, 27 July 2020 (UTC)
  •  Keep. P17 is necessary to get additional country-specific parameters (currencies, calling codes, etc.) and reduces computing time because it saves the analysis of the sequence of administrative units. --RolandUnger (talk) 09:01, 31 July 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Q99849936

Q99849936: no description: (delete | history | links | entity usage | logs)

Do not contain any link to a Wikimedia project. Was deemed out of scope for Wikipedia at en:Wikipedia:Articles for deletion/Bigzzad. —Thuresson (talk) 14:58, 2 October 2020 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 23:29, 9 October 2020 (UTC)

Theses.fr person ID (P4285)

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.

 Not deleted: The discussion suggests that both properties are different enough that they need to remain separate. Hazard-SJ (talk) 06:31, 15 October 2020 (UTC)

Theses.fr person ID (P4285): (delete | history | links | entity usage | logs | discussion)

(i) this is exactly the same identifier as for IdRef ID (P269); (ii) all theses.fr references are now included on the SUDOC authorities (here's an example). Nomen ad hoc (talk) 08:14, 18 February 2020 (UTC)

It seems to me that I already found researchers who have Theses.fr person ID (P4285) and no IdRef ID (P269) or the opposite (have IdRef ID (P269) and no Theses.fr person ID (P4285)). Maybe a SPARQL query can find all these cases. Pamputt (talk) 09:23, 18 February 2020 (UTC)
I already heard about that oddity too. Any example, perhaps? Nomen ad hoc (talk) 11:38, 18 February 2020 (UTC).
@Envlh: FYI. Nomen ad hoc (talk) 11:44, 18 February 2020 (UTC).
Pour les francophones, voir aussi cette discussion. Pamputt (talk) 09:26, 18 February 2020 (UTC)
IF we can be sure that ALL people with Theses.fr person ID (P4285) also are in IDRef, then OK to  Delete. --Hsarrazin (talk) 13:52, 18 February 2020 (UTC)
 Keep As explained two years ago, because one property is a subset of the other, you need to keep both (if you have only IdRef ID (P269), you can't guess if a value in theses.fr exists). Participants of the previous discussion should be notified. — Envlh (talk) 16:57, 18 February 2020 (UTC)
I'm afraid that only @Trivialist: can tell us that if there are archive.org records (or like) of former theses.fr URL schemes or not, if yes, I would consider keep and change its formatter URL (P1630), if not, there's no problems anymore to delete. --Liuxinyu970226 (talk) 03:59, 2 March 2020 (UTC)
@Liuxinyu970226: What are you talking about? Trivialist (talk) 11:00, 2 March 2020 (UTC)
As Envlh said that Participants of the previous discussion should be notified, @Fralambert, Thierry Caro, Framawiki, DarTar, Pigsonthewing:@ديفيد عادل وهبة خليل 2: --Liuxinyu970226 (talk) 07:08, 9 March 2020 (UTC)
 Keep all people who has a IdRef ID (P269) do not have a Theses.fr person ID (P4285). And I've already seen two different identifiers used for IDref and theses.fr. I then contacted SUDOC and they merge both ID but it may happen. Pamputt (talk) 07:17, 30 April 2020 (UTC)
Pamputt, tu as des exemples de personnes avec un identifiant theses.fr mais pas SUDOC ? Merci, Nomen ad hoc (talk) 18:08, 10 May 2020 (UTC).
@Nomen ad hoc:, non pas en tête. Et peut-être que ça a été corrigé depuis. Mais une requête SPARQL devrait permettre de les trouver. Pamputt (talk) 18:28, 10 May 2020 (UTC)
 Keep Per Pamputt, not enough be a reason to replace. --Liuxinyu970226 (talk) 04:29, 21 May 2020 (UTC)
 Keep. Per Pamputt and Envlh. Ivanhercaz (Talk) 13:38, 28 September 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P8031

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.

 Not deleted: It seems that the open questions were resolved, and the discussion suggests that this should remain separate from participant (P710). Hazard-SJ (talk) 06:36, 15 October 2020 (UTC)

perpetrator (P8031): (delete | history | links | entity usage | logs | discussion)

Open questions in creation discussion --- Jura 08:08, 28 March 2020 (UTC)

No need due to participant (P710). --Infovarius (talk) 18:10, 29 March 2020 (UTC)

It's pretty bizarre to call the perpetrator of a terrorist attack a 'participant'. Participant makes it sound like a contest or recurring event @Thierry Caro, Tinker Bell, Misc, Jklamo: --Trade (|talk) 02:03, 31 March 2020 (UTC)

@Trade , I do not see "participant" in the property, I may miss some context, could you detail ? --Misc (talk) 08:42, 31 March 2020 (UTC)
Infovarius thinks that the property is unnecessary since we just can use "participant" instead. --Trade (talk) 15:21, 31 March 2020 (UTC)
 Keep I think this level of property detail is ok, given precedents here already. ArthurPSmith (talk) 18:21, 9 April 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P8032

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.

 Not deleted: The discussion suggests that this should remain as a property. Hazard-SJ (talk) 06:41, 15 October 2020 (UTC)

victim (P8032): (delete | history | links | entity usage | logs | discussion)

Premature creation, created before the usual wait of a week --- Jura 08:38, 28 March 2020 (UTC)

participant
Normal rank John Doe edit
object has role victim
0 references
add reference


add value

--SixTwoEight (talk) 22:09, 3 April 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P8102 (P8102)

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, given the concerns raised about the creation on the proposal and here, and that the property has been unused (though also explicitly marked as such). Hazard-SJ (talk) 07:07, 15 October 2020 (UTC)

P8102 (P8102): (delete | history | links | entity usage | logs)

Wikidata:Property proposal/NASA active astronaut ID

Hello.
 · First criterion. There is no consensus: 1 approval and 2 negative comments indicating that the property cannot be realized.
 · The proposal contains an error on the RegEx and has been copied identically into the property.
 · A gap: subject item according to the old property.
 · Domain lacking precision and not reported on the property.
 · In short, the property, in the current state, cannot be put into production. I added this fact to the Property Label (since error). As I already wrote, the property contains errors, as well as many shortcomings. The proposal has been left fallow for 1.5 months. The NASA biographical ID (P2030) is still active, and, for my taste, it is this property which should simply be changed by a discussion on its TP. If Epìdosis has no outlet, I will provide a proposal on it when the time comes. This nonsenseThis issue needs to be resolved before.

Like what this discussion is not trivial. Cordially. —Eihel (talk) 23:17, 9 April 2020 (UTC)

Participant, proposing user, concerned with the old property: @Epìdosis, ArthurPSmith, Amitie 10g: and @Adert, Pigsonthewing, Jura1, יונה_בנדלאק, Trade: —Eihel (talk) 23:33, 9 April 2020 (UTC)

considering only Former (maybe also Management) and Active Astronauts, I don't see an economic way to have Former and Active Astronauts in the same property; so, my conclusion was that, being Former Astronauts the great majority, we could readapt old P2030 for Former Astronauts and create a new property P8102 for Active Astronauts. If no better alternative is found, I think that the property should be kept. --Epìdosis 07:52, 10 April 2020 (UTC)
  •  Keep Now that the property exists I don't see that it hurts anything to keep it. I would have agreed with the suggestion to wait, but neither of the "negative" comments explicitly stated they opposed creation, so I don't think the creator did anything wrong here, it was a judgment call. NASA did recently accept several thousand applications to become astronauts - here's a page on it - so I do think the number will be higher soon. ArthurPSmith (talk) 13:20, 13 April 2020 (UTC)
 speedy delete Created by wrong parameters, just re-create it. --223.104.7.115 22:07, 9 May 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P8531

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.

 Not deleted, no willingness to delete except that of the proposer. Pamputt (talk) 10:56, 22 October 2020 (UTC)

Filmstarts title ID (P8531): (delete | history | links | entity usage | logs | discussion)

Redundant (see creation discussion): the same identifiers is used on several websites of the publisher and we already have a property for it (Property:P1265). Unfortunatly the proposer omitted mentioning this when the proposal was first made. --- Jura 08:43, 17 August 2020 (UTC)

You and 99of9 were the only ones opposed to the creation of this property. Eihel responded on the creation proposal page to all your arguments. This property is also similar to others we already have such as AdoroCinema film ID (P7777). Pamputt (talk) 08:50, 17 August 2020 (UTC)
The sites are different. -- MovieFex (talk) 21:20, 16 October 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P6428 (P6428)

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: Superseded by LoC HABS/HAER/HALS place ID (P8655). Hazard-SJ (talk) 06:57, 15 October 2020 (UTC)

P6428 (P6428): (delete | history | links | entity usage | logs)

This has been superceded by LoC HABS/HAER/HALS place ID (P8655), which has a wider scope and provides direct links to the relevant content. This property was actually linking to search results and was used no more than 14 times so far. —Thierry Caro (talk) 23:33, 27 September 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/Archive/2020&oldid=1576017069"