User talk:Francesco Gelati

From FactGrid
Revision as of 15:56, 11 March 2020 by Francesco Gelati (talk | contribs) (added info and link)
Jump to navigation Jump to search

Welcome

Hi Francesco,

just a brief welcome also on this site. You have managed the first QuickStatement input; it seems you know how to run this. For compatibility reasons it would be good if we could use the same label conventions - where we have adopted those of Wikidata again for the sake of compatibility. The hard core information of given names and family names is in the name statements anyway. Item:Q1308 gives you insight of how we have been organising things. And: Let me know if I can help with clues how to do things. Preparing the input will be the terrible work (especially where family names have to be first generated, where places are missing - or where they have to be matched...) We will get a tool to do this: OpenRefine; that, however, does not yet work on external Wikibases; they are working on the adaptation. I organise mappings of data (e.g. matching place names) on Excel, not ideal but one can do. You might know better ways. --Olaf Simons (talk) 11:08, 31 January 2020 (CET)

QuickStatements

Dear Olaf,

thanks for your kind message and for all of your help and support. Yes I did a CSV manual test ingest and I do have a couple of questions. Shall we post our Q&A here? FactGrid:Help

1) I was not able to enter a date of death. Neither our specific nor the ISO notation can be used as free text. I tried to learn from already existing entries how to express dates, or any kind of value which is to be expressed as literal, even as a combination of value plus item, but I failed to find info; see: FactGrid properties for dates. What should I change in e.g.

qid,P38

Q140813,10.05.1993

2) What about the properties? Are we allowed to use Factgrid-properties only? I would like to use some Wikidata properties as well as the International Council on Archives Ontology that, being myself a Diplom-Archivar, I personally cherish. The GND Ontology is an option too. I will anyhow be happy to file new property requests on Factgrid.

I do not see either a better option than OpenRefine. Yet I am still thinking on how the workflow should proceed from our tailored XML-export. I am indeed mapping data fields both to linked data, and to the archival XML standard for authority records, EAC - Encoded Archival Context. Since the workflow involves in any case several semi-automatic steps, I am not afraid of cleaning and referencing the data on OpenRefine.

Before a real dataset ingest, I believe a memorandum will be necessary with our institutions. We are still discussing internally some issues so for the moment I may unfortunately only play around. Yet I will use this lapse of time also in order to do the mapping and to develop things further.

Thanks for your help, --Francesco Gelati (talk) 14:28, 31 January 2020 (CET)

Dear Olaf,

Yes I believe it would be important to have an automated entity reconciliation. Yet how did you create items for e.g. all geonames on Factgrid, and then linked them? Would not it be possible to use, if not Wikidata-properties, at least Wikidata-items? Thanks,

--Francesco Gelati (talk) 17:05, 6 February 2020 (CET)


