Talk:Q71536244

From Wikidata
Jump to navigation Jump to search

Autodescription — currently valid value (Q71536244)

description: reason for preferred rank based on validity
Useful links:
Classification of the class currently valid value (Q71536244)  View with Reasonator View with SQID
For help about classification, see Wikidata:Classification.
Parent classes (classes of items which contain this one item)
Subclasses (classes which contain special kinds of items of this class)
currently valid value⟩ on wikidata tree visualisation (external tool)(depth=1)
Generic queries for classes
See also


While it is true the opposite, the most recent value (Q71533355) is not necessarily the currently valid value (Q71536244). E.g. an item could currently NOT have an official website, but indeed there are two former websites, one of which is more recent. --Horcrux (talk) 10:46, 26 April 2021 (UTC)[reply]

  • @Horcrux@Jura1, after looking at these items for a few minutes, I'm still struggling to tell them apart. There's very inadequate documentation, which I think may lead to the sort of situation where if you asked ten editors for an explanation you'd get 10 different ones. I'd suggest either defining the distinction properly in the item, or merging them, with a preference toward the latter unless there's enough of a distinction to warrant the split. {{u|Sdkb}}talk 16:56, 7 June 2023 (UTC)[reply]
    @Sdkb: While Q71536244 refers to the current value, Q71533355 refers to the most recent one among the specified ones (maybe adding this specification could be clarifying). As in the example above, it could be the case that you don't know if the most recent value among the specified ones is also the one that is currently valid. I hope this helped. --Horcrux (talk) 17:51, 7 June 2023 (UTC)[reply]
    @Horcrux, thanks. If I understand correctly, then, currently valid value (Q71536244) refers to a value that's currently true, whereas most recent value (Q71533355) refers to a value that is the most recent of the various values provided. That makes sense for a distinction in theory, but in practice, I don't think it's one we ought to be making.
    The values where this applies tend to be ones that require regular updates. In order for "currently valid" to have meaning distinct from "most recent," we'd need to also define "currently valid as of [X date]", which we don't currently do. Otherwise, users ought to expect a reasonably high chance that anything marked as "current" may have gone out of date and is actually just the most recent.
    Additionally, there's widespread misuse — from what I've seen, people tend to just use most recent value (Q71533355). That alone wouldn't be a dealbreaker, but combined with the above, I think we ought to proceed with a merge. {{u|Sdkb}}talk 18:16, 7 June 2023 (UTC)[reply]
  •  Comment @Sdkb: I was reasoning about the initial example that I provided. I suppose that, in case we know that a property has currently no value but it used to have one, one could both specify the "no value" snak (with a certain start time (P580)) and the old value for that property (with a certain end time (P582)), possibly raking the second one as preferred, specifying something like "latest non-empty value" (instead of most recent value) as Wikibase reason for preferred rank. What do you think?--Horcrux (talk) 10:44, 17 August 2023 (UTC)[reply]
    @Horcrux, if there's any hope of these values being used correctly at scale, the distinction between them needs to be simple and clearly articulated at the items themselves. If I still don't understand it very well after extensive talk page discussion, we are extremely far from a simple distinction, and certainly not a well-documented one. I fail to see a compelling reason these need to be separate items and continue to support a merge. {{u|Sdkb}}talk 13:40, 17 August 2023 (UTC)[reply]
    @Sdkb: My assumption was that currently valid value (Q71536244) and most recent value (Q71533355) are going to be merged. --Horcrux (talk) 13:52, 17 August 2023 (UTC)[reply]

Proposed merge with most recent value (Q71533355)[edit]

Following up from the discussion above, I propose of merge of currently valid value (Q71536244) with most recent value (Q71533355). To the extent that there is any distinction between these, it is insignificant/insufficiently defined to be useful as a qualifier for reason for preferred rank (P7452). Courtesy pinging @Jura1@Horcrux. {{u|Sdkb}}talk 21:03, 27 July 2023 (UTC)[reply]

  • @Sdkb: Well that was a very regrettable merge. 'most recent value' is not always the same as 'currently valid value'. In the area in which I work - listed buildings and scheduled monuments - the 'currently valid value' is very frequently a scheduled monument value which long predates a listed building value which has been deprecated in favour of the scheduled monument value. The 'currently valid value' is not the 'most recent value'. If you have any concern for accuracy, truth, and evidence-based practice, you will revert the merge. The two things are simply different concepts. --Tagishsimon (talk) 17:42, 11 March 2024 (UTC)[reply]
Evidence: https://w.wiki/9S8u ... and let me spell it out for you for the absolute avoidance of doubt. Take the example of Saltcoats Castle (Q7406057). It was given a value SM776 on 18 May 1936. It was then given a value LB1368 on 5 February 1971. So LB1368 is the most recent value. LB1368 was removed as a value on 3 July 2017, meaning that the castle has only one value, the OLDER SM776 value. There is no planet on which SM776 is the 'most recent value'. Self evidently LB1368 was the 'most recent value'. But SM776 is the 'currently valid value'. --Tagishsimon (talk) 17:56, 11 March 2024 (UTC)[reply]
As an update, I've reverted the merge to avoid 'currently valid value' data being substituted by possibly erroneous 'most recent value'. --Tagishsimon (talk) 18:47, 11 March 2024 (UTC)[reply]
In your example, the preferred rank was not because the value was the currently valid one, in the sense of newer than older values that no longer apply, but rather because all other values were obsolete. That could be alternatively expressed by assigning deprecated rank to the obsolete values and using reason for deprecated rank (P2241)obsolete (Q107356532). As I said above, every different editor seems to have a different understanding of what the distinction between "most recent" and "currently valid" is. You've just chimed in with another, which is very different from the "currently valid means we've checked to make sure it's up to date, but most recent does not" understanding some others had. If the two items are to remain separate, it is essential that we come to a consensus on what the difference between them is, and that we articulate that difference precisely at the items themselves (not just hidden on a talk page in a single editor's comment). I actioned the merge because that was not achieved above, and if it is not achieved now I will favor re-actioning it. Best, Sdkbtalk 19:04, 11 March 2024 (UTC)[reply]
@Sdkb: Oh for heaven's sake. Deprecation is for statements that were never true - see https://www.wikidata.org/wiki/Help:Ranking#Deprecated_rank "used for statements that are known to include errors (i.e. data produced by flawed measurement processes, inaccurate statements) or that represent outdated knowledge (i.e. information that was never correct, but was at some point thought to be)". It was true that the Castle was a listed building. So the correct forumlation is normal rank for the listing number and preferred rank for the scheduled number. You were wrong to conflate 'most recent value' with 'currently valid value'. You are wrong about the use of rank, just plain wrong.
If it helps, the difference between 'most recent value' and 'currently valid value' is that the first relates to the temporal sequence of values, and the second to the currency of values. Two distinct and different concepts. It is, with respect, only you who seems to be having a difficulty seeing this. --Tagishsimon (talk) 21:22, 11 March 2024 (UTC)[reply]
This particular example is salient because before the P150 statements along with rankings and precise qualifiers (currently valid value) were added, another editor created duplicate items (Dayton, OH Metropolitan Statistical Area (Q105130064) and Dayton-Kettering-Beavercreek, OH Metropolitan Statistical Area (Q105129400)), solely based on changes to P150 (currently valid value) and official name (P1448) (most recent value). Duplicates were created for other items, as well. -- DCflyer* (talk) 21:23, 11 March 2024 (UTC)[reply]