Property talk:P691

Hi I found the page about НКВД at NKVD (Q182449) . Until today the value kn20010711414 for NL CR AUT ID (P691) was available but no VIAF identifier was present.
Please add a constraint violation report for all pages where P691 is present but VIAF ID (P214) is not.
It should be possible to find the correlated VIAF id via [1]. This search returns more results. You need to identify the correct one. Here the right one is viaf:138853936.
Please add links of the followimg format to the report:

'https://viaf.org/viaf/search?query=cql.any+all+%22'+$1+'%22+and+local.sources+any+%22nkc%22&sortKeys=holdingscount'

Thanks in advance! לערי ריינהארט (talk) 02:49, 6 November 2013 (UTC)Reply

If instance of (P31) is a Wikimedia disambiguation page (Q4167410) the presence of NL CR AUT ID (P691) is prohibited

see: Wikimedia disambiguation page (Q4167410) with NKC identifier (P691) . Usualy there might be two possibilities:

a) please identify the non - ambiguation page (WD item) where the property NKC identifier should be moved;
"normally" no other statements should be left at the disambiguation page;
it can happen that a set of properties should be moved to another (a second) WD item, another set to a third WD item etc.

b) verify which language is a disambiguation page and separate it from the rest; please use Gadget-labelLister.js ^{can be activated at preferences#gadgets} to remove all faulty descriptions after the disambiguation page is separated (the languages are de, en, fr, es, pt, pt-br, ru, sv and possibly some others).

Thanks in advance! gangLeri לערי ריינהארט (talk) 17:40, 22 May 2014 (UTC)Reply

There is problem b), one of linked pages is disambiguation. Both (cswiki) articles, where is NL CR AUT ID (P691) are correct. JAn Dudík (talk) 21:26, 22 May 2014 (UTC)Reply

@JAn_Dudík I will look at it tomorrow. לערי ריינהארט (talk) 21:33, 22 May 2014 (UTC)Reply

@Jklamo, Mormegil: Would it make sense to replace current constraint single-value constraint (Q19474404) by single-best-value constraint (Q52060874)? The reason is that single-value constraint (Q19474404) leads to recognition of deprecated values, such as those in Johann Nepomuk Huber (Q75037), as constraint violations... Vojtěch Dostál (talk) 14:03, 1 January 2020 (UTC)Reply

Sure, that makes sense.--Jklamo (talk) 20:45, 1 January 2020 (UTC)Reply

OK, will do, I just hope that Krbot will be able to understand this new constraint and report mistakes accordingly.Vojtěch Dostál (talk) 13:47, 2 January 2020 (UTC)Reply

Unfortunately, it seems that this type of constraint would require "best ranks" for one of the values, which is not what we want to do. We want to keep all values as "normal rank" except for the deprecated ones. Not sure what to do. Vojtěch Dostál (talk) 13:51, 2 January 2020 (UTC)Reply

I do not understand. Johann Nepomuk Huber (Q75037) seems to be completely wrong (as is probably VIAF). What does that Johann Nepomuk Huber (Q75037)NL CR AUT ID (P691)jo2013797195reason for deprecated rank (P2241)duplicate entry (Q1263068) even mean? Especially that “reason for deprecated rank (P2241)duplicate entry (Q1263068)” seems to be very strange – I don’t think we should choose and deprecate any identifier, that is the job for NKČR; only after they find out they have a duplicate identifier (e.g. thanks to us telling them) and fix that in their database, we should follow suit. Other than that, I see nothing systematically wrong at the item which could be detected by a constraint specification. So, in other words: what are you trying to achieve (maybe more examples)? --Mormegil (talk) 09:39, 3 January 2020 (UTC)Reply

