Ich wollte grade mal wieder den 365Chess Crawler unter https://paws.wmflabs.org/paws/user/Steak/notebooks/Crawler.ipynb anwerfen, um automatisch Identifier zu prüfen. Allerdings werden jetzt alle, auch falsche Identifier, als valide eingestuft. Hat sich da was an der Website geändert und müsste man das Skript anpassen?
User talk:MisterSynergy
Jump to navigation
Jump to search
Hat sich erledigt. Sorry für die Störung.
Viele Grüße! :-)
Hallo MisterSynergy, danke, dass du die Weiterleitungen korrigierst. Nur eine Bitte: Kannst du die alte Quellenangabe dabei löschen? Es passiert leider häufig in Wikidata, dass Bots Werte überschreiben, aber die Quelle bleibt stehen. Beispiel:
- Syrisch-katholische Kirche (Q755970)
- Vorher: GND 1028109199 (Typ Körperschaft), Quelle: deWP
- Nach Korrektur: GND 1154461270 (Typ Geografikum), "Quelle: deWP"
In Wikipedia fallen solche Fehler auf, da die Normdatenvorlage den GND-Typ erfasst. In Wikidata bleiben sie unkorrigiert stehen.
Danke, guter Punkt. Ich entferne dann wahrscheinlich in Zukunft die alte Aussage, und ergänze danach eine komplett neue.
Hast Du eine Idee, wie ich dann die Herkunft des Weiterleitungsziels in der Fundstelle angeben könnte? Irgendwie ist das Weiterleitungsziel ja dann schon von dem von dewiki importierten Identifikator abgeleitet worden. In der Versionsgeschichte kann man das per editsummary nachlesen, aber das ist halt nicht Teil der strukturierten Daten. Wobei sich eh die Frage stellt, wie wichtig Fundstellen für Identifikatoren sind…
Mein Vorschlag: Einfach die alte Quellenangabe löschen. (Sie wäre nur hilfreich mit Abrufdatum, das fehlt bei den alten Importen, und einem Zusatz wie "Update auf Weiterleitung am ...".) Das Ideal wäre, wenn man erfasst, wann eine Normdatennr. importiert wurde und dann per Bot ein Mal pro Jahr einen automatischen Update macht. Vor allem VIAF entwickelt sich ständig weiter und die Ergebnisse dort werden immer besser.
Ja, dann machen wir das so.
Abgleiche mit Wikipedia-Werten macht man am besten Wikipedia-seitig, weil von hier aus nicht so recht klar ist, wo man im Quelltext nach dem Identifikator schauen muss. Wir führen da ja langsam die Vergleichskategorien ein, wobei ich das in Zukunft noch etwas robuster gestalten möchte.
Hat Kollege Wurgl nicht einen Offline-Dump von VIAF-Links rumliegen? Ich meine, er hätte mal so etwas gesagt. Dann könnte man jedenfalls mal verschiedene Abgleiche starten, die paarweise VIAF-Identifikatoren, GNDs oder Wikidata/Wikipedia-Links beinhalten (ggf. auch die anderen Identifikatoren von VIAF). Bei Jneubert auf der Disk. habe ich vor ein paar Tagen zwei Vergleichsabfragen an die GND notiert, siehe die (zurzeit) letzten beiden Links unter User talk:Jneubert#Queries (der experimentelle GND-Endpoint scheint aber einmal wieder zu hängen).
Anstatt so etwas jährlich abzugleichen, würde ich lieber täglich (oder wöchentlich) aktualisierende Wartungslisten nach dem Prinzip der covi-Listen aufsetzen, das einmal runterarbeiten und danach dann nebenbei mit erledigen. Das würde klappen, solange der Großteil der Wartungsarbeiten Wikidata-seitig anfällt, und nicht in GND oder VIAF – dort haben wir nämlich keinen uneingeschränkten Einfluss darauf, wie schnell Fehler beseitigt werden.
Hmm - eben habe ich die "Query with federation" ausgeführt, und sie hat sehr rasch einen Treffer erbracht. Auch "Tn's in Wikidata" läuft flott. Vielleicht einfach zeitweise Überlast am Endpoint. Jneubert (talk) 15:37, 30 October 2018 (UTC)
Danke, ich versuche das nachher noch einmal. Am Wochenende hatte es schon einmal nicht funktioniert, aber da hatte ich nicht genug Zeit, näher nachzuschauen.
Grundsätzlich sehe ich das sehr entspannt. Das Teil ist experimentell, und ich möchte nicht zu häufig wegen (vermeintlicher oder tatsächlicher) Ausfälle nerven. Die bisher gelisteten Abfragen sind ja auch alle recht schwergewichtig, vielleicht liegt es gelegentlich einfach auch daran.
Viele Grüße!
Ich hab hier http://viaf.org/viaf/data/viaf-20181007-links.txt.gz von http://viaf.org/viaf/data/ herumliegen, also in einer 7GB SQLite-Datenbank. Das File enthält VIAF-ID und die zugehörigen anderen Identifikatoren. Es enthält (manchmal) auch Wikipedia-Links. Bei machen Bibliotheken ist sowohl die ID welche die VIAF verwendet enthalten als auch ein Link auf die entsprechende Seite, also z.B.
http://viaf.org/viaf/100144928704054440114 DNB|1079471162 http://viaf.org/viaf/100144928704054440114 DNB@http://d-nb.info/gnd/1079471162 http://viaf.org/viaf/100145003288961300710 NLI|004686503 http://viaf.org/viaf/100145003288961300710 LC|nb2015022940 http://viaf.org/viaf/100145003893261340515 DNB@http://d-nb.info/gnd/1079820728 http://viaf.org/viaf/100145003893261340515 DNB|1079820728 http://viaf.org/viaf/100145304375678570834 NLI|001846229 http://viaf.org/viaf/100145375917983681133 NDL|001221153 http://viaf.org/viaf/100146461532027731295 LC|no2016066566 http://viaf.org/viaf/100146997313418891705 NII|DA06549468 http://viaf.org/viaf/100146997314918891712 NII|DA06708958 http://viaf.org/viaf/100146998525418942258 NII|DA02303604 http://viaf.org/viaf/100146998580518942548 NII|DA02777460 http://viaf.org/viaf/100147094985625081522 DNB|1109931689 http://viaf.org/viaf/100147094985625081522 DNB@http://d-nb.info/gnd/1109931689 http://viaf.org/viaf/100147266917535482493 NTA|397410360
oder
http://viaf.org/viaf/101244348 ISNI|0000000071659444 http://viaf.org/viaf/101244348 WKP|Q25802599 http://viaf.org/viaf/101244348 Wikipedia@https://de.wikipedia.org/wiki/Franz_Friedrich_Ruhstrat http://viaf.org/viaf/101244348 DNB|139512950 http://viaf.org/viaf/101244348 DNB@http://d-nb.info/gnd/139512950
Bei mehrfachen Identifikatoren einer Bibliothek, wie in dem Beispiel gibt es ein Problem. Und zwar die Zuordnung von "DNB|..." zu "DNB@..." hier im Beispiel sind die Ids gleich, nur das ist bei Geographika nicht der Fall. Noch hab ich da zu wenig Erfahrung um zu sagen, ich ordne die immer richtig zu.
Wegen Abgleich: Die DNB erzeugt den Dump 3 mal im Jahr, im Oktober sollte ein Dump kommen, bisher gibt es keinen. Die VIAF erzeugt ihre Dumpfiles monatlich, am Monatsanfang. Ich weiß nicht, ob da ein wöchentlicher Abgleich so sinnvoll ist. Unstimmigkeiten müssten jedenfalls per Zugriff auf die Webseite überprüft werden, bevor da was auf die Fehlerliste kommt (in meiner Fehlerliste mach ich das auch so bei der Validierung einer GND-Nummer, es werden ja täglich neue angelegt).
Aber sag mal genau was du wie abgeglichen haben willst.
Ach das Ding. Ich glaub ich hatte das vor einigen Wochen schon einmal angeschaut, es war aber für spontane Nutzung zu unhandlich (85M Zeilen). Ich schaue mal, ob ich das selbst in eine MySQL-Datenbank in einer Form reinkriege, so dass ich das selbst machen könnte. Korrekte Indizierung wäre da wohl hilfreich :-)
Ganz primitve Datenbank (Typ Text entspricht VARCHAR)
CREATE TABLE "viafData" ("viafId" TEXT NOT NULL, "bibName" TEXT NOT NULL, "bibViafId" TEXT NULL, "bibLink" TEXT NULL)
CREATE INDEX "viafIdIdx" ON "viafData" ("viafId")
CREATE INDEX "bibNameIdx" ON "viafData" ("bibName", "bibViafId")
CREATE INDEX "bibLinkIdx" ON "viafData"("bibLink") WHERE "bibLink" NOT NULL
Das heißt, ich kombiniere diese Zeilen mit dem @ (das ist der Link) mit denen mit dem | in ein Record.
Damit komm ich durch.
Ich nehme SQLite weil das ist bei vielen Einzelabfragen hintereinander um einiges schneller da keine Interprozess-Kommunikation stattfinden muss. Auf den Toolservern mit NFS geht das wohl nicht so gut.
Das andere <hier Flüche einsetzen> Ding ignorier ich. Da dauert der Download 7 Stunden weil die VIAF extrem bremst, das dürfen die behalten.
Danke. Ich mache das ein kleines bisschen anders, aber grundsätzlich scheint das so ein guter und performanter Ansatz zu sein. Bist Du sicher, dass auf @ immer ein Link folgt und auf | immer eine blanke ID? Irgendwie habe ich auch blanke IDs hinterm @ im Oktober-Dump.
Stimmt! Bei LCCN, und NUKAT (und noch ein paar) sehe ich die auch. Bei denen ist wohl die ID so formatiert, dass man da irgendwie schneller einen Link basteln kann. Wobei mich die gar nicht so sehr interessiert haben, Wikipedia- und DNB-Links haben mich interessiert und dort passt das wohl.
Hab mal zwei VIAFS mit solchen linklosen @ angeklickt. Dort ist dann auf der Seite von dem entsprechenden Bibliotheksdatensatz der Link zur Bibliothek einer, der wieder zu genau der Seite zurückführt (oder gar kein Link).
Genau welchen solcher Links hab ich bei denen mal nachgefragt und sogar eine Antwort bekommen: BNF does not always produce a link to their source authority record. You can determine if an authority for BNF will have a clickable “Authority/Source Record” link by verifying that there is an 009 field in the actual BNF authority record viewed in VIAF (see screenshot for example).
https://viaf.org/processed/BNF%7C13561620 <-- mit 009er Datensatz https://viaf.org/processed/BNF%7C17732651 <-- ohne 009er
Ich habe das mittlerweile gut am Laufen, mit zwei MySQL-Tabellen (eine für blanke IDs und eine für URIs). Mit den Indizes wie Vorgeschlagen ist das tatsächlich recht effizient auszulesen.
Nebenbei habe ich jetzt auch den .nt-Dump von VIAF einmal angeschaut. Komprimiert 11G, ausgepackt ein Textfile von fast 93G Größe, mit knapp 809 Millionen Zeilen RDF :-) Mit Python kann ich das aber tatsächlich einigermaßen gut durchsuchen.
Bei der Aufteilung in zwei Tabellen … wie klammerst du mehrere Pärchen von ID + Link? Ich hab ja auch so ein Problem bei meiner Tabelle, allerdings beim Füllen. Ich sag ganz einfach: Hab ich bisher keine ID oder keinen Link, dann gehört das zum bisher gefundenen. Hab ich schon eine ID (und finde gerade eine weitere – bzw. eben einen Link und finde einen Link), dann ist das eben ein weiteres Pärchen. Was natürlich bedeutet, dass ich bis zum Wechsel der VIAF mehrere "halbfertige" Records in einer (Hash-)Liste habe.
Ist das der VIAF-Dump wo man auch Umleitungen innerhalb der VIAF-Ids findet? Dunkel erinnere ich mich, mal sowas gesehen zu haben, aber welches File weiß ich nicht mehr. Hab übrigens mal eine Nörgelmail an die VIAF geschrieben, wegen langsamen Download. Mal sehen ob da was kommt.
Ich habe einfach zwei unabhängige MySQL-Tabellen:
- für IDs: id, viafId, bibName, bibViafId
- für URLs: id, viafId, bibName, bibLink
id ist in beiden Fällen einfach eine fortlaufende Nummer (primary key, mit auto_increment). Alle anderen Indizes sind nicht primary und auch nicht unique, also einfache Indizes. Jedenfalls kann ich mit den passenden Indizies und zwei Abfragen sehr schnell alle IDs und Links haben, die ich gerade brauche. Insgesamt habe ich in beiden Tabellen zusammen exakt soviele (Tabellen-)Zeilen drin, wie Einträge/(Text-)Zeilen im JustLinks-Dump drin sind.
Der VIAF-Dump mit Weiterleitungen ist der ganz unten unter http://viaf.org/viaf/data ("persist"), der ist noch recht verdaulich. Das richtig dicke Ding ist dieser .nt-Dump hier, wo praktisch alle VIAF-Informationen drin stehen. Es ist ja so ein bisschen das Problem von RDF, dass es bei interessanten Graphgrößen einfach mal irre viel Speicherplatz braucht, und eigentlich auch ziemlich viel Hauptspeicher, wenn man den Graphen richtig nutzen möchte (zum Beispiel Abfragen mit SPARQL). Ich habe da jetzt aus den 93G Text jedenfalls 5.5 Millionen Angaben zu Geschlechtern rausextrahiert, um hier ca. 160.000 Einzelnachweise zu verbessern; dazu das Ding mit Python geöffnet und einmal durchgelaufen, über jede der 809M Zeilen einen regulären Ausdruck drübergejagt, und die Treffer in einer Datei abgelegt. Dauerte so gut zwei Stunden insgesamt, was akzeptabel ist, da ich das nur einmal machen musste.
Die Datenmengen sind einfach irre, ja!
Ich hab gestern diese neue Fehlerliste gemacht. Musste ein wenig den Code anpassen, weil die wieder mal was geändert haben (und ja, ich bin aus gutem Grund recht streng). Dann die VIAF laden, dann via SSH diverse Daten aus APPERs Datenbank zur Vorlage Normdaten und anderen Vorlagen rausfischen und dann hat das Ding gerödelt. Da war dann der halbe Tag rum. Hab mir schon mal überlegt meine alte Kiste ein wenig aufzumöbeln, so 64 GB Memory wären schön :-) Aber die Kiste ist zu alt, daher erstmal nicht. Bei dem dicken Ding muss ich aber wohl.
Auf dem Stand von März habe ich VIAF für Fuseki in eine TDB geladen. (Auf einem internen Hochleistungsrechner, den ich dafür nutzen kann. Leider habe ich nicht genug Platz auf dem öffentlichen Server, um das Ergebnis - ca. 150 GB, inkl. Textindex - einfach rüberzuschieben.) Beim Laden ist viel Hauptspeicher gut, aber noch wichtiger sind schnelle Platten.
Interessant.
Brauchst Du den Hauptspeicher nur fürs Laden, oder bleibt der Graph auch nach dem Laden im Hauptspeicher drin? Nach meinem Verständnis macht es performancetechnisch durchaus einen Unterschied, den Triple Store on disk oder in memory zu haben. Leider kenne ich keine Zahlen und kann das hier auch nicht ausprobieren, denn die infrage kommenden Graphen sind einfach mal alle viel zu groß für den, nunja, Hausgebrauch.
Die Konfiguration inkl. Hardwareausstattung für den Wikidata Query Service ist hier und dort beschrieben, allerdings nicht ganz einheitlich. Da sind zurzeit zwölf Server aktiv, von denen nur sechs den öffentlichen Endpoint bedienen (die anderen sechs sind für interne Abfragen). Ich finde leider gerade keine Information darüber, wie die Daten da vorgehalten werden – im Hauptspeicher oder auf SSDs.
Stimmt. Dennoch: Bei MySQL hab ich damals beim letzten Rechner (2 CPUs, je 1 Kern, 1GB Memory) mich mal mit größeren Datenmengen gespielt. Das Ding war sauschnell, solange die Datenbank ins Memory passte. In dem Moment wo das nicht mehr der Fall war, gabs einen mehr als massiven Einbruch. Hab damals damit auch ein wenig mit Threads experimentiert. War ganz interessant, dass ich mit 5 Threads (jeder hat eine andere Tabelle geladen, die Tabellen waren aber durch Foreign Keys miteinander verknüpft, also mussten die Threads schon ein wenig auf einander warten) doch noch einiges an Zeit aufholen konnte. Mich hat eben gewundert, dass bei weit mehr Threads als CPUs das Ding trotzdem um einiges schneller war.
Und hier hab ich das Ding mit Debug-Ausgaben laufen lassen. Ich glaub 40GB Zeugs hat der an Debug so nebenbei mitgeschrieben. Ohne Debug mit 2 Threads (einer liest XML, der andere schaufelt in die Datenbank) dauert das Lesen so 30 Minuten beim GND-Dump. Ungefähr soviel auch bei diesem kleineren VIAF-Dump.
Beim Lesen der Datenbank aus der APPER-Datenbank von den Toolservern nervt nur was: Die Query läuft ca. 30 Minuten bis die ersten Daten eintröpfeln. Die Query liefert 1,97 Mio Datensätze, von insgesamt 73 Mio (ein einfaches SELECT count(*) hat jetzt auch 39 Minuten benötigt). Da muss ich mal ordentlich ran und die Struktur umbauen, nur blöderweise laufen da einige Scripte und die muss ich alle auf einen Schlag umstellen :-(
Hoi, I noticed that you attributed Viaf identifiers to a "wikimedia project". They are not. Many of these have been looked up and have not been imported at all. The value of such representations are not only wrong, they are misleading. Please undo these attributions.
Hey GerardM, I do not quite understand. I actually try to do the exact opposite of what you tell here, i.e. transfer references from imported from Wikimedia project (P143): Virtual International Authority File (Q54919) to the correct form stated in (P248): Virtual International Authority File (Q54919); I also add actual VIAF identifiers to references, and verify for each edit that the referenced claim is indeed supported by the VIAF cluster. This means that I actually remove the attribution of VIAF as a “Wikimedia project” that is implied by the label and entire definition of imported from Wikimedia project (P143).
I would not completely rule out that something went wrong, but in fact I am highly confident about what I am doing. If not, can you please provide a diff link to an edit which you think is not correct? Thanks and regards!
Hoi, you are right.. It turns out that I read hardly ever the changes. Sorry and thanks for doing a good job.
Ok no problem, and nevertheless Thanks for showing up here! :-)
Hi, du hattest mal vor längerer Zeit die Titel von der FIDE-Datenbank gezogen und mit den Statements hier verglichen (damalige Ergebnisse sind hier ). Könntest du das bitte nochmal machen?
Hallo, bin gerade nicht mehr ganz sicher, ob ich das Skript von damals wiederfinde. Für welche Items soll da nochmal nachgeschaut werden?
Für alle Items, die eine Fide-ID haben.
Ok, dann ist da ein bisschen was zu tun. Ich habe mittlerweile wohl das richtige Skript wiedergefunden, und mache das bei Gelegenheit an. Weil das Skript alle Seiten einmal abrufen muss, dauert das ein bisschen…
Noch eine Bitte, wenn du sowieso alle Seiten crawlen musst: Kannst du mit dem Eintrag im Feld "Federation" systematisch die Property:P1532 ergänzen?
Ich würde sowieso erstmal eine lokale Kopie speichern, und darauf dann die Auswertung durchführen. Da kann man dann auch spontan noch nach anderen Dingen schauen.
Gibt es hier Fortschritte?
Gibt noch nichts neues, das Thema hier ist und bleibt aber offen. Derzeit zuwenig Zeit für Wikidata…
I have the 2004 edition of this book on my shelf. Obviously, with electronic databases of individuals, they have an ID and can have an entry at Wikidata. Is the same done for books that contain bios? It says in the foreword that 755 athletes competed at Olympic Games and the remaining 245 bios cover those who have won world or European championships, and/or were "most popular". Hence, they'd all be notable.
I'd happily sit down and compile a spreadsheet with:
- item identifyer
- page number(s)
Could that be useful? If so, maybe you could give me a spreadsheet that has the following:
- item identifyer of GDR Olympic attendee
- label (name)
I'd then add the other 245 bios to it and then add the page numbers. The complication with this approach is that the page numbers will only be correct for the 2004 edition of the book; the 2000 version was a bit shorter. But maybe that's just another property that could be added over time (by those who have access to the 2000 edition).
This is typically not done with external identifiers, but there are possibilities.
First of all, for printed works we typically distinguish between work items and edition items, to address your concern from the your paragraph. Technically: we use an approach similar as in the "FRBR model". When using as a source, one refers to an edition item in order to provide exact pages and so on as qualifiers. As far as I see, there is neither a work item nor a edition item for this book right now, so both would have to be created and possibly also for older and newer edition we want to have items as well, besides your 2004 edition.
From my opinion, use of described by source (P1343) would be the best and most appropriate solution here. I also explicitly think this would be very valuable to have. The statement would link to the edition item (here: 2004 edition of the work), and page(s) (P304) qualifiers pointing to pages could be added as qualifiers.
It would indeed be sufficient to compile a "QID --> page(s)" mapping in a spreadsheet, and then transform this into input for a batch processing tool that adds this reference as a statement to all 1000 items automatically. I could make the transformation to tool input from the mapping, and provide it to you for the actual processing. However, it looks like the big task here is to lookup all the Q-IDs, where I am not sure right now how to do this efficiently. Querying and automatic mix-n-match on names could certainly help. As a start, I can offer 1394 GDR citizens with a Sports-Reference identifier in Wikidata (you can download the result as TSV or so), which is probably the best measure to identify Olympic GDR participants (according to SR, there are 1360 of them; diff likely due to double citizenships and 1992-and-later participations of former GDR citizens).
Excellent. Let's do it then. Have just figured out where the big discrepancy comes from; Kluge is talking about 755 Olympic medallists! I guess there's nothing in Wikidata that keeps track of medals. Should there be? Could there be?
Either way, it could be useful to also include P734 (family name) in the query as Kluge sorts the book by that. Not everyone will have their surname listed and it could be useful to have that as a starting point and add the missing ones manually (or better still, see what could be added within Wikidata and then export again).
And we should filter for Olympic event. Sorting by birth year, I see that the oldest people listed participated in 1908 or 1912. We are only interested in events between 1956 and 1988. East Germany didn't participate in 1952.
Once I've done a few basic things in Excel, I can then put the spreadsheet into Google Docs and let you (and other interested editors) know where it lives. That way, further amendments to the spreadsheet can be done by others, too. Once the spreadsheet itself is in good nick, I can go through the book and identify who's there, who is not, and who needs adding.
Any other thoughts?
I've done a bit of work with the query output. There's now an occupation defined for everyone. The first 100 or so now have the individual sporting events linked rather than just the Olympic year. I've also started adding missing family names but it'll become easier once you've added that field to the query (I tried to do so myself but did not succeed). I've noted that everybody has a birth year defined (the query looks like birth year being optional and I'd be surprised if everyone's birth year was known).
There should be information about Olympic results in Wikidata, but we barely have this yet. Not even participation information is close to being complete.
I have now iterated over all SR profiles of GDR citizens to retrieve this information directly, and added a filter for GDR medallists to the query, see here. 664 results, so some 91 are still missing. Not sure whether no items exist, no GDR citizenship information exist, no SR profile link exists, or something is wrong with the profiles or with my evaluation script.
I suggest to split the names at spaces in a spreadsheet and sort by family name then.
Thanks; I'll have a look. There will be more missing than 91 as I noticed this morning that Kluge does not list all individuals who have medalled in a team sport; looked at a couple of soccer bronze medallists this morning.
Mh.
Does the book have an index of biographies, ideally including a mapping to pages (i.e. "sportsperson name --> page in book")? An alternative approach would be to look for items based on athlete names. I have a script for such a task as well, and it can handle minor differences in spelling of names.
Unfortunately not. It will be a manual process for me to go through the book.
Just a heads up that I'll be on holiday for the next few days; not sure how much internet access there will be. I'm making good progress going through the list that your last query produces (have completed entries up to 1949 birth). I'm amending entries for the following:
- Participation in Olympic events (where those are defined)
- "East German" in description
- Add surname where it's missing
- Add maiden or married names where missing
I've already finished adding 'sports' where that field was empty.
To assist with the above, it would be good if you could amend the above query by 'description' (English) and surname; that way it's much easier to check whether the former contains "East" (and even "German" is often missing) as well as whether there's a surname defined. Where a surname hasn't been set up I create it.
Question - why does the query not pick up Q461155?
Thanks for your ongoing help!
- Thanks for the update.
- The SR profile of Klaus Richtzenhain (Q461155) tells he participated for GER in 1956. There was no GDR team at that time. The query filters only those athletes that have won a medal at one of these games.
- updated query with English descriptions and surname labels
Well, that explains it. That's missing the six games (summer and winter; 3 each) that the United Team of Germany competed in, made up of a mixture of East and West Germans (1956, 1960, 1964).
Okay I started my script again and provide yet another version of the query. Includes medallists for GER in 1956, 1960, or 1964 (Summer and Winter each) that have a GDR citizenship in Wikidata. 729 items, also including Klaus Richtzenhain (Q461155) now.
Right, the Wikidata entries are now mostly tidy. I can now export this to a spreadsheet and add columns with various properties, I suppose. Let me just check whether my thinking is correct:
- We will set up a property for the book itself
- We will record, for all entries, that this refers to the second edition of the book
- We will use P1810 "named as" and that's the name that I will confirm in the spreadsheet for each entry. The listings use the format "last name, given name"
- We will use P304 "page(s)"
How would you like me to record when an entry is on more than one page? It's generally two pages and if it's on pages 10 and 11, say, I could record it as "10f" - is this method what's used on Wikidata?
Great! I have created three items:
- Das große Lexikon der DDR-Sportler (Q57783316) – the work item
- Das große Lexikon der DDR-Sportler (1st edition) (Q57783317)
- Das große Lexikon der DDR-Sportler (2nd edition) (Q57783318)
Please have a look whether the information is correct as much as you can verify with your hardcopy. I took all information from the Internet.
The way how you input the pages is indeed a bit flexible, as page(s) (P304) has "String" datatype, thus it allows some kind of text. "10f" or "10–11" or even just "10" would all be okay. Anyways, how it should (roughly) look like later:
< Klaus Beer (Q523359) 
page(s) (P304)
named as (P1810)
page(s) (P304)
named as (P1810)
The lower two lines indicate qualifiers to the described by source (P1343) claim. To get this done in QuickStatements, you need proper input (cf. Help:QuickStatements for details). For the claim above, it would look like this (V1 format, not CSV format):
Q523359 P1343 Q57783318 P304 "31f" P1810 "Beer, Klaus"
Mind the tabs between everything, and the quotes around the strings "31f" and "Beer, Klaus". You should be able to generate such strings for all matched lines in your spreadsheet (if not: send it to me, I’ll send the input back to you to execute the batch with your account; this is at maximum a 5 min task for me).
Once this is done, open QuickStatements, start a new batch, add the input and import it as "V1" format. You can see in the preview whether it looks okay. If so, there is the "Start" button at the end of the tool page.
Watch your contributions carefully while executing the batch. Do not delete the batch input; in case something goes wrong, it is much easier to repair when the input is still known.
Progress report: have done the entries up to the end of B. It's slow going as I fix up a lot of issues with the bios and amend the Wikidata entries at the same time. I find a surprising number of entries that the query should have picked up but didn't (e.g. Q95785 & Q98491). Not sure why but it doesn't matter; I'm now working in an offline spreadsheet.
Mh. Reasons why the two listed items are missing:
- Q95785’s ranking is given as “3T” as Sports-Reference. My script didn’t expect such values, thus it does not understand that this means “tied third place”.
- Q98491 did not win an Olympic medal according to SR. Maybe he is part of the other ~250 athletes?
By the way, I've played around with QuickStatements and got my head around that. Very useful!
Thank you for youe reply but I think you ARE wrong because you misundertand the proper order of the names. In the western usage the given names stand at the edge of the personal names so one calls them as first names and the family names or surnames come to the end of the personal names. This is the teason that in English you call him David Adger and not Adger David but you HAVE NOT observed the very little comma between the names: Adher, David. You may know that the most important element of each personal names is the surname/family name and one can register the persons in the alphabetical order of their sirnames and in the scintific publications the surnames/family names come first and the comma indicates that the first element in front of the comma (Adger) is the surname/family name and the second element behind the comma (David) is the given/first name. In the eastern usage like in Chinese, Korean, Japanese and Hungarian (my mother tongue) language the surname/family names come first and given names stand in the second place which is more logical because the surnames/family names are the more saliant part of the names. So you can see that Adger, David mens David Adger, they are equal so I was right when I had chosen the GND ID Adger, David for linguist David Adger. Thank you fpr xor kind attention.~~~~
Hey Borgatya, thanks for the comment. Unfortunately, it misses the point. Whether we write him "Adger, David" or "David Adger" does not matter here. Not at all. I chose the spelling "Adger, David" in User talk:Borgatya#On David Adger because GND does so as well.
If you need more evidence about GND ID (P227) usage and the general unsuitability of Tn type entries, please have a look at Property talk:P227. There is overwhelming community consensus *not* to use them here, as they contradict basic principles of external identifiers. You may not like the community consensus, but I guess it would be best to act according to it, rather than investing in a goal you cannot reach.
spinnen, oder :-)? Was siehst Du für Möglichkeiten, deren weltweiter Belästigungskampagne effizient ein Ende zu setzen? not amused grüßt das --Eloquenzministerium (talk) 18:15, 21 October 2018 (UTC).
Antwort gesehen, in die gleiche Kerbe gehauhen, möge es klappen, hier wohl erstmal erledigt. Danke. --Eloquenzministerium (talk) 18:38, 21 October 2018 (UTC)
Es wäre hilfreich, wenn Du Dich da mehr zurückhieltest.
Ich finde deren aktuelle Position extrem unverschämt, bin aber mit dem Terrain nicht vertraut. Wo liegt das diplomatische Problem? --~~~~
Hallo, ich bin nicht so sonderlich erfahren mit Wikidata. Deshalb habe ich eine Frage zu dieser Änderung: was bedeutet „undifferentiated GND (type tn)“? Vielen Dank im voraus und herzliche Grüße, --Frank Schulenburg (talk) 18:18, 22 October 2018 (UTC)
Hallo Frank, im Wesentlichen gilt Hilfe:GND#Personen in dewiki auch für die Eigenschaft GND ID (P227) bei Wikidata: wir nutzen sie, um differenzierte/individualisierte Personeneinträge (Typ Tp) in der GND zu verlinken. Hauptzweck ist: eine Aussage machen, dass die in dem entsprechenden Wikidata-Objekt beschriebene Person dieselbe ist wie im verlinkten GND-Eintrag.
Nun hat die GND aus verschiedenen Gründen zahlreiche sogenannte undifferenzierte/nicht-individualisierte Personeneinträge (Typ Tn), was eigentlich Namenseinträge sind: sie beziehen sich nicht auf eine bestimmte Person, sondern sind als Sammler für alle Personen mit demselben Namen (aber ohne individualisierten Tp-Eintrag) in der GND zu verstehen. Die Tn-Einträge eignen sich natürlich nicht, um mit der Eigenschaft GND ID (P227) Identitäten festzustellen, und sollen daher nicht mit der Eigenschaft genutzt werden. Das ist im vorliegenden Fall der Hintergrund für die Entfernung.
Bei Wikipedia werden Tn-Einträge in der Vorlage:Normdaten in einem separaten Feld "GNDName" gespeichert, weil in der GND gelegentlich interessante Literatur unter diesem Eintragstyp verlinkt ist. Die richtigen Einträge vom Typ Tp kommen exklusiv ins Feld "GND" der Vorlage.
In der GND gibt es übrigens mehr als sieben Millionen undifferenzierte Einträge (Typ Tn), und nur knapp fünf Millionen differenzierte Einträge (Typ Tp).
Viele Grüße!
Super, vielen herzlichen Dank. Habe eine Menge gelernt. Toll, dass Du dir Zeit für eine ausführliche Erklärung genommen hast. Ich weiß dass sehr zu schätzen. Beste Grüße vom Flughafen in Columbus, Ohio :-) -–Frank Schulenburg (talk) 18:55, 22 October 2018 (UTC)
Wie schwierig wäre es, von Fernschachspieler-Datenbankeinträgen wie z. B. https://www.iccf.com/player?id=510006 die Titel und Titeljahre zu crawlen und in die entsprechenden Items einzufügen?
Ich würde sagen wir bearbeiten erst einmal die andere Geschichte weiter unten auf meiner Disk. Das hier bleibt solange offen, bis ich mir das genauer angeschaut habe. Könnte etwas dauern.
Auf den ersten Blick: das sieht nicht ganz so einfach aus, weil die Datenbank geschickt die Zugänglichkeit erschwert (technisch: es sind nur wenige id- und class-Attribute an den HTML-Elementen im Quelltext angegeben). Unmöglich ist aber nichts, nur im Zweifel fummeliger zu extrahieren…
Ok, dann muss es nicht sein, es war nur als Aufgabe zwischendurch gedacht falls es sehr einfach gewesen wäre. Ich setze es auf erledigt.
Wieder geöffnet. Mir ist eingefallen, dass es auch PDFs gibt, die recht übersichtlich sind, z. B. für Fernschach-Großmeister hier: https://www.iccf.com/userfiles/files/2012%20LGM.pdf. Kannst du ICCF-ID mit den Items hier matchen und Titel und Jahr ergänzen?
Ich kriege das nicht direkt aus dem PDF heraus extrahiert, auch wenn das bestimmt technisch irgendwie möglich ist.
Wenn ich das richtig verstehe, gibt es da mehr als das eine PDF-File. Wenn Du alle PDFs händisch in einer Textdatei/wikitext-Seite duplizierst – unformatiertes c+p mit einer Zeile je Tabellenzeile reicht völlig aus – dann wäre das aber in der Tat ziemlich einfach.
Auf User:Steak/Empty items ist die csv-Liste mit allen Titeln, passt das?
Ja, das passt so. Weiter nun:
- Bei "Simagin, Vladimir Pavlovich -- RUS -- IM -- 1965" fehlt die ICCF-ID in dem File. Irgendwie verloren gegangen?
- Ich bräuchte nun ein Mapping der fünf Titel zu Q-IDs:
- GM
- SIM
- LIM
- LGM
- IM
- Wenn möglich, würde ich auch die URLs der jeweiligen PDFs haben wollen, dann können wir nämlich gleich auch Fundstellen ergänzen. Ist doch richtig, dass da ein PDF je Titel existiert, oder?
Wir können später auch noch "country" und "name" mit P27/P1532 sowie label/alias abgleichen.
Die PDFs sind hier ganz unten verlinkt: https://www.iccf.com/Titles.aspx . Im entsprechenden IM-PDF hat Simagin auch keine ID, also insofern passt das. Ich hab ihn grade händisch erledigt.
Q-IDs:
GM: Q3818700
SIM:Q27579729
IM:Q4288508
LGM: Q51281931
LIM: Q51288964
Country und den Rest dann später, japp. Teilweise kann es sein, dass bereits ein Titel in den Items eingetragen ist, aber eine andere Jahreszahl. Es wäre gut wenn du diese Fälle in einer Textdatei protokollierst.
Das räumen wir später auf, mit einer Abfrage.
Ich habe eben gesehen, dass wir nur knapp 300 ICCF-ID hier hatten. Gerade habe ich noch einmal den entsprechenden Mix'n'match-Katalog durchgeschaut und knapp 500 weitere IDs ergänzt. Wir haben aber bei weitem nicht alle gut 3000 Titelträger hier in Wikidata. Übersehe ich etwas?
Ne du übersiehst nichts, die Abdeckung ist wirklich nicht besonders gut. Aber was bleibt uns übrig? Die Items jetzt spontan zu erstellen ist wahrscheinlich nicht so sinnvoll, da ja nicht mal Geschlecht oder Geburtsdatum importierbar ist.
Ich habe Dir den Input für QuickStatements2 auf Deiner Seite abgelegt. Immerhin 338 Titel von den gut 3000 kannst Du damit ergänzen.
Vielen Dank, ist durchgelaufen. Jetzt müsste man noch ein paar Sachen hinterherräumen, z. B. bei Q15688969 stehen jetzt zwei Jahreszahlen.
Vermutlich kann man es rechtfertigen, dass man die differerierenden Jahreszahlen entfernt, aber ganz trivial ist es nicht (daher mein Hinweis am Anfang). Z. B. bei Q3821648 gibt das ICCF-Profil andere Jahreszahlen an als die PDF-Dateien.
Alle erledigt. In vier Fällen waren zwei verschiedenen Jahre angegeben, das habe ich anhand der Quelle angepasst. In ca. 15 Fällen waren zwei identische Jahreszahlen als Qualifikatoren angegeben, was ich ebenfalls repariert habe.
Danke, immerhin nur vier Abweichungen. Ein paar Titelträger scheinen in den PDFs auch zu fehlen, zumindest gibt es mehr Einträge in den Profilen. Aber das meiste ist da. Damit ist das hier wohl erledigt.
Sonst sag gern nochmal Bescheid. Das war jetzt kein großer Akt.
Achso, wie ist das mit den Verbänden und dem Label-Abgleich? Also Verbands-Statements wären ja easy, du hast ja vermutlich noch das Mapping ISO-Kürzel -> QID. Aber: Sollte man als Qualifier für den Verband dann sowas wie "betrifft: ICCF" ergänzen? Tendentiell würde ich sagen nein, aber es kann theoretisch Fälle geben, bei ein Spieler bei der FIDE für einen anderen Verband antritt als bei der ICCF. Man könnte dann natürlich auch nur in so einem Spezialfall mit Qualifier arbeiten?
Frage übersehen oder zu beschäftigt?
Zu beschäftigt. Solange das hier offen ist, geht das eh nicht verloren. Dauert nur im Zweifel etwas :-)
Der Countrycode gibt in der Tabelle den Verband an, für den der Schachspieler antritt, richtig? Wie würde das eigentlich am besten modelliert werden? Mit country for sport (P1532)? Dann würde ich vorschlagen, wir ergänzen das nur dann wenn der Wert von dem country of citizenship (P27)-Wert abweicht, sofern ein solcher vorhanden ist.
Ich würde bevorzugen, dass P1532 immer ergänzt wird. Schon allein aus praktischen Gründen, damit man in Listen wie Wikidata:WikiProject Chess/Lists/GM die Nationalitätsspalte einfach weglassen kann.
Ich habe jetzt bei fast allen Nahschachspielern die FIDE-Verbandszugehörigkeit ergänzt. Wenn du die Hinzufügungen für die ICCF-Spielern vornimmst, brauchst du also den Verband nur dort ergänzen, wo entweder noch gar keiner vorhanden ist oder er sich vom FIDE-Verband unterscheidet.
