Shortcut: WD:PFD
Wikidata:Properties for deletion
Properties for deletion This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:
Requests may be closed after 7 days, but may be extended if consensus is not reached. If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead. Properties for deletion may be used:
Properties for deletion should not be used:
|
On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Wikidata:Properties for deletion/Archive/2024/12. |
Requests
[edit]
uBio ID (P4728): (delete | history | links | entity usage | logs | discussion)
Le site Ubio est fermé depuis de nombreuses années suite au décès de son inventeur. aujourd'hui l'appel de cette propriété P4728 (Ubio) propose une attente attente réseau et un dépassement de délai... Il vaut mieux supprimer toutes ces élements et leur appel possible dans tous les versions linguistiques : le français est depuis longtemps, l'anglais est demandé. Bonne continuation, bon courage et merci d'avance.
the Ubio site has been closed for many years following the death of its inventor. today the call of this property P4728 (Ubio) offers a network waiting and a timeout... It is better to remove all these elements and their possible call in all language versions: French has been for a long time, English is requested. Good luck, good luck and thank you in advance —Philippe rogez (talk) 09:19, 24 November 2024 (UTC)
France Culture person ID (DEPRECATED) (P5301): (delete | history | links | entity usage | logs | discussion)
Replaced by P10780 Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).
Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).
- @Nomen ad hoc: I do not understand why this is happening, and the property proposal likewise gives no explanation at Wikidata:Property proposal/Radio France person ID. If this deletion is to proceed can someone add an explanation to the original property proposal about why the new property was created to replace this one? Bluerasberry (talk) 12:44, 27 May 2022 (UTC)
- @Bluerasberry: it is extremely simple; IDs from this prop have been retrieved by the new prop (whose formatter URL has changed). Nomen ad hoc (talk) 13:52, 27 May 2022 (UTC).
Delete : after, of course, migration of all the pages using this "old" property France Culture, to "new" property Radio France... Problem: a contributor of Wikidata is adding since some days this P5301 on many pages!... That will complicating the work of cleaning pages. Maybe a bot could be use to do that? --YANN92340 (talk) 14:15, 10 July 2023 (UTC)
- @YANN92340 , Nomen ad hoc: Is it only fetching the 307 url used in P5301 to set P10780 according to the redirection? -Framawiki (please notify !) (talk) 23:20, 13 July 2023 (UTC)
- Wait: there are several entities where the URL given by this property does not work. Examples: Bernard Baas (Q2897472), Sophie Pujas (Q68587627), see also fr:Catégorie:Page utilisant P5301 (in each section Liens externes). I do not know how to migrate them ? Eric-92 (talk) 00:46, 18 July 2023 (UTC)
- The P5301 ID concerning Q2897472 (Bernard Baas) and Q68587627 (Sophie Pujas) have strictly no reasons to work: seems "fake ID", these people are not listed in the database! As you can see, they are not in https://www.radiofrance.fr/personnes?startsWith=B and https://www.radiofrance.fr/personnes?startsWith=P&p=16... --YANN92340 (talk) 10:03, 6 August 2023 (UTC)
Delete I have imported the Radio France ID. In these cases, I deleted the obsolete identifiers. There are probably still some Radio France and France Culture identifiers (duplicate items, one with Radio France, the other with France Culture), but these cases should be rare. --Hamuli (talk) 19:44, 4 October 2023 (UTC)
Scilit journal ID (P7662): (delete | history | links | entity usage | logs | discussion)
The source website does not keep permanent identifiers for journals. After a website update, all IDs seem to have changed. All (?) IDs in Wikidata seem now either to resolve to a 404 page (Scilit journal ID (P7662) of Journal of inorganic and general chemistry (Q186776), Scilit journal ID (P7662) of Intel Technology Journal (Q130945), Scilit journal ID (P7662) of IEEE Transactions on Mobile Computing (Q129122), ...) or refer to completely different entities now (Scilit journal ID (P7662) of Nucleic Acids Research (Q135122), Scilit journal ID (P7662) of Journal of Chemometrics (Q127755), Scilit journal ID (P7662) of Microscopy Research and Technique (Q59757), ...).
@GZWDer, Eihel: Ping as property creators. --Haansn08 (talk) 21:49, 4 August 2023 (UTC)
- Keep The property was updated by User:Blz 2049 with URL https://app.scilit.net/sources/$1. The identifiers simply need to be updated. In the example International Journal of Climate Change Strategies and Management (Q15816386) of Scilit journal ID (P7662), the ID is no longer 687103, but 19668. So this property is fully operational, no need to delete it, see this. Cordially. ―Eihel (talk) 23:14, 4 August 2023 (UTC)
- Info The problem has already been raised in May 2022, and resolved. Cordially. ―Eihel (talk) 23:35, 4 August 2023 (UTC)
- Changing the formatter URL did not resolve the problem, as the IDs currently in Wikidata are still invalid with the new URL. Haansn08 (talk) 21:12, 14 August 2023 (UTC)
- Delete. If the source doesn't bother to maintain persistence now, I don't see a reason to expect that they won't do this again. Further, with a changed formatter URL and changed values, I think it is best to see the new identifiers as an entirely new property rather than a modification of the existing property. We could create a new property for the new values, but given the threat to persistence, I think the onus is on advocates in this conversation to demonstrate why this property is useful enough to outweigh its potentially transient nature. Daask (talk) 23:36, 24 October 2024 (UTC)
national team appearances (P1129): (delete | history | links | entity usage | logs | discussion)
We have number of matches played/races/starts (P1350) to express the number of games for any team as a qualifier. This is used currently more than 700,000 times, also for national teams – as number of matches played/races/starts (P1350) is generic, it can be used for all kinds of teams, from youth teams to national teams. There is no need for national team appearances (P1129) besides number of matches played/races/starts (P1350), but the co-existence and mixture creates problems when using the data outside of Wikidata. Therefore, I propose to change the 5,000 usages of national team appearances (P1129) to number of matches played/races/starts (P1350) and then delete national team appearances (P1129). —Yellowcard (talk) 18:24, 10 October 2023 (UTC)
- Support This has bugged me for a long time as well. I see no reason to make a difference between games played for a national team and games played for a club. Jssfrk (talk) 21:00, 9 June 2024 (UTC)
- As a national player in my sport, I have to say that these are two different issues. Take the example of today's announcement that Manuel Neuer, the German goalkeeper, has retired as a national player after 124 games for Germany (which is a record call-up to the German national soccer team). In many sports codes, it is common to count the number of national team caps, and it is often shown in the Wikipedia info box.
- Please consider this. Tank you. Detlef Pfeifer (talk) 15:32, 22 August 2024 (UTC)
- We have been doing this in the German Wikipedia for a long time. That is exactly what qualifiers are for. You do not need a separate property for doing that. See de:Kategorie:Wikipedia:Infobox Fußballspieler mit Daten aus Wikidata for a list of the players with infobox data from Wikidata, many of them are national players and have their numbers of national games in the infobox as well. From a technical point of view, there is no real difference to show the appearances in the several clubs the player played for, and the (maybe several) national team(s). Random example: de:Rasheedat Ajibade. In Rasheedat Ajibade (Q50082738) you will see that national team appearances (P1129) was not used or needed here, but we are showing his appearances for the Nigerian national team as well as his club appearances. All this information comes from Wikidata. Regards, Yellowcard (talk) 06:48, 27 August 2024 (UTC)
interested in (P2650): (delete | history | links | entity usage | logs | discussion)
This is a follow-up of Wikidata:Project chat#Interested in vs. Field of work (opened by @Daask: on 18 October): as argumented by many users there, the difference between interested in (P2650) (with 17k uses in main statements) and the older field of work (P101) (with 938k uses in main statements) is not clear enough; whilst it has been said that P101 is for professional areas and P2650 for non-professional areas, it seems that presently both properties have been used for both fields, and there is a high probability that this confusion will worsen in the future; thus, following the proposal of @Vojtěch Dostál:, I agree that we can "merge the duplicates and start a new proposal if required for some other (or perhaps the originally intended) use case". So I'm proposing to delete P2650, bot-transferring all its values to P101; I'm not fully convinced that we need another property besides P101, but if someone wants to propose it in the future, this deletion wouldn't hinder them from doing it. Otherwise, if we choose not to delete P2650, I think we need to 1) state much more clearly how it differs from P101 and 2) find effective methods to move wrong uses of P2650 to P101 and viceversa (note: wrong according to the clearer definition of P2650 foreshadowed at point 1). —Epìdosis 19:20, 25 October 2023 (UTC)
- There is possible merit in it for people's hobbies (as was argued for fictional characters where field of work (P101) read oddly), but I can see no merit for organisations, all uses there should be transferred. Vicarage (talk) 21:23, 25 October 2023 (UTC)
- That's how I used it, because "field of work" sounded a bit odd for something that is usually seen as an opposite to work. If it had "hobby" (occupation (P106) comes up for this in a search because of a French alias) or "pastime" as an alias that might make me more confident in using it. GreenReaper (talk) 20:38, 5 June 2024 (UTC)
- Weak support P2650 is hardly used at all in the arts domain (artists with P2650). P2650 does not meet any need in this domain that P101 or inspired by (P941) cannot meet. But I cannot speak for other domains... Fjjulien (talk) 19:57, 1 December 2023 (UTC)
Before deletion we need an analysis of the current uses so we can inform people. Since it was originally proposed for WikiProjects I assume it was in use for a few, but could never have been many, because I would have seen it pop up in the proposal discussions for on focus list of Wikimedia project (P5008). Jane023 (talk) 08:36, 27 October 2023 (UTC)
- @Jane023: A quick SPARQL query indicates that it is currently in use on 18 WikiProject items. Daask (talk) 13:43, 27 October 2023 (UTC)
- Thanks! It's interesting to see the minimal information for such projects on Wikidata - the first page I looked at, Wikidata:WikiProject Moravian Knowledge Network Research, doesn't even point to any external site in the wikiverrse or otherwise. It's probably a good idea to start a larger campaign to clean this up. Jane023 (talk) 14:11, 27 October 2023 (UTC)
Support Move all uses to P101 and delete.Vojtěch Dostál (talk) 12:47, 25 June 2024 (UTC)
- Support I totally agree with all that's been said above about confusion with P101. Powerek38 (talk) 09:55, 26 November 2024 (UTC)
- Support Agree with everything said. --Nw520 (talk) 10:05, 26 November 2024 (UTC)
SvFF national player ID (archived) (P4830): (delete | history | links | entity usage | logs | discussion)
Branches only to the archive version of the database, for running url there is Schwedische Fußballassoziation ID (P1238), see Property_talk:P4830 without an answer; verzweigt nur auf die Archivversion der Datenbank, für laufende url gibt es Schwedische Fußballassoziation ID (P1238), siehe Property_talk:P4830 ohne Antwort --Nordprinz (talk) 18:53, 24 October 2023 (UTC)
- Notified participants of WikiProject Sweden Notified participants of WikiProject Association football --Ameisenigel (talk) 12:27, 7 July 2024 (UTC)
GeoNLP ID (obsolete) (P5400): (delete | history | links | entity usage | logs | discussion)
Following the upgrade of GeoNLP to version 2.0 on July 8, 2021, the existing GeoNLP IDs have been invalidated and replaced with new identifiers called GeoLOD IDs. Due to the lack of compatibility between GeoNLP IDs and GeoLOD IDs, which no longer function as identifiers for the same entities, it is necessary to delete the GeoNLP ID property from Wikidata and create a new property corresponding to GeoLOD IDs. This request is based on official announcements from GeoNLP ('Release of GeoNLP Version 2.0' and 'About the major renewal of GeoNLP'). Therefore, I request the deletion of the GeoNLP ID property. —Likibp (talk) 10:14, 5 November 2023 (UTC)
- GeoLOD ID (P12170) has now been created. Jonathan Groß (talk) 20:00, 22 November 2023 (UTC)
Hungarian National Namespace organisation ID (old) (P6989): (delete | history | links | entity usage | logs | discussion)
The property IDs and the formatting URL have also changed. A new property (Hungarian National Namespace organisation ID (new) (P11685)) was created, which was added to all old (P6989) data with the new identifier. This property is deprecated and can be deleted. (Control query: https://w.wiki/8JmT) —Pallor (talk) 18:21, 28 November 2023 (UTC)
- Keep It is still valuable information. While the official website (abcd.hu) is no longer available, these statements can still help match IDs found elsewhere to Wikidata items (and through them, even to new MNN IDs). —Tacsipacsi (talk) 15:16, 2 December 2023 (UTC)
- Tacsipacsi Can you list the data that is available on the old form with the old ID but not on the new ABCD? (otherwise the abcd.hu site is available). So what data would be lost if we delete the identifier? Pallor (talk) 17:25, 2 December 2023 (UTC)
- @Pallor: What we would lose is the fact that the MNN ID of the National Assembly (Q648716) using the old scheme is 204006. External identifiers are pieces of information themselves, not only references for other pieces of information. It may happen that third-party data reusers (or even ourselves) find a reference to an organization that uses this old scheme. Removing these statements would make it impossible to process that reference (at least without digging into item histories, which is probably not something one would want to do or want to write a program for). —Tacsipacsi (talk) 19:55, 2 December 2023 (UTC)
- @Tacsipacsi: By this argument, I think we could completely eliminate the deletion of external IDs for property IDs, since you argue that, whatever the topic, each ID carries information. But the practice is not: if the IDs do not lead to information that would be lost without them, then feel free to delete them. And these IDs do not carry any information, since everything that was on the page accessed with the previous ID is also on the page accessed with the new ID. Pallor (talk) 22:03, 2 December 2023 (UTC)
- Indeed, I generally don’t agree with the deletion of external ID properties unless creating them has never been a good idea (e.g. it is, and has always been, totally useless), or for technical reasons (including cases when a new property was created after a schema change for technical reasons, but the old ID can be algorithmically determined from the new one). I may be in minority with this opinion, though; if the vast majority of users who comment in this discussion are in favor of the deletion, I’ll accept the community decision. —Tacsipacsi (talk) 01:26, 3 December 2023 (UTC)
- I second all that Tacsipacsi wrote. Keep! I don't see the value in deleting defunct IDs either. – Máté (talk) 20:51, 28 January 2024 (UTC)
- Indeed, I generally don’t agree with the deletion of external ID properties unless creating them has never been a good idea (e.g. it is, and has always been, totally useless), or for technical reasons (including cases when a new property was created after a schema change for technical reasons, but the old ID can be algorithmically determined from the new one). I may be in minority with this opinion, though; if the vast majority of users who comment in this discussion are in favor of the deletion, I’ll accept the community decision. —Tacsipacsi (talk) 01:26, 3 December 2023 (UTC)
- @Tacsipacsi: By this argument, I think we could completely eliminate the deletion of external IDs for property IDs, since you argue that, whatever the topic, each ID carries information. But the practice is not: if the IDs do not lead to information that would be lost without them, then feel free to delete them. And these IDs do not carry any information, since everything that was on the page accessed with the previous ID is also on the page accessed with the new ID. Pallor (talk) 22:03, 2 December 2023 (UTC)
- @Pallor: What we would lose is the fact that the MNN ID of the National Assembly (Q648716) using the old scheme is 204006. External identifiers are pieces of information themselves, not only references for other pieces of information. It may happen that third-party data reusers (or even ourselves) find a reference to an organization that uses this old scheme. Removing these statements would make it impossible to process that reference (at least without digging into item histories, which is probably not something one would want to do or want to write a program for). —Tacsipacsi (talk) 19:55, 2 December 2023 (UTC)
- Both opinions represent a point of view that could be added to virtually all properties for deletion ("keep it because it's valuable"), but they don't explain what the value is in an unused and unrecoverable identifier. Such a belief essentially makes cancellation discussions impossible, since it is too general and elusive to be considered as an argument and to respond to it in a meaningful way.
- As additional information, I describe that the database currently consists of 62,060 items, of which 35 items have been transferred to Wikidata. No data can be read back from any of them, on the other hand, the new identifier makes all data available. I still maintain my deletion proposal. Pallor (talk) 21:43, 17 March 2024 (UTC)
YerelNet village ID (P2123): (delete | history | links | entity usage | logs | discussion)
Yerelnet website was a government-supported website in Turkey. There was an identifier id for every village in Turkey and it had an index about all villages. However, this project was terminated by a law in 2018. The domain name of the site (https://www.yerelnet.org.tr) is currently used for personal purposes and the site does not currently serve as a database. Also, all id numbers added to wikidata pages are currently not working. For these reasons, it would be appropriate to delete Property:P2123. —Sadrettin (talk) 15:34, 3 December 2023 (UTC)
- Delete It seems that this site is currently not working. It is better to make it stop. Mereyü 💬/✉️ 16:06, 3 December 2023 (UTC)
- Delete Right. Yerelnet is not working anymore. We don't need this property. --Kurmanbek 💬 16:23, 6 December 2023 (UTC)
- @Sadrettin: Have you exported the current IDs (for historical purposes)?--Geverkshaft (talk) 10:18, 17 December 2023 (UTC)
- Delete Looks reasonable. Nanahuatl (talk) 18:54, 27 December 2023 (UTC)
- Keep for now, as it's the only way to find villages (or places that were villages until recently) in a district (although now several years out of date). Many have been archived or included in an archived list from which the identifier can be found. It was mostly accurate, although because places could be added it had a few (around 5-10) additions that were not part of the data originally added to the site that were probably neighbourhoods or other locations (although I'm not sure if any of these are in Wikidata). Otherwise the P31 can be vague (Erikli (Q1155400) for example, which otherwise only has a GeoNames ID). Wikidata:Property proposal/Tüik number needs proposing as separate properties, including one for village; when approved and added to items, it can replace this. Peter James (talk) 21:03, 4 February 2024 (UTC)
- I also noticed most instances of mahalle (Q17051044) were changed to neighborhood (Q123705) (which seems incorrect, as is the statement that Q123705 is a subclass of administrative territorial entity type (Q15617994) - and in most countries Q123705 isn't an instance of that either). Instances of village in Turkey (Q1529096) would then become village (Q532) to be consistent, although I prefer more specific administrative units for Wikidata - at least make it clear whether something is an administrative unit or not. Adding statements such as that in Q123705 (or quarter (Q2983893), where the claim to be a subclass of administrative territorial entity (Q56061) is wrong in some countries and conflicts with the description) is not the correct way to clarify this, or to fix constraint violations, or whatever was intended. Peter James (talk) 01:38, 18 February 2024 (UTC)
- YerelNet links were added years ago and the website closed 8 years ago. If you believe that you can rely on these links and find villages in Turkey, this list will be very incomplete. Frankly, I can't find a single concrete benefit for not deleting YerelNet connections. Sadrettin (talk) 19:18, 17 June 2024 (UTC)
- Delete per nom. --Wüstenspringmaus talk 11:48, 3 June 2024 (UTC)
- Keep The Wayback Machine has over 35,000 archived pages (see IDs starting with 23, 24, 25, 26 and 3). We have 35,691 IDs, so almost all of them should have an archived version.
- The pages I looked at had information such as population history, altitude and a map showing the location. There are at least 10,000 pages linking to the pages on other wikis, according to the Global Search tool.
- - Nikki (talk) 12:53, 21 August 2024 (UTC)
- Keep The data seems to be historically useful and the wayback machine has pages that contain some of the information. ChristianKl ❪✉❫ 09:09, 31 October 2024 (UTC)
Singapore Infopedia ID (former scheme) (P8350): (delete | history | links | entity usage | logs | discussion)
The URIs of Singapore Infopedia articles had been amended. For example, the URI for the article of Siva Choy https://eresources.nlb.gov.sg/infopedia/articles/SIP_1665_2010-04-28.html is replaced by https://www.nlb.gov.sg/main/article-detail?cmsuuid=8709468f-f41f-44b4-9e8a-ef6ac25accfe. We would like to propose a new property of the same name Singapore Infopedia ID to replace the current property P8350. The request for a new property was made at Wikidata:Property proposal/Singapore Infopedia ID (new scheme). The label of P8350 had been renamed Singapore Infopedia ID (former scheme). —Nlbkos (talk) 05:38, 26 February 2024 (UTC)
Argentine Chamber of Deputies ID (P4454): (delete | history | links | entity usage | logs | discussion)
Initially discovered because the ID's links were timing out. Looking at the spanish webpage (https://www.hcdn.gob.ar/diputados/index.html) it appears that only current politicians have a profile, but ideally an extra set of eyeballs would be nice for a confirmation. Anyways, since the identifiers are unstable, there is no point in a property and so it shall be deleted. —Infrastruktur (talk) 15:33, 10 March 2024 (UTC)
- Keep Unless the IDs are entirely transient (i.e. get re-used for someone else) that only seems like a reason to update or remove the links, not to remove the property entirely. Not having a current profile page doesn't mean that the IDs aren't used elsewhere on the site, or won't be included in future if the person is re-elected or the site is redesigned, or that these IDs aren't in use in historic data-dumps etc. I don't understand why we would want to throw that information away. Oravrattas (talk) 16:08, 10 March 2024 (UTC)
- If the site does not employ a scheme to prevent reuse of identifiers then reuse is a distinct possibility. The identifier seems to be based on one letter for given names and the whole surname. And surnames are reused all the time, making ID collisions fairly likely. Infrastruktur (talk) 17:00, 10 March 2024 (UTC)
- Do you have examples of this ever happening? The idea that an identifier might get reused seems pretty thin as a rationale for deleting a well-used property. Oravrattas (talk) 01:17, 13 March 2024 (UTC)
- If the site does not employ a scheme to prevent reuse of identifiers then reuse is a distinct possibility. The identifier seems to be based on one letter for given names and the whole surname. And surnames are reused all the time, making ID collisions fairly likely. Infrastruktur (talk) 17:00, 10 March 2024 (UTC)
statistical unit (P2353): (delete | history | links | entity usage | logs | discussion)
I propose deleting statistical unit (P2353) since its current use differs greatly from the original idea, both of which could be better modelled through other existing properties.
Most of the P2353 statements are to my understanding essensially duplicates of instance of (P31), except only for telling that the item is an instance of some sort of statistical unit. For example, on one of the example items of the property, Bni Gmil (Q1942317) has a statement statistical unit (P2353)rural commune of Morocco (Q17318027) meanwhile P31 has the exactly same value. On the second example item, Orchard Ridge (Q23137124), there is a statement statistical unit (P2353)Neighborhood Statistical Area of Baltimore (Q111902602) but P31 doesn't have that value, even though it clearly should. The property is currently stated on 246 items, of which 173 are located in Baltimore, United States.
If I understood correctly, the original purpose of P2353 presented in the property proposal was to model what kind of units populate a dataset or database. I can find only 13 items where P2353 is used this way, all of which originate in France, for example ASPIC (Q101086386) and Fichier des personnes décédées (Q80900474). In my opinion these cases could be better modelled through existing properties has part(s) (P527) or has part(s) of the class (P2670) as is done in most items about databases. —Samoasambia ✎ 20:04, 13 April 2024 (UTC)
- I've suggested to create the property because I needed to describe datasets or database. The idea is that some datasets describe countries, some datasets describe organization, etc. See Q3509449#P2353 for a good example.
- has part(s) (P527) doesn't work for my use case
- has part(s) of the class (P2670) is better than has part(s) (P527) but not precise enough.
- The most precise description would be "the subject describes entities of this class". Until I find another property matching this definition, I'm not in favour of the deletion of P2353. PAC2 (talk) 22:02, 15 April 2024 (UTC)
Fossilworks taxon ID (P842): (delete | history | links | entity usage | logs | discussion)
The website has been down for a very long time and all its contents were moved to Paleobiology Database taxon ID (P10907): identifier for a fossil taxon in the Paleobiology Database. The IDs were kept the same across both databases, so a bot could theoretically just chance one for the other. —Trooper57 (talk) 17:23, 29 May 2024 (UTC)
- It does look like fossilworks is no more. It did go down for a while before (months?) and returned, but this seems terminal. The two sites ran in parallel for many years, supposedly using the same database with the fossilworks mirror updated daily (according to the fossilworks FAQS). The records were not exactly the same, with some occasional differences in the ecology and number of collections.
- For some reason the Paleobiology Database taxon ID (P10907) only has about 11,000 entries on Wikidata, whereas fossilworks has over 100k.
- The taxonbar on English Wikipedia still uses Fossilworks taxon ID (P842). When fossilworks went down we changed it to get the ID from Fossilworks taxon ID (P842) and then link it to PBDB. Obviously this workaround wouldn't be necessary if Paleobiology Database taxon ID (P10907) was fully populated. Jts1882 (talk) 13:57, 2 June 2024 (UTC)
Fossilworks reference ID (P7720): (delete | history | links | entity usage | logs | discussion)
Fossilworks (Q796451) has been dead for some time now; Fossilworks reference ID (P7720) has been superseded by Paleobiology database reference ID (P12793) and all the instances of its use copied across (they in fact matched 1:1); thank you, Maculosae tegmine lyncis (talk) 06:00, 7 June 2024 (UTC)
- Question Are we used to delete properties on the basis that they are instances of Wikidata property for a discontinued website (Q60457486) (currently we have 127 of such properties)? --Horcrux (talk) 10:42, 2 July 2024 (UTC)
Charity Navigator ID (obsolete) (P4861): (delete | history | links | entity usage | logs | discussion)
The source no longer uses these identifiers, and no longer provides a way to access or search for entities by using this identifier. Some prior related discussion is at Property talk:P4861#New Scheme Daask (talk) 17:38, 18 June 2024 (UTC)
@Ringbang, Newt713, BrokenSegue, Problemsmith, Pintoch: Courtesy ping to editors who have worked on this item. Daask (talk) 17:45, 18 June 2024 (UTC)
- accessible via internet archive do not delete. https://web.archive.org/web/20221204131344/https://www.charitynavigator.org/index.cfm?ein=200049703&bay=search.results BrokenSegue (talk) 18:01, 18 June 2024 (UTC)
- @BrokenSegue: Your example uses IRS Employer Identification Number (P1297), not Charity Navigator ID (obsolete) (P4861). That said, some archives are available. Daask (talk) 20:58, 5 December 2024 (UTC)
- Delete No longer existing. There are currently ~110 entries that have an Charity Navigator ID (obsolete) (P4861) but no IRS Employer Identification Number (P1297) (-> Query). Perhaps we can work on that. I exported it. I also made sure, that all entries with Charity Navigator ID (obsolete) (P4861) are marked as a Nonprofit and have a value for country. --Newt713 (talk) 18:22, 18 June 2024 (UTC)
- Charity Navigator only rates large nonprofits that have been around for several years. It should be possible to get all of those charities' EINs from the charities, as one of the CN criteria is that the IRS form 990 is accessible from the charity's website, and the EIN will be in the 990. The Squirrel Conspiracy (talk) 06:52, 26 July 2024 (UTC)
- There is no Item left with a Charity Navigator ID (obsolete) (P4861) and no IRS Employer Identification Number (P1297). IRS Employer Identification Number (P1297) has the URL to Charity Navigator as an third-party formatter URL (P3303). Perhaps it's time to delete or archive this property. --NGOgo (talk) 20:15, 2 November 2024 (UTC)
(Moved from Wikidata:Properties for deletion —Ameisenigel (talk) 09:08, 19 June 2024 (UTC))
- Comment It seems unlikely to me that this property will be useful in the future. At the moment, it's mostly a source of confusion to Wikidata editors who improperly add EINs to this property. I think the main argument for keeping it would be if sources external to Wikidata have used this identifier, which I don't think has occurred. Is there a way to search VIAF processed record contents for links to charitynavigator.org? Daask (talk) 21:00, 5 December 2024 (UTC)
Facebook page ID (P4003): (delete | history | links | entity usage | logs | discussion)
Redundant to Facebook numeric ID (P11705). The page’s ID is actually only the number at the end. —MSMST1543 (talk) 15:54, 4 July 2024 (UTC)
- Delete. I have verified that all of the following pages redirect to the same page
- https://www.facebook.com/pages/Statistical-Society-of-Australia-Inc/186936994713723
- https://www.facebook.com/pages/anyrandomtext/186936994713723
- https://www.facebook.com/Statistical-Society-of-Australia-Inc-186936994713723
- https://www.facebook.com/anyrandomtext-186936994713723
- https://www.facebook.com/186936994713723
- I do have a recollection that at least at some points in Facebook's history, these kinds of URLs produced different webpages for the same Facebook user. It may be worth doing further tests to consider that possibility. Daask (talk) 13:44, 28 October 2024 (UTC)
- Delete. Yes, that would be good. A lot of people confuse it with Facebook username (P2013) and Links don't work. But there is the need to transfer/clean-up data first. If data in Facebook page ID (P4003) are in the right format, they can be transferred to Facebook numeric ID (P11705), in most other cases transfer it to Facebook username (P2013).--NGOgo (talk) 21:57, 1 December 2024 (UTC)
TGbus ID (P10996): (delete | history | links | entity usage | logs | discussion)
Website is not available, response status codes 503 —Rainsday (talk) 06:36, 6 July 2024 (UTC)
- Notified participants of WikiProject Video games Rainsday (talk) 06:44, 6 July 2024 (UTC)
- Changed the formatter URL to Wayback Machine (Q648266). Matthias M. (talk) 10:53, 6 July 2024 (UTC)
- Keep Yeah, archived links will be fine here. By the way, it is not said that the site is completely dead, it may still appear online. This is what the error 503 "Service Temporarily Unavailable" says itself. Regards Kirilloparma (talk) 00:42, 7 July 2024 (UTC)
Géopatronyme ID (P3370): (delete | history | links | entity usage | logs | discussion)
Website related to it seems to redirect and is no longer relevant to what the property was created for. —Akaibu (talk) 14:50, 31 August 2024 (UTC)
- Disagree. Personally, in my use, the site is fully functional and remains complementary to lexeme Geneanet family name ID. —— DePlusJean (talk) 05:18, 13 September 2024 (UTC)
- Support I have tested randomly: at Bowers (Q18549), Kern (Q25229), Fotopoulos (Q28657), Lund (Q29599), De Lange (Q32876) all links lead to an error page of filae.com. --Balû (talk) 10:29, 16 September 2024 (UTC)
North Carolina session law (P9590): (delete | history | links | entity usage | logs | discussion)
The property is a law identifier for North Carolina, US. I think law identifier (P8550) should be used instead since the property does not link anywhere and there is no other reason for a separate law indentifier property just for North Carolina. The property is currently used on zero items. —Samoasambia ✎ 19:00, 10 October 2024 (UTC)
Wikisimpsons article ID (P10291): (delete | history | links | entity usage | logs | discussion)
As far as i can tell this identifier is pretty much identical to MediaWiki page ID (P9675) Trade (talk) 02:42, 15 October 2024 (UTC)
- Oppose, as we currently have twenty-eight Wikidata property linking to articles in MediaWiki websites by wgArticleId. I think you shuld open a broader discussion for deciding a uniform solution.
- In any case, before deleting any of such property we should create the corresponding property linking the article's title (like these ones). Check out the examples provided in MediaWiki page ID (P9675). --Horcrux (talk) 09:22, 29 October 2024 (UTC)
ACUM Work ID (P12990): (delete | history | links | entity usage | logs | discussion)
Appears to be an exact duplicate of ACUM work ID (P8201).
@לוכסן: who proposed the duplicate, @מקף, Kdkeller, Geagea: who supported the duplicate, @ZI Jony: who created the duplicate, and @Tomer T, יונה בנדלאק, בורה בורה, Pamputt: involved in the property proposal for the original. Mahir256 (talk) 19:39, 17 November 2024 (UTC)
- Ya duplicate. Geagea (talk) 21:23, 17 November 2024 (UTC)
- Delete, it’s duplicate! -- Regards, ZI Jony (Talk) 03:56, 18 November 2024 (UTC)
- Yes, an accidental duplicate in principle. I didn't realize that existed.
- But, ACUM Work ID (P12990) specified (as I proposed) that the ID is six digits exactly (as always listed on the ACUM website, as in Imagine (Q16342332) –> 251038, even though the URL has a "1" at the beginning (=1251038), making seven digits), but ACUM work ID (P8201) doesn't specify (so probably seven digits, in a way that doesn't agree with how the ACUM website lists its IDs).
- So, I think the six digits is better.
- So, we should consider what to do here. לוכסן (talk) 07:35, 18 November 2024 (UTC)
- Delete it's a dupicate. @לוכסן: can you update p8201 with additional data from p12990? - yona b (talk) 08:50, 18 November 2024 (UTC)
AAAS keyword ID (P7456): (delete | history | links | entity usage | logs | discussion)
Notified participants of WikiProject Authority control, @Pigsonthewing(proposer), @Pintoch(creator)
The URL formatter doesn't work starting from mid-2021, and there seems no replacement. This property is mostly unused (1 main statement & 1 qualifier other than example cases). —Mzaki (talk) 12:20, 28 November 2024 (UTC)
- Delete That's unfortunate that they removed the website. I don't see any point keeping it with such low usage here. ArthurPSmith (talk) 12:59, 28 November 2024 (UTC)
- Delete +1 --NGOgo (talk) 13:25, 28 November 2024 (UTC)