Ich antworte mal auf Deutsch: QuickStatements muss ganz exakt bedient werden. Die präzisen Syntaxanforderungen für Datumseingaben findest Du hier
Du musst als Datum etwas angeben wie +1913-08-27T00:00:00Z/11, falls Du tagesgenau eingeben willst. Monatsgenau ist +1913-08-00T00:00:00Z/10 und Jahresgenau +1913-00-00T00:00:00Z/9 (der Unterschied liegt in den 00 Angaben und in /9 /10 /11 für die Genauigkeit). (Die Zeitangaben werden derzeit nicht von der Software unterstützt, da unklar ist, wie sie bei verschiedenen Zeitzonen laufen sollen.
Zur Frage der Properties: Du kannst beliebige Properties verwenden - doch müssen es alles FactGrid Properties sein. Eine Wikidata-P-Nummer läuft bei uns so wenig wie eine Wikidata Q-Nummer. Die Software zählt P- und Q-Nummern sukzessive beim Anlegen, jede Wikibase-Instanz hat im Verlauf anderen Nummern für dasselbe.
Entweder findest Du bereits eine passende Property im Directory of Properties oder Du generierst eine nach Deinen Wünschen. Wenn es exakt eine P-Nummer, wie Du sie brauchst, bei Wikidata gibt aber nicht bei uns, dann notieren wir die Korrespondierende Wikidata-Nummer für den späteren Datenabgleich mit P343 im Datensatz unserer P-Nummer.
Wenn Du bestimmte Bibliotheks-Standards bei der Benennung von Properties hast - und wenn das nur eine Frage der Namensgebung ist, kannst Du die Dir passenden Namen als Alias einführen oder Du schaltest Deinen Account auf "Formales Deutsch" um, und belegst unsere Properties dort mit den Labels und Beschreibungen, die Dir praktisch sind.
Was die Frage einer offiziellen Kooperationsvereinbarung anbetrifft - da sind wir flexibel. Mit Wikimedia und der GND trafen (und publizierten) wir solche Kooperationsvereinbarungen, um uns gegenseitig Sicherheit zu geben in Anbetracht der Schwierigkeiten und der Größe der beginnenden Projekte. Seitens der Uni Erfurt war bei beiden Projekten klar, dass das Präsidium unterschreiben würde - Rechtsabteilungen waren hier einzuschalten und verschiedene Institutionen der Uni (Bibliothek, Pressestelle etc.) zu involvieren. Wir können uns auf einen solchen Weg begeben, wir können ansonsten vermutlich auch erst einmal sehr viel unbürokratischer verfahren. Ihr könnt beliebig Personen-Datensätze anlegen, P-Nummern generieren, die interessant wären und bislang im System fehlen, P-Nummern an Standards anschließen und Definitionen einfügen, wie Ihr sie bei der Arbeit nützlich findet. (Gut ist es jedoch, wenn wir bei allen Dingen, die die Datenmodelle verändern, miteinander sprechen, da das ganze Projekt davon profitiert, wenn Datensätze auf dieselben Suchanfragen schlüssige Ergebnisse liefern.)
Open-Refine läuft bei uns noch nicht integriert - das ist mir von Wikidata-Leuten mit dem nächsten Software-Update versprochen. Bislang bereite ich in Google Spreadsheets größere Eingaben vor.
Geografika haben bei uns alle Wikidata-Nummern. Mit dieser Abfrage kannst Du sie aus der Datenbank ziehen und danach mit Wikidata abgleichen.
Bei den ersten Ortseingaben (deutsche Orte) zog ich aus Wikidata lediglich die Geokoordinaten und GND Nummern (wo vorhanden). Bei der letzten großen Erweiterung (38.000 französische Orte) bezog ich aus Wikidata zudem BNF und GeoNames-Identifier und setzte die aktuelle territoriale Zugehörigkeit (Frankreich) sowie die aktuelle Einwohnerzahl hinzu, da das mehr sagt als "Dorf" oder "Stadt".
Wenn ich für eine größere Eingabe Orte als Strings/Zeichenketten habe und unsere Q-Nummern brauche, ziehe ich mir unseren ganzen Bestand an Orten aus der Datenbank und lasse ein Google Spreadsheet der Spalte mit Ortsnamen unsere Q-Nummern zuordnen (mittels Vertical Lookup). Mit der obigen Abfrage kannst Du einen Wikidata-Abgleich vornehmen, auch aus Wikidata die GeoNames beziehen und dann bei uns ankoppeln. Letztlich scheint sich herauszustellen, dass die Wikidata-Nummern für alles die besten Identifier sind. Wir sorgen mittlerweile überall dafür, dass Dinge mit Wikidata-Nummer diese Referenz erhalten.
Hab ich eine Frage übersehen? Oder kommen neue Fragen, lasse es mich wissen. Grüße --Olaf Simons (talk) 14:08, 10 February 2020 (CET)

Örtliche Zuständigkeit bestand schon

Hier nochmal abgelegt:

Für die örtliche Zuständigkeit bestand bereits Property:P429 - ich sehe aber zudem exakt das Problem das Martin sieht, wir brauchen etwas Sinnvolles für die sachliche Zuständigkeit. Ich denke dabei brauchen wir reziproke Optionen. Beides lege ich an als Property:P452 "Zuständigkeitsbereich" und Property:P453 "im Zuständigkeitsbereich von". Martin mag gerne legale Definitionen beifügen, das geht mit Property:P423. --Olaf Simons (talk) 15:40, 4 March 2020 (CET)

Ich eempfehle jetzt mal, mit meinen weiterzufahren, da die korrekt binnen-kategorisiert sind und nur so auch in den Listen auftauchen. --Olaf Simons (talk) 16:02, 4 March 2020 (CET)

career statements

Items sollten entweder eine P2 oder P3 Aussagen haben - wir lassen bis jetzt alle Aussagen zu Jobs und Berufspositionen in einem sehr weiten Rahmen als Career statements laufen, damit man sie so insgesamt abrufen kann - das geht bis zur "Bäckerswitwe", die man schlecht als Beruf fassen kann. Abfrage des Komplexes Karriere-Aussage --Olaf Simons (talk) 17:40, 10 March 2020 (CET)

Die Entscheidung für das offener Wort Karriere-Aussage ist dabei ein Provisorium. Ich hoffe noch sehr auf eine Kollegin, deren Fachgebiet die historische Klassifikation von Berufen ist, und der ich gerne eine kluge Zergliederung des Durcheinanders überlassen will. Deshalb sammeln wir bislang einfach mal die Aussagen, um dann später zu sortieren und zu hierarchisieren. --Olaf Simons (talk) 21:48, 10 March 2020 (CET)

Vielen Dank Olaf! Ich habe letztes Jahr Dr. Katrin Moeller des Historischen Datenzentrums Sachsen-Anhalt kennengelernt und weiß nicht, ob du am ihren Projekt über lebenslaufbezogene Daten denkst. Auf Deine Expertise sowie von Deinen Kollegen freue ich mich sehr.