Help talk:Deprecation

reason for deprecation (P2241)

"A deprecated value should always have a reason for deprecation (P2241) qualifier - see values already used for this (some may be sub-optimal). "

I don't think it's good to have such a rule as it increases the amount of work that has to be done for deprecation which discourages using the feature. incorrect value (Q27533685) also doesn't really provide added information. ChristianKl (talk) 13:41, 5 July 2017 (UTC)

Maybe we should say that every P2241 must have a reference? Q.Zanden questions? 13:43, 5 July 2017 (UTC)

Firstly, we're not writing "rules". Secondly, incorrect value (Q27533685) is already nominated for deletion. Thirdly, please note that the wording you quote says "should", and not "must". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 5 July 2017 (UTC)

Well, it is only just an option and therefore I'm using "should". Please note that EN is not my native language. Q.Zanden questions? 14:02, 5 July 2017 (UTC)

My reply was to the original poster in this section, not you (you didn't quite any wording). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 5 July 2017 (UTC)

My default understanding of "should" when writing documentation is the RfC2119 one. That means there can be expections, but there has to be a specific reason to avoid a recommendation. I think that's too strong in this case. Not wanting to put in the effort to add a qualifier, is ground enough to avoid doing it. ChristianKl (talk) 16:17, 5 July 2017 (UTC)

What is the reason of this page ?

Why do we need a new help page ? We have already Help:Rank so please use that page instead of spreading information in several pages. With time this will just lead to contradictions and confusion. Snipre (talk) 18:07, 5 July 2017 (UTC)

Maybe one property (reason for deprecated rank (P2241)) is not enough to have a separate Help page.

We need materials from this page but probably at Help:Rank page, so both can be accessed at once. d1g (talk) 23:22, 5 July 2017 (UTC)

Item of insufficient quality

Almost a year ago I found that software (Q7397) had as many as six different model items defined, which seemed good. However, I didn't agree that Android (Q94) was a suitable model item for software (Q7397), mainly for two reasons:

• It was (and still is) an instance of (P31) mobile operating system (Q920890) (preferred, besides computing platform (Q241317)). This is not wrong, as mobile operating system (Q920890) is indeed a subclass of software (Q7397), but it's far from a typical class of software. Many properties defined for a mobile operating system may not be relevant for an arbitrary piece of application software. Provided there are no other issues, Android (Q94) might be a suitable model item for mobile operating system (Q920890) instead.
• Android (Q94) was (and still is) declared a subclass of (P279) mobile operating system (Q920890) as well. In class logic, an item typically isn't (except for a few special cases) both an instance and a subclass of the same class.

Since I didn't have time to sort out how instance of (P31) and subclass of (P279) should be used with respect to software items, i decided to deprecate the model item statement pending a future resolution. For lack of a more obvious option, I used disputed (Q18912752) as my reason for deprecation.

I later found that disputed (Q18912752) wasn't initially defined as a reason for deprecation, but had been added to the class of reasons shortly before I used it.

Now I wonder: Is there a more appropriate reason for deprecated rank to use with model item (P5869) claims, or should we create one? I would also like to indicate why the object item is undesirable as a model, but that indication is probably better placed on the object item itself. I'm now merely looking for something like "item of insufficient quality" or similar (so as not to restrict use of this reason to model item (P5869) only, but it might be used also with other potential properties where the data quality or structural constitution of the object item is important). Is there a procedure by which additional reasons should be evaluated before creation, or can I define new ones as I see a need for them?

I have now also added reason for deprecated rank (P2241)refers to different subject (Q28091153) and intended subject of deprecated statement (P8327)mobile operating system (Q920890) to the deprecated claim, with respect to my first objection above.

Since I'd like to encourage more active evaluation and monitoring of model item assignments (see Wikidata talk:WikiProject Data Quality#Model item quality, and related aspects), I'm putting this extra effort into getting community approval of any relevant procedures well in advance. --SM5POR (talk) 14:09, 1 January 2023 (UTC)

Clarification of reasons

I should mention that I have added a "Clarification" section to Talk:Q42727519 in order to provide a more elaborate explanation why a particular (but yet common) kind of claim has been deprecated, and may continue to do likewise with other reason items, as the "reason" labels alone may be a bit cryptic to editors unfamiliar with Wikidata conventions. If there is a need to point out exactly which explanation applies, a qualifier like Wikimedia community discussion URL (P7930)https://www.wikidata.org/wiki/Talk:Q42727519#Subclass_of_entity can be used in addition to reason for deprecated rank (P2241).

I realize this measure is limited to a single language (English in our case), but I figure it's better to have some guidance in place than having none at all just because a more specific reason item hasn't been created and labeled yet. --SM5POR (talk) 14:21, 1 January 2023 (UTC)

Refers to lexicographic sense

There are quite a few items with statements clearly referring to the label of the item in one or more languages, rather than to the subject item itself; based on earlier queries I estimate this to be true for up to some 10,000 items. An example is subclass of (P279) of Russian Soviet Federative Socialist Republic (Q2184) which I just deprecated not only for this conflation (which it technically is), but also for using an inappropriate property (subclass of (P279) instead of instance of (P31), thereby making it ideal as a deprecation showcase since a named defunct state is typically never a class anyway).

Processing all these cases will be a substantial undertaking, and one that shouldn't be performed on a whim, since we need to agree on the appropriate procedure, and even if it should be undertaken at all; I believe myself that it should be, but it marks a shift in the way we deal with language-specific information in Wikidata, and that has to be properly discussed and decided by the community.

Since labels in Q-item space aren't sophisticated enough to hold arbitrary properties of their own, I propose that these statements, if deemed desirable to retain, should be moved from Q-item space to the corresponding lexicographic senses of said items, or possibly some other kind of entity that may or may not yet exist.

To prepare for this potential move, I propose creating a "refers to lexicographic sense" reason for deprecation, in analogy with refers to different subject (Q28091153) which is already used for a similar purpose within the main Wikibase item namespace. I also invite you to comment on the appropriateness of this particular item, as well as the major strategy proposal above. Do you see any alternative strategies that should be considered? --SM5POR (talk) 00:06, 5 January 2023 (UTC)

I may have to retract some of my earlier claims about Wikidata being littered with tens of thousands of lexemes dressed up as make-believe Wikibase items, after realizing it may simply be a matter of poor classification; of course, merely claiming that an entity is an instance of term doesn't necessarily make it one, especially if there is widespread confusion regarding the difference between "term" and "concept".

But there are still some items that are instances of word or phrase, and when I now find myself compelled to deprecate instance of (P31) of Lopado­temacho­selacho­galeo­kranio­leipsano­drim­hypo­trimmato­silphio­karabo­melito­katakechy­meno­kichl­epi­kossypho­phatto­perister­alektryon­opte­kephallio­kigklo­peleio­lagoio­siraio­baphe­tragano­pterygon (Q101) which turns out to be an existential claim of one of the oldest items in Wikidata, even I hesitate at the boldness of such an action, and I would like to hear a second opinion. Could it really be that Lopado­temacho­selacho­galeo­kranio­leipsano­drim­hypo­trimmato­silphio­karabo­melito­katakechy­meno­kichl­epi­kossypho­phatto­perister­alektryon­opte­kephallio­kigklo­peleio­lagoio­siraio­baphe­tragano­pterygon (Q101) has been a case of conflation for all this time? Who am I to suggest that this showcase item is actually in violation of one of the guiding principles in the design of the Wikidata ontology?

@VIGNERON, @GZWDer, @Wd-Ryan, @TomT0m, @Infovarius, @ArthurPSmith, maybe you can weigh in on this? If Q101 (I'd better avoid expanding that label if anyone is going to read this) is indeed a case of conflation as the word is not the thing, then all its linguistic claims ought to be moved to its corresponding Greek lexeme (L7868), its labels in languages other than Greek properly translated and described (or removed, if the dish isn't known at all in a particular language), and be left with instance of (P31)fictional dish (Q64493617) and fabrication method (P2079)fricassee (Q791790) as its only claims.

But as any Wikimedia article focusing on the word rather than on the thing would still require a Wikibase item to link to, such an item would have to be created, and all the claims that were just moved to the lexeme (where they belong) would be copied back to this new instance-of-word item, and we would end up with two entities within Wikidata serving the role of one, just using slightly different data structures (lexeme vs item). And the fictional dish item wouldn't be one of them, but a third entity ("the thing").

If this doesn't make the case for allowing Wikimedia articles to link directly to a lexeme (rather than to a Wikibase item associated with that lexeme) as their main subject, then I don't know what does.

However, "refers to lexicographic sense" has not yet been acknowledged as a valid reason for deprecation (and a subclass of (P279)refers to different subject (Q28091153)); perhaps it shouldn't be? I proposed it, so it can hardly be my job to approve it as well, if an approval is even warranted in such a case. But given my recent observation above, anyone who decides on this issue should from now on be aware that an approval will probably lead to the deprecation of Q101 as a map–territory relation (Q1963130) kind of conflation and therefore its partial relocation to lexeme space, once the Wikimedia-link-directly-to-lexeme-Do-not-pass-Wikibase-item-Do-not-collect-$200 issue has been resolved.

A proposal towards the latter end is in the works, and that is what led me to write this comment. I just need to sort out the confusing statistics. Or maybe not. --SM5POR (talk) 08:44, 20 January 2023 (UTC)

@SM5POR: The English wikipedia article is clearly about both the word and the fictional dish, and I'm guessing the same is true in other languages, so it seems fine to leave this item as being about both things (just like "Bonnie and Clyde" etc). If we feel we need separate items for the word and for the dish we could do that, but I don't believe in forcing creation of extra items if we don't have some other need for them. ArthurPSmith (talk) 14:34, 20 January 2023 (UTC)

@ArthurPSmith: Thanks; I do appreciate the feedback! I also admit to not having looked at the articles themselves, assuming their actual contents won't really matter. This may have been a tactical mistake of mine.

The actual problem here isn't Q101, but the more general one of dealing with the implicit word/thing relationship that may be overlooked when writing an encyclopedic article in any single natural language. Wikidata is an attempt at separating the two (word vs thing) from each other, and I find it quite successful at that, except when editors fail to recognize the distinction and treat the two aspects as one and the same, leading to conflation when the item is simultaneously declared to be an instance of word or phrase (Q115372263) and a class or an instance of physical object (Q223557) (or any other non-linguistic object, including fictional and abstract ones).

In most cases of conflation, the issue can be resolved by deprecating the few statements pertaining to the lesser or secondary topic, usually the word when it's a word/thing issue, no big deal. But in the case of Q101, it actually is a big deal, because the same approach would effectively destroy the item (unless you are prepared to deprecate the dish-related statements and keep it as a word item only), and that's why I picked it as an illustrative example of the general problem. While the Wikipedia articles may well discuss the dish itself, that item would hardly have met the notability criterion if it hadn't been for the long and very unique Greek word Aristophanes coined to describe the dish.

A conflated item is characterized by mixing properties pertaining to one or the other of multiple item classes but not both, such as pronunciation audio (P443) and mass (P2067), even when the former property is qualified using language of work or name (P407) (and I think there is a good reason this qualifier isn't labeled "language of word, work or name"; it's simply not intended for arbitrary items, just for creative works or proper names). This may not be obvious to an editor working in a single language, say English, but it sure looks weird to a native speaker of Swedish when curriculum (Q207137) is described as a series of learning and a Latin phrase as was the case two years ago, considering that the Swedish word läroplan (L482307) is certainly not a Latin phrase.

I'm sometimes tempted to add a statement whale (Q1865281)different from (P1889)public election (Q40231) just to drive home the point I'm trying to make. I mean, nobody can claim that's an incorrect statement, right, but is it necessary or even generally helpful..?

Maybe this shows that Q101 isn't a particularly good example anyway, due to the apparent lack of translations of the original Greek word, which keeps the number of potential items down. Thus, solving the problem for Q101 only by somehow declaring it exempt from the claim of conflation will not help addressing the general issue.

However, unilaterally declaring "refers to lexicographic sense" as a valid reason for deprecated rank (P2241) without explicit support from any other editors, just because I can, isn't exactly my cup of tea, and I may simply avoid working on similarly conflated items for the time being. As I said, I have a proposal for a solution in the works, but as long as nobody else is asking for it, putting forward that proposal is likely to fall flat as a wasted effort. --SM5POR (talk) 14:22, 21 January 2023 (UTC)

Bad qualifiers

As deprecation depends on the rank, which is associated with the main statement only, there is no way to deprecate a bad or misplaced qualifier (nor a poor or misleading reference). An example of this is location (P276) of Madonna and child with saints (Q3842699) which has an incorrectly used qualifier of floors above ground (P1101) (it's meant tp indicate the height of the building, not what floor a subject item is to be found on.

I suppose I should simply remove the misplaced qualifier, but am I expected to do anything besides removing it or not? Either way, a brief clarification in the Help:Deprecation#Examples section would be helpful. --SM5POR (talk) 13:41, 15 January 2023 (UTC)

You either remove the qualifier or you deprecate the whole statement and at another statement that's correct. ChristianKl ❪✉❫ 15:58, 2 February 2023 (UTC)

Should people the death of fictional characters who were revived be deprecated?

My intuition suggests that butsumetsu (Q104602651) isn't a valid reason for deprecation as the death is real. What do others think? ChristianKl ❪✉❫ 17:57, 2 February 2023 (UTC)

As the person who first brought it up on the OP's talk page: my reason for considering the item in question suitable as a deprecation reason was that although the deaths indeed occur (that is, are real in terms of the fictional universe) in the shows, the characters are still revived from the deaths in question, which thus negates the death date. Additionally, there are also other existing deprecation reasons like surrendered and withdrawn award (the latter which is on Help:Deprecation's page) which involve things that initially occurred (rating classification and award granting) but were reverted in principle. ミラP@Miraclepine 22:57, 2 February 2023 (UTC)

@Miraclepine, @ChristianKl: If conditions change, such that a claim that was once true no longer is so, the response should be to set an end time on the claim, not to deprecate it like you do if the claim has always been false. In a fictional universe where characters may have several lives, the constraints against multiple times of death for the same individual (and others of a similar kind) simply don't apply.

I haven't actually studied cases of withdrawn award, but if it's used to deprecate the claim the award was ever given, then I think that's wrong and the reason should be reconsidered. However, there may be other claims relating to an award given in the past that will be false if, unknown to the editor making the claims, the award had been withdrawn in the interim, and then this would be a valid reason for deprecation. But this is just theoretical on my part; I'd need to see its actual use to properly evaluate it. Compare with an invalidated election.

The only reason to deprecate a claim about something that happens in a fictional universe would be that the claim disagrees with the ultimate authority on that universe, which I assume is most often its author. --SM5POR (talk) 12:07, 8 February 2023 (UTC)

@SM5POR: Thank you for the lengthy explanation.

Given what you explained, I think we'll need a review of all the instances of Wikibase reason for deprecated rank (Q27949697) for which ones fall under the "was true but is no longer" umbrella, and it looks like withdrawn award (Q24629887) should no longer be listed as an example in Help:Deprecation.

In the meantime I've added butsumetsu (Q104602651) to date of death (P570) as qualifier object has role (P3831), though I do have to note that P570 does not currently support end time (P582) as a qualifier. ミラP@Miraclepine 16:14, 8 February 2023 (UTC)

@Miraclepine: I'm not convinced the changes need to be that significant. Checking withdrawn award in particular, it's used on 15 claims, most of which I maintain should not be deprecated since the awards were withdrawn years after they were awarded. Most of them have a specified end date though, and the withdrawal could be stated as an end cause rather than a reason for deprecation. However, I suggest looking into all those awards in case there is one where deprecation is reasonable before fully rejecting it though.

Also, I'm not the one who will decide this; I'm merely stating my opinion.

In contrast to an award, which persists over time unless it's terminated, date of death is a point in time all by itself, wherefore adding an end date to it would not be appropriate. In order to handle the case of the same character eventually having multiple stated dates of death, the single best value constraint could be amended to allow if they can be told apart using one of the qualifiers as separator, and object has role could perhaps serve that purpose.

By the way, I changed instance of (P31) of butsumetsu (Q104602651) to include fictional occurrence (Q14136353) to make it a little more specific and satisfy another constraint. --SM5POR (talk) 19:02, 8 February 2023 (UTC)

@SM5POR: I understand, and I concur with your opinion, since it is supported by Help:Deprecation#Outdated statements and 'end date', so I'll look at the statements in question as soon as I can. As for the death date, I concur, in my capacity as the person who made the edits, and wanted to know how exactly to handle this outside of such edits. ミラP@Miraclepine 23:16, 8 February 2023 (UTC)

There are other situations than works of fiction that may warrant multiple dates of death. In some cases, I believe months or maybe even years have passed between a person suffering irreversible brain damage while on artificial life support and that support eventually being turned off, while in others such as date of death (P570) of Raoul Wallenberg (Q152850) a person may have been missing for years and declared dead in absentia for legal reasons (in order to interpret a will and transfer the estate; the claim I'm linking to has a nature of statement (P5102) qualifier, while I think object has role (P3831) would be a better fit), but later found to have died on an entirely different date. --SM5POR (talk) 06:31, 9 February 2023 (UTC)

Wrong property

I was surprised to find that one to me obvious subclass of (P279) statement had been deprecated as wrong property (Q110646418) in favor of represents (P1268), by a new editor (IPv6) changing statement mentioned in case the editor's reputed qualifications matter. while I have trouble understanding the new editor's reasoning here, I find myself unable to fix it in the recommended fashion (by deprecating rather than simply removing the bad statements without leaving a similarly unmotivated deprecation for other editors to hopefully "learn" from, as I would declare represents (P1268) the "wrong property, and I cannot deprecate the deprecation. Your advice would be appreciated both concerning the primary issue of when subclass of (P279) can reasonably be the wrong property and the procedural one of how to revert it in an acceptable and to the community ultimately useful manner. --SM5POR (talk) 11:05, 30 January 2024 (UTC)

I have spelledout my own reasoning comparing represents (P1268) to subclass of (P279) at [1]. In case you disagreewith it, feel free to adjust it or add your own examples. I hadsimply forgotten my own solution to the rank clarification problem. --SM5POR (talk) 11:51, 30 January 2024 (UTC)