User talk:Jneubert

I've added lately information about economists and their identifiers in various catalogs. Please let me know when you have comments.

Hello Jneubert, I write you because you created 40 items without any content. Those items I have deleted. I think you have misunderstood the QuickStatements tool. Perhaps next time you should try with one item only, just to see how it works out. But I see you have done more successful additions of items as well, so you might not need my advise... Good luck. Kind regards, Lymantria (talk) 06:52, 26 April 2017 (UTC)[reply]

Hi @Lymantria:, Thanks a lot for cleaning up! I accidentally did not replace delimiters when copy&pasting data from my linux terminal for these items, and was not aware that the CREATE statement worked despite anything else did not - sorry. Thanks again, Jneubert (talk) 07:26, 26 April 2017 (UTC)[reply]

No problem. :) Lymantria (talk) 07:32, 26 April 2017 (UTC)[reply]

Hallo Joachim, dein Botlauf hat offenbar mehrere Dubletten produziert. Kannst du bitte mal unter:

• Wikidata:Database reports/Identical GND ID#Can be merged

nachschauen? Pierre M. Picard (Q30073171) habe ich von Pierre Picard (Q30073175) getrennt (nur bei einem scheint der Mittelname "M." und die dazugehörige GND korrekt zu sein). Gruß --Kolja21 (talk) 15:48, 2 June 2017 (UTC)[reply]

Hallo @Kolja21:, vielen Dank für den Hinweis auf die Merge-Candidates-Liste, die kannte ich noch nicht. Auch die übergeordnete Seite Wikidata:Database_reports scheint einiges an verborgenen Schätzen zu bergen.

Im Konkreten habe ich keinen einfachen Merge-Fall gefunden, sondern ein erstaunlich vielfältiges Bestiarium. Es wäre klasse, wenn du da nochmal drauf schauen könntest (ich bin ziemlich neu in Wikidata, und viele Verfahrensweisen lerne ich erst Schritt für Schritt):

• Weißt du etwas genaueres über die Kriterien, nach der KRbot die Liste erstellt? (identical GND allein müsste gefühlt sehr viel umfangreicher sein)
• Bei der Disambiguierungsseite Richard Harris (Q438571) habe ich die GND gelöscht.
• Bei dem Bildhauer Peter Hayes (Q7174593), der offenbar über VIAF mit Peter Hayes (Q1703746) gleichgesetzt wurde, habe ich die GND durch "unknown value" ersetzt.
• Bei John B. Williamson (Q6220167) hat mein Bot anscheinend bei zwei Läufen die GND mit der für John Williamson (Q1347901) überschrieben (die du offenbar zwischenzeitlich schon händisch korrigiert hattest - sorry!). Das habe ich nun korrigiert, die VIAF-Cluster scheinen inzwischen auch ok zu sein.
• Bei John Hagan (Q6237200), der über eine falsche VIAF-ID mit John Hagan (Q1700343) gleichgesetzt war, habe ich VIAF- und GND-ID auf "unknown value" gesetzt. Zudem habe ich bei letzterem die korrekte VIAF-ID eingetragen und die dort schon eingetragene VIAF-ID (offenbar ein Dublette in VIAF) auf deprecated gesetzt - korrekt?
• Marcel Boyer (Q3288726) und M. Martin Boyer (Q30084289) sind offenbar zwei verschiedene Personen mit unterschiedlicher RePEc-ID und Publikationsgeschichte, die aber in der GND vermischt werden. (Einen ähnlichen, noch nicht korrigierten Fall von Vermischung scheint es bei Efthymios G. Tsionas (Q30071049) zu geben. Der von dir dankenswerterweise aufgesplitte Pierre (M.) Piccard scheint ein ebensolcher Fall zu sein). Eine GND-Korrektur kann ich versuchen anzustoßen, aber was solange tun mit den Wikidata-Einträgen?

(Efthymios) M(ike) Tsionas war tatsächlich zweimal mit verschiedenen Vornamen in RePEc - ist schon vor einiger Zeit dort gemergt und von mir im Item mit korrekter RePEc ID eingetragen worden. Jneubert (talk) 09:19, 1 September 2017 (UTC)[reply]

Was mich bei der Arbeit mit Wikidata positiv überrascht hat, ist, dass die verstreuten hier verfügbaren Tools auf ziemlich vielfältige Weise zur Verbesserung der Qualität der unterschiedlichen Normdateien eingesetzt werden könnten (auch wenn das dann ggf. nur schleppend abgearbeitet werden kann, wie Wikipedia:GND/Fehlermeldung zeigt). Weißt du, ob dazu schon mal jemand systematisch gearbeitet hat? Jneubert (talk) 09:25, 6 June 2017 (UTC)[reply]

