Wikidata:Properties for deletion/Archive/2020

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)

Delete as redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 1 February 2020 (UTC)
Delete A simple Datatype migration process. --Liuxinyu970226 (talk) 14:04, 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)

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)

Delete. I agree with above. --Tinker Bell ★ ♥ 02:50, 20 September 2019 (UTC)

Keep It's a summary of all the militar units commanded. Now is in use a ca:template:infotaula persona. The P39 shows the different position, but in military use to show only high ranks position, not one per one of its commanded units. Amadalvarez (talk) 11:38, 4 October 2019 (UTC)
Delete Too hard to translate, note that I'm the most "hate" user of "XXX of" properties. --Liuxinyu970226 (talk) 04:58, 1 January 2020 (UTC)
Delete store information in inverse or use position held (P39), but for the latter one would have to create items for the positions. Michael FV (talk) 03:27, 9 January 2020 (UTC)
Delete XXX of should be fixed by qualifiers not creating vandalism properties. --117.136.54.109 23:15, 20 January 2020 (UTC)
Delete Redundant with position held (P39). See Bengt Gustafsson (Q5777531) as an example. Also commander of (DEPRECATED) (P598) can only be used for independent commands, not for deputy commander (Q20160287) or military chief of staff (Q707492) /ℇsquilo 19:58, 22 January 2020 (UTC)
Delete redundant, as described above. -- Ajraddatz (talk) 20:22, 8 February 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) 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)

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

Maybe we can change the formatter URL to web.archive.org instead of deleting it. Is the website properly archived? Robin van der Vliet (talk) (contribs) 09:52, 11 September 2019 (UTC)
- +1 --Adam Harangozó (talk) 18:37, 14 October 2019 (UTC)
Wikidata property for a discontinued website (Q60457486)? so maybe keep. --Liuxinyu970226 (talk) 11:25, 11 September 2019 (UTC)
Keep and deprecate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:19, 15 September 2019 (UTC)
Keep and deprecate. Dhx1 (talk) 14:28, 27 September 2019 (UTC)
Keep and deprecate. --Tinker Bell ★ ♥ 22:03, 1 November 2019 (UTC)
Deprecate then Delete. We have enough longstanding online databases of species to link to, so little value is lost in deleting one property pointing to one dead website. Deryck Chan (talk) 18:54, 11 November 2019 (UTC)
Delete We must face the facts. Keep Over 12000 uses and with WP links, there are certainly archives of the site. —Eihel (talk) 22:44, 23 December 2019 (UTC) Eihel (talk) 02:48, 3 April 2020 (UTC)
Keep shutdown of other site is not reason to delete information in own site. Michael FV (talk) 03:38, 9 January 2020 (UTC)
Keep never delete - but possibly with a warning that the database linked to may be out of date S a g a C i t y (talk) 09:53, 2 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) 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)

Delete per above. --Tinker Bell ★ ♥ 22:02, 1 November 2019 (UTC)
@ChristianKl: Ok for the deletion, but why a stringa datatype and not a numeric value ? Snipre (talk) 12:32, 4 November 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)

Delete per nom. Michael FV (talk) 03:46, 9 January 2020 (UTC)
Delete per above. --Flixwito ^(•‿•)^ 06:50, 28 January 2020 (UTC)
Delete per above.--So9q (talk) 08:01, 22 March 2020 (UTC)
Question @ChristianKl: Can you give me 2 or 3 examples with the Item type? I'm curious. Otherwise the scale goes from 0 to 10, 0 being the most complicated (and the most expensive) Teardown and 10 being the easiest Teardown, reference. —Eihel (talk) 02:35, 3 April 2020 (UTC)
For examples look at the properties I referenced and how they use items. ChristianKl ❪✉❫ 20:23, 6 April 2020 (UTC)
OK. I thought you had something special in mind. So 11 new Items labeled respectively from 0 to 10. The Items must be able to describe what they are, but I did not find a "description" on the site, other than "repairability score". Here, we only know the ends of the scale: the numbers between 1 and 9 are completely abstract. Does one describe an adhesive or a solder? We do not know it. Finally, I think that a Quantity datatype is not such a bad idea. —Eihel (talk) 22:19, 7 April 2020 (UTC)
Delete Just for the name: it is specified on the site that Repairability is different from Teardown This teardown is not a repair guide. The Formatter URL only leads to Teardowns (≠ https://www.ifixit.com/Guide/...). The property does not only concern smartphones and the property has been corrected to no longer correspond to the proposal. Premature. —Eihel (talk) 22:19, 7 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) 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)

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

Notified participants of WikiProject Movies —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:

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

--- ʂɤɲ ✉ 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)

