Properties for deletion

This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:

Place the {{Property for deletion}} template on the property talk page.
Open the discussion by typing the property number below and pressing "Add a new request".
Transclude the subpage under #Requests below.
Notify the user who originally proposed the property and the property creator who created it on their respective talk pages.
Check if the property is being used in other projects (using {{ExternalUse}}) and if it is, leave a message on a project discussion page by notifying the participants.

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:

To merge a property to another, or request to deprecate a property in favor of another.
To change the data type of a property currently being used.
Rarely, to delete a property with no replacement (e.g. it refers to an external website that is closed and/or not suitable for Wikidata).

Properties for deletion should not be used:

To change the scope or purpose of a property; these should be discussed at the talk page of the property, project chat, or requests for comment.
To request of undeletion of a property. To challenge a recently closed properties for deletion, you may use administrators' noticeboard; otherwise, you may repropose the property.

Edit

Translate this header box!

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.

Property:P4728

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)[reply]

Property:P5301

Replaced by P10780 Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).[reply]

Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).[reply]

Notified participants of WikiProject Podcasts. Nomen ad hoc (talk) 09:17, 27 May 2022 (UTC).[reply]

@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)[reply]
- @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).[reply]

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)[reply]

@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)[reply]

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)[reply]
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)[reply]

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)[reply]

Property:P7662

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)[reply]

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)[reply]
Info The problem has already been raised in May 2022, and resolved. Cordially. ―Eihel (talk) 23:35, 4 August 2023 (UTC)[reply]
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)[reply]
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)[reply]

Property:P1129

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Property:P2650

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@Jane023: A quick SPARQL query indicates that it is currently in use on 18 WikiProject items. Daask (talk) 13:43, 27 October 2023 (UTC)[reply]

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)[reply]

Support Move all uses to P101 and delete.Vojtěch Dostál (talk) 12:47, 25 June 2024 (UTC)[reply]

Support I totally agree with all that's been said above about confusion with P101. Powerek38 (talk) 09:55, 26 November 2024 (UTC)[reply]

Support Agree with everything said. --Nw520 (talk) 10:05, 26 November 2024 (UTC)[reply]

Property:P4830

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)[reply]

Notified participants of WikiProject Sweden

Notified participants of WikiProject Association football --Ameisenigel (talk) 12:27, 7 July 2024 (UTC)[reply]

Property:P5400

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)[reply]

GeoLOD ID (P12170) has now been created. Jonathan Groß (talk) 20:00, 22 November 2023 (UTC)[reply]

Property:P6989

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

Property:P2123

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)[reply]

Delete It seems that this site is currently not working. It is better to make it stop. Mereyü 💬/✉️ 16:06, 3 December 2023 (UTC)[reply]

Delete Right. Yerelnet is not working anymore. We don't need this property. --Kurmanbek ^💬 16:23, 6 December 2023 (UTC)[reply]

@Sadrettin: Have you exported the current IDs (for historical purposes)?--Geverkshaft (talk) 10:18, 17 December 2023 (UTC)[reply]

Delete Looks reasonable. Nanahuatl (talk) 18:54, 27 December 2023 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Delete per nom. --Wüstenspringmaus _talk 11:48, 3 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

Property:P8350

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)[reply]

Property:P4454

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Property:P2353

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)[reply]

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)[reply]

Property:P842

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)[reply]

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)[reply]

Property:P7720

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)[reply]

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)[reply]

Property:P4861

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)[reply]

@Ringbang, Newt713, BrokenSegue, Problemsmith, Pintoch: Courtesy ping to editors who have worked on this item. Daask (talk) 17:45, 18 June 2024 (UTC)[reply]

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)[reply]

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)[reply]
- 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)[reply]
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)[reply]

(Moved from Wikidata:Properties for deletion —Ameisenigel (talk) 09:08, 19 June 2024 (UTC))[reply]

Property:P4003

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)[reply]

Delete. I have verified that all of the following pages redirect to the same page
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)[reply]
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)[reply]

Property:P10996

Website is not available, response status codes 503 —Rainsday (talk) 06:36, 6 July 2024 (UTC)[reply]