Danke für die detaillierte Fehleranalyse. Ich bin zzt. nur selten auf Wikidata und habe den Überblick verloren, da die Fehlerlisten zu umfangreich geworden sind. User:Gymel kennt sich besser aus. Womit ich gute Erfahrung gemacht habe, ist VIAF auf die Sprünge zu helfen, indem wir fehlende GNDs ergänzen (s. Beispiele unter de:Benutzer:APPER/VIAF). GNDs können wir mittlerweile selbst anlegen und müssen nicht mehr auf die Bearbeitung durch die DNB warten. --Kolja21 (talk) 21:24, 8 June 2017 (UTC)[reply]

•  Done Marcel Boyer (Q3288726) und M. Martin Boyer (Q30084289) haben jetzt zwei getrennte GNDs. (Für den Feinschliff unter de:Wikipedia:GND/Fehlermeldung/Juni 2017#Todesjahr nach 1850 eingetragen.) --Kolja21 (talk) 23:49, 8 June 2017 (UTC)[reply]

Danke für die Hinweise und für's Anlegen von M. Martin! Dass VIAF anscheinend Wikidata als Input-Schnittstelle für Korrekturen nutzt, ist natürlich auch klasse (und ziemlich clever, weil sie sich damit Ausnahmelisten zum Tuning ihrer Clustering-Algorithmen sparen). In Thoms blog war das noch nicht erwähnt, aber vielleicht ist das auch eine neuere Entwicklung. In den Bibliotheken (wie z.B. BnF/BL scheint diese Art von Workflow noch gar nicht auf dem Schirm zu sein. Jneubert (talk) 11:13, 9 June 2017 (UTC)[reply]

Given your background in knowledge organization systems, authorities, and Linked Open Data; and also your earlier participation in the proposal discussion for narrower external class (P3950), I think your opinions would be interesting and useful on the value (or not) of Wikidata:Property proposal/broader concept, to record where broader/narrower links are given in external ontologies between objects which do have Wikidata items. Jheald (talk) 20:59, 11 February 2018 (UTC)[reply]

@Jheald: Thank you for making me aware of that discussion. I will look into it. Cheers, Jneubert (talk) 09:57, 12 February 2018 (UTC)[reply]

Hey Jneubert, a while ago you’ve provided that interesting “GND ID count by GND Ontology class” on Property talk:P227. May I ask how you evaluated the numbers? Dankeschön und Viele Grüße, MisterSynergy (talk) 10:27, 18 October 2018 (UTC)[reply]

Hi @MisterSynergy:, these are the fetched results of a federated SPARQL query on our experimental GND endpoint. It takes more than an hour, and depends on getting all GND IDs from WD in one service call - so I hope infrastructure can keep up with the increasing number of P227 assignments :) Cheers, Jneubert (talk) 12:23, 18 October 2018 (UTC)[reply]

Okay thanks. Do I have access to the experimental endpoint as an external user as well? Recently I was trying to evaluate such numbers locally from the GND RDF dumps from here. Unfortunately, my hardware (2012 notebook with Core i5 CPU, 12G memory and an SSD) is apparently by far not powerful enough to read the entire graph in reasonable time, neither to memory nor to disc, so I did not succeed :-/ If you happen to be experienced with local RDF graph software, I’d be interested a lot. I was trying to use Python+RDFlib first and RDF4J later, but I’m not really bound to any software yet.

In case I have no access to the experimental GND endpoint, can you please run other queries against it? I would be interested in:

• GND redirecting identifiers that are stored in Wikidata (we could resolve them here as well). The relevant query part is probably ?targetGnd owl:sameAs ?redirectGnd.
• GND Tn's that are stored in Wikidata (to be removed). Probably ?gndTn rdf:type <http://d-nb.info/standards/elementset/gnd#UndifferentiatedPerson> …

Thanks, MisterSynergy (talk) 14:07, 18 October 2018 (UTC)[reply]

The endpoint is publicly accessible at http://zbw.eu/beta/sparql/gnd/query. It has been created for our own experiments and is provided without any warranty - feel free to use. The current data state is 2018/06, from time to time it is rebuild from the lod dumps.

Your use cases sound interesting. Would you consider publishing the queries, perhaps in an own Github repository, or via pull request to https://github.com/zbw/sparql-queries?

