Wikidata:Property proposal/Deprecation date

Deprecation date edit

Originally proposed at Wikidata:Property proposal/Generic

Not done

Description	when the statement ceased to be considered true
Data type	Point in time
Domain	qualifier for any deprecated statement (or source ?)
Example	deprecated : ⟨ Savara (Q33771)    ⟩ instance of (P31) ⟨ language ⟩ deprecation cause Search ⟨ https://www.wikidata.org/wiki/Q29485 ⟩ deprecation date Search ⟨ 2015 ⟩
See also	statement disputed by (P1310) https://www.wikidata.org/wiki/Property:P2241 Search

Motivation

«end time» may be used by the claim and it does not seem right to add an « instance of » for something like spurious language (Q5015649)   who adds visibility to a known mistake. author TomT0m / talk page 09:16, 19 July 2017 (UTC)[reply]

Discussion

I don't see how instance of (P31) spurious language (Q5015649) is wrong. It describes exactly what it is. In general, I would support being able to add deprecated dates because deprecation (in the normal use of the term, not the specific meaning of Wikidata's deprecated rank) does not mean the same as end time (P582) (for example, IETF language tags can be deprecated which means that they discourage you from using them, but they are still valid - a meaning more consistent with en:Deprecation). However, I don't agree with your planned usage. For something like this, I would expect instance of (P31) language (Q34770) with no qualifiers but instead a reference containing reference URL (P854) http://www-01.sil.org/iso639-3/chg_detail.asp?id=2015-010 reason for deprecated rank (P2241) withdrawn identifier value (Q21441764) ISO 639-3 code (P220) svr. Then on the item's ISO 639-3 code (P220) statement, a end time (P582) qualifier (since the identifier has been withdrawn as of that date) and a reference which also contains reference URL (P854) http://www-01.sil.org/iso639-3/chg_detail.asp?id=2015-010. No deprecated date is needed. (Regarding using reason for deprecated rank (P2241) as part of a reference instead of a qualifier, please see Wikidata:Project_chat#We_need_to_improve_the_use_of_the_.22deprecated.22_rank and the linked argument at [1]). - Nikki (talk) 10:45, 19 July 2017 (UTC)[reply]

@Nikki: I added « (or source ?) » in the domain because of Markus’ point in the mail (although I missed or forgot the mail). So OK to add this to a reference only. But this proposal refers to the deprecation in Wikidata data model specifically. « spurious languages » can be, according to enwiki’s article, languages that never existed in the first place.

I don’t think that https://www.wikidata.org/wiki/Q21441764 is when people realised the author made a mistake and named and mentioned the language was wrong, this is just a consequence. This is probably acknowledged in a scientific paper. This property is supposed to reflect the period linguists realized they made a mistake, not the time in which the code was deleted. Note that this is just the example that motivated the proposal, but the pattern is way more general. When did scientists stopped believing the earth was the center of the universe ?

Not having a P31 for this kind of (non)entities would avoid them showing up in queries that requires a P31. I think if you want them you should explicitly query for deprecated one.

PS : sorry, I should have explained all this from the beginning. author TomT0m / talk page 14:24, 19 July 2017 (UTC)[reply]

If we are deprecating it based on a paper rather than the fact the language code was withdrawn, then our reference supporting the deprecation would be the paper and the paper would have publication date (P577). There wasn't a single point when scientists stopped believing the earth is the centre of the universe and there aren't single points when linguists stop believing that something is a language, so I don't think a "deprecation date" makes sense in those situations. For example, the rationale given in [2] for withdrawing the code svr mentions three different sources (ca. 1987, 2009 and 2015) which disputed the existence of the language.

What seems to be missing (to me) is a way to describe which parts of the statement a given reference supports, so that we can explicitly say "this reference supports the creation of this statement" and "this reference supports the deprecation this statement" and then we would know which sources claim the statement is true, which claim it is false, and their corresponding dates. Something like that would also be useful when a reference only supports the value and not the qualifiers or vice versa (a problem I've been having recently...) - Nikki (talk) 18:09, 19 July 2017 (UTC)[reply]

@Nikki: Not really important as verifiability implies … verification imho. Hence the reader has to actually check the references to understand the story. The reference date may not be enough and might not be a primary one. Think of a nowadays history of science book or an historiographic book that says « scientific community was convinced by heliocentric arguments around the 16th century». This source the deprecation date, and it’s definitely not the publication date. And Wikidata data model can express fuzzy dates, so no real problem with multiple dates. author TomT0m / talk page 07:24, 20 July 2017 (UTC)[reply]

OK, I finally (sorta) understand what you're trying to capture... but I'm still not convinced that a single "deprecation date" is a good way to try to model it, because (as I said) it's not a single point in time. Even a single source can mention different dates for different people and different regions, so it seems like this property as proposed would not actually enable us to capture the details which describe the evolution of knowledge over time.

If you think it will work, prove it. :) Find some real examples, describe the reference, quote what it says and explain how we would enter it in Wikidata. At the moment, the only example does not show any need for this property since the suggested date can be represented by the publication date of the paper and the end date of the identifier. It's also not clear to me why we should consider 2015 the right "deprecation date", since it's clear that people had not believed it many years before that point.