--- ʂɤɲ ✉ 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:

Minha Mãe é uma Peça 2 - O Filme (Q28803031) → 223673
Fala Sério, Mãe! (Q27703437) → 249032
A Divisão 260004 the film of A Divisão (Q68258925)

and many others… But to satisfy VIGNERON, there is The Boy and the World (Q16246692) :

→ 202641 for AdoroCinema film ID (P7777)
→ 227624 for AlloCiné film ID (P1265)

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)
- @Eihel: I'm still neutral but I have no problem with keeping this property. Cheers, VIGNERON (talk) 08:15, 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)

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)

Keep If that's just the URL scheme change then @Andre Engels: the formatter URL (P1630) value should be changed (add the current scheme as the preferred value, and optionally add until property to the Old one). --117.136.54.109 23:34, 20 January 2020 (UTC)
Huh? URL scheme change? Change the value? Add the current scheme? The pages do not exist any more. Not in this schema, not in another schema. - Andre Engels (talk) 23:40, 20 January 2020 (UTC)
Comment Delete Links to artists found on the site also lead to the same link found by Andre Engels. If iHeartMedia put these links elsewhere, I did not find them on this site. So P1630 changes nothing. ~~: the IDs are lost for this property.~~ —Eihel (talk) 20:49, 1 February 2020 (UTC) —Eihel (talk) 01:23, 8 April 2020 (UTC)

Keep Redirect the formatter URL to the internet archive. --Trade (talk) 23:42, 10 February 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)

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)

A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
Had never more than 50 uses .. I'd tend to delete this --- Jura 08:19, 10 April 2020 (UTC)
Keep Available at scoresway.us. I changed the formatter URL accordingly. Lymantria (talk) 09:40, 19 April 2020 (UTC)
- I reverted my removals aswell. Pelmeen10 (talk) 19:30, 19 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)

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)

A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
Had never more than 50 uses .. I'd tend to delete this --- Jura 08:18, 10 April 2020 (UTC)
Keep Available at scoresway.us, I changed the formatter URL accordingly. Lymantria (talk) 09:37, 19 April 2020 (UTC)
- @Lymantria: Thanks, I didn't know it's repairable. I reverted my removals aswell. So the .us works for all these IDs? Pelmeen10 (talk) 19:20, 19 April 2020 (UTC)
  - It seems so, but only for the "american sports". Lymantria (talk) 19:56, 19 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)

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

A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
Keep Available at scoresway.us. I fixed the formatter URL. Lymantria (talk) 09:34, 19 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)

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

Notified participants of WikiProject Astronomy --Liuxinyu970226 (talk) 05:27, 7 January 2020 (UTC)

Keep: the property is very similar to determination method or standard (P459), but has specific constraints (type, value type and specific values) that cannot be checked using a general property as determination method or standard (P459). --Paperoastro (talk) 07:22, 7 January 2020 (UTC)
Keep: quoting Paperoastro motivations.--Ysogo (talk) 22:01, 7 January 2020 (UTC)
Keep Per Paperoastro, determination method or standard (P459) should better be used in other cuts of Astronomy. --Liuxinyu970226 (talk) 03:39, 8 January 2020 (UTC)
Delete per nom. Michael FV (talk) 04:26, 9 January 2020 (UTC)
Please STOP @GZWDer: there are many astronomic things that are serving their own names, own concepts, own items and own properties. Do you really know the astronomy? Absolutely keep keep keep. --117.136.54.109 23:30, 20 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 this camera (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)
        @Pamputt: would you do so? --- Jura 10:58, 25 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)

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)