Cheers, Jneubert (talk) 14:27, 18 October 2018 (UTC)[reply]

Oh that’s really great! Looks like I don’t need to set up a local graph software any longer . I’m still testing as I’ve never used SPARQL federation, and I will share queries later (although they are not very complex, tbh…). Some observations:

• It looks that the retrieval of data from WDQS is not the bottleneck here, even if you ask for all ~700k identifiers. The equivalent query executes quite quickly in the WDQS UI (order of 10 sec), and I don’t think it will take much longer when using federation. Try for instance this one, which, to my knowledge, needs to retrieve all gnds from Wikidata to output 10 of them.
• Even if you let Wikidata's endpoint make the GND IRIs from GND IDs, the query executes in about 40 sec, similarly as if you directly did it in WDQS.
• Things become more inefficient when there are many matches on GND side. Not yet sure exactly how this comes.
• On redirects: they can be identified with such a query, but from my experience one needs to use "LIMIT 1000" or so in order to keep it executable in reasonable time. The listed Wikidata items have the redirecting GND ID set, but the target GND ID may or may not be there. Question is: what to do with the redirects? Asking @Kolja21, Wurgl here as well. We could either replace them with the target GND, or add the target GND additionally to the items, with preferred rank.
• I will later try to identify Tn's in Wikidata. Further ideas would be to compare GND types with instance-of information from Wikidata, which would probably be a little more complicated due to the very different ontologies (rather simple in GND, rather chaotic in Wikidata).

Anyways, it’s really great to see that there is a possibility to query GND. —MisterSynergy (talk) 19:55, 18 October 2018 (UTC)[reply]

IMHO storing redirecting GNDs is of no help, they might just be useful for some historical reasons. I would simple replace them by the redirect-target. --Wurgl (talk) 20:03, 18 October 2018 (UTC)[reply]

+1. A former Tn for example can be changed into a redirect, so deleting outdated IDs saves us a lot of trouble. --Kolja21 (talk) 20:09, 18 October 2018 (UTC)[reply]

Apropo löschen: @MisterSynergy: Du schreibst: "I will later try to identify Tn's in Wikidata." Ich arbeite gerade die 2015‎ von User:Pasleim erstellte Liste Wikidata:WikiProject Authority control/Tn ab. In den meisten Fällen wurde der Tn bereits entfernt, aber nur selten durch einen Tp ersetzt. (Das sind jene Fälle, wo der VIAF-Cluster bessere Treffer enthält als vor drei Jahren.) Trotzdem liegt häugig bereits a) ein schwach indivualisierter Tp vor, den man per Hand recherchieren muss, oder b) ein Tn mit verknüpfter Literatur, den man auf de:WP:GND/F melden kann. Ideal wäre daher, wenn ein Bot zwar einerseits die Tns löscht, aber gleichzeitig die Fälle, in denen ein Tn nicht durch einen Tp ersetzt wird, in einer Wartungsliste erfasst. --Kolja21 (talk) 22:01, 18 October 2018 (UTC)[reply]

• Problem ist, dass wir kaum Möglichkeiten haben, in solchen Fällen automatisch eine Tp zu ermitteln. Bei VIAF nachschauen ist tatsächlich möglich, aber das habe ich gerade versucht und da sind mit ganz wenigen Ausnahmen dieselben Tn's verlinkt, die ich gerade erst entfernt hatte. VIAF ist diesbezüglich bestenfalls in Einzelfällen hilfreich.
• Tn's haben in Wikidata und Wikipedia verschiedenen Problemcharakter. Hier sind sie tatsächlich einfach falsch, bei Wikipedia haben sie für Leser potenziellen Nutzen (verlinkte Literatur); sie werden aber auch dort in einem separaten Feld festgehalten.
• Am einfachsten wäre es wohl, alle entfernten Tn's samt ihrer Q-IDs aufzulisten, so ähnlich wie auf Deiner Wartungsliste. Dann sind sie hier nicht im Wege, und wer interessiert ist kann sie durchgehen und ggf. zur Individualisierung anmelden. Ich weiß leider gerade noch nicht, ob man die zu Tn's verlinkte Literatur irgendwie automatisch ermitteln kann.

—MisterSynergy (talk) 22:40, 18 October 2018 (UTC)[reply]

Zweiter Punkt: Der unangemeldete User sieht Tn's nicht! Könnte man aber ändern, siehe dazu auch de:Wikipedia_Diskussion:Normdaten#GND_Kollateralnutzen?. --Wurgl (talk) 22:47, 18 October 2018 (UTC)[reply]

