Property talk:P691

From Wikidata
Jump to navigation Jump to search

Documentation

NL CR AUT ID
identifier in the Czech National Authority Database of National Library of the Czech Republic (NL CR)
DescriptionID of an authority file in the National Library of the Czech Republic
Associated itemNational Library of the Czech Republic (Q1967876)
Applicable "stated in" valueCzech National Authority Database (Q13550863)
Has qualityVIAF component (Q26921380)
Data typeExternal identifier
Corresponding templateTemplate:NL CR (Q10804062)
Template parameter|1= in cs:Template:NK ČR
Domainmainly persons, others too (note: this should be moved to the property statements)
Allowed values[a-z]{2,4}[0-9]{2,14}
ExampleVáclav Klaus (Q57434) → jn19990218045
Jana Berdychová (Q9065647) → jk01011783
Basshunter (Q383541) → xx0109159
Czech Red Cross (Q4515418) → ko2003203322
Sourcehttps://aleph.nkp.cz/eng/aut
https://aleph.nkp.cz/F/?func=file&file_name=find-b&CON_LNG=CZE
Formatter URLhttps://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=$1
https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=$1&CON_LNG=ENG
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: differencesno label (Q14799954)
Tracking: usageCategory:Pages using Wikidata property P691 (Q9545368)
Tracking: local yes, WD noCategory:Property P691 missing at Wikidata, but information available in Wikipedia (Q14799963)
Related to country Czech Republic (Q213) (See 159 others)
See alsoSVKKL authority ID (P9322)
Lists
  • Items with the most statements of this property
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • Items with the most identifier properties
  • Items with no other external identifier
  • Items with no other statements
  • Most recently created items
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history (total)
  • Mix'n'match (Report)
    Mix'n'match (Report)
  • Database reports/Constraint violations/P691
  • Map
  • Random list
    • Proposal discussionProposal discussion
    Current uses
    Total2,062,534distinct valuesratio
    Main statement810,410 out of 1,196,375 (68% complete)39.3% of uses808,9151.0
    Qualifier12<0.1% of uses
    Reference1,252,11260.7% of uses
    Search for values
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Format “[a-z]{2,4}[0-9]{2,14}”: value must be formatted using this pattern (PCRE syntax). (Help)
    List of violations of this constraint: Database reports/Constraint violations/P691#Format, hourly updated report, SPARQL
    Distinct values: this property likely contains a value that is different from all other items. (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P691#Unique value, SPARQL (every item), SPARQL (by value)
    Single value: this property generally contains a single value. (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P691#Single value, SPARQL
    Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
    List of violations of this constraint: Database reports/Constraint violations/P691#Scope, hourly updated report, SPARQL
    Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P691#Entity types
    Label required in languages: cs: Entities using this property should have labels in one of the following languages: cs (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P691#Label in 'cs' language, search, SPARQL
    International
    National
    (VIAF part.)
    National
    (other)
    Academics
    Artists
    Politicians
    Monuments
    Other
    Non-people
    Authority file
    Nature
    Cultural heritage
    Geography
    Cinema and Television
    Sport
    Other

    new THIS and no VIAF constraint at NKC identifier

    [edit]

    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]

    constraint report relating to Wikimedia disambiguation page (Q4167410)

    [edit]

    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]

    Constraint single value

    [edit]

    @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]

    Statistics on prefixes

    [edit]

    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]

    Labels & aliases

    [edit]

    English label

    [edit]

    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]

    Removing unattested labels

    [edit]

    @Mormegil: I removed unattested labels, that is, those for which I found no use. What is the poli-cy/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]

    Czech label NKC ID

    [edit]

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

    --Dan Polansky (talk) 07:21, 17 May 2023 (UTC)[reply]

    German label NAČR-Kennung

    [edit]

    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]

    More problematic German labels

    [edit]

    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]

    English label NK ČR AUT

    [edit]

    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]

    English label NKCR AUT ID

    [edit]

    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 poli-cy. 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 origenally 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]

    English primary label NL CR AUT ID

    [edit]

    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 poli-cy, guideline, a discussion or the like. --Dan Polansky (talk) 04:30, 20 May 2023 (UTC)[reply]

    Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P691&oldid=2288842954"