Keep Deleting this property is not the right way to go IMHO. But it need to be further clarified that it is a geographical property. There are other properties already in place for non-geographical objects like country of citizenship (P27), country of origin (P495), country of registry (P8047) and applies to jurisdiction (P1001). /ℇsquilo 08:38, 12 July 2020 (UTC)
@Esquilo: Not the right way to go? Would you go the opposite way? To create analogous specific properties for all existing levels of geographic and administrative division? I once proposed one, and it was rejected on the grounds that a geographical belonging should be derived hierarchically from below. It is a fact that it would be useful to can find affiliation to the municipality, affiliation to the region, to the federal state, etc. with a single question. This now requires a relatively sophisticated script that is not available in many projects. --ŠJů (talk) 14:22, 12 July 2020 (UTC)
That approach would make Wikidata objects more useful. Not just for geographical properties but particularly for even more hierarchical objects like species. /ℇsquilo 15:15, 12 July 2020 (UTC)
@Esquilo: Sometimes P17 values can also be targeted as roots of edit wars, just if the affected items are having territory conflicts, e.g. do you remember what happened on Golan Heights (Q83210)? Edits from [4] though [5] to [6], I would say that we are developing an edit war platform via this property. --Liuxinyu970226 (talk) 13:18, 14 July 2020 (UTC)
If we delete P17, the war will just move to located in the administrative territorial entity (P131). /ℇsquilo 13:37, 14 July 2020 (UTC)

what does it mean to be a geographical property? wouldn't location (P276) cover the cases you're talking about? BrokenSegue (talk) 21:38, 12 July 2020 (UTC)
location (P276) can be large enough to be located in multiple countries, like a mountain. located in the administrative territorial entity (P131) is usually in only one country, though. /ℇsquilo 20:03, 13 July 2020 (UTC)
Right but when would you propose country (P17) be used? BrokenSegue (talk) 20:22, 13 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)

Delete To me widely used isn't a reason to not delete something, if something is confused by themselves, then we may slowly defunct it. --Liuxinyu970226 (talk) 11:51, 14 July 2020 (UTC)
Keep used 12,847,294 times. Mandatory statement on plenty of properties. Without this property it's nearly impossible to work on specific countries because crawling the tree is too slow. Multichill (talk) 10:32, 18 July 2020 (UTC)
Keep. located in the administrative territorial entity (P131) is subproperty of location (P276). As such, it is used for things located in an administrative entity. However, country (P17) is also used for institutions, companies etc. which are under jurisdiction of a given country. Vojtěch Dostál (talk) 09:45, 19 July 2020 (UTC)
Delete Very widely used shouldn't mean we should continue to tread in the wrong direction. As long there is an entity to denote the same thing, we won't lose any information. I'mfeistyincognito (talk) 22:08, 26 July 2020 (UTC)
Keep I do not think we should delete without a more clear policy of what the follow-up is. I agree the property is suboptimal but given the lack of guidance it is better than nothing. BrokenSegue (talk) 03:13, 27 July 2020 (UTC)

Keep Good point for Vojtěch Dostál (talk • contribs • logs) Bouzinac (talk) 05:20, 27 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 much more useful in the daily practice than it is doing harm. Apart from that, I agree with Vojtěch. → «« Man77 »» 08:10, 30 July 2020 (UTC)
Keep in addition of what has been already said, this property is useful with the constrain item-requires-statement constraint (Q21503247). Pamputt (talk) 18:17, 30 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)