Hauptsache, die Tns gehen nicht verloren, auch wenn die Liste vermutlich umfangreich ausfallen und lange vor sich hinschmoren wird. Wie MisterSynergy schon sagte, gehören Tns nicht in Wikidata, aber falls sie "blind" gelöscht würden, fallen alle Personen, die keinen Artikel in deWP haben, durch das im Laufe der Jahre eng gestrickte Wartungsraster. --Kolja21 (talk) 22:57, 18 October 2018 (UTC)[reply]

Ich bin ehrlich gesagt nicht sicher, ob der Aufwand den Nutzen wert ist. In anderen Wikimedia-Projekten wird man tendenziell nicht so an der aus Tn's verlinkten Literatur interessiert sein (weil Publikum nicht deutschsprachig). Da wurde halt der Tn ergänzt, weil der Name passte; hier in Wikidata wurden die Tn's automatisiert ergänzt, weil sie bei VIAF verlinkt ist, wo man da in verschiedener Weise auf den Cluster zugreifen kann, ohne den Tn-Charakter der GND-ID zu bemerken. Die Liste mache ich trotzdem, wobei die mit dem GND-Endpoint eigentlich recht einfach zu ermitteln sein müsste. Ich schaue mir das morgen nochmal an. —MisterSynergy (talk) 23:26, 18 October 2018 (UTC)[reply]

Danke für deine Mühe! Wenn du willst, kopiere die Treffer in Wikidata:WikiProject Authority control/Tn, dann ist die Liste leicht zu finden. Und zur Klarstellung: Es geht mir nicht um den Erhalt der Tns, sondern um die bereits vorhandenen oder noch anzulegenden Tps, die in Wikidata fehlen. Auch VIAF ist darauf angewiesen, dass die Datengrundlage sauber ist; nur so kann der Algorithmus fehlerfrei arbeiten. --Kolja21 (talk) 23:49, 18 October 2018 (UTC)[reply]

Ich habe da jetzt längere Listen ergänzt, auch von der Juni-Aktion. —MisterSynergy (talk) 19:09, 19 October 2018 (UTC)[reply]

Sieht aus, als haben wir gerade tatsächlich keine Tn's mehr in Wikidata [1] (basierend auf dem Juni-Dump der GND). Dann schaue ich jetzt nach den redirects… —MisterSynergy (talk) 08:43, 20 October 2018 (UTC)[reply]

+1 for removing redirecting GND IDs. Thank you for the all the work you are putting into this! 07:37, 19 October 2018 (UTC)

Auch von mir herzlichen Dank! @MisterSynergy: Wenn ich es richtig sehe, kann jetzt die Liste User:KasparBot/GND Type N, letztmalig Oktober 2016 aktualisiert, gelöscht weren. Richtig? --Kolja21 (talk) 19:18, 19 October 2018 (UTC)[reply]

Wenn ich durch bin, versuche ich die ganzen Listen einmal zu konsolidieren (doppelte Einträge entfernen, und solche wo das Wikidata-Objekt mittlerweile wieder eine GND-ID hat). —MisterSynergy (talk) 20:03, 19 October 2018 (UTC)[reply]

Just updated the GND dataset to 2018-10. Jneubert (talk) 12:09, 21 November 2018 (UTC)[reply]

• Tn's in Wikidata
• GND redirects in Wikidata
• Type comparisons:
  • P31:Q5 in Wikidata, but not a Tp in GND
  • GND Tp, but not human in Wikidata (might occasionally time out as the Wikidata-part of the query is expensive and close to the WDQS timeout limit)
• VIAF inconsistencies (WD-Item links to GND, but WD-Item and GND have different links to VIAF; human/Tp only; ignoring cases where the WD item has more than one VIAF identifier)
• Wikipedia link inconsistencies (WD-Items links to GND, but WD-Item and GND have a different link to German Wikipedia; human/Tp only; postprocessing required to identify: missing Wikipedia pages, Wikipedia redirects, and Wikipedia disambiguation pages)
• Gender comparisons ("male ↔ female" only)
  • male in Wikidata, female in GND
  • female in Wikidata, male in GND
• Likely missing links to GND from Wikidata (and probably de-Wikipedia as well), based on Wikipedia links in GND (incomplete due to WDQS timeout limitations)

—MisterSynergy (talk) 12:12, 20 October 2018 (UTC)[reply]