If this is going to be added, it really needs a different name. People will almost certainly use a property called "deprecation date" for other things, e.g. the sort of deprecation dates I mentioned above and for the date we marked a statement as deprecated (unnecessary, yes, but that never stopped anyone). - Nikki (talk) 09:58, 20 July 2017 (UTC)[reply]

@Nikki: No name can prevent mistakes. Only explanations. People are so confused around this « end » notion. I come here after a discussion with someone on fr pc that seem to believe the language « existed » before the removal of the code. This is complicated and no name can be a solution. After all I’m not opposed to use this property for the notion of API and programming as the context is entirely different - source versus qualifier or main snak.

> « to me why we should consider 2015 the right "deprecation date" » It’s a POV, and Wikidata has a way to represent different povs. No real problems. It also has a way to deal with not so clear date with precision … the problems you raises are not really different for any kind of dates. We’ll just deal with this the same way we deal with other one.

Anyway, I think we have many usecases to discuss : https://en.wikipedia.org/wiki/Paradigm_shift#Examples_of_paradigm_shifts author TomT0m / talk page 12:16, 20 July 2017 (UTC)[reply]

If someone thinks that a language exists until its code is deleted, then they don't understand language codes. I don't think there are any changes we could make to our data (that would be correct) that would fix that.

We don't represent the point of view of the person editing Wikidata, we represent the point of view of a source. If you claim that 2015 is the "deprecation date", you should be able to point to a source which says that (and it should state it clearly enough that other people would interpret it as saying the same thing, otherwise it's not a convincing source). You haven't said which source claims 2015 is the right date to enter and I would not interpret anything I've seen as saying that 2015 is when people stopped believing it (as I said, the sources I've seen give dates before then).

No name/description will ever be perfect, but the name you're proposing is ambiguous (as I pointed out, there are at least two other things which could be called a "deprecated date" and both would be more obvious meanings to me than yours) and the intended usage is unclear (you had to try more than once to explain it to me above). That makes it very likely that it will be misused. Even my first instinct was to use it for something you say it should not be used for. I'm only one person, but if I had trouble understanding the purpose of it and want to use it for something it's not intended for, I would expect some other people to do the same.

For now I'm voting

Oppose. While I can see that there are some things where it might be useful, I don't think this is a well-thought through proposal and therefore shouldn't be added as currently proposed. I explained above that I don't think that what you are proposing will work well and asked you show that it will, but you haven't. I'm also starting to repeat myself and that's not a productive use of my time. If you make some changes to the proposal, I will look at them and consider changing my vote, but if you don't agree that my concerns are valid, then there is no point in me replying any more. Also, I apologise for writing so much... I'm not good at short replies :( - Nikki (talk) 13:35, 20 July 2017 (UTC)[reply]

Sorry to hear that. I felt I tried to answer to some of your concerns but I don’t really feel read or understood on this :( If you have ideas on this, now you say you understand the need or what I want to do, please share. I may have not the perfect proposal, but there is few perfect proposals around here. author TomT0m / talk page 14:34, 20 July 2017 (UTC)[reply]

~~Support~~ deprecation reason could be paired with "deprecation date"

It could be for other items, not relevant to language codes at all.

E.g. Timezone or standard or currency could be deprecated at specific point in time. d1g (talk) 20:33, 30 July 2017 (UTC)[reply]

@D1gggg: That is not what this property should be used for, see the discussion above. If you agree with me that it will almost certainly be misused if it's added as currently proposed, because the intended usage is too unclear, then I would recommend changing your vote. - Nikki (talk) 12:11, 26 August 2017 (UTC)[reply]

@Nikki: maybe several examples would help? d1g (talk) 18:26, 26 August 2017 (UTC)[reply]

~~Support~~ but please change the sample.
--- Jura 18:42, 14 August 2017 (UTC)[reply]
- Oppose changed my vote. Sample should really be fixed first.
  --- Jura 12:18, 26 August 2017 (UTC)[reply]
Support ChristianKl (talk) 09:53, 23 August 2017 (UTC)[reply]

Not done Lack of support.--Micru (talk) 14:53, 15 September 2017 (UTC)[reply]