Notified participants of WikiProject Video games Rainsday (talk) 06:44, 6 July 2024 (UTC)[reply]

Changed the formatter URL to Wayback Machine (Q648266). Matthias M. (talk) 10:53, 6 July 2024 (UTC)[reply]

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)[reply]

Property:P3370

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)[reply]

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)[reply]
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)[reply]

Property:P9590

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)[reply]

Property:P10291

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)[reply]

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)[reply]

Property:P12990

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)[reply]

Ya duplicate. Geagea (talk) 21:23, 17 November 2024 (UTC)[reply]

Delete, it’s duplicate! -- Regards, ZI Jony ^(Talk) 03:56, 18 November 2024 (UTC)[reply]
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)[reply]
Delete it's a dupicate. @לוכסן: can you update p8201 with additional data from p12990? - yona b (talk) 08:50, 18 November 2024 (UTC)[reply]

Property:P7456

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)[reply]

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)[reply]

Delete +1 --NGOgo (talk) 13:25, 28 November 2024 (UTC)[reply]

On hold

These discussions have been closed but are awaiting deletion.

Property:P10589

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.

Done with 10 registered users wanting deletion and only 7 opposing there a consensus to delete and we don't want Wikidata to be in legal trouble for pirated material. – The preceding unsigned comment was added by ChristianKl (talk • contribs) at 15:30, 31 October 2024 (UTC).[reply]

The website MangaDex is a website for scanlation (Q557923) and therefore gives people access to copyright protected works for free without holding a license to publish it or consent of the copyright holder. The website infringes copyrights and I don't see any reason why wikidata should link items to such a website.

—Christian140 (talk) 07:58, 7 November 2022 (UTC)[reply]

Weak oppose Linking to a website doesn’t mean endorsing its practices. The question in this case would be whether the benefits of having this site linked outweigh the concerns about legal issues. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 10:12, 7 November 2022 (UTC)[reply]

Delete in the past Japanese publisher sent cease and desist letters to aggregators for Scanlation. Having this property might essentially makes us an aggregator for Scanlation and thus opens up the possibility of legal threads against Wikimedia. I think it's ideal if your community can self regulate in this regard and delete the property without needing to interact with Wikimedia legal. ChristianKl ❪✉❫ 15:12, 7 November 2022 (UTC)[reply]

(Japanese publishers having sent cease and desist letters for scanlation sounds … interesting given that it’s not their – arguably monetary – rights infringed upon, but those of the author, and in Japan itself it wasn’t possible until a few years ago to take legal actions on behalf of a third party against copyright violations. Just as an aside. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 15:53, 7 November 2022 (UTC))[reply]

Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl ❪✉❫ 00:15, 10 November 2022 (UTC)[reply]

Admittedly yes, therefore an aside (basically saying that they are taking advantage of another country’s legal provisions where this would not be possible in their own country – indeed not of interest here). --2A02:8108:50BF:C694:1432:F47C:55CC:B105 19:37, 12 November 2022 (UTC)[reply]

Delete I created this property honestly not knowing it was a scanlation website or what scanlation was. Linking to a website that distributes copyrighted material is basically assisting in that distribution which is illegal. Lectrician1 (talk) 20:18, 7 November 2022 (UTC)[reply]

Delete As for scanlation sites, Japanese and U.S. publishers declared in a joint statement in 2010 that they are illegal. By making them available for free, they are infringing on the financial benefits that copyright holders rightfully deserve. Afaz (talk) 04:01, 9 November 2022 (UTC)[reply]

While this is undoubtedly true, there are no financial benefits for copyright holders anyway if nobody publishes their work commercially in a country. If there is no “official” translation that is sold in, e.g., the US, anyone who wants to read it (in English) there has to resort to “unofficial” translations, which have no choice but to infringe on copyright. I don’t want to endorse copyright violations, in no way, but the “financial” point of view doesn’t get us anywhere here. That said, what was the point of creating links to the specific site discussed here in the first place? What benefits were seen in linking it? --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 10:18, 9 November 2022 (UTC)[reply]

As far as the laws are concerned people can import Japanese comics whether or not they are translated. The Berne convention exists to give mutual recognition of copyright and not require products to be marketed in a country to be protected in that country. ChristianKl ❪✉❫ 00:13, 10 November 2022 (UTC)[reply]