Keep. Agreeing with Vojtěch.--Sinuhe20 (talk) 10:23, 1 August 2020 (UTC)
Keep per above. Yellowcard (talk) 09:20, 2 August 2020 (UTC)
Keep P131 could potentially cause a loop, since nobody here still hasn't provided sufficient information what "located in the administrative territorial entity" means in every case. 62 etc (talk) 12:01, 5 August 2020 (UTC)
Keep definitely does more good than harm. Lirazelf (talk) 17:23, 12 August 2020 (UTC)
Keep per comments above. ImprovedWikiImprovment (talk) 15:58, 18 August 2020 (UTC)

Keep per above. --Prahlad (tell me all about it / private venue) (Please {{ping}} me) 03:18, 27 August 2020 (UTC)
Keep Usefull for querrying. --Fralambert (talk) 22:18, 1 September 2020 (UTC)
Keep per comments above. - PKM (talk) 22:35, 1 September 2020 (UTC)
Keep, huge list of equivalent property (P1628) is a blocker for deletion, removing properties like this would break ontological standards and render Wikidata unusable for many of organizations. --Lockal (talk) 05:44, 8 September 2020 (UTC)
Keep for now, but I agree that P131 is sufficient. This problem is similar to the P373 problem, both are easy-to-use properties, but both are wrong ways to structure data. --Tinker Bell ★ ♥ 22:18, 11 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.

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)

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

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)

In the meantime, the question has been resolved in the proposal discussion. If no other reasons for deletion had come up, I'd withdraw this. --- Jura 08:00, 10 April 2020 (UTC)
Keep NMaia (talk) 02:59, 28 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.

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)

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

Probably covered with participant (P710). --Infovarius (talk) 18:11, 29 March 2020 (UTC)
It's not very practical if someone wants to extract the name of a murder victim into to infobox @Thierry Caro, Tinker Bell, Misc, Jklamo, Husky: --Trade (talk) 02:06, 31 March 2020 (UTC)
- participant (P710) is something radically different than a victim. Husky (talk) 09:55, 31 March 2020 (UTC)
  - @Husky: A victim is a participant in a crime (although they don't want to be one) with a role of victim (Q1851760):

participant

John Doe

edit

object of statement has role

victim

0 references

add reference

add value

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

Keep I think this level of property detail is ok, given precedents here already. ArthurPSmith (talk) 18:22, 9 April 2020 (UTC)
"significant person" or "participant" should do for this. --- Jura 08:08, 10 April 2020 (UTC)
Delete It's not very hard to obtain victim item using object of statement has role (P3831). --Tinker Bell ★ ♥ 02:39, 4 May 2020 (UTC)
Note: proposed 21 March created 28 March. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:08, 25 May 2020 (UTC)
Keep per Arthur Germartin1 (talk) 19:44, 2 June 2020 (UTC)
Keep Husky (talk) 23:11, 4 June 2020 (UTC)
Delete use key person property. This avoids needing to use different properties on items that have labels "death of", "murder of", "police incident leading to the death of", and "suicide of". --- Jura 08:51, 20 June 2020 (UTC)
Keep The entirely generic participant (P710) would just increase the cognitive load of reading an entry. Along the same line of reasoning, any properties with the same datatype could be aggregated: "related quantity" of 80,000 would then be qualified with "population" or "copies sold", depending on context. mother (P25), father (P22), sibling (P3373), child (P40), and killed by (P157) would all be listed as "relevant person", in no specific order. I also don't remember many examples for the query service touching on qualifiers, and most users would end up with a list of events and connected name, but no immediate idea of how to make the rather central distinction between victim, perpetrator, bystander, and so on. In English, and even more so in other languages, the term "participant" also denotes an active, most often voluntary, participation. The idea of, for example, listing Holocaust victims as "participant[s] of the holocaust" appears ridiculous to me, and might, not entirely without reason, be interpreted as tacit approval of similar long-running conspiracy theories. I also see no problem with "murder of", "suicide of", "police incident leading to the death of" and the others listed above, since the term "victim" applies not just to crimes, but also accidents and other events: a suicide victim is the victim of their own suicide, and so on.--Matthias Winkelmann (talk) 00:36, 6 July 2020 (UTC)
Keep My impression is that this property mostly is used as a qualifier already, and since qualifiers can't have qualifiers, the example above does not apply. /ℇsquilo 08:30, 12 July 2020 (UTC)
Keep NMaia (talk) 03:00, 28 August 2020 (UTC)
Keep per Arthur. Note that property constraints are nicely built.--Jklamo (talk) 14:24, 6 September 2020 (UTC)
Keep Sometimes it needs qualifiers, so, it can't be covered with P170 + a qualifier like P3831. Amadalvarez (talk) 04:45, 17 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.

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 nonsense~~This 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)

