Property talk:P227

From Wikidata
Jump to navigation Jump to search

Documentation

GND ID
identifier from an international authority file of names, subjects, and organizations (please don't use type n = name, disambiguation) - Deutsche Nationalbibliothek
RepresentsGND ID (Q54506313)
Associated itemGerman National Library (Q27302)
Applicable "stated in" valueIntegrated Authority File (Q36578)
Has qualityVIAF component (Q26921380)
Data typeExternal identifier
Template parameteren:Template:Authority control: |GND=Template:Authority control (Q3907614)
Allowed values1[0123]?\d{7}[0-9X]|[47]\d{6}-\d|[1-9]\d{0,7}-[0-9X]|3\d{7}[0-9X]
ExampleUniverse (Q1)4079154-3 (RDF)
Voltaire (Q9068)118627813 (RDF)
Jehan Sadat (Q212190)118604740 (RDF)
Dakar (Q3718)4010921-5 (RDF)
Slovenian Red Cross (Q12800001)1231643-X (RDF)
Atelier de Création Radiophonique (Q754069) → not applicable
Tomb of the Scipios (Q1540716)7505698-7 (RDF)
pianist (Q486748)4131406-2 (RDF)
pianist (Q486748)4426550-5 (RDF)
Sourcehttps://portal.dnb.de
Formatter URLhttps://d-nb.info/gnd/$1
https://d-nb.info/gnd/$1/about/lds
http://d-nb.info/gnd/$1/about/marcxml
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: differencesCategory:GND different on Wikidata (Q55746867)
Tracking: usageCategory:Pages with GND identifiers (Q8709075)
Tracking: local yes, WD noCategory:GND not on Wikidata (Q56825653)
Related to country Germany (Q183) (See 347 others)
See alsoDeutsche Biographie (GND) ID (P7902), Sächsische Biografie (GND) ID (P1710), FID performing arts ID (P10608), CERL Thesaurus ID (P1871), DNB edition ID (P1292)
Lists
  • Property talk:P227/Conflation
  • Property talk:P227/Constraint violations/Single best value constraint
  • Property talk:P227/Constraint violations/Single best value constraint (humans died before 1851)
  • Property talk:P227/Duplicates
  • Property talk:P227/incorrect identifier value
  • Property talk:P227/human/wanted
  • 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/Complex constraint violations/P227
  • Database reports/Constraint violations/P227
  • Map
  • Random list
  • Proposal discussionProposal discussion
    Current uses
    Total2,782,641
    Main statement1,828,223 out of 9,499,173 (19% complete)65.7% of uses
    Qualifier10<0.1% of uses
    Reference954,40834.3% of uses
    Search for values
    Explanations [Edit]

    The Integrated Authority File (Q36578) (GND) is managed by the German National Library in cooperation with various library networks in German-speaking Europe and other partners.

    Allowed qualifiers

    List of qualifiers
    Wikidata qualifier (Q15720608) entity (Q35120) Example
    subject named as (P1810) person (Q215627) Naguib Mahfouz (Q7176): Maḥfūẓ, Naǧīb
    subject named as (P1810) geographical feature (Q618123) Universe (Q1): Weltall / Kosmos <Begriff>
    alternative name (P4970) person (Q215627) Édith Piaf (Q1631): Gassion, Edith G.
    start time (P580) geographical feature (Q618123) Dnipro (Q48256):
    subject named as (P1810): Jekaterinoslaw (1776)
    end time (P582) corporate body (Q106668099) Leipzig University (Q154804):
    subject named as (P1810): Karl-Marx-Universität Leipzig (1991)
    point in time (P585) event (Q1656682) Chaos Communication Congress (Q516804): 2005
    object has role (P3831) person (Q215627) Mark Twain (Q7245): subject named as (P1810): Twain, Mark
    + object has role (P3831): pseudonym (P742)
    object has role (P3831) corporate body (Q106668099);
    more precise: museum (Q33506)
    Panorama Mesdag (Q1738414): museum in the Hague
    object has role (P3831) work (Q386724) Q110996824: no description
    object has role (P3831) geographical feature (Q618123) Tomb of the Scipios (Q1540716): subject named as (P1810): Rom / Scipionen-Grab
    + object has role (P3831): cross-reference (Q1302249)
    object has role (P3831) term (Q1969448) / topical term (Q115439461) book publisher (Q1320047): subject named as (P1810): Verlag
    + object has role (P3831): quasi-synonym (Q2122467)
    applies to part (P518) geographical feature (Q618123)
    corporate body (Q106668099)
    Peace Palace (Q834448): architectural structure
    Peace Palace (Q834448): organization
    location (P276) corporate body (Q106668099) Academic Press (Q2076913): New York / San Diego
    sex or gender (P21) term (Q1969448) / topical term (Q115439461) pianist (Q486748): male or of unspecified gender / female
    scope note (P9570) work (Q386724) Xenien (Q523255): Goethe / Schiller
    scope note (P9570) Ukrainian literature (Q1276062) Benutze Kombination: Ukrainisch AND Literatur
    + object has role (P3831): cross-reference (Q1302249)
    scope note (P9570) creator of the GND
    (for help with indentification)
    Karl-Heinz Schulze (Q113454903): Datensatz angelegt von
    DFF - Deutsches Filminstitut & Filmmuseum / filmportal.de [DE-Wi17FP]
    identifier shared with (P4070) term (Q1969448) / topical term (Q115439461) Orient (Q205653)Q1947733
    reason for deprecated rank (P2241) refers to different subject (Q28091153)
    unconfirmed (Q28831311)
    redirect (Q45403344)
    reason for deprecated rank (P2241) (rare case where GND was accidentally reused) Alfred Daiber (Q114087670): replacement (Q23009439)Alfred Daiber (Q15782350)
    reason for deprecated rank (P2241) (should be replace with valid GND) undifferentiated identifier value (Q68648103)
    intended subject of deprecated statement (P8327) In addition to refers to different subject (Q28091153)

    See: property constraint (P2302) = P227#P2302 (P227#P2302)


    Sources and abbreviations


    Gadget

    • To import data from the authority file you can use the gadget GND reveal. You only have to add
    importScript( 'User:Magnus Manske/gnd reveal.js' )
    to your page User:…/common.js.


    Notes


    Known VIAF/GND problems

    VIAF is helpful but also often incorrect, outdated, and is mixing two identifier systems that in some cases produce dead links.

    1. Johannes Fabian (Q15641418), VIAF 91414487 merged in January 2014 three GNDs, only one was correct:
      1. GND 107342049: Fabian, Johannes R., undifferentiated
      2. GND 122878310: Fabian, Johannes (* 1937), Amerikan. Anthropologe
      3. GND 172084180: Fabian, Johannes R., Dipl.-Ing.
        • Update: now both Wikidata and VIAF have only one GND
    2. VIAF changes numbers with dashes: Instituto Brasileiro de Geografia e Estatística (Q268072).
      1. GND 1026669-0 (correct)
      2. VIAF-GND 004164695 ("404 Not Found")
    3. Same name + same year of birth = different person
      1. In some cases VIAF merges two persons because only one of them has a GND
      2. Please use: GND = "no value" (for the person without a GND) [1]
      3. For items often confused use: different from (P1889)
    4. For unknown reasons VIAF is not importing all GND ids
      1. Samuel Ramos (Q7412445) = GND 1022446479 (created 16-05-12)
      2. June 2015: 3 years later the GND id still not harvested by VIAF
        • DNB and VIAF have been made aware of the problem, there might have been a harvesting glitch during the first weeks of the GND going live in April 2012: GND records which never have been touched since then are still unknown to VIAF (as an estimate about 15.000 GND records for persons created in early summer 2012 are not represented in VIAF). [7. Jun. 2015‎ Gymel]
        • Update: GND 1022446479 added to VIAF:59099151 on 2015-07-12.
    5. In some cases VIAF clusters get deleted instead of merged
      1. Åke Blomström (Q270863): VIAF 228866914; taken care by KrBot
    6. In rare cases VIAF clusters are reused for a different item
      1. William of Ockham (Q43936): VIAF:41835567 in 2015
        1. Lorenzo Guglielmo Traversagni (Q18674108): VIAF:41835567 in 2016
        2. William of Ockham (Q43936): VIAF:262145669298005170004 (created 2016-02-28)
      2. Drew Fudenberg (Q1258707): till 2016-09-25 VIAF:59183378 (now: "First National Bank of Lynn")
    7. In the case a conflated VIAF cluster was used for creating an item, see Help:Conflation of two people (Wikidata:VIAF/cluster)
    Format “(1[0123]?\d{7}[0-9X]|[47]\d{6}-\d|[1-9]\d{0,7}-[0-9X]|3\d{7}[0-9X]): value must be formatted using this pattern (PCRE syntax). (Help)
    List of violations of this constraint: Database reports/Constraint violations/P227#Format, hourly updated report, SPARQL
    Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410), Wikimedia list article (Q13406463): this property must not be used with the listed properties and values. (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Kingdom of Granada (Q1495642)
    List of violations of this constraint: Database reports/Constraint violations/P227#Conflicts with P31, SPARQL
    Single best value: this property generally contains a single value. If there are several, one would have preferred rank (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/P227#single best value, 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). Known exceptions: Q196538, Q912313, Q19786, Q83367, Q302, Q51666, Q695368, Q206587, Q1301203, Q35672, Q1779748, Q15407350, Q15407351, Q20852, Q2293670, Q84, Q23306, Q520867, Q1110145, Q1787342, Q1803227, Q695, Q1588974, Q164256, Q1111292, Q6257, Q1662807, Q1502013, Q2515177, Q414110, Q514802, Q1780615, Q1780476, Q630163, Q1454729, Q152002, Q955464, Q439072, Q841090, Q1360467, Q695316, Q1454727, Q683834, Q864640, Q772835, Q853085, Q116, Q1097498, Q58968, Q381142, Q6256, Q7275, Q179043, Q214518, Q1232145, Q1803430, Q315027, Q1571264, Q329676, Q7380391, Q1803272, Q1787368, Q1305171, Q5261695, Q14756366, Q34497, Q192184, Q151843, Q301751, Q675085, Q1454726, Q17955, Q3059502, Q44352, Q155570, Q1460, Q4951156, Q15608499, Q2456068, Q40, Q533534, Q21010, Q15058181, Q1148511, Q170213, Q7473516, Q1490, Q67996, Q3905364, Q865, Q22502, Q707297, Q17353989, Q637238, Q690821, Q13362, Q693570, Q19831595, Q1206262, Q170390, Q697084, Q5923, Q1803420, Q2839, Q16332967, Q20883, Q20892, Q1396026, Q1787565, Q13344, Q157575, Q20808141, Q429850, Q19311569, Q277759, Q1700470, Q742421, Q2088357, Q41662, Q8867089, Q11634, Q350268, Q321087, Q13165156, Q6877935, Q104602244, Q163446, Q6087062, Q107434788, Q1783171, Q7777494, Q1147752, Q2994505, Q110551885, Q7377, Q111396014, Q159462, Q192874, Q178, Q877546, Q123168143
    List of violations of this constraint: Database reports/Constraint violations/P227#Unique value, SPARQL (every item), SPARQL (by value)
    Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (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/P227#Scope, SPARQL
    Conflicts with “instance of (P31): Wikimedia category (Q4167836): this property must not be used with the listed properties and values. (Help)
    List of violations of this constraint: Database reports/Constraint violations/P227#Conflicts with P31, hourly updated report, search, 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/P227#Entity types
    Label required in languages: de: Entities using this property should have labels in one of the following languages: de (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/P227#Label in 'de' language, search, SPARQL
    Error reports
    Contact:

    For Persons, see de:Wikipedia:GND/Fehlermeldung. Hints for other types at User:Jneubert/GND_errors

    Ideally this information should be moved to the item for the reference and be transcluded from there.
    Reports:
    Error type Item(s) affected Description/Duplicates Exception Reported Resolved (also unpublished) Resolved and published Wikidata updated
    This property is being used by:

    Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


    GND ID - type human should not have GND ID containing -
    GND ID exists, type is human, GND ID contains - (Help)
    Violations query: SELECT ?item ?gndid WHERE { ?item wdt:P227 ?gndid; wdt:P31 wd:Q5. FILTER(REGEX(STR(?gndid), "-")) . }
    List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should not have GND ID containing -
    GND ID - type human should have sex
    GND ID exists, type is human, sex missing (Help)
    Violations query: SELECT ?item ?gndid WHERE { ?item wdtn:P227 ?gndid; wdt:P31 wd:Q5 . MINUS { ?item wdt:P21 [] } } LIMIT 1000
    List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should have sex
    GND ID - type human should have VIAF
    GND ID exists, type is human, VIAF missing (Help)
    Violations query: SELECT ?item ?gndid WHERE { ?item wdtn:P227 ?gndid; wdt:P31 wd:Q5 . MINUS { ?item wdt:P214 [] } } LIMIT 1000
    List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should have VIAF
    GND ID - type human should not be instance of a subclass of human
    GND ID exists, type is human, is instance of a subclass of human (Help)
    Violations query: SELECT ?item ?gndid WHERE { ?item wdt:P31/wdt:P279+ wd:Q5 . ?item wdt:P31 ?type . ?item wdtn:P227 ?gndid . }
    List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should not be instance of a subclass of human

    Discussion[edit]

    Second half of 2021[edit]

    @Emu, Kolja21: The second half of 2021 is starting, let's make a new point of the situation for GND and DtBio. I just add here the first points:

    • numbers: as of now 1'252'200 items having P227 as main statement and 627'074 items having P7902 as main statement
    • backlog of 2020 import: still 1138 items from 2020 import having the same VIAF as another item (https://w.wiki/3VzL)
    • backlog of 30/6/2021 import: 4224 items having substantially no data (https://w.wiki/3ZrH), @Bargioni: has accepted enriching them from GND in the next weeks

    I am not opposed in principle to new imports, but I think it is better to delay their discussion after cleaning the backlog from 2020 import. If you have any idea about the current situation, problems to be solved and perspectives for the next months, we can discuss them here with the greatest pleasure for us all! Good evening, --Epìdosis 18:49, 30 June 2021 (UTC)[reply]

    No. 3: Thanks @Bargioni. Importing data from GND will bring us a great step forward. No. 2 is tricky since VIAF clusters are unstable. Same problem with BBLD (Property talk:P2580). The blocked user seems to be the same who has access to Baltisches biografisches Lexikon digital (Q18616550). He is doing mainly copy & paste edits:
    The BBLD IDs have changed two or three times (own IDs, tests with ISNI, now mainly GND). We should keep an eye on these items. --Kolja21 (talk) 19:19, 30 June 2021 (UTC)[reply]
    About the backlog: Items like Ferenc Karacs (Q1104400) [2] and Marko Martinović (Q4282609) [3] are imports from Biographisches Lexikon des Kaiserthums Oesterreich (Q665807). Plus there are thousands Mathematics Genealogy Project ID (P549) imports with information about an university degree. These items have to be further individualized and merged if the person is known in Wikipedia. Those who did their doctorate in Germany usually have a GND. --Kolja21 (talk) 20:00, 30 June 2021 (UTC)[reply]

    backlog of 30/6/2021 import: The new BBLD imports[edit]

    dnbn in URL[edit]

    For Q120968405 I added what I thought a was a valid GND identifier, but the URL differs; it contains dnbn instead of gnd (https://d-nb.info/dnbn/390065072). I guess this is not a valid use of the property, is there another way to add the entry correctly? Dorades (talk) 18:50, 27 July 2023 (UTC)[reply]

    Hi Dorades, recording companies and music publishers have yet not been imported into the GND. (de:Hilfe:GND#Körperschaften: "Tonträgerfirmen und Musikalienverlage wurden gesondert erfasst und nicht in die GND importiert.) You can add these IDs with DNB edition ID (P1292). Not a perfect solution, but there is no other option at the moment. --Kolja21 (talk) 22:36, 27 July 2023 (UTC)[reply]

    Removing GND redirect statements[edit]

    Message from my talk page:

    Headline: Removing deprecated statements

    You shouldn't be removing deprecated statements like this one. Please undo your edits. Multichill (talk) 19:04, 18 November 2023 (UTC)[reply]

    My reply:

    Multichill, I couldn't find a rule for what you requested in the property description. Please point to the rule or write it down here. I know that User:Kolja21 and User:Magnus Manske did the same. User:Kolja21 several times thanked me after I removed a redirect ID. He is also hiddenly removing them by simply replacing them with target values. I think User:KrBot does remove redirects in VIAF statements (sometimes by replacement without adjusting references, ranks and qualifiers.)

    So, it is not that only I do that.

    Topic:Xspjdsm1j614amoh shows a bot operation and the statement that 438,641 redirect targets exist in the redirect file from 2023-10-13.

    The highest number of GND IDs on one item about a human that I have evidence for is four, the item is Q3159374, 3x normal rank, 1x deprecated redirect.

    Wikidata:Database reports/Constraint violations/P227 says under "Single value" violations "Violations count: 12359". A subset of these are redirects, while other violations can be fixed by other means, permanent redirects can't.

    That means if all currently existing redirects were stored in Wikidata, the page would list at least 438,641 violations just based on the redirects, if it could handle them at all.

    I think I have seen a discussion between you and several other users, one being User:Kolja21, about the removal of GND redirects, but I don't remember where. In case that you remember that discussion please provide a link to it, so one can see which arguments have been exchanged there.

    Among the 10mio+ items about instances of humans there are currently:

    1. 1587071 that have at least one GND statement (making GND the most used ID property on instances of humans among the VIAF contributors)
    2. 870 GND redirects found by https://w.wiki/8CFz
    3. 877 GND redirects found by https://w.wiki/8CGE

    I planned to remove the 870 today by batch and check the 7 that make up the difference manually, but will halt the batch and wait for feedback.

    Please also note that there are tens of thousands of GND IDs in VIAF clusters about instances of humans that are not yet in Wikidata and thousands of articles about humans in the German Wikipedia that don't contain a GND ID yet.

    I am not against storing redirects in Wikidata, but the software doesn't seem to provide the means to do so without getting in the way of maintainers that use the web frontend. Also, if it is done and a reference should be provided, the reference should be one to the GND item in question and not one to the whole VIAF DB as shown in the diff you provided.

    Furthermore I doubt the reference in the diff you provided states the truth at all, as it was first used in 2015 while the value was not marked as redirect, and was simply kept in 2022 when the value was marked as a redirect. Kolja21 removed the statement and you reverted, by doing so re-inserting a false claim. So, on this very item two people actively working on GND maintenance removed the statement. Asterix2023 (talk) 21:44, 18 November 2023 (UTC)[reply]

    Leave them there. Identifiers serve as unique names for entities, and names do not become obsolete just because that name also has the role of an URL that now redirects. User:Multichill is correct. ---MisterSynergy (talk) 22:22, 18 November 2023 (UTC)[reply]
    You wrote three sentences without any links. The first is a command, the second a claim which can be true but doesn't address the issues raised above, the third is a claim which probably is false, as pointed out by me. Asterix2023 (talk) 23:33, 18 November 2023 (UTC)[reply]
    There are plenty of best practices which are not explicitly coded into rule etc., but Wikidata editors usually get along with a minimal set of generic policies. There is no policy to remove those claims, and no policy to keep them.
    If you look for single value constraints regarding P227, see Property talk:P227/Constraint violations/Single best value constraint. KrBot lists are not useful when ranks are involved, so you can ignore some of the sections at Wikidata:Database reports/Constraint violations/P227. Mind that we do not want to make editorial decisions based in a faulty bot report. —MisterSynergy (talk) 16:15, 19 November 2023 (UTC)[reply]
    Thank you. Others disagree with you, saying that since this is the standard report it should be at least considered. And it isn't the only problem. The redirect IDs are valid IDs, they are names as you said. Other names from a given GND object are stored next to the main statement via a qualifier.
    Why are the redirects stored differently? In a separate main statement and that statement is down ranked? Get other fully valid aliases a rank "deprecated"? Why put them on par with faulty information?
    Why not store them using a qualifier and
    1. get the reference (the main statement for free) and
    2. have a clear grouping and
    3. have them shown *after* the main value
    ? Asterix2023 (talk) 23:01, 19 November 2023 (UTC)[reply]
    KrBot constraint violation reports have been largely abandoned in recent years by most of the community. Its maintainer is pretty much the inventor of those constraint reports, but the bot has never been capable enough to really make useful reports for many constraint types. "Single best value constraint" is one of them, since KrBot does not access ranks at all. The reference implementation for constraint violations is much rather the one which is used by the web UI (the indicators that you see when there is a problem), but that one does not generate reports. If you want a particular report, you can set up your own one or ask for help to get it done.
    The other issue is a somewhat reasonable concern. We do want only one claim with best rank in order to allow data users to pick "the best" identifier with ease, and that usually defaults to an identifier that does not redirect on GND side. This could be achieved by raising that best claim to preferred rank and leave all other valid claims at normal rank. With P227, however, things have over time evolved differently with quite a lot of use of deprecated rank. This is an oddity indeed, but since we are using reason for deprecated rank (P2241) qualifiers usually for these deprecated ranks to indicate the reason for that editorial decision of ranking usage, this is an acceptable situation for the moment. Mind that ranks are merely visibility controllers without an intrinsic semantic meaning for the claim.
    Other than that, we do not want to replicate particular data from GND (or any other source) in the identifiers section if form of qualifiers. Such information is often not particularly stable and thus super difficult to maintain in good shape, and besides that it can be queried at GND directly in machine readable form. —MisterSynergy (talk) 23:28, 19 November 2023 (UTC)[reply]
    As of now we lack a precise guideline, since Wikidata:Requests for comment/Handling of stored IDs after they've been deleted or redirected in the external database (opened in mid 2020) is still deadlocked; if I count correctly, 12 users have supported keeping redirected and obsolete IDs in some way and 4 users (including me) have somehow supported removing them; apart from the central issue (keep in some way or just remove), there is still no consensus about how we should possibly keep the IDs and also about allowing or not the addition of IDs which have already become obsolete. My personal feeling, mainly for the reasons I expressed back in 2020 (and for the ones expressed by Ivan A. Krestinin in 2021), is still in favour of removal, although I understand some of the reasons which motivate the option of the keep option. Practically, since there is an ongoing (although deadlocked discussion) where presently a majority of users favours in some way keeping these IDs, and since a massive removal of them is not (at least IMHO) a prioritary part of our curation of interlinks between Wikidata and authority files, I tend to be against massive removals of referenced redirected IDs (for not-referenced ones, I have no objection). Anyway, I have noticed that some of the removed IDs have been added by Reinheitsgebot executing AC2WD (e.g.) although they were already redirects (see deprecation after only one day), and probably also this lacks sufficient consensus, since only a minority of the users who took part in the RfC explicitly supported such additions; I think that, for the same principle, we should also avoid these additions. --Epìdosis 23:25, 18 November 2023 (UTC)[reply]
    The GND provides a new redirect file every month, which Magnus Manske is able to parse. From that file redirects can be easily added. No redirect is lost.
    As you didn't address each issue I addressed, now three direct questions:
    1. Do you support keeping redirects having false references?
    2. Do you support the increasing number of unfixable constraint violations in the standard reports page, which make the page less useful for maintainers?
    3. Do you support down ranking of redirects, which if the target is correct are 100% correct themselves, and by doing so putting them on a level with conflated and otherwise false IDs?
    Asterix2023 (talk) 23:49, 18 November 2023 (UTC)[reply]
    For me 1) no, I support removing them; 2) the fact that constraint violations reports don't take ranks into account is a know issue which should (but in fact has never been fixed), so it could be considered as an incidental incentive to removing redirected IDs (anyway, checking constraint violations through queries allows to filter out deprecateded statements); 3) personally my preference would be just removing redirected IDs, although (as I said above) it seems that presently a majority of users supports keeping them (on the way of keeping them there is no clear agreement in the RfC). --Epìdosis 00:52, 19 November 2023 (UTC)[reply]
    I now read the full RfC, thanks for structuring the thought process. For GND all redirects are available from the source itself as CC0/Public Domain. That is the definitive source that can tell if something is a redirect or not. There can still be reasons to store them in Wikidata, they should be written down, e.g. better technology, more detail, largest (?) CC0 ID hub. There can also be reasons against, Krestinin spoke out against from a general data perspective and as a software developer and I spoke out here against from the other end of those working on the IDs, as someone manually working on the items. Kolja21 is also a person actively working manually on the IDs and like me is against, probably also because the UI and the reports are as they are. There are probably more people actively working manually on the "GND humans", but some may never have seen items with 4 or more IDs on them. There is MisterSynergy who runs a bot, for him the UI and standard error reports are of less relevance as he can use the bot and selfmade reports instead. And then there are users in that discussion that maybe don't do any maintenance on GND humans so aren't aware of the problems maintainers face. The red and green rank colors have been mentioned, I may add that Kolja21 frequently changes the order of the values - manually. If redirects are kept, more UI users may want to do that as no bot seems to do it. I think this is distracting humans from doing other work in WD.
    A cheap option hasn't been mentioned yet: Let a bot take care of the redirects inside qualifiers, then they are visible to humans whilst requiring a minimal amount of UI space, and being placed next to the target value, no change of sort order and misuse/misleading use of the deprecated rank needed (they are called deprecated in GND, but that is not what the rank deprecated is used for in WD elsewhere, they are 100% valid IDs.) They don't need to be links as they resolve to the target anyway, it is actually better they are not, to avoid that crawlers follow them and spend energy on it. Users, me included, may like to test if a redirect really resolves to the target - if a bot takes care of the maintenance there might be less desire by these users, because they simply trust the given values. Already now qualifiers are used to present data from the source item, e.g. "subject named as" does so, therefore such usage is in line with existing practice. We could have "subject has redirect" or "subject has alias/secondary ID". That solution could, or probably should, only be used for source items that provide the aliases, which is the case for GND. No extra references on redirects as the target ID, the one in the main statement is the source for the alias as it is for "subject named as". There is also some Javascript GND reveal.js, or authority control.js, maybe it can be programmed into these tools to maintain redirects, so one is a bit more independent from bots. The tools could also provide links. Asterix2023 (talk) 05:57, 19 November 2023 (UTC)[reply]

    Storing GND redirect ID in qualifier[edit]

    Example using alternative name (P4970): https://www.wikidata.org/w/index.php?title=Q87718745&diff=prev&oldid=2013930086

    Fulltext search finds the alias ID: https://www.wikidata.org/w/index.php?fulltext=1&search=1090225261&title=Special%3ASearch&ns0=1&ns120=1

    Issues solved:

    1. redirect ID in Wikidata, no need for access to an external DB
    2. value available in truthy dump [5]
    3. clear relationship to primary ID (redirect target ID)
    4. compact representation
    5. no misuse or misleading use of ranks
    6. no sorting issues regarding primary ID, the primary is always shown first
    7. no false references regarding the alias nature, as the source for that claim is the item linked to in the main statement (like for "subject named as")
    8. moveClaim.js can move a full set of information to another item

    To do:

    1. create a dedicated qualifier property named either
      1. alias ID
      2. alternative ID
      3. ...?
    2. update JavaScript tools so they handle that qualifier
      1. gnd reveal.js
      2. authority control.js
      3. ...?
    3. get bot help
      1. to add the IDs
      2. to check the IDs maybe monthly (after the GND redirect dump is published? At time of publication it may already be outdated)
      3. to provide reports on changed values?
    4. let Wikibase
      1. show links?
      2. sort the qualifier at the same place independent from when it has been added
      3. sort an ID among others independent from when it has been added to the main statement

    Asterix2023 (talk) 07:34, 19 November 2023 (UTC)[reply]

    @Ecelan: at Q8351762 Despuig you reverted the removal, you reverted the revert, but in talk expressed the wish to have the old values. What do you think about storing them in a qualifier? Details in the first message of this section. Asterix2023 (talk) 15:10, 19 November 2023 (UTC)[reply]

    I am generally against eliminating information (inclusionist), because you never know when it can be useful. Even wrong or old information can be useful if you present it in the correct context. So I'm in favor of keeping the old DNS numbers however you decide to do it. --Ecelan (talk) 15:25, 19 November 2023 (UTC)[reply]

    GND Umleitung in Qualifier speichern[edit]

    Es äußern sich immer wieder Leute zum Thema, die wohl nicht GND-Wartung per Hand per Webinterface betreiben. Die Diskussionen finden dann meist auf Englisch statt, was ja grundsätzlich OK ist, aber auch Leute ausschließen kann, die GND-Wartung betreiben. Daher hier nun in deutscher Sprache der Sprache der GND.

    Direkt oberhalb ist der Vorschlag auf Englisch die Weiterleitung-IDs im Qualifier zu speichern.

    Beispiel unter Verwendung von alternative name (P4970): https://www.wikidata.org/w/index.php?title=Q87718745&diff=prev&oldid=2013930086

    Volltextsuche findet die Weiterleitunggs-/Alias-ID: https://www.wikidata.org/w/index.php?fulltext=1&search=1090225261&title=Special%3ASearch&ns0=1&ns120=1

    Die Weiterleitungs-IDs sind ja vollständig gültige IDs, sie als "deprecated" zu speichern stellt sie auf eine Stufe mit falschen oder kaputten Werten. Es gibt rund eine halbe Million Weiterleitungen, die Wartungsseite zeigt schon gar nicht mehr alle Single-value-Regelverletzungen mehr an, keine einzige Qid hat ein Label dort, die Seite ist praktisch unbenutzbar. Es ist zudem nicht klar auf welches Ziel sich eine Weiterleitung bezieht, es können in einem Wikidata-Objekt ja mehrere Nichtweiterleitungen enthalten sein.

    Findet man einen Fehler bei der Zuordnung und möchte einen Wert zu einem anderen Element verschieben (mit dem Helferlein moveClaim.js möglich), müsste man die Weiterleitungen überprüfen. Und schiebt man die dann auch rüber zu Q456, oder weil irgendeine Quelle mal sagte sie gehört zu Q123 soll sie da bleiben? Kopiert man, also bei beiden speichern?

    Die Reihenfolge der Elemente ist auch problematisch, es können zuerst mehrere Weiterleitungen gelistet sein, danach kommt dann der aktuelle Hauptwert. Oder umgekehrt, allerdings stehen DtBio, Sächsische Biographie und Kalliope dann in größerer Entfernung. Überhaupt ist der Platzverbrauch viel höher im derzeitigen System.

    Die Speicherung im Qualifier löst mehrere Probleme, die Darstellung ist kompakt, die Zuordnung zum Zielwert eindeutig und die Quelle der Information auch, denn wie die gelegentliche Angabe des Namens wie er in der GND steht mittels Qualifier, ist auch bei der Angabe sekundärer IDs mittels Qualifier die GND selbst die Quelle.

    Meinungen? Asterix2023 (talk) 13:57, 19 November 2023 (UTC)[reply]

    @U. M. Owen: du hattest auch die Löschung hinterfragt, bzw. dich etwas dagegen geäußert. Was hälst du von Speicherung in einem Qualifier? Asterix2023 (talk) 15:15, 19 November 2023 (UTC)[reply]

    Eine veraltete GND als alternative name (P4970) einzutragen, ist unzulässig. Warum? Weil eine ID kein alternativer Name ist. @Emu, Epìdosis: Can you have a look at this? It's a typical User:Humanisator idea. Trying out new concepts that contradict all the rules. --Kolja21 (talk) 22:20, 19 November 2023 (UTC)[reply]
    User:Kolja21 seit wann ist eine ID kein Name? Hast du gelesen was User:MisterSynergy schrieb [6] "Identifiers serve as unique names for entities, and names do not become obsolete just because that name also has the role of an URL that now redirects." I don't understand why you after writing in German in this section that was started in German switch to English and refer to User: Humanisator. It's a typical Humanisator idea? Did you confuse that user with MisterSynergy as it was him who seems to have first mentioned here that identifiers are names? Also, I wasn't "trying out new concepts" I just made one edit to test if the search finds a name stored in the qualifier. If you knew that before fine, I didn't. I have seen no documentation on that. Asterix2023 (talk) 23:17, 19 November 2023 (UTC)[reply]
    @Kolja21 See Wikidata:Requests for checkuser#MrProperLawAndOrder --Emu (talk) 23:29, 19 November 2023 (UTC)[reply]