That’s not the point. There are probably many people in the world who want to read Japanese comics, but cannot read Japanese. That’s the reason why scanlation (and regular translation) exists in the first place. Of course it would be better if they paid the original authors, but the author doesn’t get any money regardless of whether someone abroad reads their comic in scanlation form (without paying) or doesn’t read it at all. Hence the “financial” point of view doesn’t get us anywhere here. There’s more to copyright than remuneration (and the Berne convention presumably exists regardless of financial considerations). --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 12:45, 10 November 2022 (UTC)[reply]

Copyright is driven by actual laws. You might disagree with those laws but they exist. Scanlation clearly creates deriviative works of copyrighted works. In the US context where Wikimedia has it's legal home, that's forbidden by copyright law unless you have permission or can argue for fair use. Courts have made many rules on copyright and have developed a concept of financial interests in the process. You might not like it or disagree with it, but that's still the law of the land. ChristianKl ❪✉❫ 12:20, 12 November 2022 (UTC)[reply]

Neither do I disagree with copyright laws (where did I claim that?) nor do I deny that scanlation violates them. All I’m saying is that it does not hurt the authors financially and that the claim by Afaz that they infringe on “the financial benefits that copyright holders rightfully deserve” is therefore misleading. Of course they have “financial interests” – they are selling their works in Japan, after all –, but that’s different from “financial benefits”. (Easy example: A greengrocer has a financial interest in getting vegetables sold, but no financial benefit if nobody buys them – a reason for which might be that all the people who would like to buy them live in another city. Does this make stealing the vegetables from the greengrocer and giving them away for free in that other city legal? Obviously not. Does the greengrocer have a financial damage? No, he doesn’t receive money for the vegetables anyway.) But let’s stop this pointless discussion here – both of us agree that scanlation is a copyright violation, while we seem to disagree on why it is (or maybe not; the deriviative work argument is independent of financial aspects, and I’m not sure the US context is actually necessary for it, but anyway). The reason why it derailed was probably my justification for the continuing widespread existence of scanlation despite its illegality – which is unnecessary for the point I wanted to make, I think (now). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:07, 12 November 2022 (UTC)[reply]

The reason why I’m so nit-picky about this is that it often gets mixed up. If remuneration were the problem, scanlators could solve it by taking money from their “customers” and using it to pay the original authors – but in the absence of permission to do so this would still be a copyright violation. That there is more to copyright than remuneration can also be seen in the advent of Creative Commons licences, where copyright holders waive their right to remuneration without (necessarily) waiving other rights they deserve, such as proper attribution (a misconception many have: “It’s free, so I can use it any way I want”). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:33, 12 November 2022 (UTC)[reply]

Both Afaz's financial argument and your rebuttal are political in nature and a distraction from the merits or deficiencies of the proposal. Let's not derail the discussion into general arguments about intellectual property vs. free culture and questions of artist rights and compensation. The fact that the website is in fact illegal in at least some if not most Wikimedia jurisdictions is a relevant consideration. Anon20240724 (talk) 04:38, 21 July 2024 (UTC)[reply]

Question I see questions of copyright here but if this was actually an issue of concern with wiki projects merely linking, then wouldn't this be a major issue with wiki projects linking to the Internet Archive (Internet Archive ID (P724) and the works there that are still under copyright? If there isn't an issue with that I dont see the issue here. -Jeanjung212 (talk) 20:51, 18 November 2022 (UTC)[reply]

@Jeanjung212: Can you link any item there where the site infringes the copyright? On the first look, all the content looks like public domain and creative commons as well as previews. Also, not that copyright is not the problem. There are also links to Netflix. Copyright infringement is the problem. --Christian140 (talk) 07:58, 19 November 2022 (UTC)[reply]

This website (linked from Tetris (Q71910)), for example, doesn’t seem to be public domain, so technically (ianal) the Internet Archive is infringing on the creator’s copyright by making a copy of it available. (It’s just that no one bothers to sue the Internet Archive, I think.) --Data Consolidation Officer (talk) 21:11, 21 November 2022 (UTC)[reply]

