Wikidata:Properties for deletion/Archive/2022/5
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Contents
- 1 Scoresway tennis person ID (archived) (P6308)
- 2 third-party formatter URL (P3303)
- 3 Sicilian Regional Assembly numeric ID (P8152)
- 4 AICS Chemical ID (BEING DELETED) (P7049)
- 5 Property:P9460
- 6 Roman agnomen (P2366)
- 7 intangible cultural heritage status (P3259)
- 8 P8279 (P8279)
- 9 Property:P7322
- 10 P6623 (P6623)
- 11 Property:P6150
- 12 individual of taxon (P10241)
- 13 Property:P4538
- 14 P6065 (P6065)
- 15 Shoftim BeIsrael judge ID (P3751)
- 16 ALA-LC romanization for Ukrainian (P9453)
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.
- Keep — Martin (MSGJ · talk) 11:56, 13 May 2022 (UTC)
Scoresway tennis person ID (archived) (P6308): (delete | history | links | entity usage | logs | discussion)
Pages do not exist as scoresway.com is defunct. Pelmeen10 (talk) 19:56, 2 April 2020 (UTC)
- A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
- >800 uses. I'd tend to keep. --- Jura 08:15, 10 April 2020 (UTC)
- Remove, useless. Stryn (talk) 13:56, 13 April 2020 (UTC)
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.
- No consensus. There is consensus that the distinction between first-party and third-party links is not useful. However there is not a consensus to delete this property shown in this discussion! As the discussion has been open since 2020 I am closing it now. If there is a clear plan for this property in future, then please start a new request — Martin (MSGJ · talk) 12:06, 13 May 2022 (UTC)
third-party formatter URL (P3303): (delete | history | links | entity usage | logs | discussion)
Merge with formatter URL (P1630). The distinction between first-party and third-party URLs is rather arbitrary. And because Wikidata.org only creates external links for P1630 and not for P3303, third-party URLs are often placed in P1630 if no first-party URL exists (e.g. autonomous system number (P3797), Minecraft UUID (P8727)). We can use ranks to define the best URL(s), and use nature of statement (P5102) to mark URLs as 'official' or 'unofficial' if need be, but having two separate properties just seems unnecessary. —IagoQnsi (talk) 17:04, 23 October 2020 (UTC)
- Is there some Wikibase code change that allows that? --- Jura 12:29, 24 October 2020 (UTC)
- @IagoQnsi: Maybe the name should be modified, but I don't see the purpose of having multiple P1630's on a property. The Wikibase UI will only use one of them, and I'm not sure it currently correctly selects the preferred one (there's a delay in any case, so it's complex to check). The advantage of a separate P3303 is that it makes clear that the entity making use of it needs to do the formatting themselves, the Wikibase UI won't help. Merging with P1630 will confuse that. ArthurPSmith (talk) 22:26, 24 October 2020 (UTC)
- If Wikibase can select the preferred format over multiple claims, I'll support it. --Tinker Bell ★ ♥ 01:44, 25 October 2020 (UTC)
- Keep It is important to distinguish primary 'official' formatter and the third party formatters. But it would be nice to have a tool/gadget to display external links also from third-party formatters.--Jklamo (talk) 10:40, 27 October 2020 (UTC)
- Delete @Jklamo: No need to "distinguish", we should be neutral on every URL schemes. --Liuxinyu970226 (talk) 08:32, 30 October 2020 (UTC)
- Delete We don't have a rule that formatter URL (P1630) can only be filled with official formatter urls. If we want to store information about some formatter urls being official we can do that better explicitely via qualifiers. In addition we can use the preferred rank to chose the formatter url that's used by default. ChristianKl ❪✉❫ 23:30, 1 December 2020 (UTC)
- Can somebody test/confirm that Wikidata's UI does correctly select the preferred Formatter URL value, if there are several? ArthurPSmith (talk) 18:32, 2 December 2020 (UTC)
- I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do). --- Jura 19:42, 2 December 2020 (UTC)
- FYI I added a preferred formatter URL a couple of days ago to Mapy.cz ID (P8988) and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate). We might want to test some more, but it looks like maybe this issue is actually ok now. ArthurPSmith (talk) 19:06, 1 January 2021 (UTC)
- I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do). --- Jura 19:42, 2 December 2020 (UTC)
- I feel like there is something important missing in this discussion. There are multiple use cases at play: 1. The built-in functionality of linkifying the property value. 2. Secondary links to various more- or less- related websites/tools using the same identifier. I completely agree the current official distinction between #1 and #2 (#1 is “first-party/official”, #2 is “third-party/unofficial”) is wrong (and that distinction is not even important or interesting) and does not match the current usage. What we need is one linkifying URL template (OK, we could use the preferred rank for that), plus a potentially unbounded set of URL templates with an agreed-upon way to indicate where that URL leads. I mean, nature of statement (P5102) unofficial (Q29509080) is nice but in fact, I don’t really care. What I’d like to have is a drop-down menu next to each ISBN statement, showing me the links to various online book databases, libraries, e-shops, whatever (now, for the specific case of ISBNs, we outsourced this job to Special:Booksources which is the “official formatter” for ISBNs… funny, right?). Ditto for DOIs, OIDs, MeSH codes, … So, sure, we might merge P1630 and P3303 and use the rank to mark the primary linkifier. But I think it is not the greatest priority. For now, I’d say Keep and rename both to indicate the distinction is not first-party/third-party, but auto-linkifier/additional links (cf. ArthurPSmith above). Then, let’s use operator (P137) (or anything else) for each of these additional URLs, and then let’s build a gadget (or Wikibase core functionality) to use the data in the property. That would be useful. --Mormegil (talk) 13:24, 18 December 2020 (UTC)
- @Mormegil: I like this idea of a gadget to make these "live" - I think we'd need an additional qualifier though to label the links in a drop-down list, no? ArthurPSmith (talk) 19:07, 1 January 2021 (UTC)
- @ArthurPSmith: Yes, that’s exactly what I meant with the note about the operator (P137) qualifier. Not because I’d consider P137 to be a great choice but it’s apparently already used for this, see e.g. ICAO airline designator (P230), IRS Employer Identification Number (P1297), GitHub username (P2037), etc. (With some others used as well, e.g. has use (P366) and applies to part (P518) have overlapping semantics with this, I guess.) --Mormegil (talk) 08:27, 4 January 2021 (UTC)
- OK, I created a prototype implementation of that and I’m fairly happy with the result. You can test it by adding the script to your common.js. --Mormegil (talk) 17:24, 18 January 2021 (UTC)
- @ArthurPSmith: Yes, that’s exactly what I meant with the note about the operator (P137) qualifier. Not because I’d consider P137 to be a great choice but it’s apparently already used for this, see e.g. ICAO airline designator (P230), IRS Employer Identification Number (P1297), GitHub username (P2037), etc. (With some others used as well, e.g. has use (P366) and applies to part (P518) have overlapping semantics with this, I guess.) --Mormegil (talk) 08:27, 4 January 2021 (UTC)
- @Mormegil: just noting that your suggested gadget sounds a little like Entity Explosion, which shows these links even if you don't start from Wikidata. --99of9 (talk) 04:54, 17 February 2021 (UTC)
- It seems to me EE works “inversely” in a sense, doesn’t it? I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property. On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs. I added a screenshot. → --Mormegil (talk) 15:19, 18 February 2021 (UTC)
- @Mormegil: I like this idea of a gadget to make these "live" - I think we'd need an additional qualifier though to label the links in a drop-down list, no? ArthurPSmith (talk) 19:07, 1 January 2021 (UTC)
- @Mormegil: It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a operator (P137) or a matching language). See this screenshot. I haven't advertised this feature much - perhaps I should! --99of9 (talk) 06:11, 19 February 2021 (UTC)
- Keep per Jklamo and Mormegil, whose comments I completely support. --Epìdosis 20:12, 30 December 2020 (UTC)
- Delete Per Liuxinyu970226 and ChristianKl. --Nw520 (talk) 15:31, 18 February 2021 (UTC)
- Placeholder Keep for now. I use this as part of the decision making in Entity Explosion, so have a preference for not doing extra work if there is a way of reconceiving of the difference between these two properties. --99of9 (talk) 01:13, 21 February 2021 (UTC)
- Keep - I use Entity Explosion and its excellent for a property like Eionet bathing Water ID (P9616) were we lack a "EU" formatter but maybe have formatters for some countries like Sweden (Q34) - Salgo60 (talk) 07:55, 6 June 2021 (UTC)
- Keep Ainali (talk) 21:47, 12 January 2022 (UTC)
- Delete As others have pointed out formatter URL (P1630) isn't limited to first-party URLs, deletion of third-party formatter URL (P3303) would therefore lead to more homogeneous data. We could use nature of statement (P5102) and operator (P137) as qualifiers to distinguish the nature of each formatter-URL. Abbe98 (talk) 09:16, 31 March 2022 (UTC)
- Delete As others have pointed out, this property can be replaced with a qualifier at no loss of functionality, and probably should. Infrastruktur (talk) 23:10, 28 April 2022 (UTC)
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.
- No consensus to delete — Martin (MSGJ · talk) 12:08, 13 May 2022 (UTC)
Sicilian Regional Assembly numeric ID (P8152): (delete | history | links | entity usage | logs | discussion)
Duplicates Property:P8151. Seems to have been created without proper proposal (see Wikidata:Property_proposal/Sicilian_Regional_Assembly_ID) --- Jura 19:51, 22 February 2021 (UTC)
- It may be a duplication, I'm not sure. @Horcrux: and Airon90 ValterVB Alexmar983 Epìdosis Pietro Jura Beta16 Yiyi Sannita Camelia Sentruper Pierpao Marcok CristianNX Daniele Pugliesi (WMIT) AttoRenato Parma1983 Aborruso Sabas88 Lalupa DnaX Fausta Samaritani Patafisik Malore Jtorquy Nicholas Gemini Civvì Devbug Afnecors Susanna Giaccai FabC FeltriaUrbsPicta Horcrux Uomovariabile Luckyz Francians Carlobia Ferdi2005 Luca.favorido Lemure Saltante Giacomo Alessandroni divudì Federica Gaspari Zwolfz Daniele Santini Bargioni Wiccio S4b1nuz E.656Notified participants of WikiProject Italy for opinions. --Epìdosis 21:13, 22 February 2021 (UTC)
- I don't really know what is meant by "duplicate". For sure the two properties are alternative to eachother (there is a 1:1 mapping between them). I don't know nothing more than what has already been said in Wikidata:Property proposal/Sicilian Regional Assembly ID. --Horcrux (talk) 09:24, 23 February 2021 (UTC)
- It's the same item but specified with two different ways, string and number. The numeric ID redirects to the string one, however I was unable to find the numeric ID on the specified website. I suggest to delete the Property:P8152 (only after a migration to the string property). --DnaX (talk) 09:30, 23 February 2021 (UTC)
- I think that a numeric ID is more stable than a string ID, although it is not human-readable. I suggest to delete the other one and leave P8152 as main property. One can use P554 or something similar to indicate the string ID --★ → Airon 90 07:31, 24 February 2021 (UTC)
- If you prefer to delete the other and keep this one, I'm fine with that. --- Jura 09:06, 28 February 2021 (UTC)
- Why not keep both, and use one as a qualifier on the other? Then people can match their data to our items, no matter which of the two identifiers they have got. Jheald (talk) 13:15, 7 March 2021 (UTC)
- If you prefer to delete the other and keep this one, I'm fine with that. --- Jura 09:06, 28 February 2021 (UTC)
- I think that a numeric ID is more stable than a string ID, although it is not human-readable. I suggest to delete the other one and leave P8152 as main property. One can use P554 or something similar to indicate the string ID --★ → Airon 90 07:31, 24 February 2021 (UTC)
- I see points for keeping both of them: one is easier to retrieve but not very "identifying" (for example, it is not clear how two persons with same name would be treated), the other one is a classic identifier but more difficult to retrieve. --Horcrux (talk) 14:09, 1 April 2021 (UTC)
- @Jura1, Horcrux, Airon90, DnaX, Epìdosis: any other comments on this? Otherwise I will close as no consensus to delete — Martin (MSGJ · talk) 22:33, 17 February 2022 (UTC)
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.
- On balance the request to delete is weakly supported. Deletion will be delayed by 30 days in case anyone wants to use the data in any way — Martin (MSGJ · talk) 12:14, 13 May 2022 (UTC)
AICS Chemical ID (BEING DELETED) (P7049): (delete | history | links | entity usage | logs | discussion)
Replaced without reusing IDs —SCIdude (talk) 14:47, 29 March 2021 (UTC) @Dhx1:
In short, the database has been replaced [1] and the new database does not use the old identifiers. Not only do our identifiers now link to the Wayback Machine but, because the database was not really functional for long (few months?), the archived pages do not show anything. --SCIdude (talk) 14:47, 29 March 2021 (UTC)
- I was tending to agree with deletion on the basis of the Internet Archive and Trove neither having any saved pages from the old online database using the IDs of AICS Chemical ID (BEING DELETED) (P7049). Additionally the example links of [2], [3] and [4] are not saved correctly by the Internet Archive, which seems to think all these example IDs match up with a single chemical in the database. Then I stumbled across [5], which indicates at least some pages were being saved by the Internet Archive correctly up to 2 years prior to AICS Chemical ID (BEING DELETED) (P7049) existing in Wikidata. This property is used over 16,000 times on Wikidata items and who knows how many of these uses does result in an archived page off the old NICNAS inventory website. Given the lack of archiving observed and seemingly invalid archived pages when Internet Archive did make an attempt, I'm tending to Weak support the deletion of AICS Chemical ID (BEING DELETED) (P7049) instead of the usual case of leaving AICS Chemical ID (BEING DELETED) (P7049) in a deprecated state (for the purpose of Internet Archive etc linking). Mix'n'Match seems to contain the full catalogue of previous IDs but what is the point if there is no copy of the original page available? --Dhx1 (talk) 13:28, 30 March 2021 (UTC)
- I updated the label, but given the number of uses and the importance of the database, I'm not really convinced by the deletion proposal. If the identifier was used elsewhere than on the website, I think that should be kept. If it wasn't used elsewhere, somehow our description of the identifier has a problem. @99of9: who worked on this mostly. --- Jura 21:19, 30 March 2021 (UTC)
- Grrrr... I hate when databases do this. I'm accepting of my wasted efforts, but can't quite bring myself to vote for deletion! MnM will still be there in the unlikely event that we want to restore the data. --99of9 (talk) 21:44, 30 March 2021 (UTC)
- this is really sad. we need to get better at archiving these external identifier URLs BrokenSegue (talk) 00:06, 31 March 2021 (UTC)
- It looks to me that the reason the Wayback Machine only has a fraction of the pages is because they were only online for a few months, not because the links were defect. What does that tell about the creator's intention or the database's quality? Do we really need to keep something alive that had not much time to mature? --SCIdude (talk) 12:59, 1 April 2021 (UTC)
- It seems the database has been around for years.
Is it in web.archive.org.au (or is that the same)? --- Jura 14:20, 1 April 2021 (UTC)
- It seems the database has been around for years.
- No objections. --Egon Willighagen (talk) 13:57, 2 April 2021 (UTC)
- I wasn't going to bother creating a new property proposal for the new database https://www.industrialchemicals.gov.au/search-inventory because it seems it could be a waste of time again. The only use it'd theoretically be is determining whether a chemical can be manufactured or imported into Australia. For example, Chlorinated Biphenyls are listed as a restricted class of chemicals at present, but an Internet Archive copy from April 2021 states no restriction. According to [6] and [7], polychlorinated biphenyl (Q211171) substances have been banned from manufacture and import in Australia since the 1970s so this new website in April 2021 appears to have been wrong in a fairly significant way. The database doesn't provide useful information such as the date a chemical was listed as being able to be manufactured and/or imported, or the date it was restricted or banned. As another example, DDT (Q163648) isn't listed at all (which would be expected), meaning it is most likely banned from manufacture or import. However, more generally, there is no way of knowing for sure what the meaning of a missing chemical is as the register also contains "secret chemicals" that manufacturers or importers may want to hide knowledge of from competitors. --Dhx1 (talk) 15:56, 14 October 2021 (UTC)
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.
- No consensus to delete — Martin (MSGJ · talk) 11:52, 13 May 2022 (UTC)
Washington Rare Plant Field Guide ID (PDF version) (P9460): (delete | history | links | entity usage | logs | discussion)
Given that Wikidata:Property_proposal/Washington_Rare_Plant_Field_Guide_(2021-_Version)_ID is being created and was created not too long ago and is hardly used. --- Jura 17:20, 28 September 2021 (UTC)
- Not sure if “was created not too long ago” (April 2021) and “is hardly used” (213 uses) are really good reasons for a PfD request, especially if the links still work. CC User:UWashPrincipalCataloger --Emu (talk) 19:36, 28 September 2021 (UTC)
- In combination with the soon to be available replace property it surely is. Maybe "rarely" described it better than "hardly". --- Jura 15:31, 29 September 2021 (UTC)
- I can confirm that the links to the PDFs still work and that I can add additional ones to items. Although the PDFs are no longer linked from the site, a simple Google search of the species name plus "PDF" brings them up at the top of the search results. UWashPrincipalCataloger (talk) 19:50, 28 September 2021 (UTC)
Washington Rare Plant Field Guide ID (Web version) (P9967) has been created. Pamputt (talk) 18:04, 12 October 2021 (UTC)
@UWashPrincipalCataloger, Emu: do we need both Washington Rare Plant Field Guide ID (Web version) (P9967) and Washington Rare Plant Field Guide ID (PDF version) (P9460)? — Martin (MSGJ · talk) 12:36, 14 February 2022 (UTC)
- The documents retrieved from the different properties do not necessarily have the exact same content. Having both also allows someone to access a PDF version if they prefer that over a web page. And there are new additions to Washington Rare Plant Field Guide ID (Web version) (P9967) that are not in Washington Rare Plant Field Guide ID (PDF version) (P9460). I do not see a reason to delete Washington Rare Plant Field Guide ID (PDF version) (P9460). UWashPrincipalCataloger (talk) 16:46, 14 February 2022 (UTC)
- Thanks for the clarification — Martin (MSGJ · talk) 21:20, 14 February 2022 (UTC)
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.
- No consensus to delete — Martin (MSGJ · talk) 12:10, 16 May 2022 (UTC)
Roman agnomen (P2366): (delete | history | links | entity usage | logs | discussion)
Epìdosis
B20180
llywrch
Jahl de Vautban
Alexmar983
StarTrekker
Mathieu Kappler
Tolanor
JASHough
Darellur
Ahc84
Liber008
User:Jonathan Groß
User:Luca.favorido
- Delete yeah, it is probably too precise to be helpful. --Jahl de Vautban (talk) 16:13, 26 October 2021 (UTC)
- Comment This is part of a series of properties for Roman nomen: Roman praenomen (P2358), Roman nomen gentilicium (P2359), Roman cognomen (P2365), Roman agnomen (P2366). Obviously, not all are used with equal frequency and they could all be seen as subproperties of a "Roman name part" property. Depending on the use, one can query one or several of these properties. That they are generally single valued allows to determine easily if they are present or not (or if others are missing, e.g. cognomen is present, but not praenomen). The question is if P2366 would misidentify names as agnomen or not. That the property could have the alias "additional Cognomina" or "Roman name part 4* doesn't require it to be merged with the other properties. As mentioned, one can query one or several properties together. That terminology varies isn't really a reason not to use any of it. --- Jura 13:15, 8 January 2022 (UTC)
- Keep It is very helpful in cases where a name is derived from adoption or similar.*Treker (talk) 22:03, 15 March 2022 (UTC)
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.
- Keep — Martin (MSGJ · talk) 13:56, 16 May 2022 (UTC)
intangible cultural heritage status (P3259): (delete | history | links | entity usage | logs | discussion)
WikiProject Cultural heritage has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. @Fralambert, Jingkaimori, Ulumarifah, Nw520, Aiaiaiaiaia, VIGNERON:
Also notified https://vec.wikipedia.org/wiki/Discusion_Modeło:Infobox_de_Bało: if someone speaks "vec", could you please repost at their "Village Pump", as I can't find that page.
There's no proper definition. The values are a total mess. Replace with has list (P2354) and individual IDs in such lists, eg UNESCO ICH ID (P10221), Wikidata:Property proposal/identifiant Inventaire national du Patrimoine culturel immatériel —Vladimir Alexiev (talk) 08:31, 9 January 2022 (UTC)
- Keep Strong oppose see the discussion Total mess! for all explanations refuting Vladimir Alexiev hypothesis. In a nutshell: there is a proper definition, this is not exactly equivalent to a list (so has list (P2354) is not a replacement) and not all have individual IDs, there is some "mess" (an exagerated and unneededly aggressive word) but it can be fixed, this is not a reason for deletion. Also pinging @Fierodelveneto: who built the Infobox de Bało and @Vladimir Alexiev: the local village pump can very very easily be found on Project:Village pump (Q16503). Cheers, VIGNERON (talk) 09:09, 9 January 2022 (UTC)
- The definition is "status of an item that is designated as intangible heritage" but the values (see query https://w.wiki/4dAz) don't conform to it, eg:
- Inventory of intangible cultural heritage in France
- Intangible Cultural Heritage of Indonesia
- intangible cultural heritage
- Beijing Municipal Intangible Cultural Heritage
- Please tell me what is the common theme between all these items.
- Maybe they are not "exactly equivalent to lists" but surely they are not "statuses"? Vladimir Alexiev (talk) 11:11, 9 January 2022 (UTC)
- "Inventory of intangible cultural heritage in France" says "instance of: list"
- "intangible cultural heritage" is surely not designated by any institution, it's a class of all ICH
- "Intangible Cultural Heritage of Indonesia" says "status awarded by the Indonesian Ministry of Education and Culture" but then the name should be "Designated Intangible Cultural Heritage of Indonesia" (because there may be extra ICH in Indonesia that are not designated)
- The current prop "designated status" has a mix of values that include lists of designated and non-designated items
- So let me ask again, how is that "not exactly equivalent to a list"
- It makes more sense to have a property "designated by"
- Or better yet "designation ID" in various registers (UNESCO, FR, and more to come) Vladimir Alexiev (talk) 11:21, 9 January 2022 (UTC)
- heritage asset listed by IPHAN (Q45823285) is "instance of: heritage designation", which makes more sense to me
- I'd agree to keep this prop if we rename it to "heritage designation" or "intangible cultural heritage designation"
- I've added a col "isHeritageDesignation" to the query https://w.wiki/4f2N. Most lists (values of this prop) are NOT instances of heritage designation (Q30634609) or subclass thereof Vladimir Alexiev (talk) 11:28, 9 January 2022 (UTC)
- @Vladimir Alexiev: I agree mostly with you and the property should be cleaned (per it's definition and how it was intended at the beggining) and not deleted. Cheers, VIGNERON (talk) 17:20, 10 January 2022 (UTC)
- The definition is "status of an item that is designated as intangible heritage" but the values (see query https://w.wiki/4dAz) don't conform to it, eg:
- @Vladimir Alexiev, VIGNERON: hello, I'm not understanding the problem! What does the Infobox de Bało have to do with it? --Fierodelveneto (talk) 09:26, 9 January 2022 (UTC)
- @Fierodelveneto: the infobox you created uses this property so the deletion will affect it. Cheers, VIGNERON (talk) 09:29, 9 January 2022 (UTC)
- Keep When data is a mess we clean it. This proprerty is incompatible with heritage designation (P1435) so we can't merge it. If the goal is to broaden the name of the property, why proposing it to deletion? It's a waist of time. --Fralambert (talk) 13:49, 9 January 2022 (UTC)
- Keep It should be possibly to sort it out, see Property_talk:P3259#How_to_fix_it:_values_or_definition? for further details. --- Jura 11:17, 12 February 2022 (UTC)
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.
- Merge into RAWG game ID (P9968) and delete — Martin (MSGJ · talk) 11:49, 13 May 2022 (UTC)
P8279 (P8279): (delete | history | links | entity usage | logs)
Modern ag.ru is just a Russian interface for rawg.io (compare https://rawg.io/games/barony & https://ag.ru/games/barony). Since we already have a property for RAWG, P8279 gives nothing above that: same ID, same info. There might be a reason to keep a link to an old (pre-2019) AG database, but I'm not sure about that, pretty sure it was merged with RAWG after AG was sold. @Kirilloparma:. —Facenapalm (talk) 15:56, 25 January 2022 (UTC)
- @Facenapalm: Comment. Unfortunately, ag.ru and RAWG are not quite the same databases. Yes, ag.ru uses the same API and interface as RAWG, but the new version of Absolute Games is different in that it has editorial reviews from the old version ([8], [9]), while RAWG does not ([10]).
- I'm not sure about the old database either, because if the new one has reviews from the old version, then it makes no sense to create a new property. As for removing this particular property, I'm not sure if it's worth it as we can still use it as the old database by changing the formatter URL. By the way, maybe we should also ask the members of the respective project on ruwiki what they think of it, and which of these versions is preferable, the old one or the new one?
- If we conclude that we don't need the new version, then we can delete it or rename Absolute Games ID to Absolute Games ID (old version)/Old.ag.ru ID and use RAWG database for the new games only. Regards Kirilloparma (talk) 19:04, 25 January 2022 (UTC)
- @Kirilloparma: looks like there are only 5217 AG.ru reviews, while RAWG have over 625k games in database. If we'll keep P8279, there would be 620k pairs of identical links. I think deleting P8279 and creating property for old.ag.ru is more optimal solution. If we're considering those reviews important. Facenapalm (talk) 21:22, 25 January 2022 (UTC)
- @Facenapalm: P8279 currently has a total of 272 uses. This is not so much and these links can be removed using QS batch. In order not to create a separate property, we can use this one if we reach a consensus to rename it from Absolute Games ID to old.ag.ru ID (if it can be done, of course) and changing the formatter URL from
https://ag.ru/games/$1
tohttps://old.ag.ru/games/$1
. What do you think? As far as I can see, the colleague who originally proposed this property has no objections to any further decision. Regards Kirilloparma (talk) 23:53, 25 January 2022 (UTC)- @Kirilloparma, I'm not sure if it's okay to change a property midway like that. And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information). If you're sure it's okay, I don't mind. As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. Facenapalm (talk) 00:20, 26 January 2022 (UTC)
- @Facenapalm: Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one. Regards Kirilloparma (talk) 01:29, 26 January 2022 (UTC)
- @Kirilloparma, I'm not sure if it's okay to change a property midway like that. And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information). If you're sure it's okay, I don't mind. As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. Facenapalm (talk) 00:20, 26 January 2022 (UTC)
- @Facenapalm: P8279 currently has a total of 272 uses. This is not so much and these links can be removed using QS batch. In order not to create a separate property, we can use this one if we reach a consensus to rename it from Absolute Games ID to old.ag.ru ID (if it can be done, of course) and changing the formatter URL from
- @Kirilloparma: looks like there are only 5217 AG.ru reviews, while RAWG have over 625k games in database. If we'll keep P8279, there would be 620k pairs of identical links. I think deleting P8279 and creating property for old.ag.ru is more optimal solution. If we're considering those reviews important. Facenapalm (talk) 21:22, 25 January 2022 (UTC)
- @Facenapalm: By the way, there is another property of Ag.ru related to personalities of the gaming industry. What should we do with this property? Regards Kirilloparma (talk) 03:04, 26 January 2022 (UTC)
- @Kirilloparma, I'd probably reorganize it into RAWG.io property as well. As far as I see, some descriptions are translated to Russian (Gabe Newell: [11][12]), but most of them are completely identical (Jesper Kyd: [13][14]), no point in linking both.
- Moreover, AG and RAWG IDs are identical as well, right? We usually keep only one property in that case as far as I'm concerned. For instance, we don't have a separate property for GameRankings because it's the same to GameFAQs. And we also don't have a property for SteamDB because it uses application ID from Steam. Please correct me if I'm wrong. Facenapalm (talk) 14:54, 26 January 2022 (UTC)
- @Facenapalm: That's right, they are completely identical. In this case, only one database should be used, and that is RAWG. Regards Kirilloparma (talk) 15:09, 26 January 2022 (UTC)
- Moreover, AG and RAWG IDs are identical as well, right? We usually keep only one property in that case as far as I'm concerned. For instance, we don't have a separate property for GameRankings because it's the same to GameFAQs. And we also don't have a property for SteamDB because it uses application ID from Steam. Please correct me if I'm wrong. Facenapalm (talk) 14:54, 26 January 2022 (UTC)
+ @INS Pirat: pinging also the original proposer of this property. Regards Kirilloparma (talk) 19:08, 25 January 2022 (UTC)
- I don't have any specific comment. Have no objection to any further decision. --INS Pirat ( t | c ) 19:13, 25 January 2022 (UTC)
- @Kirilloparma, Facenapalm: sorry about the slow response on this. I just looked at a random example The Elder Scrolls Online (Q1188904). Changing the formatter link to
https://old.ag.ru/games/$1
produces a 404 error for me: https://old.ag.ru/games/the-elder-scrolls-online So this can't be changed or perhaps I am misunderstanding your suggestion? — Martin (MSGJ · talk) 20:54, 12 May 2022 (UTC)- @MSGJ, old.ag.ru had different IDs, but modern ag.ru has the same IDs to RAWG game ID (P9968) (that's basically two web interfaces for the same database). My suggestion was to merge P8279 (P8279) into RAWG game ID (P9968) basically, and Kirilloparma's suggestion was to re-organize P8279 (P8279) to link at old.ag.ru (after we'll move all the current values to RAWG game ID (P9968)). Looks like noone minds both of these suggestions, so I can do the first part. Facenapalm (talk) 21:06, 12 May 2022 (UTC)
- Yes please, do the merge. There is consensus for that part. I think perhaps the identifier for old.ag.ru should go through a new property proposal, if anyone thinks that would be worthwhile — Martin (MSGJ · talk) 11:46, 13 May 2022 (UTC)
- @MSGJ, old.ag.ru had different IDs, but modern ag.ru has the same IDs to RAWG game ID (P9968) (that's basically two web interfaces for the same database). My suggestion was to merge P8279 (P8279) into RAWG game ID (P9968) basically, and Kirilloparma's suggestion was to re-organize P8279 (P8279) to link at old.ag.ru (after we'll move all the current values to RAWG game ID (P9968)). Looks like noone minds both of these suggestions, so I can do the first part. Facenapalm (talk) 21:06, 12 May 2022 (UTC)
Notes
- @MSGJ, I've cleared all links to P8279 (P8279), what to do next? Facenapalm (talk) 14:19, 13 May 2022 (UTC)
- I guess we can go ahead and delete then — Martin (MSGJ · talk) 20:02, 13 May 2022 (UTC)
- Done, thanks for helping with this — Martin (MSGJ · talk) 11:29, 16 May 2022 (UTC)
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.
- Delete — Martin (MSGJ · talk) 11:55, 18 May 2022 (UTC)
P7322 (P7322): (delete | history | links | entity usage | logs)
This is a duplicate of the older property Marine Regions Geographic ID (P3006). I have manually migrated all items that referenced P7322 to now reference P3006. In addition, I have migrated the updated formatter URL and URL match pattern properties for P3006 to match P7322 and ranked these as preferred. The only thing missing are the per-language labels, descriptions, and akas which have a uniqueness constraint. This property could either be merged or deprecated —Ozmorph (talk) 03:42, 17 April 2022 (UTC)
- Delete How'd we miss that duplication? I guess proposers and reviewers should try a bit harder to spot this sort of thing?! ArthurPSmith (talk) 15:19, 18 April 2022 (UTC)
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.
- Migrate and delete — Martin (MSGJ · talk) 11:54, 18 May 2022 (UTC)
P6623 (P6623): (delete | history | links | entity usage | logs) Functionally identical to Fandom article ID (P6262) after Fandom Inc. purchased Gamepedia --Trade (talk) 13:56, 5 July 2021 (UTC)
- migrate and Delete. Keep references if possible --Shisma (talk) 18:13, 5 July 2021 (UTC)
- Keep seems to be reasonably used and the change of hosting service shouldn't affect the ids. --- Jura 11:17, 6 July 2021 (UTC)
- Comment @Trade: Are they the same data/target or different. If they are separate sites still and not an exact duplication then I see no issue with both existing. If they are exact duplicates then we should look to migrate/merge. — billinghurst sDrewth 12:13, 19 July 2021 (UTC)
- The Gamepedia article ID's redirects to their Fandom article ID counterpart. @billinghurst:--Trade (talk) 17:47, 19 July 2021 (UTC)
- Good-o. Then per Shisma, migrate. Mark redundant, point to alternate, and when all have been migrated then delete. — billinghurst sDrewth 02:09, 20 July 2021 (UTC)
- The Gamepedia article ID's redirects to their Fandom article ID counterpart. @billinghurst:--Trade (talk) 17:47, 19 July 2021 (UTC)
- migrate and Delete. We should keep our list of properties clean; many people already complain that Wikidata is difficult to query. Imagine now that, for example, 1/3 of the links to fandom.com is added as "Gamepedia ID", 1/3 is added as "Fandom ID", 1/3 is just added twice (maybe with different qualifiers) - it is a nightmare. --Lockal (talk) 08:25, 24 August 2021 (UTC)
- Comment Please be careful when migrating, some Fandom sites existed with the same name as Gamepedia sites. Some of these Fandom sites were suffixed with "-archive" and locked, like minecraft -> minecraft-archive. AntisocialRyan (Talk) 01:08, 5 May 2022 (UTC)
Notes
@Trade, Shisma: are you able to help with the migration of this data? What still needs to be done? Regards — Martin (MSGJ · talk) 11:54, 18 May 2022 (UTC)
- MSGJ all statements using P6623 (P6623) can be directly moved to Fandom article ID (P6262). I don't know how to do that, keeping all the references and qualifiers. Is there a bot able to perform such an action?--Shisma (talk) 16:29, 18 May 2022 (UTC)
- MSGJ with the help of @TomT0m: I was able to identify all statements that can be moved with QuickStatements (Q20084080). The remaining ~200 statements have been moved manually with moveClaim (Q110793966). You can now delete this property --Shisma (talk) 18:30, 21 May 2022 (UTC)
Deleted — Martin (MSGJ · talk) 21:04, 23 May 2022 (UTC)
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.
- No consensus to delete — Martin (MSGJ · talk) 10:34, 24 May 2022 (UTC)
Academy Awards Database nominee ID (P6150): (delete | history | links | entity usage | logs | discussion)
No matter which link you open, you get the message: "The page you were looking for does not exist." The error has been occurring for at least 6 weeks. HarryNº2 (talk) 18:48, 12 October 2021 (UTC)
- keep. see the web archive. e.g. [15] BrokenSegue (talk) 22:30, 12 October 2021 (UTC)
- Then all entries pointing to Property:P6150 must refer to archive.org via bot. Or another replacement has to be found. The user expects to find an entry and instead receives a 404 message. --HarryNº2 (talk) 23:14, 14 October 2021 (UTC)
- why is a bot needed? just change the formatter URL. BrokenSegue (talk) 14:24, 7 November 2021 (UTC)
- @BrokenSegue: can you help to update the formatter URL on this property please? — Martin (MSGJ · talk) 22:29, 8 February 2022 (UTC)
- I updated it how I think it should work. Let's wait for the cache to purge and see if it works. BrokenSegue (talk) 22:54, 8 February 2022 (UTC)
- Thanks, then we can close this — Martin (MSGJ · talk) 10:04, 9 February 2022 (UTC)
- For some reason it was necessary to mark the new formatter as preferred. I did this and the links appeared, but I can't test them properly yet — Martin (MSGJ · talk) 12:32, 14 February 2022 (UTC)
- @BrokenSegue: links are not working ... — Martin (MSGJ · talk) 21:30, 15 February 2022 (UTC)
- @MSGJ: it's working for some. See Stevie Wonder (Q714) for example. Some of the snapshots are "too new" and so redirect to an error. BrokenSegue (talk) 21:42, 15 February 2022 (UTC)
- I updated it how I think it should work. Let's wait for the cache to purge and see if it works. BrokenSegue (talk) 22:54, 8 February 2022 (UTC)
- @BrokenSegue: can you help to update the formatter URL on this property please? — Martin (MSGJ · talk) 22:29, 8 February 2022 (UTC)
- why is a bot needed? just change the formatter URL. BrokenSegue (talk) 14:24, 7 November 2021 (UTC)
- Then all entries pointing to Property:P6150 must refer to archive.org via bot. Or another replacement has to be found. The user expects to find an entry and instead receives a 404 message. --HarryNº2 (talk) 23:14, 14 October 2021 (UTC)
- @HarryNº2: are you happy to withdraw this nomination? — Martin (MSGJ · talk) 11:34, 16 May 2022 (UTC)
- Because of me. --HarryNº2 (talk) 11:40, 16 May 2022 (UTC)
- I don't understand your comment. Are you replying to me or BrokenSeque? — Martin (MSGJ · talk) 07:03, 17 May 2022 (UTC)
- Because of me. --HarryNº2 (talk) 11:40, 16 May 2022 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- There is no consensus to delete this property based on this discussion. However it is clear that a sizeable proportion of the Wikidata community feel that taxons are classes, and that these properties should be replaced by P31/P279. As this would be a major change and affects more than a single property, it would be best addressed in a request for comment (if anyone has the inclination to start such a discussion) — Martin (MSGJ · talk) 10:44, 24 May 2022 (UTC)
individual of taxon (P10241): (delete | history | links | entity usage | logs | discussion)
This property effectively replaces instance of (P31) for a narrow set of classes: taxons. It was discussed and proposed with fairly little activity, and only two support votes (including the proposer). Yet, Vojtěch Dostál is now using it to remove P31 statements at a large scale, leaving behind several items with no P31 statements at all, which of course results in many constraint violations (see K35 (Q72009266), permalink, for an example), as well as breaking queries (e.g. my moon trees map no longer has working colors/layers). I don’t think we have consensus for this migration yet, and furthermore I believe this property doesn’t make sense in the first place and should be deleted again.
My answers to the questions in the discussion and property proposal are, I think, fairly simple:
- Moja (Q12038481) has instance of (P31) : western lowland gorilla (Q876500), which has subclass of (P279) : animal (Q729). Sounds straightforward but are really all animal taxa supposed to be subclass of (P279) : animal (Q729)? No, the taxa that are used in instance of (P31) statements should suffice. This is what I and others have done in the past: when creating an instance of a taxon, and the taxon isn’t a subclass of anything yet (which is easily seen thanks to a constraint violation), add a suitable subclass of (P279) statement to the taxon. (It can be something fairly general, since we don’t need to duplicate the exact parent taxon hierarchy: I think I’ve used subclass of (P279)tree (Q10884) at times.)
- Borovice u Žibřidic (Q26789614) has instance of (P31) : Pinus sylvestris (Q133128) but that isn't subclass of anything, it's just a taxon item, and it triggers a constraint warning. What would be a proper step there? Add a subclass of (P279) statement to the taxon, as above.
- Sunny (Q14744025) has instance of (P31) : Portuguese water dog (Q38559) which has subclass of (P279) : dog (Q144), which is however not a taxon item at all and is not linked to Canis familiaris (Q20717272) or Canis lupus familiaris (Q26972265) Okay, so create a link between them. sheep (Q7368) (permalink) shows one possible way to link such items.
- Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see. Ditto. I don’t see why a new property is needed for this.
The property proposal doesn’t even explain how individual of taxon (P10241), once created, would be used to solve these issues, nor does it elaborate how this property is any different from instance of (P31) – in fact, one of the property’s aliases is “instance of taxon”.
Pinging discussion participants: Vojtěch Dostál, TiagoLubiana, ArthurPSmith, Jura1, UWashPrincipalCataloger, William Avery. (WikiProject Taxonomy is too large to ping, but I’ll leave a message on their talk page.) —Lucas Werkmeister (talk) 00:50, 13 January 2022 (UTC)
- Delete I agree that we should use instance of (P31). I don't think creating another subproperty is the solution to an issue caused by poor support for subproperties. I also don't think we should model non-human living things in a way which is the opposite of what we do with other data (a lot of the suggestions I've seen of what we should use for instance of (P31) instead of the species are things which would normally go in occupation (P106) or heritage designation (P1435)). - Nikki (talk) 01:44, 13 January 2022 (UTC)
- Delete, agree with Nikki. - PKM (talk) 02:50, 13 January 2022 (UTC)
- Delete It's clear that taxonomies can be classified just like everything else without requiring a special property. Lectrician1 (talk) 04:00, 13 January 2022 (UTC)
- Keep For the following reasons:
- 1) The property has >11000 uses. If replaced by P31, this will lead to 11000 constraint violations in property P31. @Lucas Werkmeister: is suggesting to circumvent this by adding subclass of (P279) to all taxa which are used as P31, which seems completely unsystematic to me. Why would you want some taxa with P279 and some without it?
- 2) I leave it to local taxonomists to consider if it would even make semantic sense to use P31:Taxon to indicate that an individual animal is classified as a given taxon. To me it doesn't. Same with P279:taxon in taxa items as discussed above. @Succu: with whom I discussed the P31/P279 logic just yesterday.
- 3) This problem was discussed just recently in Project chat and then you had the opportunity to discuss this in the property proposal. By deleting it again, you'd be saboteering our work. Why should someone create a new property ever again if there is a simple way for opponents to just wait a week after its creation, then nominate it for deletion - effectively demotivating everyone to propose large-scale changes... Vojtěch Dostál (talk) 08:21, 13 January 2022 (UTC)
- Why wouldn't it make semantic sense? Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.
- To me it seems that considering the impact the property was created just too hastily. 2001:7D0:81DA:F780:D95:8B9D:98C7:D69C 12:48, 13 January 2022 (UTC)
- @Vojtěch Dostál:
- 1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31. For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time. Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.
- 2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.
- 3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens. Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it. (The weekly summary where the property proposal was included happened to be the December 27 one – between the holidays and rC3 2021 (Q110157763), I did not spend much time looking at Wikidata then.) And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest. (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) Lucas Werkmeister (talk) 01:03, 14 January 2022 (UTC)
- @Lucas Werkmeister As for (1) I've made effort to add P31 to all items migrated to P10241. Some might have been accidentally left out but that's a simple thing to fix. I've added a correct instance to your example https://www.wikidata.org/w/index.php?title=Q72009266&type=revision&diff=1562092751&oldid=1559804057 Vojtěch Dostál (talk) 12:31, 14 January 2022 (UTC)
- Comment I also noticed these large scale changes to P31 values, and I find it a poor workaround to the problem that taxa items in the first place still don't make proper use of basic membership properties. Generally, taxa are classes, and so every taxa should have P279 statement, as other class items normally do. P279 value for taxa could be organism (Q7239), or something a little less generic. But ideally parent taxon (P171) could be phased out eventually and P279 could be used to model taxonomic hierarchy, so that it could be properly combined with other hierarchies (e.g. indicate that all species of a family are carnivore species by simply setting the parent taxon as a subclass of carnivore class). Not making proper use of P279 for taxa is a root of all sorts of deficiencies, e.g. see also comments here. 2001:7D0:81DA:F780:D95:8B9D:98C7:D69C 12:48, 13 January 2022 (UTC)
- Delete This is pretty clearly duplication of the semantic content of instance of (P31) → "some specific taxon, usually a species", which should itself eventually be subclass of organism (Q7239). P31/P279* is the absolutely standard and, IMO, logical membership idiom used for hundreds of millions of items. What is the actual need for this sub-property that cannot be achieved using that idiom?
- If there's a good technical/ontological need for this sub-property, that's a pretty huge discovery, because it must also apply to most other "instance" items and would represent an end-to-end shake-up of the basic structure of Wikidata. Not that that's necessarily a bad thing, but consistency is absolutely critical, and so if that's where taxa go, everything else should follow (notably, occupation (P106) is also a deviation and starts getting metaphysical when you wonder what the difference is between "being" a writer and "doing writing"). Buildings should have their instance of (P31) claims pointing to subclasses of building (Q41176) stripped out and replaced with a "is a building of type" property. And so on. Specifically, there should be a very clear path to transitioning to a new, more consistent, status quo than introducing a sub-property and changing only a small domain of items. There's enough fragmentation, inconsistency and fuzzy modelling about as it is. Inductiveload (talk) 14:00, 13 January 2022 (UTC)
- Comment I wasn't part of the original discussion of this (I was pinged but didn't participate - I don't really have strong opinions on taxon-related items or properties). However, can we fix the constraints on instance of (P31) so that the value can have a statement with either subclass of (P279) or *any subproperty* of P279? Lucas Werkmeister you have some familiarity with constraint logic, is this possible? That would eliminate the need for the workarounds mentioned above. ArthurPSmith (talk) 16:07, 13 January 2022 (UTC)
- I don’t think that’s possible, no. Lucas Werkmeister (talk) 00:47, 14 January 2022 (UTC)
- I'd rather say that subproperty support would be yet another workaround to the actual problem of taxon items lacking P279 statements. 2001:7D0:81DA:F780:449B:6048:408E:76D1 10:34, 14 January 2022 (UTC)
- Comment No strong feelings about it, but I do feel P31 suffices. The ontological modelling of taxa is weird, though: it is a mix of people seeing it as a class and people seem it as a term. taxon synonym (P1420) treats taxa like terms, like lexemes, for example. IMO, if we agree on Delete we are also agreeing that taxa should be modeled as classes (what I support). TiagoLubiana (talk) 17:20, 13 January 2022 (UTC)
- As I understand it, despite using the work "synonym", the property taxon synonym (P1420) is referring to a synonym (Q1040689), aka taxonomic synonym, which isn't a linguistic/lexical concept, but rather a specific statement that someone somewhere has said that two taxa are referring to the same organisms (taxonomy being a complete mess, historically, this happened quite a lot!). It's more like a special case of said to be the same as (P460) with very specific semantics (completely unlike P460).
- But taxa are very odd, since they have an entirely separate membership hierarchy to all other items. Inductiveload (talk) 18:06, 13 January 2022 (UTC)
- Exactly this. “…weird, though: it is a mix of people seeing it as a class and people seem it as a term”. Taxa and nomina could be modeled separately. (Or maybe there is a more elegant solution to handle both taxonomic concepts and naming?) For example, the Pacific oyster has been classified as Crassostrea gigas (Q20857) or Magallana gigas (Q61695262). It's still the same species concept, the circumscription hasn't changed. But we don't have a single item for the concept of “pacific oyster”. What has changed is the concept of the genus it belongs to: Crassostrea in the broader sense (sensu lato) includes Crassostrea sensu stricto and Magallana (Q47463935). Those two senses of Crassostrea are distinct sets having different membership. But because they have the same name “Crassostrea”, we only have one item Crassostrea (Q542708). Stepping up above the genus level, pacific oysters are still a type of oyster; Crassostrea s.l., Crassostrea s.s., and Magallana are all sub-taxa of family Ostreidae (Q21154). This example isn't some weird edge case: lumping and splitting parent taxa is just one of the many ways that names can change, and happens in taxonomy and nomenclature (two separate but related disciplines) all the time. (In some ways, the distinction between taxa and nomina is akin to our separation of items and lexemes apple (Q89) / apple (L3257).) ⁓ Pelagic ( messages ) 20:00, 10 February 2022 (UTC)
- Comment Is Marius (Q15979689) a named individual of the species reticulated giraffe (Q27497311) and/or the subspecies Giraffa camelopardalis reticulata (Q656059)? From a nomenclatural perspective the names Giraffa reticulata and Giraffa camelopardalis reticulata refer to the same thing, because they have the same type (Q3707858). Adding different values of subclass of (P279) to them (Giraffa/Giraffa camelopardalis) would make no sense. From a taxonomic perspective both belong to the (sometimes monotypic monotypic taxon (Q310890)) genus Giraffa (Q862089). Giraffa is a name which refers to different taxon concepts (!=taxon (Q16521)) up to 4 recognized species (eg. Whole-genome analysis of giraffe supports four distinct species (Q110263251), First insights into past biodiversity of giraffes based on mitochondrial sequences from museum specimens (Q104624724), Multi-locus Analyses Reveal Four Giraffe Species Instead of One (Q26857906), Ungulate Taxonomy (Q110414936)). subclass of (P279) is not a replacment for parent taxon (P171) as suggested in the past and here again. We do not model taxa. We do model taxon name (P225) according to the different nomenclature code (Q2673092) and their relationship. --Succu (talk) 18:12, 13 January 2022 (UTC)
- @Lucas Werkmeister: All of your above mentions examples have more than one issue. E.g. Sunny (Q14744025) is a dog breed (Q39367) in the taxonomy of Fédération Cynologique Internationale Groups (Q2150520). --Succu (talk) 19:13, 13 January 2022 (UTC)
- Methuselah (Q590039) should be better somehow related to solitary plant (Q476164).--Succu (talk) 20:21, 13 January 2022 (UTC)
- Moja (Q12038481) is/was a Gorillas in Zoo Praha (Q21167458) modeled as captive mammal (Q57812611)... --Succu (talk) 21:00, 13 January 2022 (UTC)
- This view that we model taxon names, not taxa, does not reflect reality really. In general, current taxon items are explicitly set as instances of taxon (Q16521), while taxon name (P225) is given as merely an attribute to a taxon, taxon (not its name) has parent taxon (P171) etc. Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database. Any taxon as class warrants some P279 statement as well. If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see Wikidata:Lexicographical data).
- It isn't clear what are you trying to polemize about with this giraffe example. What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem. You also say that "examples have more than one issue", but your subsequent response doesn't explain in any way what the issues are, as far as I can see. Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought Q21167458 was). 2001:7D0:81DA:F780:449B:6048:408E:76D1 10:34, 14 January 2022 (UTC)
- I do not discuss this with you Tamawashi. --Succu (talk) 19:48, 14 January 2022 (UTC)
- I'm fairly sure you can't provide any behavioural evidence to this baseless claim. 2001:7D0:81DA:F780:A513:C337:6EC7:3D2F 08:25, 15 January 2022 (UTC)
- I do not discuss this with you Tamawashi. --Succu (talk) 19:48, 14 January 2022 (UTC)
- We now have editors deleting existing statements using this property, which I think is premature until this deletion proposal is resolved. https://www.wikidata.org/w/index.php?title=Q14744025&oldid=prev&diff=1561810384 and https://www.wikidata.org/w/index.php?title=Q590039&oldid=prev&diff=1561810009 are two examples. This is not fair to the original proposer. UWashPrincipalCataloger (talk) 21:15, 13 January 2022 (UTC)
- Fair? --Succu (talk) 21:23, 13 January 2022 (UTC)
- @Succu Sure, this qualifier-based solution would also be possible, I'm just warning it's less elegant because it doesn't allow multiple values with different circumstances such as in Q11133287#P10241. Vojtěch Dostál (talk) 12:16, 14 January 2022 (UTC)
- It shows only that it is not necessary to randomly drop in subclass of (P279) statements at taxon items to resolve the constraints. A sperate property is allway a better solution. --Succu (talk) 16:41, 14 January 2022 (UTC)
- @Succu Sure, this qualifier-based solution would also be possible, I'm just warning it's less elegant because it doesn't allow multiple values with different circumstances such as in Q11133287#P10241. Vojtěch Dostál (talk) 12:16, 14 January 2022 (UTC)
- Fair? --Succu (talk) 21:23, 13 January 2022 (UTC)
- Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above). 2001:7D0:81DA:F780:A513:C337:6EC7:3D2F 08:25, 15 January 2022 (UTC)
- Plus @Succu: it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept. Liuxinyu970226 (talk) 02:25, 26 April 2022 (UTC)
- Actually it would probably be doable too, using two independent statements. I'm taking it back. Your solution is an option, definitely better than using taxon names as values in P31 itself. Vojtěch Dostál (talk) 12:20, 14 January 2022 (UTC)
- Keep Solution using instance of (P31) is quite poor - hard to query and creating constraint violations. --Jklamo (talk) 01:59, 14 January 2022 (UTC)
- Comment Anyway, in case the decision to migrate back to P31 prevails, I would prefer if the current usage of taxa in P31 is cleaned up before migration, because most of them have nothing to do with individual organisms. See https://w.wiki/4gUi for items which currently include taxa among their P31 statements. Please don't create chaos where measures to introduce order were taken, even if you don't agree with the way it's been done.--Vojtěch Dostál (talk) 12:26, 14 January 2022 (UTC)
- Keep For arguments see above --Succu (talk) 20:18, 14 January 2022 (UTC)
- Delete Too hard to understand and for translation, better to propose more smartphone-like properties. --Liuxinyu970226 (talk) 04:18, 15 January 2022 (UTC)
- presumably you commented on the wrong discussion? what does this have to do with smartphones? BrokenSegue (talk) 23:00, 15 January 2022 (UTC)
- Keep i don't understand how you propose replacing this with instance of (P31)? Do you want to make every taxon also a subclass? That seems like a big change. Can't vote delete until this is answered. BrokenSegue (talk) 23:00, 15 January 2022 (UTC)
- It's answered in the original post and in subsequent posts. The change that we currently face is/was to replace P31, not the other way around. Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon? In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like this, for unclear reason. 2001:7D0:81DA:F780:7D84:5196:57E3:FA94 13:45, 16 January 2022 (UTC)
- As you know this problem was „fixed ages ago“ via parent taxon (P171). --Succu (talk) 18:57, 17 January 2022 (UTC)
- „This edit“ becomes to that. What is a taxonomic subclass of Fraxinus excelsior (Q156907)? Anything equal or below plant (Q756)? Or taxonomic - according to a source - related? --Succu (talk) 22:28, 17 January 2022 (UTC)
- Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what "problem" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well.
- What is a (taxonomic) subclass of Q156907? I don't quite understand why you ask and what this have got to to do with previous discussion. 2001:7D0:81DA:F780:3D6D:39C0:BEF:717D 10:32, 18 January 2022 (UTC)
- Comment As Lucas noted, P31 wasn't working as he didn't notice before that "Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see."
- The property actually fixes items in a field that was poorly modeled with instance of (P31).
- This is similar to the way we do it with sex or gender (P21), occupation (P106) and other aspects.
- In general, if need to be a expert in a field to determine the correct P31, than it's probably not good modeling (IMHO). --- Jura 11:12, 18 January 2022 (UTC)
- It's answered in the original post and in subsequent posts. The change that we currently face is/was to replace P31, not the other way around. Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon? In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like this, for unclear reason. 2001:7D0:81DA:F780:7D84:5196:57E3:FA94 13:45, 16 January 2022 (UTC)
- Keep Yes the change was very poorly communicated. I understood about it after some people started complaining to me about broken queries and missing data. That said I support the new property. Adapting my broken queries to the change actually made them simpler and faster. I think that, given the universal character (and scale) of the Wikidata Knowledge Graph it makes sense to unload instance of (P31) as much as possible from specifics about a given field. Similar to human (Q5), I approve the prospect of being able to rely on something like individual organism (Q110224119) and a dedicated property instead of having to filter out which of the types I am looking for. --Nikola Tulechki (talk) 08:43, 19 January 2022 (UTC)
- Delete. Taxons are classes, we don't need a subproperty of instance of (P31) just for taxons. P31 should accept P171 as equivalent to its superproperty. --Yair rand (talk) 23:07, 8 February 2022 (UTC)
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.
- Nomination withdrawn — Martin (MSGJ · talk) 10:31, 24 May 2022 (UTC)
Snooker Database player ID (archived) (P4538): (delete | history | links | entity usage | logs | discussion)
Linked website has not been updated for several years and has now gone permanently offline / verlinkte Website wurde seit Jahren nicht mehr aktualisiert und ist jetzt offline gegangen —- HvW (talk) 14:29, 21 March 2022 (UTC)
- Property has 464 uses. @HvW: is there any archive available that we can link to? — Martin (MSGJ · talk) 07:19, 17 May 2022 (UTC)
- Wait a minute. Can it be. . . I think snookerdatabase.co.uk is online again. The web.archive replacement in WD was misleading. Okay, if that's so the property may not be of much use, but we can keep it just the same. -- HvW (talk) 08:29, 17 May 2022 (UTC)
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.
- Delete — Martin (MSGJ · talk) 20:27, 26 May 2022 (UTC)
P6065 (P6065): (delete | history | links | entity usage | logs)
Pages do not exist as scoresway.com is defunct. I already removed the few usages it had. Pelmeen10 (talk) 12:36, 2 April 2020 (UTC)
- A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
- Had never more than 50 uses .. I'd tend to delete this --- Jura 08:18, 10 April 2020 (UTC)
- Then, please discuss at the projects where is used first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)
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.
- No consensus to delete — Martin (MSGJ · talk) 20:20, 26 May 2022 (UTC)
Shoftim BeIsrael judge ID (P3751): (delete | history | links | entity usage | logs | discussion)
Shoftim.org.il is defunct. —עלי (talk) 00:50, 3 June 2021 (UTC)
- @עלי: being defunct is not alone a reason to delete. also you went through and removed all the links to this property which makes assessing whether we should keep it impossible. please undo that. BrokenSegue (talk) 01:28, 3 June 2021 (UTC)
- @BrokenSegue: I will not do something as useless as that. Sorry. You may examine the Wikidata property example (P1855) of this property, so it's not impossible. When a property's sole purpose is linking to a website, I think the website being defunct is sufficient reason to delete the property. It was a sufficient reason to delete its template at hewiki. Having said that, tipping you for a useless property is enough. Accept or reject the request, I am not going to spend even one more second of my time regarding this property. Thanks. עלי (talk) 01:59, 3 June 2021 (UTC)
- @עלי: wow... that was needlessly hostile. Deleting all usages of a property and then listing it for deletion is obviously the wrong order to do something in. It's like blanking an item and then listing it for deletion. What hewiki does has no bearing here. There is potential value in external identifier for defunct websites. BrokenSegue (talk) 03:20, 3 June 2021 (UTC)
- @BrokenSegue: No, there isn't. At least not when we are talking about a private website, who holds a private nonofficial database. The website died and its identifiers died with him. Please elucidate what could be the potential value, regarding this specific property. Sorry for my previous impatient reply. עלי (talk) 03:56, 3 June 2021 (UTC)
- @עלי: often websites are well archived by some third party e.g. http://web.archive.org In those cases these identifiers can still be used by looking at the archives. Additionally if a website's identifiers are used elsewhere on the Internet then having these identifiers remains valuable for joining between databases. BrokenSegue (talk) 04:11, 3 June 2021 (UTC)
- @BrokenSegue: No, there isn't. At least not when we are talking about a private website, who holds a private nonofficial database. The website died and its identifiers died with him. Please elucidate what could be the potential value, regarding this specific property. Sorry for my previous impatient reply. עלי (talk) 03:56, 3 June 2021 (UTC)
- @עלי: wow... that was needlessly hostile. Deleting all usages of a property and then listing it for deletion is obviously the wrong order to do something in. It's like blanking an item and then listing it for deletion. What hewiki does has no bearing here. There is potential value in external identifier for defunct websites. BrokenSegue (talk) 03:20, 3 June 2021 (UTC)
- @BrokenSegue: I will not do something as useless as that. Sorry. You may examine the Wikidata property example (P1855) of this property, so it's not impossible. When a property's sole purpose is linking to a website, I think the website being defunct is sufficient reason to delete the property. It was a sufficient reason to delete its template at hewiki. Having said that, tipping you for a useless property is enough. Accept or reject the request, I am not going to spend even one more second of my time regarding this property. Thanks. עלי (talk) 01:59, 3 June 2021 (UTC)
- Comment Some pages are archived at Internet Archive, e.g. https://web.archive.org/web/20180307051719/http://www.shoftim.org.il/page.asp?id=104. --Stevenliuyi (talk) 04:09, 3 June 2021 (UTC)
- Fine. I will not pursue this request any further. Wasted enough of my time, that's wikidata's maintenance administrators concern anyways. Thanks. עלי (talk) 04:16, 3 June 2021 (UTC)
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.
- No consensus to delete at this time. Please consider a well framed RfC to look at the whole issue in more detail — Martin (MSGJ · talk) 20:58, 27 May 2022 (UTC)
ALA-LC romanization for Ukrainian (P9453): (delete | history | links | entity usage | logs | discussion)
We already have a property for ALA-LC romanisation - ALA-LC romanization (P8991) - and I don't see any need for this one to be separate. It has only been used 6 times so far, so migrating the statements would be easy and deleting it shouldn't break anything.
(pinging people from the original proposal @ArthurPSmith, Pamputt, Mzajac:)
--Nikki (talk) 08:04, 30 August 2021 (UTC)
- I just noticed on the property talk page that Mzajac thinks we should have specific properties for every romanisation table ALA-LC has. I don't think that's a good idea because it would require a lot of properties (making it much harder for people find the right one to use) for little benefit. On https://www.loc.gov/catdir/cpso/roman.html there are 75 different files (which sometimes have different variations for different languages, e.g. Non-Slavic Languages (in Cyrillic Script)) and the index of languages covers around 150 different languages. The tables can also change over time (e.g. the 1997 version for Korean would use "dijain" for "디자인", while the 2009 version would use "tijain").
- For the most part, there is one ALA-LC romanisation system for each language and script. In the cases where it's ambiguous (e.g. Khakass in the non-Slavic languages file), I would suggest using determination method (P459) to specify the exact version.
- - Nikki (talk) 08:50, 30 August 2021 (UTC)
- Nikki makes a good point here, I have no strong opinion on whether this is really needed or not. ArthurPSmith (talk) 13:32, 30 August 2021 (UTC)
Firstly, a romanization is precisely defined by a single table. For example, ALA-LC Romanization for Ukrainian and ALA-LC Romanization for Russian are two different tables, intended for alphabets that share many of the same letters, some of which are pronounced differently. They can be applied to a specific string of characters and yield different results. ALA-LC Romanization is a very large set of tables. For Slavic languages, there are also some simplified variations (“modified Library of Congress”) intended for use in text rather than for library cataloguing. It has tried to maintain some phonological consistency, so languages can be compared. In contrast, BGN/PCGN is a set of tables coming from different national authorities, so its schemes are diverse. Some systems are for only one language and have only one table. There are also “universal” transliteration systems like ISO 9-1995 that has one table for all Cyrillic-script text. Some have changed their standards, so, e.g., there’s a BGN/PCGN-1965 romanization for Ukrainian and a 2019 one. For unambiguous identification, and for automation, just “ALA-LC romanization” is not good enough.
Secondly, and more importantly, romanization as it is modelled in Wikidata is a hot mess, and solitary changes like this won’t fix it. We need to create an overall framework. I started proposing properties based on others already present. But even now I can’t hold in my head at once all of the ways to indicate romanization here: sometimes it’s a statement (for items representing names), sometimes a property on a statement, sometimes a determination method property, and I don’t even know anything about how lexemes work. It applies differently to monolingual text or generic strings that may contain multiple languages. So I have no idea whether deleting this property is an improvement or not.
In comparison, w:IETF language tagging is a flexible scheme for identifying romanized text with a variable amount of precision, and this might be a useful model to inform us going forward. I can construct a language tag that indicates language, writing system, or method of romanization referring to a general system or a specific version of it. —Michael Z. 17:26, 3 September 2021 (UTC)
- Keep Per Michael above, the scale of culture differents between RU and UA made the potential merging of properties nogo. --Liuxinyu970226 (talk) 01:04, 7 September 2021 (UTC)
- I don't see why ALA-LC romanization (P8991) could not be used, qualified by the particular table: ALA-LC romanization of Ukrainian (Q100903064) has an item. I tried it out on Б (Q16291). UWashPrincipalCataloger (talk) 21:32, 28 September 2021 (UTC)
- Because if I remember correctly, Г (Q16335) is pronunced as /ɦ/ in Ukrainian, not /g/? Liuxinyu970226 (talk) 07:15, 11 January 2022 (UTC)