When you look at de:Benutzer:Wurgl/Fehler_GND#V-475_erl. you see "… und 16566 weitere". All these are GND-IDs for Persons where the DNB holds a link to Wikipedia but no GND in the corresponding article or where the article holds a VIAF-Id and that VIAF-Id is also contained in the DNB-dump. About 1 out of 20 links is incorrect (or I am not sure). I expect a new dump next week, so I will regenerate that list again. It seems that those links in the DNB-dump come from wikidata via VIAF. Maybe not all of them, VIAF is still a miracle.

BTW: In http://viaf.org/viaf/data/ you find a file viaf-20181007-clusters.xml.gz I tried to download, but it take 7(!) hours for lousy 15GB. And no, I have a fast internet connection (150 MBit download), it should load within less than half an hour. So I refused that one. --Wurgl (talk) 15:08, 20 October 2018 (UTC)[reply]

The last query with the missing links IDs in Wikipedia is wellknown. Most of them are okay, but 5-10% of the links are not okay. Just one example: http://d-nb.info/gnd/138606668 (click on "Zugehöriger Artikel in Wikipedia"). So please, no bot-job! --Wurgl (talk) 17:14, 16 November 2018 (UTC)[reply]

I consider to import with a cross-check to VIAF: loop over all Wikidata items of the query result; if the item has a VIAF ID: check whether the GND ID associated to the item in the query is also listed in the VIAF cluster; if so, import with a reference to the VIAF cluster. Otherwise no import. There is of course still potential for mistakes, but I guess I can use the saved time compared to a full manual import to fix those mistakes, and do a lot of other things. —MisterSynergy (talk) 23:11, 16 November 2018 (UTC)[reply]

• Jneubert, I have a question regarding the GND ontology and the dump. I was trying to output preferred names for different GND types, and it turns out that several subproperties of gndo:preferredName are typically used as predicates, depending on the GND type. Unfortunately I don’t manage to bind all of them to a variable ?p in order to do ?gnd ?p ?preferredName. Since these two queries result empty sets, I assume that the GND ontology (current RDF) itself is not contained in the dumps. Is this correct? Do you think it would be possible at some point in the future to change this, similarly as we have Wikidata properties completely accessible in the Wikidata Query Service (simple example)? It would make querying much more efficient and flexible in many situations. Viele Grüße, MisterSynergy (talk) 20:14, 20 October 2018 (UTC)[reply]

Hi @MisterSynergy:, there was already an issue for this. Your use case tipped the balance - I've loaded the gndo version which was probably in use at creation time. Thank you for your great work, I'm happy that I can support it. Cheers, Joachim

Thanks a lot; it worked perfectly this morning, but throughout the day I have problems to use the endpoint. Seems like there is some kind of a problem with the federation part of the query. I will update and tweak the queries above once it is fine again. —MisterSynergy (talk) 17:15, 22 October 2018 (UTC)[reply]

• SPARQL federation via SERVICE <https://query.wikidata.org/bigdata/namespace/wdq/sparql> { ... } does not work for me since yesterday, even for very simple query fragments. Examples: query with federation and without federation. There are different error messages available, like “Gateway Timeout (#504)” and “Proxy Error (#502)” with some unparsed HTML output. Without federation, the GND endpoint works perfectly. Any idea what’s on here? —MisterSynergy (talk) 10:05, 23 October 2018 (UTC)[reply]