Hmmm. But on all websites where every user can upload content, copyright infringement happens. On wikipedia and commons, too. Just, eventually it gets deleted. However, for mangadex, copyright infringement is the core of the website. For internet archive, they have this site: Rights – Internet Archive Help Center. So, you could report content you think that infringes copyright. But here, I am actually not sure if it is copyright infringement. A lot of old software is made available for free and you can download them from many serious websites. --Christian140 (talk) 08:01, 22 November 2022 (UTC)[reply]

Internet Archive, or archiving in general, might even be covered by Fair Use (I simply don’t know). And given the large number of pages archived there, reporting copyright violations would be a Sisyphean task. As I stated below, I don’t think there’s a legal issue with mere linking, but P10589 is very dispensable anyway. --Data Consolidation Officer (talk) 20:23, 22 November 2022 (UTC)[reply]

The Internet Archive is also recognised as a library by the US government. Thibaut (talk) 10:39, 13 February 2023 (UTC)[reply]

Comment Linking doesn’t mean endorsing, afaik, so the site’s copyright violations alone wouldn’t be valid grounds for deletion of this property. Having a look at the property proposal discussion, however, it seems that the property was created without thorough discussion, basically because “I think properties for it would be useful”. Wikidata should, imho, be extremely restrictive with respect to which external databases it chooses to systematically link, given the considerable effort of maintaining such link collections, avoiding inconsistencies and so on. That’s why I’d tend to vote for deletion at the moment, unless someone provides a good reason why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 21:03, 21 November 2022 (UTC)[reply]
It's 100% endorsing. You're exposing the copyrighted works to a wider audience by linking to them. You're clearly assisting in their distribution. Lectrician1 (talk) 21:30, 21 November 2022 (UTC)[reply]
Sorry, I should have made clearer that I was specifically talking about legal issues. There can of course be ethical issues with linking (depending on intention), but afaik (and ianal, so please correct me if I’m wrong) courts in various contries have established that website operators cannot be held liable for criminal violations by other sites they merely link, so Wikimedia Foundation could not be (successfully) sued for those links or something like that. Anything else is a question of whether we, as a community, want those links, but as I said, I don’t really see any reason anyway why we should. --Data Consolidation Officer (talk) 20:12, 22 November 2022 (UTC)[reply]

There's a difference between having a simple link to MangaDex and having a system on Wikidata that tells Wikidata users for every manga, the exact page where they can download a copyright violating copy of that manga. Having a link to every single manga, is like torrent websites that link to individual content and torrent websites do face legal problems. ChristianKl ❪✉❫ 11:12, 27 November 2022 (UTC)[reply]
Which all the more raises the question why Wikidata would want such a system in the first place; a question the answer to which I still don’t see. Given that it took nine months (the property was created in early April) until someone noticed that there are copyright violations linked, I wouldn’t consider any claim about copyright infringement endorsement intentions plausible (in contrast to torrent sites; and indeed those links will have been created in good faith in most cases), but let’s the lawyers fight that out (or not). --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)[reply]

Delete, as indicated, on the grounds that there has been no good reason given why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)[reply]
As the property proposer, I have no objection to deletion based on the arguments provided. Tol (talk | contribs) @ 01:01, 30 November 2022 (UTC)[reply]
Comment I won't comment on the actual scanlated content MangaDex works, but they are a gold mine of information, as they maintain links to many of the other manga databases on the internet. Maybe deletion can be waited on until my bot is able to copy as many of the external linkings as possible. In that case, there is another issue brewing, as whenever my bot pulls information from MangaDex it makes a reference and puts the full URL into the reference URL property, although I theorize it would be trivial to clean those up (SPARQL query for stated in MangaDex would bring them all up). RPI2026F1 (talk) 01:49, 9 December 2022 (UTC)[reply]
Alternatively, would the problem not solve itself if the link was simply removed, rather than deleting the entire property? RPI2026F1 (talk) 01:51, 9 December 2022 (UTC)[reply]

