Talk:Q52105174

From Wikidata
Jump to navigation Jump to search

Hoping to start a discussion about reasons for deprecation, it seems to me there are too many overlapping ones and maybe a few that are a little to specific (maybe even a little argumentative?). Would it maybe be a good idea to consolidate and restrict the reasons to a smaller, more universal list? Moebeus (talk) 09:02, 22 April 2018 (UTC)[reply]

[edit]

[1] --Liuxinyu970226 (talk) 06:13, 25 November 2018 (UTC)[reply]

While there might be a few false positives there, it is at least more up-to-date than the limited list in the item. Or, we could create an automatically maintained list (possibly moved to a separate Project page, added as a sitelink to this item?):  – The preceding unsigned comment was added by Mormegil (talk • contribs) at 09:46, 8 November 2021‎ (UTC).[reply]
(List moved to the top and made collapsible) —MisterSynergy (talk) 10:00, 25 February 2022 (UTC)[reply]

"Former entity"

[edit]

@Dcflyer: Per Help:Deprecation, Help:Ranking#Deprecated rank, and elsewhere, deprecation (and reason for deprecated rank (P2241)) are for statements that were never accurate. Statements that were once true but no longer are are supposed to use end cause (P1534) instead. The item former entity (Q15893266) falls into the latter category, and is properly a value of end cause (P1534), not reason for deprecated rank (P2241). Statements using it with reason for deprecated rank (P2241) should be converted to use end cause (P1534).

@Swpb: Thank you for the detailed information which you provided. Unfortunately, end cause (P1534) will not work with statements for most identifiers without the creation of single-value constraint (Q19474404) violations, opposed to the now realized incorrect usage of deprecation and reason for deprecated rank (P2241). E.g., for the recently created item Connie Morella Library (Q69776897), there are two GNIS Feature ID (P590)s (as well as two GeoNames ID (P1566)s) which create constraint violations due the fact that GNIS Feature ID (P590) contains only the single-value constraint (Q19474404) separator (P4155) of subject has role (P2868). If you know of an alternative, if such one exists, to adding single-value constraint (Q19474404) exception to constraint (P2303) to a given property for a given item for this type status, it would be appreciated. Thank you for your assistance. - Dcflyer (talk) 16:22, 23 October 2019 (UTC)[reply]
@Dcflyer: Using end cause (P1534) vs. reason for deprecated rank (P2241) doesn't cause those constraint violations; having the same value for subject has role (P2868) does. If you want to add end cause (P1534) as a separator on the single value constraints, that would clear the violation, but it might require a custom constraint. Either way, these identifier statements don't get in the way of fixing the mistake of calling "former entity" a reason for deprecation. Unless you can show me some violations that would be caused by this fix... Swpb (talk) 17:49, 23 October 2019 (UTC)[reply]

How to categorize an expired domain that has been squatted?

[edit]

Question on best practice with squatted domains. The Italian town Q303743 seems to have let their former official domain expire. The site listed as official website is now pointing to a spammy ad site (the town now has a site on a subdomain of the regional government, which I added and set to preferred rank). What to do with this link? I marked the official domain as depreciated and added the expired qualifier with 'expired domain' as reason. Strictly speaking though, the domain is still up. An alternative might be expired with 'link rot', but again strictly spearking, the link still functions. What is the best practice here? Perhaps removing the former site altogether? Deshak (talk) 17:56, 24 January 2022 (UTC)[reply]

I don't think removing it would be ideal: somebody might want to describe the history of the web site, including the move. "Expired domain" sounds right to me, as the domain did expire, regardless of what happened later. I don't know whether there are problems with how Wikidata treats the situations. –LPfi (talk) 07:58, 17 March 2022 (UTC)[reply]
Well, there is an explicit cybersquatted domain name (Q62606058). --Mormegil (talk) 08:06, 17 March 2022 (UTC)[reply]

How to describe blatant factual errors?

[edit]

How shall I describe a blatant factual error that I'm deprecating? I've been using things like "unable to confirm in sources" and there are other plausible values such as "contradiction", but I don't see anything that unambiguously denotes a verifiable falsehood that was never true. Elizium23 (talk) 21:34, 1 February 2023 (UTC)[reply]

@Elizium23 if the fact is not covered by a serious source, I think just removing is correct solution. In enwiki, unsourced statements will be just deleted Estopedist1 (talk) 06:45, 2 February 2023 (UTC)[reply]
It seemed to me that long-standing factual errors would be the ideal candidates for deprecated status. I am being told that there are many reasons to avoid deprecating in favor of removal, and now this is one more. Interesting. I am now unsure if there are ever cases to be made for deprecation at all. Elizium23 (talk) 06:52, 2 February 2023 (UTC)[reply]
If there is no source at all, and the information is clearly wrong, I’d say remove. But if there is a relevant reference which states this clear factual error, I’d say keep and deprecate. (And as for the specific reason for deprecation, I’d say choose one of many appropriate options, e.g. misinformation (Q13579947), incorrect value (Q41755623), error (Q29485), error (Q3847033), or in the relevant cases options like misprint (Q21096955) or typographical error (Q734832) may be useful.) --Mormegil (talk) 14:41, 2 February 2023 (UTC)[reply]
I'm thinking that retraction notice should be added to this list. In the case of some factual errors, I just used it somewhere think it's probably appropriate - see e.g. https://www.wikidata.org/wiki/Talk:Q59693052#Delete. Any [dis]agreement? I agree withMormegil. RudolfoMD (talk) 00:49, 30 November 2023 (UTC)[reply]
There already are retracted paper (Q45182324) and retracted scholarly article (Q77253277). --Mormegil (talk) 09:12, 30 November 2023 (UTC)[reply]
Thanks. I missed 'em. (Never mind then, folks.) RudolfoMD (talk) 09:26, 30 November 2023 (UTC)[reply]

Most common "not marked valid" reasons for deprecation used.

[edit]

As of the recent update, these are most common that are not marked valid: false precision,  former entity, most precise value, manumission, HTTP 404, writing system, name change, reopening, COVID-19 pandemic.

At a first glance, I'd say should be, respectively: valid, valid, clearly in error, valid, prolly OK?, nah?, valid, nah?, nah. most precise value is a reason to mark as preferred, so I'm going to look at these. RudolfoMD (talk) 22:00, 30 November 2023 (UTC)[reply]

pre-transition images of trans people

[edit]

In the same vein as the inclusion of "deadnaming" in this list, I think there should be a "pre-transition image" reason for depreciation listed here. I intended to use this for Q44641 whose image dates back to her high-school years, and there's probably many other relevant cases. Typhoeus (talk) 11:07, 1 March 2024 (UTC)[reply]