Hi @MisterSynergy:, I could reproduce the issue. In the frontend, after ca. 15 min I receive a Gateway Timeout (#504) by www-cache.rz.uni-kiel.de (squid). This is part of the univerity infrastruktur we use, but unfortunately I don't know at what point in the pipeline. In the Fuseki log, the query is received, but does not return anything, neither a result nor an error message.

After restarting fuseki, your simpele query with federation works, and also "Tn's in Wikidata" (52 results, takes reasonable time).

Actually, I have no idea what caused the issue, and no time to dive deeper. If it occurs again, please let me know. Cheers, Jneubert (talk) 12:01, 23 October 2018 (UTC)[reply]

It is working right now. However, I think it is worth to keep an eye on: maybe there is some filter somewhere that sees “a lot of traffic” from the Wikidata endpoint (~10-15M for “all items with their GND” per request), which is then blocked for some reason. If I experience this again, I will report here. —MisterSynergy (talk) 13:43, 23 October 2018 (UTC)[reply]

Hallo Joachim Neubert, habe die schönen Items via 20th century press archives (Q36948990) gesehen - gibt es eine sinnvolle Möglichkeit, auch Handelsregisternummern als Identifier zu taggen ? (z.B. via company register (Q1394657) Viele Grüße, Matthias --Erfurth (talk) 12:02, 28 November 2018 (UTC)[reply]

Hallo Matthias, m.W. gibt es kein Property für das deutsche Handelsregister, wie es das für das niederländische Handelsregister gibt (KvK company ID (P3220)). Das könnte ganz wesentlich daran liegen, das das niederländische offene Daten hat, die von Wikidata verlinkt werden können, während es beim deutschen eigentlich Aktenzeichen der einzelnen Registergerichte sind, so dass die ID nur mit dem Gericht zusammen unique ist, die Daten dahinter nur sehr eingeschränkt offen zugänglich und - by Design - nicht verlinkbar sind (falls sich daran im letzten Jahr nichts geändert hat). Schöne Grüße, Jneubert (talk) 16:35, 28 November 2018 (UTC)[reply]

Vielen Dank für die umfassende Antwort und das war in etwa schon meine Vorahnung. Was die Firmen von vor 1945 betrifft, gibt es immerhin für Dresden über das Adressbuchprojekt der SLUB relativ lückenlos jeweils pro Jahr ein "gedrucktes" Handelsregister. Gruß Matthias --Erfurth (talk) 09:21, 29 November 2018 (UTC)[reply]

RMaung (WMF) 16:25, 9 September 2019 (UTC)[reply]

RMaung (WMF) 19:51, 20 September 2019 (UTC)[reply]

Hello Jneubert,

Really sorry for the inconvenience. This is a gentle note to request that you check your email. We sent you a message titled "The Community Insights survey is coming!". If you have questions, email surveys@wikimedia.org.

You can see my explanation here.

MediaWiki message delivery (talk) 18:46, 25 September 2020 (UTC)[reply]

The Wikimedia Foundation Board of Trustees is organizing a call for feedback about community selection processes between February 1 and March 14. While the Wikimedia Foundation and the movement have grown about five times in the past ten years, the Board’s structure and processes have remained basically the same. As the Board is designed today, we have a problem of capacity, performance, and lack of representation of the movement’s diversity. Our current processes to select individual volunteer and affiliate seats have some limitations. Direct elections tend to favor candidates from the leading language communities, regardless of how relevant their skills and experience might be in serving as a Board member, or contributing to the ability of the Board to perform its specific responsibilities. It is also a fact that the current processes have favored volunteers from North America and Western Europe. In the upcoming months, we need to renew three community seats and appoint three more community members in the new seats. This call for feedback is to see what processes can we all collaboratively design to promote and choose candidates that represent our movement and are prepared with the experience, skills, and insight to perform as trustees?

In this regard, two rounds of feedback meetings are being hosted to collect feedback from the Wikidata community. Two rounds are being hosted with the same agenda, to accomodate people from various time zones across the globe. We will be discussing ideas proposed by the Board and the community to address the above mentioned problems. Please sign-up according to whatever is most comfortable to you. You are welcome to participate in both as well!

• Round 1 - Feb 24, 4:00 pm UTC
• Round 2 - Mar 3, 4:00 am UTC
• Sign-up and meeting details: Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats/Conversations/Wikidata

Also, please share this with other volunteers who might be interested in this. Let me know if you have any questions. KCVelaga (WMF), 14:32, 21 February 2021 (UTC)[reply]

Hallo Joachim, danke für das Update zum SPARQL-Endpoint im anderen Thema.

Ich habe zurzeit tatsächlich Schwierigkeiten, den Endpoint wie gewohnt zu nutzen. Insbesondere Abfragen mit ?entity rdf:type gndo:DifferentiatedPerson und ggf. auch einigen anderen Typen laufen nicht mehr. Ich habe das seit gestern einige Male und in verschiedenen Varianten versucht.

Nebenbei: bei der PREFIX-Autovervollständigung werden noch die alten GND-Prefixe mit http-Protokoll vorgeschlagen. Soweit ich das verstehe, sollten aber Prefix mit dem https-Protokoll genutzt werden. Ist das richtig?

Viele Grüße! —MisterSynergy (talk) 07:22, 21 February 2022 (UTC)[reply]

Kann ich bestätigen - ?x a gndo:DifferentiatedPerson ergibt keinen Treffer. Für das weitere dazu s. Github.

Die PREFIXES kommen m.W. von https://prefix.cc/gndo - Upvotes welcome. Danke und schöne Grüße, --Jneubert (talk) 07:45, 21 February 2022 (UTC)[reply]

Hallo Joachim, ich komme seit ein paar Tagen beim SPARQL-Endpoint nicht mehr durch, bekomme ausnahmslos einen Fehler 503 Service Unavailable: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Ich bin ehrlich gesagt nicht sicher, ob der Service generell nicht verfügbar ist, oder ob ich evtl. zu viel Last verursacht habe und nun in irgendeinen temporären Sperrmechnismus gelaufen bin, der mich individuell blockiert. Gibt es sowas, oder ist der Endpoint zurzeit tatsächlich nicht verfügbar? Viele Grüße! —MisterSynergy (talk) 08:11, 26 February 2022 (UTC)[reply]

Da ist der Wurm drin. Einen temporären Sperrmechanismus gibt es nicht. Der Endpoint war down seit 24.2. kurz nach Mitternacht - ohne Fehlermeldung bei einer Query nach redirects verschieden. Ich habe die JVM-Parameter angepasst und hoffe, dass er jetzt etwas stabiler läuft. Tatsächlich brauche ich aber mehr Hauptspeicher. Die Query

 PREFIX wdt: <http://www.wikidata.org/prop/direct/>
 PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
 select distinct ?gndId ?oldId
 where {
   ?gnd gndo:gndIdentifier ?gndId ;
   gndo:oldAuthorityNumber ?redirect .
   bind(strafter(?redirect, ")") as ?oldId)
   filter(?oldId != ?gndId)
 }

läuft 603 sec. und bringt 1,387,754 Ergebnisse. Jneubert (talk) 10:06, 28 February 2022 (UTC)[reply]

Okay danke. Das läuft jetzt hier auch wieder :-)

Mittlerweile kann ich auch die Dumps verarbeiten und damit so einiges Offline erledigen. Das dauert zwar länger, aber ist im Wesentlichen nur einmal je Dump-Release zu tun. Damit schone ich ein wenig die Serverkapazitäten und mache mich weniger von der Verfügbarkeit des Dienstes abhängig. Kleinere Einmal-Abfragen werde ich weiter am SPARQL-Endpoint erledigen.

Viele Grüße! —MisterSynergy (talk) 10:36, 28 February 2022 (UTC)[reply]

Prima. Danke nochmal für deine Rückmeldungen, und schöne Grüße - Jneubert (talk) 11:09, 28 February 2022 (UTC)[reply]

Hallo Joachim, ich bekomme mal wieder recht hartnäckig 503er-Fehler unter https://zbw.eu/beta/sparql/gnd/query und kann deshalb den Endpoint zurzeit nicht nutzen. Das UI scheint aber zugänglich zu sein. Klemmt da zurzeit wieder etwas? Viele Grüße! —MisterSynergy (talk) 13:50, 1 August 2022 (UTC)[reply]

Danke für den Hinweis, ich kann das Problem reproduzieren. Leider hat ein Fuseki-Neustart nichts gebracht. Andere Endpoints laufen, es scheint ein Problem speziell mit der GND zu sein, wo ich schon seit Monaten nichts verändert hatte. Erfordert leider Nachforschungen - Grüße, --Jneubert (talk) 14:15, 1 August 2022 (UTC)[reply]

@MisterSynergy: Nachforschungen erfolgreich, der Endpoint läuft wieder. Da ich zunächst in die falsche Richtung gesucht hatte, gibts jetzt auch eine neue GND-Version (2022-06). Schöne Grüße, --Jneubert (talk) 05:26, 3 August 2022 (UTC)[reply]

Besten Dank! Der Endpoint läuft tatsächlich wieder wie gewünscht :-) —MisterSynergy (talk) 07:50, 3 August 2022 (UTC)[reply]