Comment Looks like the property is going to be removed. It seems reasonable however that the actual removal can be put on hold for a period of up to 3 months (or less) to allow for links to other sites to be extracted from this identifier. Infrastruktur (talk) 20:54, 9 December 2022 (UTC)[reply]
Yes, I'm trying to get a whole bunch of properties created so I can extract maximal information from the source. I can see about 8 or 10 new properties being partially populated on top of what is already being extracted. RPI2026F1 (talk) 16:17, 21 December 2022 (UTC)[reply]
Delete per the above copyright and legal concerns. ミラP@Miraclepine 19:47, 9 December 2022 (UTC)[reply]
Keep Wikidata is neither a judge nor a police officer. Besides problematic links, the database contains other useful data as well (date of publication, artist, genres, alternative titles, even links to official shops). --Jklamo (talk) 18:30, 21 December 2022 (UTC)[reply]
Keep per Jklamo. We shouldn't censor the identifier of this useful database unless we have clear evidence of law. Laftp0 (talk) 13:47, 22 December 2022 (UTC)[reply]
Delete per the above copyright and legal concerns, we already have better manga/anime databases properties like ANN, MAL and Anilist that don't host illegal content, we don't need some random scanlation website. --Thibaut (talk) 14:30, 20 January 2023 (UTC)[reply]

Weak oppose Linking isn't endorsement, and it's very useful for getting links to other manga services. Although, ultimately if it is deleted we can still use its API to grab links as long as one of AniList/MyAnimeList/Kitsu are linked, so it wouldn't be the end of the world. Ultimately, my opinion would be based on the opinion of the Wikidata team as to whether this kind of site should be linked to. FWIW, from what I can tell MangaDex does respect the wishes of copyright holders if they do request a takedown, although whether that redeems the site is debatable. Nicereddy (talk) 02:09, 21 January 2023 (UTC)[reply]

Keep, Mangadex is just a platform (non-commercial and ad-free), which like other platforms like YouTube or Facebook could be used for publishing anything, but no evidence provided by nominator that this website opposes copyright holders in any way (other than "it is free, therefore it is illegal"). The rules are pretty restrictive there, cases when obtaining a license is required are mentioned. Lockal (talk) 04:51, 13 February 2023 (UTC)[reply]

The “rules” are not that “restrictive”:

Any scanlated release is allowed to be uploaded regardless of the existence of official translations […]

And even if there’s no official translation or it’s out of print, translating something that is copyright-protected and uploading it to the web is still illegal per the Berne convention (see above).

The difference with Facebook or YouTube is that they disallow illegal content and respond to DMCA requests. Thibaut (talk) 09:53, 13 February 2023 (UTC)[reply]

A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)[reply]

The website is literally designed to host illegal content, like Christian140 said above: it's at its core.

The mere fact that their domain reseller and/or Cloudflare had to kick them away because of the number of DMCA requests they were getting is a strong indicator ([1][2]). One of these requests was from VIZ Media, which is owned by two major Japanese publishing companies (Shueisha and Shogakukan).

Now, please enlighten me how a website hosting full manga releases translated in multiple languages without the copyright holders' permission doesn't infringe Japanese copyright law and therefore the Berne Convention? Thibaut (talk) 18:17, 12 March 2023 (UTC)[reply]

My point was that there is a way to legally host a scanlate website (or any other types of derivative works). It is not difficult to receive a permission from copyright holder to publish your own translation under well defined conditions: non-commercial (optionally providing additional details to help copyright holder to verify that translator are not seeking profit with translation) and only on specific website. Actually, I did it multiple times (not for manga, but it does not matter). Consider that all mindful translators received a permission: it is called "presumption of innocence".

The links you provided mentions that some time ago a fan group that has been coloring the Boruto manga used official scanlation, which resulted in DCMA takedown. Such types of uploads are not allowed on MangaDex:

Scans of physical official releases or rips of digital official releases/webcomics from official sources, such as original releases (raws) or officially translated releases, are not allowed to be uploaded.

Lockal (talk) 10:58, 13 March 2023 (UTC)[reply]

