Open main menu
Wikidata

Property talk:P227

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)
Has qualityVIAF component (Q26921380)
Data typeExternal identifier
Template parameteren:Template:Authority control: |GND= – Template:Authority control (Q3907614)
Allowed values1[01]?\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)
Jehan Sadat (Q212190) → 118604740 (RDF)
Sourcehttps://portal.dnb.de
Formatter URLhttps://d-nb.info/gnd/$1
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: differencesCategory:GND different on Wikidata (Q55746867)
Tracking: usageCategory:Pages using Wikidata property P227 (Q8709075)
Tracking: local yes, WD noCategory:GND not on Wikidata (Q56825653)
Related to countryFlag of Germany.svg Germany (Q183) (See 116 others)
See alsoDNB editions (P1292)
Lists
  • Items with the most statements
  • 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
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history
  • Mix'n'match (Report)
    Mix'n'match (Report)
  • Database reports/Constraint violations/P227
    • Proposal discussionProposal discussion
    Current uses790,752 out of 11,269,767 (7% complete)
    Search for values
    Explanations [Edit]

    The Integrated Authority File (GND) is managed by the German National Library in cooperation with various library networks in German-speaking Europe and other partners. Please look up GND at Online-GND or DNB-Portal. (VIAF is helpful but also often incorrect, outdated, and is mixing two identifier systems that in some cases produce dead links.)

    GND ID (P227) (Template:Entities)

    1. GND 1019646128: Stan Lauryssens (b. 1946), type Tp (person) = Yes
    2. GND 122968751: Stan Lauryssens (no info), type Tn (name, a placeholder) = No

    VIAF ID (P214)

    1. VIAF 120062731 Stan Lauryssens = Yes
    2. VIAF 293348885 Stan Lauryssens (undifferentiated) = No

    Known VIAF problems

    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 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")

    Allowed qualifiers

    See: property constraint (P2302)

    • Duplicate
      • Please mark preferred GND with "preferred" rank (see Help:Ranking)

    Subject headings

    For subject headings the GND uses quasi-synonym (Q2122467) what is useful for libraries but does not fit to Wikidata.

    Example:

    See also

    Format “|(1[01]?\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 this constraint violations: Database reports/Constraint violations/P227#Format, hourly updated report, SPARQL, SPARQL (new)
    Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410), Wikimedia category (Q4167836), 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. Known exceptions: Kingdom of Granada (Q1495642)
    List of this constraint violations: Database reports/Constraint violations/P227#Conflicts with P31, SPARQL, SPARQL (new)
    Single value: this property generally contains a single value. (Help)
    Exceptions are possible as rare values may exist.
    List of this constraint violations: Database reports/Constraint violations/P227#Single value, SPARQL, SPARQL (new)
    Distinct values: this property likely contains a value that is different from all other items. (Help)
    Exceptions are possible as rare values may exist. Known exceptions: Q196538, Q912313, Q19786, Q83367, Q302, Q51666, Q695368, Q206587, Q1301203, Q8222382, 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, Q15785077, Q13362, Q693570, Q19831595, Q1206262, Q170390, Q697084, Q5923, Q1803420, Q2839, Q16332967, Q20883, Q20892, Q1396026, Q1787565, Q20791505, Q13344, Q157575, Q20808141, Q429850, Q19311569, Q277759, Q1700470, Q742421, Q2088357, Q41662, Q8867089, Q11634, Q350268, Q321087, Q13165156
    List of this constraint violations: Database reports/Constraint violations/P227#Unique value, SPARQL (every item), SPARQL (by value), SPARQL (new)
    Qualifiers “pseudonym (P742), named as (P1810), sex or gender (P21), stated as (P1932), point in time (P585), start time (P580), end time (P582), located in the administrative territorial entity (P131), title (P1476), applies to part (P518), author (P50), criterion used (P1013), occupation (P106), reason for deprecation (P2241)”: this property should be used only with the listed qualifiers. (Help)
    Exceptions are possible as rare values may exist.
    List of this constraint violations: Database reports/Constraint violations/P227#Allowed qualifiers, SPARQL, SPARQL (new)
    Scope is as main value (Q54828448), as references (Q54828450): the property must be used by specified way only (Help)
    Exceptions are possible as rare values may exist.
    List of this constraint violations: Database reports/Constraint violations/P227#scope, SPARQL, SPARQL (new)
    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


    DiscussionEdit

    Duplicate of P107Edit

    This property seems to be a duplicate of P107 (GND entity type), or why are there now two different properties? --#Reaper (talk) 13:04, 16 March 2013 (UTC)

    Property:P107 lists the main types of item. Is the item a person, organization, event, work, term, place, or disambiguation page? (See Wikidata:Infoboxes task force for use.) It's a kind of basic classification. So Marilyn Monroe (GND 118583549) and Vladimir Putin (GND 122188926) are both "type person", but they have their own GND numbers as identifier. --Kolja21 (talk) 02:08, 17 March 2013 (UTC)
    Ah, I haven't seen that this property is from type string, the description reads like if I/you should enter "name", "work" and so on, not the ID of the GND-object. Thx. --#Reaper (talk) 12:34, 17 March 2013 (UTC)

    STICKY: Explanation of format constraintsEdit

    At its launch in April 2012 the GND established all existing identification numbers of its constituent files (PND, GKD, SWD, DMA-EST) as GND identification numbers. Records created since then follow the pattern for the former PND. Caveat: The checksum algorithms differ between the dashed and undashed types. Another caveat: The dash is essential, both 160220440 and 16022044-0 are valid GND numbers, denominating distinct entities.

    1. (1|1[01])\d{7}[0-9X]: (9 digits starting with "1" or 10 digits starting with "10" where the last "digit" may be "X") Former PND numbers, and all numbers for genuinely "GND-born" records (those created after 2012-04, always 10-digit form)
    2. [47]\d{6}-\d: 7 digits starting with "4" or "7", followed by dash and a strictly numerical check digit: Former SWD numbers. Scheme discontinued after 2012-04.
    3. [1-9]\d{0,7}-[0-9X]: one to eight digits not starting with "0", followed by dash and a check "digit" which may be "X": Former GKD numbers. Scheme discontinued after 2012-04.
    4. 3\d{7}[0-9X]: 9 digits starting with "3", last "digit" may be "X": Former DMA-EST numbers. Scheme discontinued after 2012-04.

    At the time being there is a certain overlap between the formulations 2. and 3. admitting false negatives. And of course the pattern check does not perform a checksum test. -- Gymel (talk) 11:43, 11 May 2013 (UTC)

    STICKY: Uniqueness constraint: List of persons with known conflicts between GND and WikipediaeEdit

    Below is a list of persons from GND database, where different to Wikipediae (a) GND does not distinguish between two (possibly) different persons and thus has only one database entry (b) GND identifies a pseudonym or fictional author (persona) with its creator, although the persona is more than a simple pen name. These rare exceptions can lead to violations of uniqueness constraint. Please see de:Benutzer:Gymel/Hartnäckige_PND-Dubletten for further details (in German). -- Make (talk) last update: 12:40, 27 November 2013 (UTC)

    1st group [identities historically identified with one person]
    1. http://d-nb.info/gnd/118557513 Jesus Christus
      = historical Jesus (Q51666) (historical Jesus of Nazareth) + Jesus Christ (Q302) (central person of Christianity from/in New Testament)
    2. http://d-nb.info/gnd/118557815 Johannes
      = John the Apostle (Q44015) + John the Evangelist (Q328804)
      2nd group [identity is subject of ongoing debate]
    3. NOTYETDISCOVERED but WONTFIX http://d-nb.info/gnd/118720260 Hans von Tübingen
    4. NOTYETDISCOVERED but WONTFIX http://d-nb.info/gnd/118815245 Hans Hirtz
    5. WONTFIX http://d-nb.info/gnd/11936929X Meister von Meßkirch : Q568760 Q1532784
    6. WONTFIX http://d-nb.info/gnd/119457733 Arnold : Q535832 Q694744
    7. http://d-nb.info/gnd/118746871 Irmgard
      = legendary Irmgardis von Süchteln for whom worship as patron saint of town Süchteln (Q314425) is first documented at the end of 15th century (1486, 1498) +(?) Irmgard von Köln + historical persons Irmtrudis, Irmgardis, ... who are documented as donors to the church in 11th century
      = (badly disambiguated) Saint Irmgardis (Q444949) + Q14540331
      see www.rheinische-geschichte.lvr.de/persoenlichkeiten/I/Seiten/IrmgardisvonSüchteln.aspx (deutsch)
      3rd group [pseudonyms]
    8. http://d-nb.info/gnd/118677799 Lemony Snicket
      = Daniel Handler (Q1060636) (novelist, born 1970) creator of → Lemony Snicket (Q458346) (fictional person providing his pen name)
    9. http://d-nb.info/gnd/126472009 Bonifatius Kiesewetter
      = Waldemar Dyhrenfurth (Q1307672) (German jurist and author, 1849-1899) creator of → Bonifazius Kiesewetter (Q892566) (fictional person providing his pen name, later use by other authors)
    10. http://d-nb.info/gnd/115646108 Jason Dark
      = Helmut Rellergerd (Q1604049) (German writer, born 1945) creator of → Jason Dark (Q104029) (pen name used by different authors of publisher "Bastei", Rellergerd later was granted exclusive use of the pseudonym)
    11. http://d-nb.info/gnd/123068908
      = Kurt Ostbahn (Q584872) + Willi Resetarits (Q43776)
      group ? [unclear what is going on,work in progress]
    12. http://d-nb.info/gnd/118691910 Lucius Annaeus Florus ←→ http://d-nb.info/gnd/100136907 Florus ←→ http://d-nb.info/gnd/119410672 Florus

    Leading or trailing space characters in values (resolved)Edit

    text separated here into a standalone section for archieving purposes -- Make (talk) 22:58, 26 May 2013 (UTC)

    Wikidata:Database reports/Constraint violations/P227: Some of the numbers are correct. A helpful rule would be: "Only numbers starting with 1-9 (not 0) and dashes are allowed." Can someone translate this into format pattern? --Kolja21 (talk) 16:54, 18 May 2013 (UTC)
    Examples from the list:
    Both GND's are correct. --Kolja21 (talk) 16:58, 18 May 2013 (UTC)
    I think I found out what went wrong: the tsring values contain either leading or trailing space characters. Unfortunately this is not visible on the item page or in the constraint violation report. Only if you look at the wikitext source of the report you can see the mistakes as %20 in URLs. To correct this on an item page, I had to use a 2-step somewhat hacker-like approach (since the erroneous space characters are not visible): click edit (value), add a space character at the start and at the end of the value string, click save, click edit, remove the extra characters just added, click save. But we have to wait for the next report to be sure this really works ... -- 22:41, 18 May 2013 (UTC) User:Make -- minor edits for clarity 08:07, 21 May 2013 (UTC)
    And, has it worked? Three examples from the current list (19:35, 20. Mai 2013‎):
    All three GND's are correct, but have a trailing space in the list. --Kolja21 (talk) 22:44, 20 May 2013 (UTC)
    Looks like it really worked. On May 19th, I removed space characters (with the hacker-technique described above) from value strings for Q2066, Q124696, Q71154, Q70938, Q30917, Q11143, and Q11021. None of these items show up as "format violations" in the current report anymore. -- Make (talk) 08:07, 21 May 2013 (UTC)
    I just removed the trailing space from Q1135083 see revision history for change in Bytes. You might want to try fixing some string values yourself to confirm that although the presentation on the item page is identical before and after, from the revision history you can see that indeed a character was removed. – I am not sure what to think of this. At least it is unfortunate that the presentation on the item page omits some content (namely leading/trailing space characters). Maybe there is a software bug with string input/printing behind this. -- Make (talk) 08:22, 21 May 2013 (UTC)
    I left a note at Wikidata:Contact the development team#Trailing space. --Kolja21 (talk) 13:07, 21 May 2013 (UTC)
    Yes, sorry, that's my fault. The way we added trimming is a bit hacky, which leads exactly to the issue you describe here. It will be improved, but this is probably a month or two down the line. The good news is: this kind of errors should be impossible to introduce anew. So there is only some legacy error. I am not sure, it could even be possible that pages that get edited at all loose this kind of legacy error, because the whole content gets changed, but as said, I am not sure. Whatever, in order to help here, I made an analysis, and tried to figure out a list of all places where this problem occurs. It seems to be in 148 values, listed in the following (item, property, value). I hope this helps, and again, sorry for my mistake! I anticipated it, but checked only for linebreaks, and fixed those manually before the patch, but not for simple whitespaces. --Denny (talk) 15:28, 21 May 2013 (UTC)
    Thanks@all for helping to resolve this. I just finished fixing all %20 in claims for P227. Hope I didn't miss any. We'll see if all is good when the bot-update scheduled for the early hours of May 24th brings its findings. --- Make (talk) 20:36, 22 May 2013 (UTC)
      Done Finally all values with leading/trailing spaces are fixed. -- Make (talk) 22:58, 26 May 2013 (UTC)

    DuplicatesEdit

    Please use de:WP:GND/F to report duplicates. See de:Hilfe:GND#Personen for the difference between individualized and non-individualized (VIAF: "undifferentiated" = don't use) GNDs. --Kolja21 (talk) 14:15, 11 October 2013 (UTC)

    Database reports/Constraint violations : GND identifier present but VIAF identifier missingEdit

    Hi! This might be a new type of property constraint violations.
    Is it possible to list all pages where GND ID (P227) is present but VIAF ID (P214) is missing? Regards לערי ריינהארט (talk) 06:45, 20 October 2013 (UTC)

    Thanks for the answers! In order to have fewer results one should limit the query to Wikidata pages that are linked to a specific language:

    1. having an article in yi.Wikipedia
    2. having an article in eo.Wikipedia
    3. having an article in ro.Wikipedia

    Thanks for any answer! לערי ריינהארט (talk) 09:03, 21 October 2013 (UTC)

    Magnus Manskes's tool would not work properly if no English label is present.
    How can you query all Wikidata pages having Library of Congress authority ID (P244) without English label?
    לערי ריינהארט (talk) 09:13, 21 October 2013 (UTC)
    Looks like not all items with GND ID have VIAF ID. For example I am failed to find VIAF ID for Bieszczady Mountains (Q125529), Rheinbach (Q12547), Age of Enlightenment (Q12539). — Ivan A. Krestinin (talk) 18:57, 26 October 2013 (UTC)
    VIAF has problems with hyphens and changed Bieszczady Mountains (Q125529) GND 4006552-2 into VIAF-GND 040065529. But there are also numbers missing. RERO is incomplete and GND numbers of May 2012, when PND changed to GND, were apparently not reported. Expample: Samuel Ramos (Q7412445) GND 1022446479 (16-05-12). VIAF 59099151 has today, one and a half years later, still an outdated "undifferentiated" Tn linked to the Mexican writer. --Kolja21 (talk) 21:51, 27 October 2013 (UTC)
    The "problems" VIAF has are that it (partially) confuses GND Ids with DNB Ids. Thus GND 4006552-2 cannot be resolved by "sourceID" but if you access VIAF 245618932 it links to the correct GND record, but it displays the wrong ID. -- : Gymel (talk) 00:39, 28 October 2013 (UTC)

    Thanks for the answer! לערי ריינהארט (talk)

    (GND identifier present AND its values has length 9 AND its value starts with (1 OR 2)) AND VIAF identifier missingEdit

    How many are these? Let's restrict to: 

    GND value matches pattern=[12]\d{7}[0-9X] AND VIAF is (empty OR NIL)

    i.e. no MINUS is present in GND value AND ... . Normally you should be able to identify the correlated VIAF id with a link as [2]. Note: The example contains a trailing X.
    Note: https://viaf.org/viaf/search?query=cql.any+all+%22000423580%22+and+local.sources+any+%22dnb%22&sortKeys=holdingscount can identify via normalized GND 000423580 (The - is removed from 42358-0 . Then heading ZERO's are added to get a string of lemght nine.). This does not work in general. לערי ריינהארט (talk) 04:23, 6 November 2013 (UTC)

    add GND identifier format constraint violations/P227 : values of length 9 never ever start with a digit different then 1 or 2Edit

    Hi! GND identifier vales the values never start with 0 or 9. If present here this is due to a bug of the AC tool. לערי ריינהארט (talk) 03:23, 1 November 2013 (UTC)

    Update: GND identifier vales of length 9 never ever start with a digit different then 1 or 2. לערי ריינהארט (talk) 03:31, 6 November 2013 (UTC)
    The current format constraint gives this regular expression:
    |((1|10)\d{7}[0-9X]|[47]\d{6}-\d|[1-9]\d{0,7}-[0-9X]|3\d{7}[0-9X])
    which is in fact redundant (the 3 unnecessary alternatives for the initial 1, [47], or 3 are already part of the alternative for the initial [1-9]) and fully equivalent to:
    |(([1-9]|10)\d{7}[0-9X])
    (Note: the initial "|" of both regexps indicates that the value may be empty, for meaning "no VIAF identifier currently exists for this topic", or "the VIAF identifier has been obsoleted/deprecated/removed" probably because the topic was ambiguous and did not identify really a single topic; the empty value for this property can be only set in Wikidata, provided you also add a qualifier such as "comment":"no value" and probably a "date" qualifier for this asserted comment; without the necessary qualifier(s) the property would be simply deleted from the item in Wikidata)
    But what you are saying is that: if the identifier starts by 1 or 2, then it cannot have length 9 and would have length 10. This would give the following:
    |([3-9]|([12]\d))\d{7}[0-9X])
    Is that correct ? Can you point us to a reliable source (the DNB reference page explaining it)? Verdy p (talk) 19:47, 4 March 2016 (UTC)
    I also note that GND identifiers of persons (starting by 1, and with 10 digits/letters), do not have any minus-hyphen sign before the last check digit in [0-9X], in order to preserve the maximum length of the full id to at most 11 characters (only IDs starting by 4 or 7 also have variable lengths, and all IDs except those starting by 1 or 2 accept the minus-hyphen as they have a maximum of 9 digits/letters). The actual format would be then more accurately:
    |([12]\d{8}|[35689]\d{0,7}-|[47]\d{6}-)[0-9X]
    Adding the minus-hyphen in the "long" GND ID of a person (staring by 1) causes the ID to be misinterpreted (with the last check digit discarded due to excessive length) and can sometime bring us to another unrelated authority record).
    Beside that, it seems that the minus-hyphen is now optional in "short" IDs (those starting by [3-9])
    |([12]\d{8}|[35689]\d{0,7}-?|[47]\d{6}-?)[0-9X]
    Leading zeroes (just after the required leading [3-9] "class digit") for "short" IDs must apparently be discarded. I don't know if this is true for those starting by the required [47] "class digit", but it is strange that they accept less digits than others. If so we would get more simply:
    |([12]\d{8}|[3-9][1-9]\d{0,7}-?)[0-9X]
    (where the first alternative is for "long" IDs where zeroes after the "class digit" are not discarded and where the minus-hyphen must NOT be specified, the second alternative is for all "short" IDs that may include the minus-hyphen before the "check digit" and may have leading zeroes after the "class digit").
    Verdy p (talk) 20:54, 4 March 2016 (UTC)
    Further checking in the database with SPARQL, I found that Wikidata internally stores some GND identifiers by terminating them by an additional right-to-left mark (U+200F), even if they are not visible in the editing interface.
    Then they don't match the regular exception. I think this is a bug in the Wikidata editing interface (which can insert them automatically when submitting to the database), or in its local implementation of SPARQL...
    So I looked for other querying interfaces, I found that the RLM are effectively present... but not displayed in the database.
    There are 9 occurences :
    • Q1032, GND identifier = "1018704-2<RLM>" (strlen=10 instead of 9)
    • Q7054, GND identifier = "4727207-7<RLM>" (strlen=10 instead of 9)
    • Q42108, GND identifier = "7678885-4‏<RLM>" (strlen=10 instead of 9)
    • Q21165243, GND identifier = "1058485881<RLM>" (strlen=11 instead of 10)
    • Q21638355, GND identifier = "1026070740<RLM>" (strlen=11 instead of 10)
    • Q21823350, GND identifier = "138778485<RLM>" (strlen=10 instead of 9)
    • Q21849794, GND identifier = "135929210<RLM>" (strlen=10 instead of 9)
    • Q22967417, GND identifier = "124887171<RLM>" (strlen=10 instead of 9)
    • Q22920213, GND identifier = "132592746‏<RLM>" (strlen=10 instead of 9)
    Can a wikidata admin look at what is wrong there ? I tried to edit these identifiers, but they are displayed correctly in these pages, and the links also work correctly (none of them show the RLM). Removing them prior to adding them again (typing them manually to make sure there's no RLM in a copy-paste operation) does not change the result. I fear that this could affect many other item properties (or translated labels) in Wikidata.
    Verdy p (talk) 23:23, 4 March 2016 (UTC)
    Verdy p Sorry to say, but most of what you say is utter nonsense. Why don't you just read #STICKY: Explanation of format constraints above before speculating? -- Gymel (talk) 23:15, 4 March 2016 (UTC)
    Non-sense ? Look more precisely... (http://tinyurl.com/hnarckw link to SPARQL query) You'll see I'm correct here. Those RLM are there and returned by SPARQL which does not match the expected regexps (unless I add "\u200F?" in the regexps !). Verdy p (talk) 23:25, 4 March 2016 (UTC)
    Obviously at 23:15 I did not comment on your contribution from 23:23 but on what you had been writing above. -- Gymel (talk) 22:28, 5 March 2016 (UTC)
    I looked at the history of those items, I saw that RLM were initially added the first time, then removed later (you can see that in diffs). Apparently, SPARQL does not consider the last version of a property, but randomy uses any version found (possibly in a cache, but this cache is extremely long to expire and get purged from its LRU list...) and stops there. In other words, SPARQL does not reflect the current state of the database (even if it indicates that it has all updates since the last one or two hours: these corrections were made long before). This may also explain why we see old data' everywhere when navigating in Wikidata.
    Something is wrong in the management of internal cache for WDQS... or in how it retrieves the data (probably a filter of items by their most recent version is missing when looking for properties of an item). This not only affects interactive queries, but also the navigation on the website (old data displayed including on the Wikidata website itself), and also all data extractions (export as RDF, Turtle, etc.). Verdy p (talk) 00:00, 5 March 2016 (UTC)

    Unique value constraint and gender specific valuesEdit

    Hi! @Gymel , @Kolja21 There are a lot of gender specific pairs:

    What are the impacts of this:

    a) for Wikidata
    b) for the authority control templates using one parameter value only

    related impactsEdit

    1) Is there a symmetrical counterpart of field of this occupation (P425) ?
    2) Are part of (P361) and has part (P527) to be used at pages as philology (Q40634) ? see: DNB search: Philologie

    לערי ריינהארט (talk) 07:41, 12 March 2014 (UTC)

    First of all, even when there is a process of identification between wikidata entries, wikipedia articles and GND records, there is no necessity to transport the relations between these objects between the different systems.
    Second: Your examples illustrate the issue that it has probably not been very wise to extend the Normdaten/Authority-control templates from persons to concepts: For the latter in many cases it would have been more appropriate to supply wikipedia categories (instead of articles) with the identification with GND concepts
    More specific: Since the GND as a 'document language' knows about the female terms of most professions and the German Wikipedia does not (uses redirects to the generic masculine) and other Wikipedias also don't (e.g. because their respective languages don't have female forms for many nouns) and Wikidata does not (yet) even cover wikipedia redirect pages there certainly is an "impact" everywhere.
    For reasons not clear to me librarians tend to view everything in terms of part-whole relations. Wikidata objects however are instances or classes and their relations are recorded by distinct properties, cf. Help:Basic membership properties. Specifically philology (Q40634) relates by "subclass of" to sub- and superordinate concepts.
    For GND persons (and to a lesser extent for corporate bodies) a "field of activity" has traditionally been of interest. How this was modeled in the data however has undergone several changes. IIRC currently the first profession given should be very broad and give an indication of the "field of activity". However the GND makes no attempt to assign a broad "field" to individual professions (but the underlying DDC-like "GND classification" may serve a similar purpose). -- Gymel (talk) 10:16, 12 March 2014 (UTC)
    Thanks for the answer! These days I have seen some (broken) {{PLURAL:foo}} wiki code in the help for "aliases". {{GENDER:foo}} might come also.
    Personally I think as a practical "workaround" one should only import / add male forms of GND authority identifiers. Not sure if beside actor (Q33999) there are more gender forms in English (except the girl / boy, sister / brother etc. pages. לערי ריינהארט (talk) 13:00, 12 March 2014 (UTC)
    Quoting a recent contribution in a librarian's discussion list [3]: "Actor" is almost a unique case. [...] I’ve met females who act who call themselves actresses, and I’ve met those who see the term as demeaning and prefer actor. Also note "actor / actress" as the english label for actor (Q33999). Thus:
    • items are usually neutral or include all genders
    • since there exists a dedicated property sex or gender (P21), all other properties should be choosen "abstracted from gender", i.e. should take a neutral item as value (because of the previous point there is seldom a choice at all) to achieve "orthogonality"
    For non-items or "external items" as in authority control it is probably the best to adapt that strategy: stick to the generic masculine and completely ignore female forms since they usually are not an alternative but a specialization / "narrower term" and therefore as match not as close as the male form. -- Gymel (talk) 22:33, 12 March 2014 (UTC)
    Hmm - I agree that it makes sense to use gender-agnostic items in Wikidata. However, GND took another course. They definitivly do not use the female form as a specialization, but as an alternative - so on their side no "generic masculine" exists. Ignoring this has negative consequences for applications, which use the mapping: Using Wikidata as starting point and searching for persons described by a "male" GND profession, the application will miss the females. Using GND as a starting point, no mapping exists for the female form.
    So what exactly are the problems in using an approach which maps a Wikidata item to two alternative GND targets, qualified by gender? (example in social scientist (Q15319501)) Jneubert (talk) 18:30, 13 December 2015 (UTC)
    Jneubert Quite an old thread you have been commenting on... I think for GND one has to regard several sub-applications:
    1. "Als Homonymenzusatz bei Personenschlagwörtern zugelassen" means that the female form as a text fragment is permissible in constructing headings
    2. As subject heading when cataloging objects: Appropriate if and only if sex or gender aspects of specifically woman scientists are in the focus of the publication. This is clearly much narrower in scope than the male term (which is also to be applied if sex or gender questions are not involved)
    3. As indication of profession for other GND records (i.e. persons): I just checked, for the profession data element indeed chooses the "female" profession for female persons. How one will ever be able to select all social scientists with that approach unfortunately eludes me: The reciprocal relation between the two professions is quite unspecific.
    So by listing both GND numbers in social scientist (Q15319501) we equate the two for our purposes (which is correct in a sense) since P227 indicates a 1:1 correspondence between Wikidata item and target record. On the other hand we can argue that there is a distinction between the two concepts and Wikidata is just unable (or unwilling) to represent one of them. Or perhaps the Wikidata item represents the union of the two and therefore none of them is appropriate for P227 of our item? -- Gymel (talk) 00:25, 14 December 2015 (UTC)
    Note: social scientist (Q15319501) is for male and female like "Sozialwissenschaftler", GND 4140123-2 is used for males and females. Proof: Kristen Kreider, weiblich, Sozialwissenschaftler (GND 1068218916). --Kolja21 (talk) 13:51, 17 December 2015 (UTC)

    constraint report relating to Wikimedia disambiguation page (Q4167410)Edit

    If instance of (P31) is a Wikimedia disambiguation page (Q4167410) the presence of GND ID (P227) is prohibited

    see: Wikimedia disambiguation page (Q4167410) with GND identifier (P227) . Usualy there might be more possibilities:
    a) Please identify the non - ambiguation page (WD item) where the property GND 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) (recomended method:) 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 (disambiguation) descriptions after the disambiguation page is separated: Verify the descriptions for the following languages: de, en, fr, es, pt, pt-br, ru, sv which where added by bots long time ago and take a short look at the other language descriptions.
    c) If method b) can not be used because all linked WMF-project language pages are (local) disambiguation pages please create a new WD item and add a proper description in your native language and in English.

    Thanks in advance! gangLeri לערי ריינהארט (talk) 13:29, 27 May 2014 (UTC)

    Three items seem to persist at Wikidata:Database reports/Constraint violations/P227#.22Conflicts_with.22_violations and IMHO cannot be resolved here without at least some intervention in individual wikipedias:
    1. treaty of the European Union (Q11122): some Wikipedias seem to understand this as the treaty of Maastricht with its later amendments (treaty of Lisbon, ...), some others however also include the treaty of Rome (with its companion treaties) under this heading and therefore tend to declare themselves as disambiguation pages.
    2. asymmetry (Q752641): disambiguation property declared by french wikipedia by an article already narrowed to "geometrical" aspects. Comparing the extent of the articles in the other wikipedias there is not much common ground anyway.
    3. list of wars involving Israel (Q623900): Although German wikipedia enumerates the individual conflicts I would not consider it a typical list article. Separation from the other wikipedias however would not be an improvement I think. -- Gymel (talk) 08:26, 4 June 2014 (UTC)

    Sorry, to late (I didn't read this talk page in the morning), these three cases have been already resolved. list of wars involving Israel (Q623900) = is a list of (P360) Q17126147. The German article looks more like a list but the Arabic WP has a "real" article about this topic. --Kolja21 (talk) 00:59, 5 June 2014 (UTC)

    What's type n?Edit

    Hi,
    I wanted to add a GND identifier to an item (actually I did, see Gunnar Wöbke (Q1554803)), but the description here says "(please don't use type n = name, disambiguation)". This confuses me, what is meant with "type n = name, disambiguation"? From the examples it looks like type n is where it says in the RDF representation: "<rdf:type rdf:resource="http://d-nb.info/standards/elementset/gnd#UndifferentiatedPerson"/>"

    For "real" persons it would say "DifferentiatedPerson" there, is that meant with not-type n? --Bthfan (talk) 22:11, 7 July 2014 (UTC)

    @Bthfan: Exactly. The record stands for an unknown number of individuals known by that name and therefore cannot be used to identify a single person. -- Gymel (talk) 08:09, 10 July 2014 (UTC)

    Isn't type n appropriate for Wikimedia disambiguation pages?Edit

    I quite agree that differentiated GNDs must not be used on "Wikimedia disambiguation page (Q4167410), Wikimedia category page (Q4167836), Wikimedia list article (Q13406463)".

    However, undifferentiated GNDs (type=n) quite closely match Wikimedia disambiguation pages. Does the above prohibition mean that we DON'T want such GNDs in wikidata at all? --Vladimir Alexiev (talk) 07:53, 19 December 2014 (UTC)

    de:Peter Müller would be an example: The disambiguation page lists some Peter-Paul and Peter Erasmus Müller who perhaps actually never were called "Peter" (the undifferentiated record would never tell, since "Peter Erasmus" is definitely not a form of reference for all Peter Müllers it is or should be prohibited). The set of persons in the disambiguation page may have an nonempty intersection with those meant by an authority record, but usually is neither a subset or superset: We may know about some Peter Müllers they don't know about (and perhaps never will) and vice versa. Furthermore, the disambiguation page lists the individuals, we know about individually (with the exception of redlinks perhaps), whereas the undiffereniated name records stands for the complementary set of (names of) persons the libraries do not know individually (at the moment), so usually you cannot navigate to (library items already assigned to) individual authority records by accessing the undifferentiaded record. Thus I would think both concepts have in common that they somehow deal with a group of people with common formal characteristics (their name), but the purpose and definition for this clustering generally do not have much in common. -- Gymel (talk) 09:46, 19 December 2014 (UTC)
    @Vladimir Alexiev: Yes, we don't want such GNDs in Wikidata at all. Tn's are temporary numbers. They are placeholders and will be deleted or (this was common till 2012, now with so many libraries and archives taking part in the project it's rare) individualized and turned into a Tp. --Kolja21 (talk) 11:21, 19 December 2014 (UTC)

    P31:Q5 and Type NEdit

    Hello everyone,

    at the request of Kolja21 my bot fetched a list of (for the beginning a few) entries with instance of (P31) human (Q5) and Type N GND ID (P227) information. You can find this list in the bot's user namespace User:KasparBot/GND Type N.

    Regards, -- T.seppelt (talk) 06:24, 19 September 2015 (UTC)

    SSLEdit

    Currently the formatter url uses http and redirects to a https connection. Is there a reason not to link the target directly? --- Jura 11:47, 3 December 2015 (UTC)

    "Funktioniert nur eingeschränkt. Fehlermeldung Firefox: 'Dieser Verbindung wird nicht vertraut.'" = https makes problems with at least some browsers. It produces error messages. We had a simular discussion @User talk:Pasleim#Property:P1630 and a revert with the reason: "weak certificates". --Kolja21 (talk) 03:04, 5 December 2015 (UTC)
    It's different. New formatter URL would be https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D$1
    It works quite well. --- Jura 06:47, 5 December 2015 (UTC)
    I think we should stick to the canonical URLs employing d-nb.info as advertized by "Link auf diesen Datensatz" (link to this record) and not substitute that by some search query for the identifier in the Library catalogue portal.dnb.de, even if that can be performed by https. -- Gymel (talk) 20:21, 6 December 2015 (UTC)
    It's not "some search query", but the https-URL preferred by d-nb.info and where it redirects. It just saves users a non-SSL step in the chain. --- Jura 11:23, 7 December 2015 (UTC)
    http://d-nb.info/gnd/2072525-5 redirects to https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D007223358. So it's a different domain and a different kind of identifier (ILTIS PPN vs. GND Id). Indeed https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D2072525-5 also gives the same result but IMHO this may change any time without notice (may I repeat that http://d-nb.info/gnd/2072525-5 is the only form advertised by the record itself). So if you insist on providing https URLs resorting to letting the identifers point to https://archive.org or https://google.com seems a safer bet than trying to outsmart data providers. -- Gymel (talk) 16:44, 7 December 2015 (UTC)
    The best to do is to contact "d-nb.info" admins asking them to setup an equivalent HTTPS server in their domain.
    They will still continue to redirect us to another HTTPS URL in another domain, which also uses another identifier.
    So we would query "https://d-nb.info/gnd/2072525-5<nowiki>" with exactly the same response as "<nowiki>http://d-nb.info/gnd/2072525-5", but this time its resulting redirect would be secured (and not spoofable).
    This could also secure us if we create in Wikimedia lots of links to d-nb.info via the GND identifiers: at least the resulting redirect to another domain would be less suspect (imagine that someone spoofs queries to the existing HTTP server or monitors it for unfair actions, by harvesting some routers...
    Some wellknown ISPs are also unfairly redirecting some wellknown unsecured domains or modify the contents returned to include advertizing, or that are redirecting their users to an unrelated website....
    With HTTPS we would know that we are effectively querying the actual webserver for the domain "d-nb.info" and not a malicious one.
    An unfair ISP will not be able to redirect an HTTPS server: as soon as the SSL session starts being negociated, the ISP cannot spoof the authentic response (using fake/stolen SSL certificates?), it can only:
    • route the unmodified query to the real site and return unmodified results, or
    • block immediately the connection (returning an HTTPS error status), or
    • reroute the HTTPS query to another HTTP or HTTPS domain of his choice (using another certificate for this domain), such as a "parking page" or a "web search helper" page displaying various ads.
    Explain this risk of website spoofing to d-nb.info admins: may be they will also setup HTTPS on their existing website, and it will be the preferred URL we will use here. All websites with large audience and contents related to lots of topics should use now SSS (See the campaign "HTTPS everywhere" that Wikimedia also strongly supports, notably since the "Snowden revelations" about NSA activities, including large-scale spoofing/monitoring of various wellknown websites). This should be the case of such reputed knowledge authorities (spoofing its website could be profitable and damaging to people, if this is used to get and verify details about someone listed in GND). Verdy p (talk) 20:19, 4 March 2016 (UTC)
    The url suggestedmentioned by Gymel would probably work best as an intermediary solution.
    --- Jura 06:35, 5 March 2016 (UTC)
    Actually I suggested using Google for looking up GND identifiers if using https connections has top priority over all other concerns. -- Gymel (talk) 06:59, 5 March 2016 (UTC)
    Sorry, changed it to "mentioned by Gymel".
    --- Jura 07:01, 5 March 2016 (UTC)
    @Gymel, Jura1: The following may be of interest. As of now, it appears that a URL of the format http://d-nb.info/gnd/$1 generates an 301 Moved Permanently redirect to a URL of the format https://d-nb.info/gnd/$1. The HTTPS URL has the same domain and identifier. For example, http://d-nb.info/gnd/2072525-5 generates a 301 Moved Permanently redirect to https://d-nb.info/gnd/2072525-5 which generates a 303 See Other redirect to https://d-nb.info/gnd/2072525-5/about/html which generates a 302 Found redirect to https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D007223358.
    In addition, regarding third-party formatter URLs, it appears that a URL of the format http://opacplus.bsb-muenchen.de/search?pnd=$1 generates a 301 redirect to a URL of the format https://opacplus.bsb-muenchen.de/search?pnd=$1. For example, http://opacplus.bsb-muenchen.de/search?pnd=118584596 generates a 301 redirect to https://opacplus.bsb-muenchen.de/search?pnd=118584596 which generates a 302 redirect to https://opacplus.bsb-muenchen.de/metaopac/search?pnd=118584596.
    --Elegie (talk) 10:58, 21 November 2017 (UTC)
    Indeed, https://www.ssllabs.com/ssltest/analyze.html?d=d-nb.info looks encouraging. And Jura1 already has entered the https formatter URL as being of preferred rank. Whereas the catalogue itself still advertises the http URL as _the_ "link to this record" and will probably continue to for a very long time, since this URL also happens to coincide with the semantic web URI of the RW entity). -- Gymel (talk) 20:28, 21 November 2017 (UTC)
    @Gymel, Jura1: With regard to the third-party formatter URL http://opacplus.bsb-muenchen.de/search?pnd=$1 for the Bavarian State Library, would it be possible to change the URL to use HTTPS instead of HTTP or to add an entry for the HTTPS version of the URL (see my previous comment about the URL redirecting)? Thanks. --Elegie (talk) 10:16, 22 November 2017 (UTC)
    Elegie I have no opinion here because I have no idea why of all the hundreds of websites you can feed selected GND numbers into and get some meaningful result, the BSB catalogue was choosen (does support only the GND identifiers for persons, usually does not provide information about that person). This property feels to mike like an attempt to generate en:Special:BookSources automatically from Property:P212? -- Gymel (talk) 18:33, 23 November 2017 (UTC)

    Identical GND IDEdit

    New report by KrBot: Wikidata:Database reports/Identical GND ID. --Kolja21 (talk) 17:08, 7 December 2015 (UTC)

    portal.dnb.de gives an errorEdit

    For now i can formater URL gives:

    Leider ist ein Fehler aufgetreten.
    Unable to invoke request

    @Gymel: Can we fix it? -- Sergey kudryavtsev (talk) 07:20, 15 May 2016 (UTC)

    Sergey kudryavtsev No, their catalogue (including other services) seems to be completely offline since some time last night. Let's just hope they'll notice it before Tuesday (tomorrow is an holiday in Germany). -- Gymel (talk) 08:35, 15 May 2016 (UTC)

    @Gymel: The portal.dnb.de working for now! -- Sergey kudryavtsev (talk) 13:24, 15 May 2016 (UTC)

    @Sergey kudryavtsev, Gymel: The server is working, but some of the new GNDs added this weekend are missing.
    Example: Jamala (Q2662517), GND 1100357025 "404 NOT FOUND" - PICA works fine
    BTW: Monday is a national holiday, correct, but that's no reason to work on Tuesday ;) Tuesday is a local holiday called Wäldchestag (Q1605844) (Day of the forest). --Kolja21 (talk) 19:54, 15 May 2016 (UTC)
    @Kolja21: Oh, Eurovision contest... ;-) -- Sergey kudryavtsev (talk) 06:42, 17 May 2016 (UTC)
    PS: DNB already knowns Jamala (Q2662517) «gewann für die Ukraine den Eurovision Song Contest 2016 in Stockholm». -- Sergey kudryavtsev (talk) 06:50, 17 May 2016 (UTC)
    @Sergey kudryavtsev: How comes that User:Kolja21 could know about the existence of 1100357025 when it was neither queryable nor visible? Hint: de:Portal:Bibliothek, Information, Dokumentation/Normdaten/GND-Kooperation ;-) -- Gymel (talk) 18:35, 17 May 2016 (UTC)

      Done Server is up again and running without errors. All new GNDs are online. --Kolja21 (talk) 11:41, 16 May 2016 (UTC)

    GND ID count by GND Ontology classEdit

    gndoClass gndCount wdCount percentage
    UndifferentiatedPerson 6653723 6244 0.1 %
    DifferentiatedPerson 4250785 402239 9.5 %
    CorporateBody 1383591 24381 1.8 %
    ConferenceOrEvent 655032 489 0.1 %
    TerritorialCorporateBodyOrAdministrativeUnit 184343 33180 18.0 %
    MusicalWork 162166 1836 1.1 %
    Work 139868 5574 4.0 %
    SubjectHeadingSensoStricto 135435 17131 12.6 %
    SeriesOfConferenceOrEvent 124043 304 0.2 %
    OrganOfCorporateBody 110727 1430 1.3 %
    BuildingOrMemorial 63958 3713 5.8 %
    NomenclatureInBiologyOrChemistry 30665 2036 6.6 %
    PlaceOrGeographicName 24996 1134 4.5 %
    Family 18924 914 4.8 %
    NaturalGeographicUnit 17589 2577 14.7 %
    AdministrativeUnit 11826 2317 19.6 %
    SubjectHeading 8788 94 1.1 %
    SoftwareProduct 7997 376 4.7 %
    Language 5703 605 10.6 %
    ProductNameOrBrandName 5548 356 6.4 %
    HistoricSingleEventOrEra 5183 508 9.8 %
    WayBorderOrLine 4583 443 9.7 %
    Manuscript 4420 117 2.6 %
    EthnographicName 4186 239 5.7 %
    RoyalOrMemberOfARoyalHouse 2963 2011 67.9 %
    VersionOfAMusicalWork 2950 4 0.1 %
    ReligiousTerritory 2847 130 4.6 %
    ProvenanceCharacteristic 2024 0 0.0 %
    CharactersOrMorphemes 1936 21 1.1 %
    NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit 1821 169 9.3 %
    MeansOfTransportWithIndividualName 1372 130 9.5 %
    ProjectOrProgram 1350 20 1.5 %
    LiteraryOrLegendaryCharacter 1313 491 37.4 %
    CollectiveManuscript 1264 3 0.2 %
    Collection 1068 3 0.3 %
    MemberState 579 297 51.3 %
    Gods 546 440 80.6 %
    CollectivePseudonym 513 49 9.6 %
    GroupOfPersons 344 30 8.7 %
    Country 327 238 72.8 %
    ExtraterrestrialTerritory 261 128 49.0 %
    Spirits 99 7 7.1 %
    FictivePlace 28 3 10.7 %
    FictiveCorporateBody 18 0 0.0 %
    FictiveTerm 1 0 0.0 %

    As of 2017-10-08 (WDQS) and 2017-08 (GND dump). Jneubert (talk) 09:15, 8 October 2017 (UTC)

    Thank you for the list. BTW: UndifferentiatedPerson (Tn) should not be used. These numbers are only placeholders similar to disambiguation pages, see User:KasparBot/GND_Type_N. --Kolja21 (talk) 15:33, 29 May 2018 (UTC)

    Update: As of 2018-07-27 (WDQS) and 1806 (GND dump) -- Jneubert (talk) 06:21, 30 July 2018 (UTC)

    The results were obtained by this federated SPARQL query on our experimental GND endpoint. Jneubert (talk) 12:23, 18 October 2018 (UTC)

    Update: As of 2018-11-21 (WDQS) and 2018-10 (GND dump) -- Jneubert (talk) 12:34, 21 November 2018 (UTC)


    Fixing "single value constraint" violation by indicating time spanEdit

    There are several entries in Wikidata that have two corresponding entries in GND, e.g. administrative areas that were incorporated by another administrative area have two GND entries – one before and one after incorporation – but in Wikidata they usually only have one entry. Often it is made clear in the Wikidata entry when the status/type of the item changed (which correlates with the minting of a second GND ID). See these three examples: Eilendorf (Q1304021), Rodenkirchen (Q885372), Roman Catholic Archdiocese of Paderborn (Q253765). I have thought about fixing violations in such entries by using start time (P580) and end time (P582) as separators. But in my understanding, these would refer to the time span when one identifier was used for the entity and not the time span in the existence of the entity the identifier applies to. Right? If this is so, how could I indicate in another way for which time span in the existence of the entitay the identifier applies? Acka47 (talk) 10:59, 23 January 2019 (UTC)

    @Acka47: we are also running in a single value constraint for professions, in all these cases where the GND knows two items, one for men, one for women. e.g. political scientist (Q1238570). --Mfchris84 (talk) 22:21, 18 March 2019 (UTC)
    In both cases - Eilendorf (Q1304021) and political scientist (Q1238570) - I would use the qualifier stated as (P1932). Adding the time would be great but it is more complicated and often the GND does not have an exact information on start time (P580) and end time (P582). --Kolja21 (talk) 01:49, 19 March 2019 (UTC)
    @Kolja21: Thanks! This makes sense and is really helpful. Acka47 (talk) 10:09, 20 March 2019 (UTC)

    Parasynonyme (fr) / Quasisynonym (de)Edit

    For subject headings the GND uses quasi-synonym (Q2122467) what is useful for libraries but does not fits to Wikidata. Example:

    How should we mark these kind of duplicates?

    book publishing company (Q1320047)
    GND ID (P227): 4063004-3
    1. Qualifier stated as (P1932): Verlag
    2. Qualifier criterion used (P1013): quasi-synonym (Q2122467)
      or mapping relation type (P4390): quasi-synonym (Q2122467) ≈ related match (Q39894604)

    @Zolo, Jneubert, Emu, Wurgl: Any suggestions? --Kolja21 (talk) 04:10, 19 July 2019 (UTC)

    @Kolja21: I wonder if there is any virtue in using these at all. The subject heading (Schlagwort) part of GND always seemed to be pretty broken to me (it actually becomes more and more broken, I am told), there isn’t much to be gained from reproducing this mess in Wikidata … --Emu (talk) 21:52, 21 July 2019 (UTC)
    Lieber @Emu: Da stimme ich dir zu, und aus diesem Grund habe ich Sachbegriffe bislang auch weitgehend ignoriert. Aber die GNDs Typ s werden nun mal aus deWP hierher importiert und tauchen in den Dublettenlisten auf, daher sollte man eine einheitliche Lösung (P1013 vs. P4390) finden. BTW: Im Moment sitze ich gerade an der Liste Wikidata:WikiProject Authority control/Tn. Dort sind die Personen aufgeführt, zu denen Tns vorlagen, die per Bot gelöscht wurden. In vielen Fällen gibt es parallel einen gültigen Tp; aber danach hat der Bot nicht gesucht. Fröhliches Schaffen --Kolja21 (talk) 22:11, 21 July 2019 (UTC)
    Hi @Kolja21: we've also suffered from this problem in STW Thesaurus for Economics (Q26903352) and other vocabularies linked from it - a nasty example was given here on the pub-thes W3C mailing list. There was no real consensus on how to deal with that situation in the SKOS community. In the end, we defined a custom property zbwext:altLabelNarrower, in order to at least being able to mark such situations (recognition however still is intellectual work). I'd suggest not using mapping relation type (P4390), which was intentionally restricted to the defined set of SKOS relations, but criterion used (P1013), as you suggested. --Jneubert (talk) 15:02, 25 July 2019 (UTC)

      OK Thanks for your feedback. I've updated Help:P227. --Kolja21 (talk) 19:19, 25 July 2019 (UTC)

    Deprecate Tn claims; which "reason for deprecation" qualifier?Edit

    There are meanwhile more than 1000 Tns in Wikidata again, so apparently users are still importing those ones from somewhere. I can batch-deprecate all of them to avoid another re-import, and add a reason for deprecation (P2241) qualifier. However, which value would be appropriate for this qualifier? Simply incorrect identifier value (Q54975531) would be possible, but somewhat meaningless. Do we have something more specific? —MisterSynergy (talk) 20:21, 1 August 2019 (UTC)

    I believe that Tns don’t fit any of the criteria in Help:Deprecation, so in theory they should just be deleted periodically. But as you said, they keep being added. The problem with incorrect identifier value (Q54975531) is that the wording does not convey any information about the real reason for deprecation to an unfamiliar user. Wouldn’t it be best to create a new item for “undifferentiated [in the sense of GND or LCCN]“ and use this? --Emu (talk) 21:49, 1 August 2019 (UTC)
    Shouldn't be necessary since DNB announced yesterday the deletion of all Tn records by June 16, 2020. -- Gymel (talk) 19:19, 29 August 2019 (UTC)
    I support Emus idea to create a new item for "undifferentiated". Even if the DNB will delete all Tns June 2020 (what I doubt), these IDs will still remain in other datebases for years, if not for decades. Though the qualifier should only be added if a source is given; otherwise I would just delete the Tn. BTW: The list Wikidata:WikiProject Authority control/Tn is quite helpful for maintenance. --Kolja21 (talk) 00:00, 1 September 2019 (UTC)
    Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P227&oldid=1006129424"
    Return to "P227" page.