Speedy is the exact term. Premature creation, but since it is a property and it seems to be approved by the community… I add an opposition in the proposal to signify that it is not enough to count the "green dots" of the discussion section. —Eihel (talk) 23:33, 9 April 2020 (UTC)
Speedy delete per above, creator's error. --Liuxinyu970226 (talk) 03:27, 10 April 2020 (UTC)
Keep if a better solution isn't found. Problems related to RegEx, Subject item and Domain have been solved. So, there is mainly one problem, the oppose votes, which focus mainly on "48 is a very small number for a property like this". I substantially agree, but I also think that NASA is a valuable source and that creating a new property is the best solution to link it. I resume what I said in Property talk:P2030: given that there are

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)

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)

KeepThe "proposer", It's me ! You might have the courage of your convictions: when you write about a contributor, you notify him. It's the least of politeness, because what you write is completely false and you know it very well. The deletion procedure is clearly explained in the header of this page. I don't understand your eagerness to suppress these properties. The examples and opinions show that the identifiers of the proposition are not always the same. The proponent (me) has clearly explained the gain in having this property and not citing other properties on the proposal is not a valid criterion. Jura1's opposition has already been rejected twice, here and then again in the debate. Therefore, like the last time, I will immediately request the early closure (without waiting 7 days) of this deletion request, because it has no serious basis. Thanks for the contributors' waste of time. —Eihel (talk) 14:30, 17 August 2020 (UTC)
Not mentioning this was previously listed for deletion by the same person seems bad faith to me. Keep if only on those grounds. BrokenSegue (talk) 14:39, 17 August 2020 (UTC)
Neutral Maybe another datatype would be better? --Liuxinyu970226 (talk) 14:29, 23 August 2020 (UTC)
Keep Description of Filmstarts (Q1415290) is "German movie website" (filmstarts.de) and so it is. I don't know if the identifier is equal to Allocine-ID, but the content is not, e.g. for Cloud Whispers (Q52777610) there is http://www.filmstarts.de/kritiken/254579/kritik.html and http://www.filmstarts.de/kritiken/254579/pressespiegel/ . This is absolutely NOT redundant. -- MovieFex (talk) 09:19, 1 September 2020 (UTC)
- It's frequent that the same identifier is shared by several sites. It's even the purpose of identifiers. --- Jura 07:17, 15 October 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)

Delete You make a good case that this is superfluous now that we have LoC HABS/HAER/HALS place ID (P8655). ArthurPSmith (talk) 13:22, 28 September 2020 (UTC)
Speedy delete Entirely replaced, there seems no usages anymore. --Liuxinyu970226 (talk) 01:45, 29 September 2020 (UTC)
Delete seems to have been created in error. --- Jura 16:36, 29 September 2020 (UTC)
Delete NMaia (talk) 05:22, 1 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.

Wikidata:Properties for deletion/Archive/2020

Contents

Property:P3722

Property:P598

Property:P6433

P7478 (P7478)

Property:P7777

iHeart artist ID (P7317)

Scoresway ice hockey person ID (archived) (P6064)

Scoresway baseball person ID (archived) (P6062)

Scoresway basketball person ID (archived) (P6063)

P8154 (P8154)

Property:P1016

P727 (P727)

Property:P8252

country (P17)

Q99849936

Theses.fr person ID (P4285)

Property:P8031

Property:P8032

P8102 (P8102)

Property:P8531

P6428 (P6428)

Navigation menu

Wikidata:Properties for deletion/Archive/2020

Navigation menu

Search