Hallo Joachim, der 503er-Fehler ist zurück — ich kann den Endpoint gerade nicht nutzen. Kannst Du bitte einmal nachschauen, ob etwas klemmt? Dankeschön und Viele Grüße! —MisterSynergy (talk) 08:08, 2 September 2022 (UTC)[reply]

Läuft wieder (war bis gestern im Urlaub, sorry) --Jneubert (talk) 05:21, 26 September 2022 (UTC)[reply]

Besten Dank! —MisterSynergy (talk) 08:41, 26 September 2022 (UTC)[reply]

Hallo Jneubert. Ich habe diese Ausgabe gesehen...hmm...die Quelle gab diesen Ort an? Es kommt mir etwas seltsam vor. Es ist seltsam, dass ein privates Unternehmen seinen Sitz im spanischen Staatsrat hat. CFA1877 (talk) 09:21, 24 April 2022 (UTC)[reply]

Thank you for hinting at this - the headquarter locaton in the source is indeed Madrid. The location data was transformed semi-automatically, and wrongly assigned to Spanish Council of State (Q2313715), which strangely was displayed under the label "Madrid". I've added a German label and fixed all occurrences of the error - thanks again! Cheers, Jneubert (talk) 09:05, 27 April 2022 (UTC)[reply]

Danke dir. Wieder'sehen! CFA1877 (talk) 09:38, 28 April 2022 (UTC)[reply]