@Mormegil: Yeah, let's put this specific case aside (I know that it's up to NKČR to decide which one of them is a duplicity. However, this is the simplest way to tag the item so that NKČR sees it in the monitoring Wikidata queries and fixes it. We can definitely think of other, more logical ways of tagging duplicate entries). There are other reasons why P691 value might be deprecated (https://w.wiki/CQh). Take the case of Samuel Johnson (Q183266) for example - one that also shows up in Wikidata:Database reports/Constraint violations/P691. I am trying to find a way to fix the property's constraints so that Krbot2's reporting works well for these kinds of items (which it doesn't right now). Or can you think of other solutions? Vojtěch Dostál (talk) 10:02, 3 January 2020 (UTC)Reply

Query with statistics on the utilisation in Wikidata of the prefixes (https://autority.nkp.cz/kooperace/identifikacni-cislo-autority/): https://w.wiki/5ooa. --Epìdosis 13:46, 12 October 2022 (UTC)Reply

I changed the label to this:

• NLCR AUT ID

It is not in use. At least, "NLCR" is in use to refer to the national library and "AUT" is in use to refer to the authority control database. Thus, "NLCR AUT" naturally and less ambiguously refers to the same thing as "AUT", and "NLCR AUT ID" naturally refers to the identifier. --Dan Polansky (talk) 15:39, 16 May 2023 (UTC)Reply

@Mormegil: I removed unattested labels, that is, those for which I found no use. What is the policy/guideline for "Also known as", is it Help:Label? If so, only commonly used labels should be used. And my intuitive understanding is that presenting actually unused alternative labels causes tangible harm. --Dan Polansky (talk) 07:11, 17 May 2023 (UTC)Reply

This is positively misleading since AUT and NKC are two different databases of the national library. I am therefore removing this label. Evidence:

• https://aleph.nkp.cz/F/?func=file&file_name=find-b&local_base=nkc -- "Aktuální báze: NKC"
• https://aleph.nkp.cz/F/?func=direct&local_base=AUT&doc_number=000115000 -- "Aktuální báze: AUT"

--Dan Polansky (talk) 07:21, 17 May 2023 (UTC)Reply

I do not see how "NAČR" refers to the library as opposed to national archive. Why would this label make sense? What evidence supports that label? --Dan Polansky (talk) 07:23, 17 May 2023 (UTC)Reply

The following labels are ambiguous and therefore misleading:

• NK ČR ID
• NKČR-Kennung

It is because AUT is not the only database of NK ČR; also NKC is a database and there are other databases. I do not see what value is brought to the users by these misleading labels. --Dan Polansky (talk) 07:26, 17 May 2023 (UTC)Reply

In that label, "NK ČR" is implied to refer to the Czech national library. However, "NK ČR" does not seem to be attested in use in English running text to refer to the library, which is to be expected given "Č"; it could be "NK CR", but even that does not seem to be attested, or is it? Therefore, I do not see what makes it an acceptable English label; it could be fine as a Czech label. I also do not see what user or use case is helped by having this as an English label.

The label control for the library is here: National Library of the Czech Republic (Q1967876). Evidence for use of candidate labels is collected on its talk page. --Dan Polansky (talk) 04:55, 18 May 2023 (UTC)Reply

I cannot find attesting quotations for "NKCR" in English running text referring to the national library. The applicable guideline-like artifact: Help:Aliases, "The label on a Wikidata entry is the most common name that the entity would be known by to readers. All of the other common names that an entry might go by, including alternative names; acronyms and abbreviations; and alternative translations and transliterations, should be recorded as aliases."; however, that text is marked in a red box. In any case, English labels should usually be attested, in my view, especially since English is a well documented language online, and I do not see any overriding concern that would grant "NKCR" an exception. --Dan Polansky (talk) 13:01, 19 May 2023 (UTC)Reply

This is not a dictionary. And this is not even the main namespace. This is a tool. All labels/aliases are “attested” by having been used for 7–10 years here. --Mormegil (talk) 09:23, 19 June 2023 (UTC)Reply

Why exactly should Help:Aliases be violated? (Maybe there is an override rationale; I have not found it.) What does the utility of non-used aliases consist in; that is, why cannot the users depend on labels actually in use?

No, labels are not "attested" by having been in Wikidata; attestation is a process pointing outside of Wikidata. --Dan Polansky (talk) 16:19, 26 August 2023 (UTC)Reply

You are mistaken. Read again my explanation above or feel free to ask for further explanation for what you did not understand. And I see nothing in Help:Aliases which would prohibit the mentioned aliases, even if the help page applied to properties which it does not as is explicitly stated there. --Mormegil (talk) 18:59, 26 August 2023 (UTC)Reply

I am mistaken about what?

From Help:Aliases: "The label on a Wikidata entry is the most common name that the entity would be known by to readers. All of the other common names that an entry might go by, including alternative names; acronyms and abbreviations; and alternative translations and transliterations, should be recorded as aliases." Boldface mine.

Let me try something else: why should an English label use "NKCR" as part of the label when that string is not used in English text? Why would anyone use that string, inappropriate for English, to pick the property in English? Are you actually typing "NKCR" and thus, am I incoveniencing you by removing that label? Is then the problem that you do not want to learn to type "NLCR" to match "NLCR AUT ID"? --Dan Polansky (talk) 19:04, 26 August 2023 (UTC)Reply

Once again, from Help:Aliases: “this page describes the use of aliases for items, not properties”. And even if it did apply to properties, the sentence you quoted is an implication, meaning if a name is common, then it should be recorded as an alias. Not that if a name is not common (whatever that might mean), it should not be an alias. For that, there is a specific section below, “You should not include”. Let me try something else: What problem are you trying to solve? --Mormegil (talk) 14:29, 28 August 2023 (UTC)Reply

I'll register that you did not answer my questions. The one question I am most puzzled about is why is typing "NLCR" so much worse than "NKCR", other than that one has to change one's habits from poor ones to good ones.

As for the force of Help:Aliases, it is perhaps not all that great; it is not even a formal policy. And you are right that the sentence about "common" can be read is rather non-binding.

What problem I am trying to solve: I am systematically trying to get rid of poor labels (unattested labels, labels with unattested parts, misleading labels, etc.), no matter where they are (properties, Q-items, etc.). In part, Wikidata is a conceptual dictionary, where each concept carries multiple labels, one called "label", the other ones called "aliases". From that perspective, unattested originally invented labels are suboptimal, to say the least. Such labels are justified if they serve a function that cannot be served otherwise. In case of "NKCR AUT ID", it serves no function that cannot be served by label "NLCR AUT ID", and therefore, I do not see what justifies "NKCR AUT ID".

Labels should not be a result of careless brainstorming; the history of P691 suggests that this is what too many of them were, some positively misleading. --Dan Polansky (talk) 10:11, 29 August 2023 (UTC)Reply

By all means change the label to the most well-used variant, but please do not remove any aliases which other editors might find useful — Martin (MSGJ · talk) 09:04, 9 October 2023 (UTC)Reply

Why should a mere hypothetical usefulness ("might") trump the fact that the label contradicts common usage patterns or is deficient in other ways, e.g. is misleading? As a supporting question, why should editors not learn to use well designed labels instead of deficient labels, provided the learning effort is manageable (type "NLCR" instead of "NKCR", which makes no sense in English)?

Is there another similar discussion where editors have argued and decided a similar case, one that I do not know of?

What are the arguments supporting the above statement? --Dan Polansky (talk) 08:33, 10 October 2023 (UTC)Reply

It's not supposed to be an official label or meet any kind of standard that you think should apply. It's an alias, designed to help editors find the property they are looking for. There is no limit to the number of aliases that we can have and if it potentially helps an editor then it should probably be kept. There is no need to "curate" the aliases. — Martin (MSGJ · talk) 08:44, 10 October 2023 (UTC)Reply

This does not answer most of the questions I asked. It seems to suggest that there should be no culture of good aliases for properties; allegedly, it should meet no standard at all as per above, which I find far from ideal and hard to believe. If the Wikidata project made that decision, fine; I hope to be eventually able to read some reasoning or sound debate at a location where this was decided. --Dan Polansky (talk) 09:09, 10 October 2023 (UTC)Reply

@ JAn Dudík: would you like to join the discussion rather than reverting further? This is becoming disruptive so I have protected the property for a while until this is resolved. — Martin (MSGJ · talk) 07:13, 11 October 2023 (UTC)Reply

But what do you want to resolve and discuss? It seems everyone except Dan Polansky agrees that there is no reason to remove aliases which were in use here for many years. But still Dan Polansky repeatedly removes them and insists we answer his long questions if we want to restore them (and even if we reply to his questions, he claims the answers are wrong/irrelevant/whatever and demands further discussion). --Mormegil (talk) 07:53, 13 October 2023 (UTC)Reply

I set the English primary label (or just "label") to "NL CR AUT ID", away from "NLCR AUT ID". Since, "NL CR" is well attested whereas "NLCR" only poorly so, per wikt:cs:NL CR and wikt:cs:NLCR. I am not sure whether there is an overriding policy, guideline, a discussion or the like. --Dan Polansky (talk) 04:30, 20 May 2023 (UTC)Reply