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
Corresponding templateTemplate:GND (Q23719249)
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 361 others)
See alsoDeutsche Biographie (GND) ID (P7902), Sächsische Biografie (GND) ID (P1710), Kalliope-Verbund (GND) ID (P9964), DDB person (GND) ID (P13049), 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
    Total3,235,430
    Main statement1,908,274 out of 9,499,173 (20% complete)59% of uses
    Qualifier10<0.1% of uses
    Reference1,327,14641% 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 of statement has role (P3831) person (Q215627) Mark Twain (Q7245): subject named as (P1810): Twain, Mark
    + object of statement has role (P3831): pseudonym (P742)
    object of statement has role (P3831) corporate body (Q106668099);
    more precise: museum (Q33506)    		 Panorama Mesdag (Q1738414): museum in the Hague
    object of statement has role (P3831) work (Q386724) Q110996824: no description
    object of statement has role (P3831) geographical feature (Q618123) Tomb of the Scipios (Q1540716): subject named as (P1810): Rom / Scipionen-Grab
    + object of statement has role (P3831): cross-reference (Q1302249)
    object of statement has role (P3831) term (Q1969448) / topical term (Q115439461) book publisher (Q1320047): subject named as (P1810): Verlag
    + object of statement has role (P3831): quasi-synonym (Q2122467)
    object of statement has role (P3831) architectural structure (Q811979)
    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 of statement 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)
     
    Maintenance lists for GND ID (P227)
    Wikidata
    Database reports
    Property talk:P227
    /human
    faulty
    /wanted
    Help
    Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
    List of violations of this constraint: Database reports/Constraint violations/P227#Entity types, hourly updated report
    Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
    List of violations of this constraint: Database reports/Constraint violations/P227#Scope, hourly updated report, SPARQL
    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" is incompatible with "mandatory" parameter List of violations of this constraint: Database reports/Constraint violations/P227#Conflicts with P31, hourly updated report, 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
    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, Q110551885, Q7377, Q192874, Q178, Q877546, Q123168143
    List of violations of this constraint: Database reports/Constraint violations/P227#Unique value, SPARQL (every item), SPARQL (by value)
    Conflicts with “DNB edition ID (P1292)”: 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).
    List of violations of this constraint: Database reports/Constraint violations/P227#Conflicts with P1292, search, SPARQL
    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.)

    International
    National
    (VIAF part.)
    National
    (other)
    Academics
    Artists
    Politicians
    Monuments
    Other
    Non-people


    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:

    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]

    Constraint violation: item requires statement violation

    [edit]

    Seit einiger Zeit lassen sich GND-IDs per HarvestTemplates

    nicht mehr importieren, es kommt die Fehlermeldung "Constraint violation: item requires statement violation".

    Möglicherweise seit dieser Änderung (@Kolja21: zur Info):

    Als Workaround kann das Ergebnis von HarvestTemplates heruntergeladen, in Excel/Open/LibreOffice umformatiert (mit =VERKETTEN("""";C1;"""") für die Hochkommata) und per QuickStatement importiert werden. Beispiel:

    M2k~dewiki (talk) 12:04, 24 May 2024 (UTC)[reply]

    Danke für den Hinweis. Ich habe die Ergänzung rückgängig gemacht. --Kolja21 (talk) 12:55, 24 May 2024 (UTC)[reply]
    Was war das Ziel der ursprünglichen Änderung? M2k~dewiki (talk) 12:58, 24 May 2024 (UTC)[reply]

    Possibly wrong merges in GND

    [edit]

    Found via https://www.wikidata.org/w/index.php?title=Special:Contributions/MsynBot&target=MsynBot&offset=20240627115603

    1. Toeplitz, Erich (1896-1933, art historian) Q94849144 GND 117393134 redirect to GND 121234533 which is stored at Q7032717 Toeplitz, Erich/Uri (1913-2006, flautist) ----
    2. Sellheim, Hugo* Friedrich Alexander 1843-1908 Q126905171 GND 1225558190 redirect to GND 117474606 which is stored at Q1439564 1871-1936, German professor of gynecology and obstetrics

    What to do? BergwachtBern (talk) 16:49, 28 June 2024 (UTC)[reply]

    Hallo @BergwachtBern: Fehlerhafte Zusammenführungen sind der GAU bei der Normdatenwartung. Du kennst de:WP:GND/F. Dort (oder besser, da schneller, per Kontaktformular) können solche Fehler gemeldet werden. Die GND-Zentralredaktion macht erfahrungsgemäßig fehlerhafte Zusammenführungen nicht rückgängig, sondern legt im Fall von Erich Toeplitz vermutlich eine neue GND für den Kunsthistoriker an. --Kolja21 (talk) 16:11, 29 June 2024 (UTC)[reply]
    GAU und demotivierend. Die beiden Fälle waren jetzt nicht so schwierig, wie konnte das passieren? Meldung per Kontaktforumular erfolgt. Bin gespannt, ob es rückgängig gemacht wird oder einfach ein neuer Datensatz angelegt wird. Im zweiten Fall dürfen dann einige externe Nutzer falsch zusammengeführter IDs an ihren Datensätzen basteln. BergwachtBern (talk) 17:25, 29 June 2024 (UTC)[reply]
    Danke für die Meldung an die DNB! Bin auch gespannt. Über den Grund der fehlerhaften Zusammenführung kann ich nur spekulieren, da GND 117393134 nicht im Webarchiv enthalten ist. (Mal hat sich jemand verklickt, mal war ein Datensatz schwach individualisiert etc.) So ein Fehler kommt zum Glück äußerst selten vor. --Kolja21 (talk) 22:16, 29 June 2024 (UTC)[reply]
    Vielleicht lässt sich über ISIL des letzen Bearbeiters etwas finden. Falls obige beide und nachfolgende Hirschberg alle eine ISIL tragen, die vor allem nicht von der GND-Oberdirektion selbst stammt... Sellheim und Hirschberg haben einen BHK-Bezug, beide im BBLD enthalten. Vielleicht hat deren Redaktion falsch zusammengeführt. BergwachtBern (talk) 22:24, 29 June 2024 (UTC)[reply]

    More:

    1. Q114568402 Hirschberg-Pucher, Eugenie GND 1238185843 redirects to GND 125197071, originally:
      1. GND 125197071 Hirschberg, Eugenie, 1882-, dissertation in Berlin 0000000014167064, now at Q126928075,
      2. GND 1238185843 Hirschberg-Pucher, Eugenie, 1862-1937, poet, spouse of GND 123818569X, husband now at Q126928176,
        1. VIAF: https://viaf.org/viaf/22162842331573042588/#Hirschberg,_Wulf_1858- DNB add 2021-08-08, data of 2021-08-04 (20210804142414.0) https://viaf.org/processed/DNB%7C123818569X http://web.archive.org/web/20240628214243/https://d-nb.info/gnd/123818569X/about/lds
        2. Wikimedia 2022-10-10 WD item created by Ploni and 2022-10-12 en-article by Plonie https://en.wikipedia.org/w/index.php?title=Eugenie_Hirschberg-Pucher&action=history
      husband's GND ends in 69(X), wife in 84(3), so only 13 (70-83) numbers between them. Also https://viaf.org/viaf/50181944/ used to be about the chemist, but the ISNI 0000000014167064 was removed from the cluster 2021-07-19.
      Who merged these? BBLD since at least 2023 also uses the chemist's ID for the poet, earliest found 2023-12-03 https://web.archive.org/web/20231203015946/https://bbld.de/GND125197071 , maybe they initiated/performed the merge? In 2022 they used 1238185843 earliest 2022-05-24 https://web.archive.org/web/20220524160324/https://bbld.de/GND1238185843 latest 2022-10-24 https://web.archive.org/web/20221024173049/https://bbld.de/GND1238185843
      Was the merge done, simply because the names "Hirschberg, Eugenie" matched? I couldn't find any other fact that suggests they are the same.
      BergwachtBern (talk) 21:57, 28 June 2024 (UTC)[reply]
    Das kann ich nicht vollständig nachvollziehen. Auf den ersten Blick scheint es sich um Dubletten gehandelt zu haben, d.h. beide GNDs bezogen sich auf die Schriftstellerin, mit der fälschlich die Dissertation des Chemikers verknüpft wurde. (Offenbar ein Mann, da in Russland auf eine Knabenschule gegangen.) --Kolja21 (talk) 22:51, 29 June 2024 (UTC)[reply]
    Nein, beide Frauen 20 Jahre Altersunterschied, die Diss-Autorin 125197071 Hirschberg, Eugenie, 1882-, dissertation in Berlin 0000000014167064 - ist wohl nicht die Poetin 1238185843 1862-1937.
    Verheiratet sind die Poetin 1238185843 und der Arzt 123818569X - passt auch von den Nummern zusammen.
    Warum sollte Dissertations-Eugenie ein Mann sein? BergwachtBern (talk) 22:58, 29 June 2024 (UTC)[reply]
    Hab BV020402180 gefunden, danke. Da in Mitau geboren, könnte es sogar eine Tochter sein, die auf der Knabenschule gelernt hat, der Mann Hirschberg war ja Arzt, vielleicht hatte sie daher Interesse an Chemie. Oder eine weiter entfernte Verwandte, Hirschberg klingt nicht so selten. BergwachtBern (talk) 23:13, 29 June 2024 (UTC)[reply]

    GND info in VIAF, Zeit entspricht dem dcterms:modified in LDS:

    1. Toeplitz https://viaf.org/processed/DNB%7C121234533 20231220003026.0 ... 040 ‎‡a DE-101‏ ‎‡c DE-101‏ ‎‡9 r:DE-101‏ ‎‡b ger‏ ‎‡d 9999 ... 042 ‎‡a gnd1
      1. https://d-nb.info/gnd/121234533/about/lds dcterms:modified "2023-12-20T00:30:26.000"^^xsd:dateTime
    2. Sellheim https://viaf.org/processed/DNB%7C117474606 20231207120448.0 ... 040 ‎‡a DE-611‏ ‎‡c DE-611‏ ‎‡9 r:DE-611‏ ‎‡b ger‏ ‎‡d 2119 ... 042 ‎‡a gnd1
      1. https://d-nb.info/gnd/117474606/about/lds dcterms:modified "2023-12-07T12:04:48.000"^^xsd:dateTime
    3. Hirschberg https://viaf.org/processed/DNB%7C125197071 20240118135534.0 ... 040 ‎‡a DE-101‏ ‎‡c DE-101‏ ‎‡9 r:DE-101‏ ‎‡b ger‏ ‎‡d 3004‏ ‎‡e rda ... 042 ‎‡a gnd3
      1. https://d-nb.info/gnd/125197071/about/lds dcterms:modified "2024-01-18T13:55:34.000"^^xsd:dateTime

    https://sigel.staatsbibliothek-berlin.de/suche?isil=DE-101 - DNB , https://sigel.staatsbibliothek-berlin.de/suche?isil=DE-611 - Staatsbibliothek zu Berlin - Preußischer Kulturbesitz, Kalliope-Verbund @Kolja21: letzte Bearbeitung von Stellen mit bundesweiter Bedeutung. Was sie geändert haben, wohl nicht ersichtlich. WebArchive sollte mal die LDS-Seiten wegspeichern, das geht schnell, da nur Text. BergwachtBern (talk) 02:06, 30 June 2024 (UTC)[reply]


    @Kolja21: es ist bei Hirschberg gekommen wie du gesagt hattest, die Chemikerin hat seit gestern https://d-nb.info/gnd/1334537232 , in https://d-nb.info/gnd/1334537232/about/lds keine ISNI, die Chemikerin-GND https://d-nb.info/gnd/125197071 gehört nun weiter der Schriftstellerin. In https://isni.org/isni/0000000014167064 (Chemikerin) weiterhin verlinkt http://viaf.org/viaf/50181944 http://d-nb.info/gnd/125197071 http://www.worldcat.org/oclc/702405016 - Kannst du diese drei Verlinkungen dort bestätigen? Wenn du es bestätigt hast, würde ich eine Anfrage an ISNI stellen und dann in diesem Fall einmal nachverfolgen, ob ISNI auf Feedback hin etwas ändert. BergwachtBern (talk) 02:51, 2 July 2024 (UTC)[reply]

    Schön, dass es so schnell geklappt hat. Ich verstehe allerdings immer noch nicht, warum GND 1238185843 die Chemikerin gewesen sein soll. Der Eintrag im gelöschten VIAF-Cluster 12162842150673041884 lautet: GND 1238185843 Hirschberg-Pucher, Eugenie 1862-1937. Imho lag und liegt der Fehler (= Vermischung) nur bei OCLC und ISNI. --Kolja21 (talk) 03:32, 2 July 2024 (UTC)[reply]
    @Kolja21: 125197071 (9-stellige ID, verknüpft mir Dissertation) war die Chemikerin, man sieht es noch in ISNI, welches dem alten VIAF entspricht, ISNI hatte damals einfach von VIAF die Cluster kopiert. Das Ehepaar Hirschberg hingegen hat: Arzt 123818569X (69) und Poetin 1238185843 (84), die wurden praktisch gleichzeitig angelegt. BergwachtBern (talk) 13:07, 2 July 2024 (UTC)[reply]
    Bereits 2022 bezog sich die GND auf die Schriftstellerin, vgl. Archivversion vom 31.10.2022, nur die Dissertation war falsch verknüpft. Hochschulschriften sind generell nicht die Stärke der DNB. Offenbar ist man dort der Meinung, dass man diese Veröffentlichungen zwar sammelt, die Dokumentation aber Aufgabe der jeweilige Unibibliothek ist. --Kolja21 (talk) 17:02, 2 July 2024 (UTC)[reply]

    Sellheim auch neu: https://d-nb.info/gnd/1334536325 - für Toeplitz nichts gefunden. Bei Sellheim in LDS gndo:dateOfBirth "1843-06-09"^^xsd:date; gndo:dateOfDeath "1908-07-21"^^xsd:date . - das Geburtsdatum ist aber 1843-06-21 nach ISO/gregor. Kalender und die Notation der Quelle "Baltisches Biografisches Lexikon digital (BBLd) (Stand: 01.07.2024)" entspricht nicht der Liste der fachlichen Nachschlagewerke für die GND https://d-nb.info/1331882079/34 S. 920 "BBLD", so lautet es tausendfach in der GND. Wikidata ist da besser, referenziert Objekte per ID und nicht als Freitext. BergwachtBern (talk) 03:17, 2 July 2024 (UTC)[reply]

    Keine Ahnung, warum sich das BBLD jetzt auf seiner Homepage "BBLd" schreibt, während es im Fließtext weiterhin die alte Abk. verwendet. Ich habe den GND-Eintrag entsprechend korrigiert. Bislang sind in Wikidata 135 Nachschlagewerke erfasst, die für die Erstellung von Normdaten herangezogen werden sollen. Leider greifen auch Bibliothekare immer seltener auf sie zurück und begnügen sich mit Drag&Drop. --Kolja21 (talk) 03:56, 2 July 2024 (UTC)[reply]


    Beim Durchgehen der Umleitungen noch etwas: Aus Adolph wurde Adrien (https://www.wikidata.org/w/index.php?title=Q94870297&action=history) GND 1032010428 und 116068531 - Umleitung von https://d-nb.info/gnd/116068531 auf 1032010428, dort Adolph nicht erwähnt, ob korrekt zusammengeführt ist nicht überprüfbar. BergwachtBern (talk) 23:32, 3 July 2024 (UTC)[reply]

    In solchen Fällen schaue ich u.a. im KVK nach. Dort ist kein "Adolph Barthélemy" vermerkt, insofern gehe ich davon aus, dass "Adolph" die falsche Namensform war. Das Dictionnaire arabe-français (1935) wurde unter "A. Barthélemy" veröffentlicht. --Kolja21 (talk) 01:11, 4 July 2024 (UTC)[reply]
    KVK - nett, kannte ich nicht, oder wieder vergessen. Aber habe vorhin zwei GND-Dubletten der "ZB MED - Informationszentrum Lebenswissenschaften, Köln" (https://lobid.org/organisations/DE-38M) in WD eingetragen, waren zwei Promovierte, nun konnte ich hier eine Promotion finden, aber GND der Person nicht angebunden - kein Mangel von KVK, sondern wohl der Daten. BergwachtBern (talk) 02:41, 4 July 2024 (UTC)[reply]
    Meinst du August Hartmann (Q126906166): 1864-1893 mit GND 1229691014? Die BBLD-Importe enthalten leider kaum Informationen, nicht einmal ein Abrufdatum. Ich habe die gebräuchliche Namensform (so wie auf seiner Diss. angegeben), den Beruf und die biografischen Angaben nachgetragen. Hätten diese Informationen vorgelegen, wäre die DE-38M-Dublette vermutlich nicht angelegt worden. --Kolja21 (talk) 03:01, 4 July 2024 (UTC)[reply]
    Die Suche unter https://portal.dnb.de/opac/showNextResultSite?currentResultId=Hartmann%2C+and+August%26any%26persons&currentPosition=20 gibt nicht so viele Personen die in den 60er geboren sind (Diss.-Datum 1889), da ist er schnell zu finden. Man sucht nach August Hartmann, schränkt auf Personen ein, ergibt 75 Treffer, und klickt sich zum relevanten Zeitraum. In VIAF http://web.archive.org/web/20240704032158/https://viaf.org/viaf/69151352089852602680/ findet sich für die GND-ID dann sogar die Arbeit, verlinkt von NUKAT, unter dem gleichen Personennamen: NUKAT "Hartmann, August Peter Friedrich‏ ‎‡d (1864-1893)", GND "Hartmann, August Peter Friedrich‏ ‎‡d 1864-1893". NUKAT seit 2017 im Cluster, GND seit 2021. Interesanterweise war WKP auch drin, wurde aber gelöscht, also WD ID nicht so verlässlich. Mal sehen wann der neue WD-Satz auftaucht und was mit dem Cluster passiert, hoffentlich stört es nicht, dass "Peter Friedrich‏" nicht mehr im Hauptnamensfeld steht. BergwachtBern (talk) 17:49, 4 July 2024 (UTC)[reply]

    GND dubious genealogical information - father dead 1578 son born 1584

    [edit]
    1. Q109616997 father Lauterbeck, Georg Lebensdaten: -1578 https://d-nb.info/gnd/119344459
    2. Q126931712 child Lauterbeck, Wolfgang Lebensdaten: 1584-1637 https://d-nb.info/gnd/130341150

    BergwachtBern (talk) 00:34, 29 June 2024 (UTC)[reply]

    Item created in 2021 by blocked User:Matlin. I will look at this case later. --Kolja21 (talk) 16:24, 29 June 2024 (UTC)[reply]
    Danke! Das Item ist ja an sich OK, der Fehler ist in der GND. Vielleicht gibt es zwischen den beiden noch einen Georg oder Wolfgang. Für Georg gibt es noch GND (Umleitung) 1089797028, vielleicht war das der Vater und er wurde mit dem Großvater zusammengeführt. Der Abschnitt "Possibly wrong merges in GND" gibt ja Beispiele für offensichtlich unsinnige Zusammenlegungen, so etwas könnte auch hier passiert sein. Bei Wikidata sind Zusammenlegungen transparenter, in der GND sieht man alte Stände als Externer nicht. BergwachtBern (talk) 17:20, 29 June 2024 (UTC)[reply]
    Das stimmt. Bei der GND gibt es keine Versionsgeschichte, aber pro Jahr (bei rund 5.000 Meldungen auf WP:GND/F) gibt es nicht mehr als zwei, drei Fälle, in denen zwei Normdatensätze falsch zusammengeführt wurden. Bei Wikidata sind dagegen unter Property talk:P227/human/conflation bislang über 60 fehlerhafte Zusammenführungen dokumentiert; und das ist nur eine kleine Auswahl. --Kolja21 (talk) 23:14, 29 June 2024 (UTC)[reply]
    ✓ Done Kann sein, dass er einen Sohn namens Wolfgang hatte, aber in der Tat war das sicherlich nicht Wolfgang Lauterbeck (Q126931712): 1584-1637. Ich habe den Eintrag ersatzlos gestrichen. --Kolja21 (talk) 23:39, 29 June 2024 (UTC)[reply]
    "aber pro Jahr (bei rund 5.000 Meldungen auf WP:GND/F) gibt es nicht mehr als zwei, drei Fälle, in denen zwei Normdatensätze falsch zusammengeführt wurden" - unter den 5000 vielleicht nur zwei, drei, aber insgesamt? Ich habe bei der Durchsicht einiger Umleitungen, mind. drei dubiose Fälle an einem Tag gefunden. Wenn die GND transparenter wäre und man alte Daten inspizieren könnte, fände man vielleicht noch mehr. Aber das ist alles Spekulation, es ist eine Black-Box. BergwachtBern (talk) 00:16, 30 June 2024 (UTC)[reply]
    @BergwachtBern: Ganz so schlimm ist es nicht. Mit etwas Erfahrung kann man meistens erkennen, für wen die GND ursprünglich angelegt wurde. (Die Bibliothek steht bei VIAF in Feld 040.) Da du die Umlenkungen unter die Lupe genommen hast, haben wir jetzt das Soll für 2024 erfüllt ;) --Kolja21 (talk) 01:33, 30 June 2024 (UTC)[reply]

    Mathey, Charles Grégoire d. 1749 GND Wirkungsdaten: 1749-1765

    [edit]

    item in GND field contains a redirect, maybe problem result of a wrong merge?

    1. Q105086945 d. 1749
    2. https://d-nb.info/gnd/1050484231 Wirkungsdaten: 1749-1765

    BergwachtBern (talk) 20:53, 29 June 2024 (UTC)[reply]

    Es gibt drei GNDs für einen Kupferstecher dieses Namens, die sich eventl. auf zwei (oder auch drei) Personen beziehen: P227. LCAuth vermerkt: Thieme-Becker (under: Mathey, C.; engraver in Paris, ca. 1740; identical with Charles Grégoire Mathey; d. June 17, 1749 in Paris?). Ich habe den Fall via de:WP:GND/F an die Bayerische Staatsbibliothek gemeldet. --Kolja21 (talk) 00:02, 30 June 2024 (UTC)[reply]
    Danke! BergwachtBern (talk) 00:06, 30 June 2024 (UTC)[reply]

    Piotr Novak 2 ORCID aber eine GND 141626224 - und eine Umleitung

    [edit]

    Each has to do with Polska Akademia Nauk (Polish Academy of Sciences) and each studied mathematics at University of Warsaw

    1. Q91216745#P227 https://orcid.org/0000-0002-6519-004X https://d-nb.info/gnd/1026997364 as redirect to https://d-nb.info/gnd/141626224
      1. Len: Piotr Wojciech Nowak, Den: Polish mathematician
      2. https://orcid.org/0000-0002-6519-004X : Polska Akademia Nauk Instytut Matematyczny: Warszawa, PL
        1. Uniwersytet Warszawski: Warszawa, PL 2003-06 | Magister (Institute of Mathematics) Education Source: Piotr W. Nowak
      3. pl:Piotr_W._Nowak
    2. Q103833723#P227 https://orcid.org/0000-0002-9325-4493 https://d-nb.info/gnd/141626224 (inferred from matching ORCID iD in DNB)
      1. https://orcid.org/0000-0002-9325-4493 :
        1. "Piotr Nowak received his MSc and PhD degrees in mathematics (after completing master and doctoral studies) from the Faculty of Mathematics, Informatics and Mechanics, University of Warsaw, Poland. Then, he received his DSc degree (Habilitation) in computer science from Systems Research Institute, Polish Academy of Sciences. Main topics of his current research are: computation and stochastic modelling in finance and insurance; financial mathematics; insurance mathematics; stochastic analysis; stochastic integration; probability; measure theory; fuzzy sets theory; statistics."
        2. "University of Warsaw: Warsaw, PL 1988 to 1993 | Master of Science in Mathematics (Faculty of Mathematics, Informatics and Mechanics) Education Source: Piotr Nowak"

    BergwachtBern (talk) 22:52, 29 June 2024 (UTC)[reply]

    ✓ Done Zwei Personen mit dem gleichen Namen und der gleichen Tätigkeit sind ein Albtraum. GND 141626224 wurde für Piotr Nowak (Q103833723): researcher ORCID 0000-0002-9325-4493 angelegt (und später vermischt). Neu: GND 1334425426 für Piotr W. Nowak (Q91216745): Polish mathematician (1978- ). Den falsch verknüpften Titel (Large scale geometry), der "Schuld" an der Vermischung war, habe ich zur Umverknüpfung gemeldet. --Kolja21 (talk) 01:23, 30 June 2024 (UTC)[reply]
    Danke! BergwachtBern (talk) 02:27, 30 June 2024 (UTC)[reply]

    GND ID redirect into newer ID - leading to broken links

    [edit]

    http://web.archive.org/web/20240630151356/https://viaf.org/processed/DNB%7C1314907034 20240620081017.0 (040 ‡a DE-7‏ ‎‡c DE-7‏ ‎‡9 r:DE-601‏ ‎‡b ger‏ ‎‡d 8999‏ ‎‡e rda ... 042 ‎‡a gnd1) the older ID redirected https://www.wikidata.org/w/index.php?title=Q28359269&diff=2192201456&oldid=2192201185 and link from DtBio https://web.archive.org/web/20240630150818/https://www.deutsche-biographie.de/1194119484.html to BBLD 404.

    https://sigel.staatsbibliothek-berlin.de/suche?isil=DE-7 Niedersächsische Staats- und Universitätsbibliothek Göttingen [DE-7] - did they create the duplicate and later merged? Why didn't they re-use the older ID? BergwachtBern (talk) 15:21, 30 June 2024 (UTC)[reply]

    Es gibt Regeln für den Gewinnersatz (Körperschaften = ehemalige GKD; Geografika = ehemalige SWD), aber die betreffen nicht Personen. Meistens wird der ältere Datensatz genommen; warum das bei Reinhard Friedrich Hollmann (Q28359269) nicht der Fall war, kann ich nicht sagen. (Manchmal liegt es daran, dass mit dem einen Datensatz bereits Literatur verknüpft ist oder dass er mehr Informationen enthält. Es kann aber auch einfach Zufall sein.) In jedem Fall zieht DBio beim nächsten Update nach. --Kolja21 (talk) 21:15, 30 June 2024 (UTC)[reply]
    DtBio ersetzt, aber die Links zum Filmarchiv sind Schrott, weil DtBio eine eigene Umlenktabelle nutzt in dem noch die alte GND steht. Beim BBLD könnte DtBio auch täglich das BBLD-Beacon auslesen, macht DtBio aber nicht, daher dann wochenlang kaputte Links.
    Was ich hier halt seltsam finde, dass überhaupt ein neuer Satz angelegt wurde. Und BBLD hab ich schon einmal gesehen, wie eine GND umdefiniert wurde, erst war es Person X, dann umgedeutet in dessen Vater oder Sohn. Hatten vielleicht den gleichen Namen, mal sehen, ob ich den Fall nochmal finde. Das war eine gnd4 oder gnd3, und wohl von BHK-ISIL bearbeitet.
    Aber gut, nur als Notiz. Insgesamt ist die GND schon praktisch, schlimmer sind ja die Einrichtungen, die ihre Datensätze gar nicht GNDisieren. BergwachtBern (talk) 21:58, 30 June 2024 (UTC)[reply]
    Es ist in der Tat sonderbar, was die SUB Göttingen da produziert hat. (Leider ist die Bibliothek auch besonders stark bei schwach individualisierten Tps vertreten.) Und bitte nicht das Filmportal erwähnen. Da deren GNDs überwiegend Wirkungs- statt Lebensdaten enhalten, sind sie eine Fundgrube für Dubletten. 1.400 Einträge müssen per Hand überprüft werden, siehe Wikidata:Database reports/Constraint violations/P2639#"Unique value" violations. --Kolja21 (talk) 23:47, 30 June 2024 (UTC)[reply]
    1401 unique value violations, na gut, das kommt noch hinzu. Ich denke, das sollte das Filmportal lösen, sollen die alles ordentlich untersuchen und wo Person klar, eine GND anbinden.
    Hast Du schon das Kürzel MVB in ISNI-Daten gesehen? Ist mir erstmals in der vorigen Woche aufgefallen, aber ich schaue auch nicht so oft in ISNI. Das könnte bei allen Lebenden, die mit Medien Geld verdienen helfen, hoffentlich werden möglichst viele Filmpersonen mit ISNI ausgestattet. ISNI hatte ja einen sehr schlechten Start mit ihrer ISNI-Vergabe an VIAF-Cluster, schnell viele Nummern generiert, aber massenhaft vermischte Datensätze. Kompetenz ist da nicht soviel zu sehen gewesen. Allein schon ein "X" in der ID, bei einem internationalem Identifier, und dann auch gleich ein Fehler auf der Website bei ISNIs mit X - die Links wurden nicht aufgelöst. Man sah es kommen. Und führende Nullen in Excel.
    Zurück zu ISNI für Medien. DSGVO https://mvb-online.de/marken-und-produkte/isni/ueber-isni : "Der Betrieb des ISNI-Standards erfordert zwangsläufig die Sammlung und Pflege von personenbezogenen Daten." - wenn die Akteure nicht ihr Geburtsjahr preisgeben und möglichst nur einen Namen, bleibt es vielleicht weiter bei Ratespielen, welche Info zu welchem Satz gehört und ob Dubletten vorliegen. BergwachtBern (talk) 00:15, 1 July 2024 (UTC)[reply]
    Ich halte nicht viel von ISNI, da mir die Datenbank bislang nicht bei der Recherche geholfen hat. Anfangs wurden dort Fehlermeldung noch fleißig abgearbeitet; mittlerweile tut sich nicht mehr viel, siehe de:Diskussion:International Standard Name Identifier#Zukunft von ISNI. Imho ist Wikidata die bessere Alternative. Kolja21 (talk) 02:49, 1 July 2024 (UTC)[reply]
    Es ist unglaublich, wie schlecht ISNI gemanaged wird. Die Website für allgemeine Infos (ja guter Hinweis mit den Pressemitteilungen), die Datenbank in einem Frame in der allgemeinen Website, keine Möglichkeit zu Archivieren - was bei VIAF ja geht -, keine Rückmeldung nach Fehlermeldung. Habe dort ein paar gemeldet, aber nicht extra notiert, was schon gemeldet. Ja, Wikidata um Längen besser. Aber es gibt weniger Schutz vor komplettem Nonsens in Wikidata. In ISNI steht natürlich auch Unsinn, aber fester strukturiert. Und wer Lust hat, kann in Wikidata irgendwelche zufäilligen Objekte zusammenführen. Wikidata könnte noch viel besser sein. Beispiele:
    1. Bei X den Vater und die Mutter eintragen, dann könnte X automatisch bei den Eltern als Kind erscheinen. - Bearbeitungsaufwand halbiert
    2. Beim Zusammenführen könnten zwei Objekte nebeneinander gezeigt werden, je Property eine Zeile. - Man würde nochmals deutlich sehen, ob nicht doch etwas nicht passt, es könnte auch verlangt werden, dass der Typ (P31) gleich ist, keine Begriffsklärung mehr mit Menschen zusammenführen.
    Zum Glück ist die BL nicht die einzige die an ISNI arbeitet, um so mehr ISNI auch von anderen Nationalbibliotheken benutzt wird, um sehr mehr tritt vielleicht das Missmanagement zu Tage. Wikidata ist viel kleiner, in "2018-06-14_GND4Publisher.pdf" [7] von Jürgen Kett (Q115624645, soeben zusammengeführt, der alte Satz hatte weder GND noch ISNI, aber meine Einspielung hatte) und Alexander Haffner (Q126955169) steht "Bislang 2 Mio. GND-Personensätze in ISNI integriert" - Falls das ungefähr Mensch meint, dann zum Vergleich in Wikidata 2024-07-01 "Mensch mit GND und ISNI" https://w.wiki/AYAm : 938420 . Vielleicht fehlt teilweise in Wikidata nur die ISNI oder die GND, aber es sind weder 2 Mio GND-Menschen noch 2 Mio ISNI-Menscchen enthalten.
    Kett und Haffner weiter: "Jede GND-Person erhält zusätzlich eine ISNI" - das war 2018. BergwachtBern (talk) 17:26, 1 July 2024 (UTC)[reply]
    Das MVB-Objekt (Q1900665) war Vermischung mit Vorgänger. BergwachtBern (talk) 17:36, 1 July 2024 (UTC)[reply]
    Danke für die Erstellung von Buchhändler-Vereinigung (Q126955232). Die Trennung ist sinnvoll, es lag aber kein Fehler vor, da sich beide Einträge auf den gleichen Wikipediaartikel beziehen. BTW: Kennst du das Helferlein "GND reveal"? Damit kannst du mit einem Klick die Daten aus der GND importieren, siehe Help:P227, Abschnitt Gadget. --Kolja21 (talk) 19:07, 1 July 2024 (UTC)[reply]
    PS: Was ISNI betrifft, hat das Projekt die Erwartungen nicht erfüllt. Die beteiligten Bibliotheken investieren daher keine Arbeit mehr in die Datenpflege, und ich vermute, die Datenbank wird langfristig eingestellt. --Kolja21 (talk) 19:17, 1 July 2024 (UTC)[reply]
    "Die beteiligten Bibliotheken investieren daher keine Arbeit mehr in die Datenpflege" - hast du das irgendwo gehört, oder/und gibt es dazu irgendwas Öffentliches? BergwachtBern (talk) 19:54, 1 July 2024 (UTC)[reply]
    Nein, ich bekomme nur keine Rückmeldungen mehr und sehe auch keine Fortschritte. --Kolja21 (talk) 04:05, 2 July 2024 (UTC)[reply]
    Keine Rückmeldung bei Meldungen über das ISNI-Feedback-Formular? Bei mir ist das nämlich so, meinst du das? Früher kam da noch Rückmeldung. BergwachtBern (talk) 13:11, 2 July 2024 (UTC)[reply]
    Genau das. Ich kann mich dunkel erinnern, dass früher Institutionen wie die British Library und die Bibliothèque nationale de France auf meine Anfragen über das ISNI-Feedback-Formular geantwortet und die Fehler innerhalb weniger Tage korriert haben. Kolja21 (talk) 16:32, 2 July 2024 (UTC)[reply]
    Danke! Und danke auch für den Hinweis auf "GND reveal" - schau ich mir demnächst einmal an. BergwachtBern (talk) 17:08, 2 July 2024 (UTC)[reply]

    Copy paste chaos from EADB-GND to DtBio, FactGrid

    [edit]

    Fehler in Wikidata in Verbindung zwischen EADB und GND, dank irgendwelchen automatischen Tools. Aber!: Genauso in DtBio und FactGrid. Schreiben die hier einfach ab??? Unglaublich.

    1. https://www.wikidata.org/w/index.php?title=Q26222280&action=history - Bartels
    2. https://www.wikidata.org/w/index.php?title=Q55193410&action=history - Johann Georg Wagner
    3. https://www.wikidata.org/w/index.php?title=Q94784029&action=history - Adolf Meyer
    4. https://www.wikidata.org/w/index.php?title=Q94927764&action=history - Christian Schmidt

    BergwachtBern (talk) 01:33, 2 July 2024 (UTC)[reply]

    Die Daten in Dt.Bio werden in der Tat automatisch mit der GND abgeglichen. Fehler bitte auf de:WP:GND/F melden. FactGrid nutze ich nicht. Da kennt sich User:Kresspahl aus. --Kolja21 (talk) 04:30, 2 July 2024 (UTC)[reply]
    FactGrid ist ein Wikibase Datenrepositorium in Kooperation mit der DNB und Teil von NFDI4Memory. Es greift als "start-up" für seine Projekte einerseits auf Datensätze aus wd zurück und nutzt andererseits die in wd gespeicherten Metadaten mit. FactGrid ist also insbesondere bei den Metadaten etwas flacher angelegt und beschränkt sich neben der GND auf wenige Identifyer, die vom individuellen Forschungsinteresse des Nutzers geleitet sind. Bei den obigen Beispielen ist ein gewisser Zusammenhang mit dem kürzlich erfolgten upload von Personendaten der Amburger Datenbank bei FactGrid erkennbar. In dem Zuge wurde begonnen, sukzessive ca. 100K Personen mit GND und wd maschinell wie händisch abzugleichen bzw zu verifizieren. Bei diesen "Osteuropa-Daten" ist die notwendige Überwindung von Sprach- und Schriftgrenzen eine der Hürden, bei denen ein ständiger Abgleich mit wd sehr hilfreich sein kann. Kresspahl (talk) 08:50, 2 July 2024 (UTC)[reply]
    "Kooperation mit der DNB" - werden denn zumindest einige EADB-Datensätze durch FactGrid mit GND-IDs versehen? Die Arbeit geschieht also anscheinend in WD - freiwillig, unbezahlt - und FactGrid kopiert einfach, hat anscheinend nicht einmal eine Expertise für /diese[] "Osteuropa-Daten"/ aber ist staatlich gefördert?
    "Überwindung von Sprach- und Schriftgrenzen eine der Hürden, bei denen ein ständiger Abgleich mit wd sehr hilfreich sein kann" - welche Sprach und Schriftgrenze hier einschlägig sein soll ist unklar. Die Daten zu den vier Personen sind ausschließlich in deutscher Sprache in lateinischer Schrift in EADB hinterlegt. BergwachtBern (talk) 12:58, 2 July 2024 (UTC)[reply]
    @Kolja21: Einen Fehler in der GND sehe ich nicht. Reinheitsgebot hat zu den ersten beiden GND-Menschen 2019 und zu den letzten beiden 2020 EADB-IDs eingetragen (2019 EADB ID korrigiert durch Magnus Manske) 1 2 3 4 . Olaf Simons hat dann am 13. März 2024 1 2 3 4 FactGrid-Ids mit temporary_batch_1710344355361 hinzugefügt.
    Ein Mehrwehrt von FactGrid, wenn FactGrid einfach eine Kopie von einigen Daten aus EADB und der GND-ID aus WD ist, ist nicht einmal ansatzweise erkennbar. Im Gegenteil, es entsteht zusätzlicher Aufwand, nicht nur in FactGrid, sondern auch in WD wegen FactGrid. BergwachtBern (talk) 12:45, 2 July 2024 (UTC)[reply]
    Das ist ein spannendes Thema. @Kresspahl: Danke für die Info! @BergwachtBern: Bei meiner täglichen Arbeit beschleicht mich das gleiche Gefühl. Es wird mehr kopiert als korrigiert, und "Zusatzangebote" wie Dt.Bio und CERL erhöhen den Wartungsaufwand. Aber das ist die Sicht eines traditionellen Geisteswissenschaftlers, ausgehend von den klassischen, intellektuell bearbeiteten Normdaten. Angesichts der Masse an Daten (und der Frage, wie man sie für die Forschung nutzbar machen kann), sollte man Projekte wie FactGrid ernst nehmen. Kolja21 (talk) 16:17, 2 July 2024 (UTC)[reply]
    Ich habe bei Ignatius Aber (Q126957937) die FactGrid-Objektkennung, incl. Dublette, eingetragen. @Kresspahl: Hat das Folgen? D.h. werden die Dubletten via Wikidata erkannt und zusammengeführt? Kolja21 (talk) 16:42, 2 July 2024 (UTC)[reply]
    @Kresspahl, Kolja21: es wäre praktisch, wenn zumindest die Dubletten eine GND-Kennung erhielten. Dann hat man einen weitgehend stabilen unique identifier. Bei den EABD-IDs ist das ja nicht der Fall und falls die EADB-Macher zusammenführen, weiß auch niemand in welche Richtung. Black Box. BergwachtBern (talk) 18:35, 2 July 2024 (UTC)[reply]
    Im Fall der Erik-Amburger-Datenbank kann man Wikidata und FactGrid als unique identifier nutzen, so wie bei Ignatius Aber geschehen. Bei der GND sehe ich im Moment keinen Anlass, Einträge aus der Erik-Amburger-Datenbank zu übernehmen, solange kein Material zu der betreffenden Person vorliegt. Kolja21 (talk) 18:52, 2 July 2024 (UTC)[reply]
    Danke! Verstehe. Neulich die eine Vermischung mit einer GND-Person, da stand zur EADB-Person wohl auch nur "Bäckermeister". Da gibt es sicher wichtigeres.
    Die Alternativen als IDs: bei Wikidata können leider sehr leicht Vandalen etwas ändern ansonsten wäre das natürlich sehr praktisch, und bei FactGrid wäre es wieder noch eine ID. Gäbe es bei Wikidata mehr Schutz vor Löschungen und Umwidmungen, dann wäre das wohl das derzeit beste System! Könnte man ISNI direkt abschaffen. BergwachtBern (talk) 19:13, 2 July 2024 (UTC)[reply]
    @Kolja21: Das ist mE derzeit nicht im Fokus der Regensburger, eher geht es um Fragen, wie man den string-Teil der alten Datenbank am Besten in wikibase extrahieren kann. Das ist auch ein Problem im Fokus von Berkeley im Zusammenhang von alten spanischen Handschriften, wo an einem Export von mehr als 400K Items gearbeitet wird. Insgesamt ist das ein Thema von Olaf Simons, also bitte da direkt nachfragen. Ich habe aber Ignatius Aber in FactGrid zusammengeführt. Dank für den Hinweis, aber wir haben davon noch etliche im Programm... FactGrid ist kein wd-clone, aber ausgeschriebene Persönlichkeiten werden der Einfachheit in dieser Aufbauphase geclont, um arbeiten zu können. Sie werden zB benötigt, um Persönlichkeiten ihres Umfelds beschreiben und einordnen zu können, die teilweise über keinerlei Metadaten oder eben nur über keine wd-Daten verfügen... Dazu jetzt bitte erstmal EoD; als Wikipedianer mache ich das übrigens ohne Bezahlung und habe daher auf den neidgeprägten Unsinn der Bergwacht als Fischkopf nicht die geringste Lust. Ein jeder pflege seine individuellen Vorurteile so gut er kann...--Kresspahl (talk) 17:57, 2 July 2024 (UTC)[reply]
    Ein weiterer Indiz für die Annahme, dass FactGrid im Bereich der EADB-Daten mehr Ärger schafft als Nutzen bringt. "als Wikipedianer" vollziehst du in FactGrid eine Zusammenführung nachdem hier in Wikidata eine Dublette markiert wurde. Veröffentlicht durch mich. Und schreibst "habe daher auf den neidgeprägten Unsinn der Bergwacht als Fischkopf nicht die geringste Lust" - hast du hier irgendwo Neid gesehen? Ich habe den Ignatius Aber auch ohne Bezahlung angelegt. Bitte schön. Tja, und im Datensatz in FactGrid hast du eingetragen " Career statement (P165): Surgeon (Q36526)" - aber "als Wikipedianer" nichts weiter in WD ergänzt. BergwachtBern (talk) 19:02, 2 July 2024 (UTC)[reply]

    Vorschlag zur Erhöhung der Datenqualität mit Bezug zu GND, EADB, BBLD

    [edit]

    Bzgl. weiter oben "Es wird mehr kopiert als korrigiert" - hier mal ein Vorschlag zur Erhöhung der Datenqualität: Wikidata:Property proposal/Imperial University of Dorpat student ID. Vorhin auch zwei GND für Menschen in WD vermerkt, die wohl wegen einer Dissertation angelegt wurden, aber die letztlich Dubletten sind, da für die Personen schon GND-Sätze existieren.

    1. Q126906166 August Hartmann, Matrikelnr.: 11255
    2. Q126906616 Otto von Essen, Matrikelnr.: 11132
    3. Q55856755 Linus Mitscherling, Matrikelnr.: 11288 (dritten Fund ergänzt) BergwachtBern (talk) 00:56, 5 July 2024 (UTC)[reply]
    4. (Q127078129 Eugen von Frey, Matrikelnr.: 10837, hier keine Feststellung als Dublette, weil wohl in GND noch nicht vorhanden, aber Geburtsjahr 1862, hingegen geben verschiedene Quellen Matrikel, Ärzte Livlands, Geni und NUKAT 1858 an. NUKAT ist mit derselben Hochschulschrift seit 2017-12-17 in anderem VIAF cluster.) BergwachtBern (talk) 01:28, 5 July 2024 (UTC)[reply]
    5. Q126907271 Heinrich von Holst, Matrikelnr.: 10292 (vierten Fund ergänzt) BergwachtBern (talk) 03:01, 5 July 2024 (UTC)[reply]
    6. Q126928176 Wulf/Wilhelm Hirschberg, Matrikelnr.: 10945 (fünften Fund ergänzt) hier die Promotion im Satz mit der niedrigeren Nummer, aber die Versionsnr. ist 20221004124436.0, das Level gnd6, der Satz mit der höheren Nummer hat niedrigere Versionsnummer 20210804142414.0 und gnd4. BergwachtBern (talk) 03:53, 5 July 2024 (UTC)[reply]

    Im BBLD wurde die Erfassung aller Studenten der Universität begonnen, aber es verschwinden seit einiger Zeit Studenten wieder aus der Datenbank. Sehr chaotisch. In EADB verschwindet wohl derzeit nichts, aber bearbeitet wird dort wohl auch nicht viel, es gibt Unmengen von Fehlern und eine Erfassung aller Studenten ist nicht erfolgt. Um dort einmal Stabilität hineinzubringen, mit einer ID die sich garantiert nicht ändert und die auch nicht zusammengelegt oder umgedeutet werden kann, bietet sich an die Matrikelnummer zu benutzen, aus einem Werk auf Papier, eingescannt und mit Log-in direkt in Estland einsehbar. Weniger Chaos, mehr Qualität. BergwachtBern (talk) 02:52, 4 July 2024 (UTC)[reply]

    Ich habe die Abk. EADB unter Erik Amburger database (Q64584900) ergänzt. (Verwechslungsgefahr mit der Onlineausgabe der bekannteren ADB.) Was die Matrikelnummer der Univ. Dorpat betrifft, lässt sie sich nicht mit der Datenbank verlinken und die Datenbank ist auch nicht frei zugänglich. Dein Beispiel: Gustav Petersen (Q16403105) hat bislang keine Beschreibung. Ergänzungsmöglichkeit: educated at (P69) + catalog code (P528) = Matrikelnummer (wobei die später angelegte Eigenschaft membership number (P11327) vermutlich besser gewesen wäre). Diesen Eintrag kann man in die Liste der Studenten einbinden. Beispiel: Spalte "Enrollment ID" in Wikidata:University of Tübingen/Listeria/UTübingen alumni (born before 1800). Kolja21 (talk) 18:43, 4 July 2024 (UTC)[reply]
    Danke für EADB-Ergänzung. Für jede Studentenmatrikel eine eigene Property anlegen ist wohl etwas umständlich, historisch habe ich nur zwei für Helsinki gefunden. Ist unpraktisch, dass nicht jeder Benutzer externe ID properties für solche Standardfälle selbst anlegen kann. Die Tübingen-Liste ist super! Ein Problem mit "membership number (P11327)" für eine Universität - es kann mehrere geben, einmal als Student und einmal als Mitarbeiter. Eine eigene Eigenschaft für die Studenten-Matrikelnummer einer Universität kann das besser klären. Ausserdem kommt sie im Fall der Kaiserl. Univ. Dorpat (KUD), auch in anderen Werken vor. Wenn man dazu etwas schreibt, könnte man die Property um die Matrikelnr. wiederzugeben, bei der anderen Methode geht das so nicht. Zur Datenbank kommt man mit entgeltfreiem Anmelden. Ca. die Hälfte der IDs fällt in die deutsche Zeit, dafür gibt es Album Academicum der Kaiserlichen Universität Dorpat (Q127052492) erschienen 1889, ohne einloggen bei der BSB erhältlich. Man könnte noch die Seitennummern aus dem Buch eintragen, also bei der externen ID ein "stated in" book... page ... . Das Digitalisat der eigentlichen Matrikel ist nicht notwendig. BergwachtBern (talk) 19:07, 4 July 2024 (UTC)[reply]

    @Kolja21: Schön, dass Uni Rostock auch eine property hat. Da kann ich vielleicht auch noch mit Daten helfen. Bei der Uni Straßburg gibt es wie bei Dorpat/Tartu auch Probleme, Suche nach Universität Straßburg in WD bringt mehrere Personen die vor 1918 einen Abschluss machten, aber es steht dann im Eintrag ein Link zur französischen Uni, mehrere die ich gesehen habe, hatten als Referenz das MathGenProject. Habe ich für eine Person bearbeitet bearbeitet https://www.wikidata.org/w/index.php?title=Q102234654&diff=2196216184&oldid=2046328918 . Vielleicht gibt es noch andere Universitäten an Orten, die die staatliche Zugehörigkeit wechselten, und bei denen es ähnliche Probleme gibt, im deutschsprachigen Bereich fällt mir als erstes Prag ein, aber mit "Students of Prague Universities ID" (Property:P8953) gibt es einen Link zu einem externen Projekt, welches laut Beschreibung mehrere dortige Universitäten abbilden möchte, da gibt es dann hoffentlich professionelle Informationen an welcher Uni eine Person war.

    Wenn Du für Tübingen auch eine eigene property möchtest, würde ich dies unterstützen. Im Gegensatz zu Wackel-IDs in WD - irgendwelche privaten Online-Datenbanken mit ID, die inzwischen offline sind oder in einer Dekade offline sein werden - sind Studentenmatrikelnummern aus der Vor-Digitalzeit wohl eine stabile Angelegenheit.

    Bei Wikidata:Property proposal/Imperial University of Dorpat student ID momentan keine weitere Aktivität. Wäre es möglich diese heute noch anzulegen? Ich könnte dann sofort ~8500 IDs einspielen, wenn man sieht wie andere Properties über lange Zeit bei Minimalbefüllung verharren, ist das hier eine ganz andere Nummer. Ggf. könnte ich auch für sämtliche Studenten bis #14331, also die im Album Q127052492 mit BSB-Kopie vorhandenen, einen Eintrag anlegen, dann ist das einmal erledigt und wenn damit verbunden Dubletten zusammengelegt werden, ist die Matrikelnummer schon vorhanden und eine falsche Uni-Zuordnung kann einfacher entdeckt werden. BergwachtBern (talk) 17:09, 6 July 2024 (UTC)[reply]

    Bitte etwas Geduld. Aus gutem Grund muss die Anlage von Eigenschaften umständlich beantragt werden. Eine Woche sollte man schon warten, damit sich jeder, der es möchte, in Ruhe äußern kann. --Kolja21 (talk) 20:50, 6 July 2024 (UTC)[reply]

    Hochschulschriften ohne Personendetails

    [edit]

    Konrad Fraenkel (Q127071872) - laut Geni ein Sohn von Albert Fraenkel (Q91335), aber im dewiki-Artikel ist er nicht erwähnt, dort für den Vater Albert nur ein anderer Sohn und ein Schwiegersohn. Habe in KVK die Schrift gelistet gesehen, aber kein Digitalisat gefunden in dem vielleicht noch mehr zur Person steht. BergwachtBern (talk) 00:01, 5 July 2024 (UTC)[reply]

    Daten-Probleme via BBLD/BHK

    [edit]

    Beispiel GND-Dublette angelegt Q109812389 Körber, Johann Georg v. (1795-1820), beide Verweisen im Feld 998 auf Q109812389

    1. https://web.archive.org/web/20221117163650/https://viaf.org/processed/DNB%7C105249899X - gnd6 , Versionsnr. 20221024160311.0,
    2. https://web.archive.org/web/20221117163517/https://viaf.org/processed/DNB%7C1268939749 - gnd4 , Versionsnr. 20220927103847.0, ISIL https://sigel.staatsbibliothek-berlin.de/suche?isil=DE-2813

    Beispiel falsche Geni http://web.archive.org/web/20240701062941/https://bbld.de/GND1197235892 - http://web.archive.org/web/20240705211509/https://www.geni.com/people/Michael-Reusner/5379552171650079341

    1. Geburt - weder Tag noch Ort stimmen zwischen Geni und BBLD überein
    2. Tod - weder Jahr noch Ort stimmen zwischen Geni und BBLD überein
    Ergo, ID für andere Person. Damit WD vor einem Fehlimport von dort geschützt ist, habe ich Michael Arnold Reusner (Q127161197) angelegt. --BergwachtBern (talk) 21:26, 5 July 2024 (UTC)[reply]
    Wenn ich das (nach mehrmaligem Lesen) richtig verstehe, willst du darauf hinweisen, dass der BBLD-Eintrag für Michael Reusner (Q95317103): 1615-1750 via Geni.com auf einen Namensvetter verlinkt. Das wird klar, wenn man bei den betreffenden Personen das genaue Geburtsdatum einträgt. (Jetzt erl.) Kolja21 (talk) 14:27, 6 July 2024 (UTC)[reply]
    Sorry, dass ich es nicht verständlicher schrieb. Ja, im BBLD falsche Geni ID vermerkt. Kein Einzelfall.
    Beispiel falsche Geni Katterfeld
    1. Q55090265 https://web.archive.org/web/20240706033141/https://bbld.de/GND1044452706 Katterfeld, Traugott Christian Friedrich Ludwig* (1843-1910)
    2. dort Geni https://www.geni.com/people/Traugott-Katterfeld/6000000011469100854 Traugott* Christian Ludwig Katterfeld (1841-1903) --- das ist ein Bruder, nun unter Q127164960
    Beispiel falsche Geni Clodt von Jürgensburg
    1. Q126912380 https://web.archive.org/web/20240706155336/https://bbld.de/GND122744284X Clodt v. Jürgensburg, Elisabeth (1840-1917)
    2. dort Geni https://www.geni.com/people/Elisabeth-Juliane-Friederike-Clodt-von-J%C3%BCrgensburg/6000000015337968954 (1813-) --- das ist eine Schwester des Vaters, nun unter Q127165078
    BergwachtBern (talk) 16:06, 6 July 2024 (UTC)[reply]
    +1. Um Personen, die z.B. in VIAF vermischt sind, auseinander zu dröseln, ist Wikidata bestens geeignet. Trage aber bitte möglichst gleich das vollständige Geburtsdatum ein, sonst werden die betreffenden Personen auch hier verwechselt. Das Helferlein
    importScript( 'User:Bargioni/UseAsRef.js' );
    kennst du - oder? Kolja21 (talk) 16:20, 6 July 2024 (UTC)[reply]
    Ich werde vielleicht mal alle deine Skripte installieren, gnd reveal hattest du ja auch empfohlen, bisher noch keine Zeit gefunden. Beim Geburtsdatum bin ich jedoch absichtlich zurückhaltend und trage lieber nur das Jahr ein, denn dies ist bis auf ca. 11-13 Tage im Jahr (18., 19., 20. Jh.), gregorianisch und julianisch gleich. Bei Geni wird das nicht professionell betrieben, es steht dort in irgendeiner Form, es ist auch eine US-Website. Der von dir von Geni übernommene Wert ist z.B. julianisch, Quelle https://www.digitale-sammlungen.de/en/view/bsb00001251?page=8 rechte Spalte #100 "19. VII. 1841" - das Werk nutzt standardmäßig julianische Angaben. Angepasst [8]. BergwachtBern (talk) 16:48, 6 July 2024 (UTC)[reply]
    Beispiel falsche(?) Geni Carlblom, Eduard (1869-) und resultierend falsches Sterbejahr(?)
    1. Q126933310 http://web.archive.org/web/20240707021419/https://bbld.de/GND1218362979 - Carlblom, Eduard (1869-) - im Text dann noch + 1916 ggf. später ergänzt?
    2. dort Geni https://www.geni.com/people/Arthur-Carlblom/6000000018383527367 - Eltern passen, aber nirgends Eduard - + 1916 - von dort zu Eduard im BBLD kopiert? Es ist ja ausser dem Album Academicum und Geni keine Referenz angegeben. --BergwachtBern (talk) 02:23, 7 July 2024 (UTC)[reply]
    Beispiel falsche Geni Klot, Burchard v. (1892-1989)
    1. Q55236634 http://web.archive.org/web/20240707023428/https://bbld.de/0000000397509331 - Klot, Burchard v. (1892-1989)
    2. dort Geni https://www.geni.com/people/Wilhelm-Burchard-Nicolai-von-Klot/6000000018424550180 - Wilhelm* Burchard Nicolai von Klot (1884-1906) - das ist ein Bruder, nun unter Q127197913 --BergwachtBern (talk) 02:46, 7 July 2024 (UTC)[reply]
    Beispiel falsche Geni Heller, Johann Friedrich (1786-1849)
    1. Q12365203 http://web.archive.org/web/20240707032306/https://bbld.de/GND1195971141 - Heller, Johann Friedrich (1786-1849) - V.: Friedrich Wilhelm H., Kaufm. M.: Catharina, geb. (Laman? Loma?)
    2. dort Geni https://www.geni.com/people/Friedrich-Johann-Heller/6000000020529458324 - Friedrich Johann Heller (1719-1789) - Eltern: Georg Heinrich* Heller und Dorothea Elisabeth Frölich - nun unter Q127200179
    die beiden Geburtstage liegen ebenso wie die beiden Sterbetage mehr als 60 Jahre auseinander, bei den Vornamen der Väter sowie den Namen der Mütter gibt es keine Übereinstimmung --BergwachtBern (talk) 03:33, 7 July 2024 (UTC)[reply]
    Beispiel falsche Geni Adolphi, Friedrich 1829-1868 http://web.archive.org/web/20240708081111/https://viaf.org/processed/DNB%7C1216324387 Versionsnummer 20210302194059.0 DE-2813 stud. Dorpat
    1. Q126904715 http://web.archive.org/web/20240225111732/https://bbld.de/GND1216324387 Adolphi, Friedrich Wilhelm Carl (1829-1868) - "Wilhelm Carl"?
    2. dort Geni https://www.geni.com/people/Friedrich-Adolphi/6000000038455277738 Friedrich Wilhelm Carl Adolphi 1819- - das ist laut Geni ein Bruder. Von hier "Wilhelm Carl" zu BBLD kopiert?
    BergwachtBern (talk) 08:13, 8 July 2024 (UTC)[reply]

    Beispiel described by source BBLD (Q18616550) und im DBBL (Q50624788, Liste der fachlichen Nachschlagewerke "Dt.-balt. biogr. Lex.") enthalten

    1. Q1299451 https://www.wikidata.org/w/index.php?title=Q1299451&diff=prev&oldid=1639775710 - https://bbld.de/0000000081171741 - DBBL S. 244 - https://bbld.de/dbbl/244/
    2. Q4012 https://www.wikidata.org/w/index.php?title=Q4012&diff=prev&oldid=1667999557 - https://bbld.de/0000000032931302 - DBBL S. 621 - https://bbld.de/dbbl/621/

    Es gibt jeweils keinen Link. Eingetragen wurde beides im Mai und Juni 2022 von einem Benutzer der wohl für die BHK das BBLD verlinkt. Besser described by DBBL und Buchseite nennen? BergwachtBern (talk) 02:00, 7 July 2024 (UTC)[reply]

    Bei Herbert Girgensohn habe ich den Link nachgetragen, d.h. beide Quellen können stehen bleiben, auch wenn das BBLD hier INSI statt der GND verwendet. Da das BBLD allerdings in der Vergangenheit immer wieder seine IDs geändert hat und auch ohne Begründung Einträge entfernt (Beispiel: GND 1228071578), wurde die dazugehörige Eigenschaft auf Wikidata gelöscht. Kolja21 (talk) 16:09, 7 July 2024 (UTC)[reply]
    Laut https://web.archive.org/web/20240707231901/https://bbld.de/BBLd-ID gibt es für die BBLD IDs drei Quellen, mit jeweils einem Rang:
    1. "ISNI" - Rang 1
    2. "GND ID" - Rang 2
    3. "Meta-Daten" - Rang 3
    Es sieht so aus, als ob nur Wechsel im gleichen Rang erlaubt sind oder rangaufwärts, wobei Wechsel von GND zu ISNI wohl umgeleitet werden. Bei Herbert Girgensohn https://bbld.de/GND118695134 leitet um zu https://bbld.de/0000000081171741 . Ausserdem wurden wohl bis 2020-06-21 (http://web.archive.org/web/20240707232629/https://bbld.de/BBLd2020) alle Einträge mit GND-ID versehen, d.h. "in der Vergangenheit immer wieder seine IDs geändert hat" ergibt sich erstmal nicht aus der BBLD-Dokumentation. Da aber in der GND selbst Änderungen vorkommen, können natürlich auch Änderungen im BBLD erfolgen.
    Das komplette Löschen von Personen ist mir jedoch auch aufgefallen, danke für das Beispiel mit Carl Heinrich Niggol, dort immerhin vermerkt "BBLD (24.02.2021; zurückgezogener Identifikator): https://bbld.de/GND1228071578 " . Laut https://viaf.org/viaf/1878149544574000490009/#Niggol,_Carl_Heinrich,_1851-1927 History of VIAF ID:1878149544574000490009 gab es auch ein Q107-Objekt in WD (wohl GND-basiert), das wurde jedoch 2021-08-24 gelöscht. Wohl erst 2023-02-25 wurde die GND-ID per Bot wieder in WD aufgenommen [9]. Mir sind in den letzten Tagen mindestens ein Dutzend Q107-Löschungen aufgefallen. Das waren vor allem Fälle, für die ich Ende Juni GND-basiert Datenobjekte in WD angelegt habe. Davon waren anscheinend 2021 schon einige in WD.
    Unter https://web.archive.org/web/20240708000149/https://viaf.org/processed/DNB%7C1228071578 sehe ich "zurückgezogener Identifikator" nicht, hast du das in der GND ergänzt?
    Ich hatte auch Valentin Niggol (Q127005131) angelegt, ein Student an der Kaiserlichen Universität Dorpat und ein Sohn von Carl Heinrich. Unverständlich, warum Carl Heinrich Niggol gelöscht wurde. Im Mai 2012 https://bbld.de/BBLd2012 schrieb David Feest (Q83384705): "Neben weiteren Einträgen zu deutschbaltischen Biographien ist vorgesehen, auch Esten, Letten und Litauer in das Lexikon aufzunehmen - aus dem deutschbaltischen wird ein baltisches Lexikon." - Ab ca. 2019/2020 wurde wohl mit der Umsetzung begonnen, insbesondere gab es 2021 einen Zuwachs, ca. 1000 neue Personen inkl. GND-ID pro Monat, der wohl auch Nichtdeutsche umfasste. Sohn und Vater wurden beide im BBLD gelöscht. Der von dir bearbeitete Valentin ist ein weiterer Sohn, auch er studierte an der KUD [10]. BergwachtBern (talk) 00:34, 8 July 2024 (UTC)[reply]
    Wir hatten, wie schon erwähnt, sowohl in Wikipedia wie Wikidata, viele Probleme mit BBLD. Den Hinweis in GND 1228071578 ("zurückgezogener Identifikator") habe ich vorhin, nach Überprüfung der Daten, eingefügt. Kolja21 (talk) 02:35, 8 July 2024 (UTC)[reply]
    Danke für die Einfügung. Vielleicht sollte generell bei allen BBLD-Referenzen eine Überprüfung erfolgen. Es verschwinden dort seit über einem Jahren Einträge, es ist sehr chaotisch. BergwachtBern (talk) 10:27, 28 July 2024 (UTC)[reply]

    Zusammenlegung von GND 1024756246 und GND 1131823109

    [edit]
    1. https://isni.org/isni/0000000379828320 Dreilingk, Caspar - Titles: Theses de transactione. - Jena - Sources https://viaf.org/viaf/258309559 https://d-nb.info/gnd/1024756246
      1. https://d-nb.info/gnd/1024756246 Dreilingk, Caspar - Dreilingk, Casparus - Wirkungsdaten: 1597 - Geburtsort: Riga - Wirkungsort: Jena - Beruf(e) - Jurist - Respondent in Jena
    2. https://d-nb.info/gnd/1131823109 Dreyling, Caspar - Quelle HAAB Weimar Stb 339 - Lebensdaten: 1582-1631 - Geburtsort: Riga - aus Riga; 1603 in Köln nachgewiesen
      1. findet sich in http://web.archive.org/web/20240708064704/https://viaf.org/viaf/259149485948493422840/#Dreyling,_Caspar_1582-1631
      2. Feld 040 DE-32 https://sigel.staatsbibliothek-berlin.de/suche?isil=DE-32 Klassik Stiftung Weimar / Herzogin Anna Amalia Bibliothek [DE-32]

    ---

    1. https://www.digitale-sammlungen.de/en/view/bsb00001250?page=35 - S. 56, Nr. 15 - * 1572-10-24 Riga + 1631 (?) Kurland - stud. jur. Dr. zu Leyden 1600-07-04
      1. hier ist Jena nicht erwähnt
      2. dies entspricht https://www.geni.com/people/Dr-jur-Caspar-von-Dreiling/6000000010061325674

    Was sind die Belege dafür, dass es sich um die selbe Person handelt? Es kann ja stimmen, aber warum?

    User:Kresspahl hat

    1. 2024-07-05/06 in FactGrid https://database.factgrid.de/wiki/Item:Q952171 angelegt, mit GND 1024756246 und Geni 6000000010061325674
    2. danach in Wikidata https://www.wikidata.org/w/index.php?title=Q127162811&action=history mit Geni 6000000010061325674 ISNI 0000000379828320 GND 1024756246 GND 1131823109

    Etwas später wurde letzteres von User:Bernice Heiderman mit dem schon bestehenden Objekt Q126933120 mit GND 1131823109 zusammengelegt. Das war von mir angelegt, mit Lese-/Schreibfehler 1532 statt 1582. Wer 1582 geboren wurde, wie kann der 1597 Respondent in Jena sein? BergwachtBern (talk) 06:55, 8 July 2024 (UTC)[reply]

    @BergwachtBern: Ich war mir nicht sicher mit dem Merge. Hier ist ein allgemeiner Stammbaum der Familie Dreilingk / Dreyling.--Bernice Heiderman (talk) 12:16, 8 July 2024 (UTC)[reply]
    @BergwachtBern: 1572 (statt 1582) geboren und 1597 Respondent in Jena (Dr. jur.) schien mir plausibel. Aber wenn es Zweifel gibt, sollte man die Zusammenführung rückgängig machen und die beiden Datensätze mit "eventuell gleichwertig" verbinden. --Kolja21 (talk) 15:53, 8 July 2024 (UTC)[reply]
    Die Person aus SDBG/Geni ist auch nicht klar einer GND zuzuordnen.
    1. https://www.digitale-sammlungen.de/de/view/bsb00001250?page=35 Nr. 15
      1. Was bedeutet I. U. in "Stud. jur. I. U. Dr. zu Leyden 4. II. 1600"? Hat er ggf. 1597 einen Abschluss in Jena gemacht und 1600 einen weiteren in Leyden?
      2. 1605 OO T. v. Cord Diepenbrock (* Coesfeld, Westfalen)
    2. OGND 1024756246 https://swb.bsz-bw.de/DB=2.299//CMD?ACT=SRCHA&IKT=2999&NOABS=Y&TRM=1024756246 - gibt es das Werk irgendwo online?
    3. OGND 1131823109 https://swb.bsz-bw.de/DB=2.299//CMD?ACT=SRCHA&IKT=2999&NOABS=Y&TRM=1131823109 - 1603 Köln -
      1. Aufsatz: [Stammbucheintrag] : Köln : 11.09.1603 / Caspar Dreyling
      2. Autorin/Autor: Dreyling, Caspar, 1582-1631 [Verfasserin/Verfasser]
      3. Enthalten in: [Stammbuch Georg Christoph Volckamer] / Volckamer, Georg Christoph *1582-1632* . - [S.l.], [1601-1603]. - [1601-1603], Bl. 126 Sprache(n): Latein
    Ich habe die Quellen (https://www.wikidata.org/w/index.php?title=Q126933120&oldid=2198675957#P1343) erweitert, das jeweilige Publikationsjahr angegeben und chronologisch sortiert, die vierte (2018) stammt von User:Kresspahl, bei dieser konnte ich keine Online-Version finden und es ist auch keine vermerkt. @Kresspahl: hast du das Buch physisch vorliegen, oder gibt es das irgendwo online?
    Die Quelle 2 von 1884 listet ihn im Abschnitt "Rostock. Aelteste Matrikel von 1419—1760" (beginnt S. 24) unter 1600 April, verweist dabei auch auf die Quelle 1 von 1827. Und verweist auf Rostock 1600, http://purl.uni-rostock.de/matrikel/100015511
    Die Aussage zur Universität Leipzig, eingefügt von User:Kresspahl [11], ist im Datenobjekt unbelegt. @Kresspahl: kannst du eine Quelle ergänzen? BergwachtBern (talk) 18:35, 8 July 2024 (UTC)[reply]
    Ich bin mir ziemlich sicher, es ist derzeit alles richtig so. Insofern @Kolja: danke für den Hinweis, aber es ist alles ok so. In FactGrid gibt es jetzt auch den gleichnamigen Vater, zu dem die Grabplatte im Dom zu Riga gehört, eindeutig belegt durch die namentliche Erwähnung der Ehefrau. Angeregt wurde ich auf der Suche nach Kulturgut. Im Katalog der Rigaschen culturhistorischen Ausstellung [1883] wurden 24 Stammbücher aufgeführt. Das erste war ursprünglich Eigentum von Dr. Caspar von Dreiling mit einer Laufzeit von 1600 bis 1605, und gehörte wie die meisten der ausgestellten Stücke der Gesellschaft für Geschichte und Altertumskunde der Ostseeprovinzen Russlands (im Katalog mit "A.G." bezeichnet, bestand bis 1939), die anderen Leihgaben waren 1883 zumeist noch im Besitz von Familienangehörigen der ursprünglichen Stammbuchhalter. Ich arbeite das für mich grad in Factgrid auf. Eine Besonderheit von FactGrid ist, das ein wikidata-link in FactGrid vor Dubletten einen relativen Schutz gibt, weil kein zweiter Artikel mit der gleichen wd-Qnr. angelegt werden kann (Wikidata und GND sind die hauptsächlichen Identifyer bei FactGrid). Außerdem erleichtert diese Verbindung den künftigen wechselseitigen Datenaustausch, nicht nur, wenn man da an künftige Möglichkeiten mittels AI denkt, sondern auch schon jetzt. Und das geht jetzt schon, um der Sorge der Berwacht entgegen zu treten, schon deutlich in zwei Richtungen, hin wie her. Beispiele findet man zB bei der Fruchtbringenden Gesellschaft.--Kresspahl (talk) 18:09, 8 July 2024 (UTC)[reply]
    1. "In FactGrid gibt es jetzt auch den gleichnamigen Vater" - in WD auch, dank mir, denn hier hast du es nicht ergänzt. Ausserdem gab es in WD schon den Grossvater, den Urgrossvater, Ehefrauen dazu. Den Vater der Mutter habe ich nun ebenfalls angelegt. Q127271269 1055573011 6000000006351595037
    2. "Eine Besonderheit von FactGrid ist, das ein wikidata-link in FactGrid vor Dubletten einen relativen Schutz gibt" - aber in WD hattest du eine Dublette angelegt, damit wäre eine Dublette trotz dieser "Besonderheit" auch in FactGrid möglich gewesen.
    BergwachtBern (talk) 19:29, 8 July 2024 (UTC)[reply]
    Habe eben versucht, den 1582 geborenen Vetter Caspar Dreiling (Jurist und Ratsherr in Riga) anzulegen (Sohn des Ältermanns Melchior). Als ich fast fertig war, hat Bernice Heiderman die beiden Vettern wieder verschmolzen, wahrscheinlich ohne Text und Daten überhaupt zur Kenntnis zu nehmen.--Kresspahl (talk) 01:13, 9 July 2024 (UTC)[reply]
    "* 1582" war doch das von mir angelegte Datenobjekt Q126933120 basierend auf GND 1131823109? Sollte dies dann wieder hergestellt werden? BergwachtBern (talk) 02:00, 9 July 2024 (UTC)[reply]
    Und "* 1572" war das von Dir angelegte Q127162811? BergwachtBern (talk) 02:04, 9 July 2024 (UTC)[reply]
    Ich habe die in diesem Abschnitt beschriebene Zusammenlegung rückgängig gemacht und die alte Bedeutung für die Datenobjekte wieder hergestellt (die Datenergänzungen von Q126933120 nach Q127162811 verschoben, da muss vielleicht manches wieder weg), inkl. dem weiteren Objekt gibt es nun:
    1. Q126933120 1582-1631 angelegt von BergwachtBern basierend auf 1131823109
    2. Q127162811 1572-1631 angelegt von Kresspahl SDBG Nr. 15 6000000010061325674 inkl GND 1024756246 und GND 1131823109 - Vater Q127271156
    3. Q127272280 1582-1618 angelegt von Kresspahl SDBG Nr. 80 6000000181131717821 - Vater Q126906811
    In den Quellen gibt es u.a. 2 Personen in SDBG, 2 in GND. BergwachtBern (talk) 02:28, 9 July 2024 (UTC)[reply]

    @Kresspahl: kommt zu Q127272280 noch etwas? Es ist in dem Datenobjekt auch keine Aktivität von Bernice zu sehen ("Als ich fast fertig war, hat Bernice Heiderman die beiden Vettern wieder verschmolzen") @Bernice Heiderman: weißt du wovon Kresspahl redet? Kresspahl hat die Vermischung der beiden GND in WD in einem Datenobjekt erstmals vorgenommen, du hattest daraufhin zusammengeführt, da die eine GND schon in älterem Datenobjekt, einen Konflikt den Kresspahl so beließ. Aber, dass du "wieder verschmolzen" hast? Es fehlen auch bei diesem neuen Objekt reichlich Quellen. @Kresspahl, lieferst du noch Quellen zu den Studienbehauptungen? BergwachtBern (talk) 22:02, 9 July 2024 (UTC)[reply]

    @BergwachtBern: 3 Personen, wobei zwei davon 1582 geboren wurden mit identischer GND, wobei die GND bei Q126933120 die einzige Quelle ist. Das ist auf jeden Fall falsch. Kolja21 (talk) 15:24, 10 July 2024 (UTC)[reply]
    Drei sind schon richtig, aber es fehlt noch feintuning. Einmal Vater+Sohn und dann der 10 Jahre jüngere Vetter des Sohnes. Ich hatte auch erst gedacht Schreibfehler, aber die HAAB hätte bei Anlegung der GND gern etwas mehr Info zugeben dürfen (denn die muss sie gehabt haben...).--Kresspahl (talk) 17:25, 10 July 2024 (UTC)[reply]
    @Kresspahl: Ich blick' beim besten Willen nicht durch. Kannst du so nett sein, die Meldung an die BSB entsprechend zu korrigieren? --Kolja21 (talk) 20:19, 10 July 2024 (UTC)[reply]
    Ich überarbeite die drei am WE in Ruhe. Bitte etwas Geduld.--Kresspahl (talk) 00:23, 11 July 2024 (UTC)[reply]
    Vater und Sohn kommt bei Geburtsjahr 2x 1582 und 1x 1572 auch nicht hin, es sei denn einer wurde mit 10 Vater. BergwachtBern (talk) 20:48, 10 July 2024 (UTC)[reply]

    @Kresspahl, Kolja21: ich würde die Meldung an die BSB erstmal zurückziehen/pausieren. Könnte zu einer, oder sogar zu zwei, der Personen ein Wikipedia-Artikel angelegt werden? Eventuell sind ja auch in den Quellen Vermischungen aufgetreten. Dort, oder bei einem Familienartikel, kann dann nachhaltiger eine Dokumentation der Unterschiede erfolgen. https://www.digitale-sammlungen.de/de/view/bsb00001250?page=33 zeigt im Stammhaus 8x Caspar, 2x Joh. Caspar, 1x Caspar Joh. und in der Linie Melchior 3x Caspar. Die von Kresspahl erwähnten 3 sind wohl aus Gen. III die Nr. 7. und aus Gen IV die Nr. 15. und 80. In Gen III und IV gibt es jeweils noch einen Caspar. BergwachtBern (talk) 21:33, 10 July 2024 (UTC)[reply]

    Ok. Habe die Anfrage zurückgestellt. Kolja21 (talk) 21:40, 10 July 2024 (UTC)[reply]

    ISNI record contains DNB MVB but GND contains no ISNI

    [edit]

    example Q125499083:

    1. https://isni.org/isni/0000000445992453 - VIAF (http://viaf.org/viaf/314863727) DNB (http://d-nb.info/gnd/1067300376) MVB
    2. https://d-nb.info/gnd/1067300376/about/lds - owl:sameAs <https://orcid.org/0009-0005-5544-966X>; dcterms:modified "2024-05-24T22:00:59.000"^^xsd:dateTime; gndo:descriptionLevel <https://d-nb.info/standards/vocab/gnd/description-level#1> . owl:sameAs <http://viaf.org/viaf/314863727>, <http://www.wikidata.org/entity/Q125499083>; gndo:oldAuthorityNumber "(DE-588)1027796397"; owl:sameAs <https://d-nb.info/gnd/1027796397>; dnbt:deprecatedUri "https://d-nb.info/gnd/1027796397";

    Zghbv (talk) 15:28, 31 October 2024 (UTC)[reply]

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