Delete - per legal concerns. Under Japanese copyright law, it is a violation of copyright law to link to a site that is known to copyvio. Links that may violate laws should not be kept. ~~The server for this site may not necessarily be located in Japan, but it should be sensitive to the law.~~ The server for this site is not necessarily located in Japan, but I think it should be as sensitive to the law as possible. Syunsyunminmin (talk) 10:15, 19 February 2023 (UTC);edit – The preceding unsigned comment was added by Syunsyunminmin (talk • contribs).[reply]

Delete - Link to a site that is a violation of copyright law. --Fralambert (talk) 19:22, 12 March 2023 (UTC)[reply]

Keep As far as I am aware:

1. MangaDex acts in full compliance with U.S. law under the DMCA act

2. MangaDex has never faced charges for hosting what they do. (they have been subpoenaed once, but that's very much not the same thing) Binarycat32 (talk) 00:52, 31 January 2024 (UTC)[reply]

@Binarycat32: One of their staff literally says that "Mangadex doesn’t adhere to DMCA requests".

Speaking of DMCA, see also above. Thibaut (talk) 06:06, 31 January 2024 (UTC)[reply]

Delete the copyright problem alone is enough to delete (in itself and because this make this website less likely to be perennial). In addition to that, I see that this property is use only on ~2800 items and ~25000 references, plus in most cases there is other identifiers and others references. It's maybe a "gold mine of information" but it's clearly not the only one, deleting these data would mean only a negligible lack of information in the end. Cheers, VIGNERON (talk) 15:30, 1 February 2024 (UTC)[reply]
"in most cases there is other identifiers"

a lot of those identifiers have been imported from mangadex. as far as i'm aware, mangadex is the only site other than wikidata that maintains links to other manga sites in this way. Binarycat32 (talk) 22:05, 2 February 2024 (UTC)[reply]
It is possible to correlate titles with their MangaDex IDs but it would require maintaining a database of MD ids and other IDs linked to MD and then regularly updating this database both with new titles and if existing titles change their IDs. RPI2026F1 (talk) 02:39, 3 February 2024 (UTC)[reply]
There's already a bot that does all of that, besides changing IDs, which happens approximately never. Binarycat32 (talk) 00:09, 5 February 2024 (UTC)[reply]
Yea, that's me, I wrote the bot that does that RPI2026F1 (talk) 01:26, 5 February 2024 (UTC)[reply]
Yeah I wondered as much, but I figured someone wouldn't write a bot then act like it didn't exist. Binarycat32 (talk) 18:30, 5 February 2024 (UTC)[reply]
The current problem with said bot is that it only adds stuff from given properties. Basically, it won't try to approximate a MangaDex ID from just the MAL ID, but it will add a MAL ID if there is a MangaDex ID because MangaDex lists a MAL ID for that entry. RPI2026F1 (talk) 13:19, 6 February 2024 (UTC)[reply]
finding the mangadex id is fairly easy with animanga-db-matcher[3]. however, this tool does not work well (or at all) for several other sites that often have their identifiers listed on MangaDex. Binarycat32 (talk) 18:51, 8 February 2024 (UTC)[reply]
Yea that would be my bad, I wrote that tool as well but I had a very limited understanding of React and I found it easier to work on the auto-import bot than the finder. The reason it's not as effective is because I designed it for items that had no identifiers whatsoever, and at that point title searching was the only way to find potential IDs. I could make a future update that looks up other identifiers as well. RPI2026F1 (talk) 21:03, 8 February 2024 (UTC)[reply]
Keep it is just a platform, its not obvious if or when copyright is broken, it a grey area, I'm inclined to give benefit of doubt, and consider it legit. Simonc8 (talk) 10:27, 22 July 2024 (UTC)[reply]

Keep per Lockal & Simonc8. Additionally, as mentioned by VIGNERON, there are currently over 2800 items with the property, but I unlike VIGNERON I would not discount it as "gold mine of information", the metadata available is quite robust. They have their own API you can use with the ID and unique info such as an independent scoring system. IntensionalLogican (talk) 03:12, 4 August 2024 (UTC)[reply]

Keep it's still a useful database. –Shisma (talk) 12:25, 3 September 2024 (UTC)[reply]

Delete There is numerous comic databases without copyright violation. Ccbysaint (talk) 03:23, 10 October 2024 (UTC)[reply]

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

Contents

Requests