Hi. I saw you created Lazard Brothers & Co (Q106817723) as an item, but I think that this is really Lazard (Q637440), it used to be called Lazard Brothers before it was restructured and floated on the NYSE as Lazard. I think you should merge them? 78.18.244.36 14:00, 10 August 2022 (UTC)[reply]

Merged - and thanks for the hint. --Jneubert (talk) 17:53, 10 August 2022 (UTC)[reply]

Änderungen wie [2] scheinen mir recht unsinnig zu sein. Käpt'n Knips (talk) 13:46, 15 September 2022 (UTC)[reply]

@Käpt'n_Knips: Bitte entschuldige die späte Reaktion, war mir durchgerutscht. Inhaltlich ist die Kombination der beiden Properties number of works (P3740) (= unknown) und number of works accessible online (P5592) (= 0) ein Weg zu sagen, dass das Archiv Material zu dieser Firma in unbekanntem Umfang enthält, von dem aber nichts online zugänglich ist. Das Material kann als nicht aufbereiteter digitalisierter Mikrofilm vorliegen - dann ist es aus urheberrechtlichen Gründen nur im ZBW-Lesesaal zugreifbar. Oder als Mikrofiche - die können auf vorherige Anfragen hin herausgesucht werden. Oder als Papier (wie in diesem Fall, für den Zeitraum nach 1980) - dann ist das Material leider nicht zugänglich. Zumindest in den beiden ersten Fällen kann die Info für Suchende schon relevant sein. Schöne Grüße, Jneubert (talk) 16:28, 18 November 2022 (UTC)[reply]

Talk:Q106589826 has mentioned many arguments against private ontologies inside Wikidata. Please don't create redundant items for your private classification.

Thank you very much. Coward at heart (talk) 20:22, 11 November 2022 (UTC)[reply]

Thank you, @Coward_at_heart: I move the topic to the Wikidata_talk:WikiProject_20th_Century_Press_Archives, in order to have the (hopefully developing) discussion easily accessible in the context of the project. Cheers, Jneubert (talk) 13:10, 16 November 2022 (UTC)[reply]

Dear Jneubert,

I hope you are doing well,

We are a group of researchers from King’s College London working on developing WQT (Wikidata Quality Toolkit), which will support a diverse set of editors in curating and validating Wikidata content.

We are inviting you to participate in an online workshop aimed at understanding the requirements for designing effective and easy-to-use user interfaces (UI) for three tools within WQT that can support the daily activities of Wikidata editors: recommending items to edit based on their personal preferences, finding items that need better references, and generating entity schemas automatically for better item quality.

The main activity during this workshop will be UI mockup sketching. To facilitate this, we encourage you to attend the workshop using a tablet or laptop with PowerPoint installed or any other drawing tools you prefer. This will allow for a more interactive and productive session as we delve into the UI mockup sketching activities.

Participation is completely voluntary. You should only take part if you want to and choosing not to take part will not disadvantage you in any way. However, your cooperation will be valuable for the WQT design. Please note that all data and responses collected during the workshop will be used solely for the purpose of improving the WQT and understanding editor requirements. We will analyze the results in an anonymized form, ensuring your privacy is protected. Personal information will be kept confidential and will be deleted once it has served its purpose in this research.

The online workshop, which will be held on April 5th, should take no more than 3 hours.

If you agree to participate in this workshop, please either contact me at kholoud.alghamdi@kcl.ac.uk or use this form to register your interest https://forms.office.com/e/9mrE8rXZVg Then, I will contact you with all the instructions for the workshop.

For more information about my project, please read this page: https://king-s-knowledge-graph-lab.github.io/WikidataQualityToolkit/

If you have further questions or require more information, don't hesitate to contact me at the email address mentioned above.

Thank you for considering taking part in this project.

Regards Kholoudsaa (talk) 16:41, 19 March 2024 (UTC)[reply]