Schlagwort: google refine

Data Munging Tools in Preparation for RDF: Catmandu and LODRefine

Die neue Code4Lib-Ausgabe 30 ist da. Besonders interessant:

Data Munging Tools in Preparation for RDF: Catmandu and LODRefine von Christina Harlow

Abstract:

Data munging, or the work of remediating, enhancing and transforming library datasets for new or improved uses, has become more important and staff-inclusive in many library technology discussions and projects. Many times we know how we want our data to look, as well as how we want our data to act in discovery interfaces or when exposed, but we are uncertain how to make the data we have into the data we want. This article introduces and compares two library data munging tools that can help: LODRefine (OpenRefine with the DERI RDF Extension) and Catmandu.

The strengths and best practices of each tool are discussed in the context of metadata munging use cases for an institution’s metadata migration workflow. There is a focus on Linked Open Data modeling and transformation applications of each tool, in particular how metadataists, catalogers, and programmers can create metadata quality reports, enhance existing data with LOD sets, and transform that data to a RDF model. Integration of these tools with other systems and projects, the use of domain specific transformation languages, and the expansion of vocabulary reconciliation services are mentioned.

xISSN und Google Refine: Infos über Zeitschriften sammeln

Für Vertragsverhandlungen wollte ich herausfinden, bei welchen Verlagen die Autoren unserer Hochschule Zeitschriftenartikel veröffentlicht haben. In einem Citaviprojekt habe ich eine Stichprobe von ca. 1000 Artikeln, die ich verwenden wollte. Das Problem: In Citavi sind die Zeitschriftenverlage nicht ordentlich zu hinterlegen. Die Lösung: wir haben die ISSN, und mit xISSN gibt es eine ganz brauchbare Schnittstelle, um mehr Daten zu einer ISSN zu bekommen.

Das Vorgehen:
Die Artikeldaten wurden inklusive ISSN in eine CSV-Tabelle exportiert. Diese CSV-Tabelle habe ich in Google (oder Open) Refine importiert. Dort ging es dann weiter. Zunächst habe ich die Spalte ISSN auf jeweils eine ISSN reduziert. In einigen Fällen waren mehrere ISSN (online und offline) im Feld.

Transform auf der Spalte ISSN mit dem Kommando slice(value, -9) nimmt die jeweils 9 letzten Zeichen und wirft den Rest weg. Aus 1234-5678, 9876-5432 wird also 9876-5432.

ISSN-Analyse in Google Refine

Danach “Add column by fetching urls on column ISSN” mit dem Kommando “http://xissn.worldcat.org/webservices/xid/issn/”+value+”?method=getHistory&format=json”, mit Anführungszeichen! Das dauert dann ganz schön. In meinem Fall hat es ca. zwei bis drei Stunden gedauert für etwa 1000 Titel.

Danach erhalte ich eine Spalte, in der die Daten zu einer Zeitschrift im JSON-Format enthalten sind. Daraus wiederum extrahiere ich eine neue Spalte (“Add column based on this column”) mit value.parseJson().group[0].list[0].publisher. Fertig.

Naja, es muss dann noch ein bißchen aufgeräumt werden. Allein Springer fand ich in 5 verschiedenen Schreibweisen, ebenso die American Physical Society. Aber prinzipiell war es das.

Von Citavi über Refine zu VIVO

Kurze Niederschrift eines möglichen Geschäftsgangs, der vermutlich nicht für jedermann verständlich ist. Wer das nachnutzen möchte, möge sich an mich wenden!

  1. Erfassung der Daten in Citavi oder einem anderen Programm, dass tabellarische Ausgabe erlaubt.
  2. Export als CSV-Datei
  3. Import in Google Refine (Open Refine ist noch in einer Alpha-Version, meines Erachtens ist es auch wirklich noch nicht sehr stabil.) Die RDF-Extension sollte installiert sein.
  4. Zusätzlich zu importierende Ontologien in Refine: VIVO und BIBO.
  5. Reconciliation gegen einen aktuellen RDF-Export aus der VIVO-Installation. Dadurch kann man auf recht flotte Art und Weise ein Autorenmatching durchführen. Wenn sowohl in VIVO als auch in den Publikationsdaten Autorenidentifier vorhanden sind, kann man die zum Abgleich verwenden. Achtung, je nach Datenmenge rechnet Refine daran sehr, sehr lange herum. Ein Testlauf von knapp 3000 Publikationen beim Abgleich mit etwa 1200 Personen wurde nach drei oder vier Stunden abgebrochen. Der Fortschrittsbalken stand da bei 45%.
  6. Add column based on this column. GREL Expression: cell.recon.match.id.
  7. Die von Citavi mitgelieferten Dokumententypen durch die VIVO-bekannten ersetzen. GREL Expression:

    value.replace(“Beitrag in …”, “bibo:chapter”).replace(“Beitrag im Gesetzeskommentar”, “fabio:Comment”).replace(“Buch (Monographie)”, “bibo:Book”).replace(“Buch (Sammelwerk”, “bibo:EditedBook”).replace(“Graue Literatur / Bericht / Report”, “vivo:WorkingPaper”).replace(“Hochschulschrift”, “bibo:Thesis”).replace(“Hörspiel”, “bibo:AudioDocument”).replace(“Internetdokument”, “bibo:Webpage”).replace(“Manuskript”, “bibo:Document”).replace(“Musikwerk / Musikalbum”, “bibo:AudioDocument”).replace(“Patentschrift”, “bibo:Patent”).replace(“Schriften eines Autors”, “bibo:Document”).replace(“Software”, “obo:ERO_0000071”).replace(“Sonderheft / Beiheft”, “bibo:Document”).replace(“Spielfilm”, “bibo:Film”).replace(“Tagungsband”, “bibo:Proceedings”).replace(“Unklarer Dokumententyp”, “bibo:Document”).replace(“Vortrag”, “vivo:Speech”).replace(“Zeitschriftenaufsatz”, “bibo:AcademicArticle”).replace(“Zeitungsartikel”, “bibo:Article”)

    [1] Es hat sich inzwischen als sinnovoller erwiesen, direkt die URIs zu verwenden, also z.B. http://vivoweb.org/ontology/core#Speech

  8. RDF-Skelett je nach Daten erstellen. An einem optimalen und für möglichst viele denkbare Fälle verwendbaren Skelett wird noch gearbeitet. Besonders bei Beiträgen in Sammelwerken ist das nicht so einfach…
  9. Export als RDF.
  10. Import in VIVO.
  11. “Name Blank Nodes” in VIVO
  12. Die Daten sind drin.

Dieser Geschäftsgang ist weder optimal, noch final. Aber er funktioniert!

Problematisch sind u.a. Beiträge in Sammelwerken oder Zeitschriften-Reconciliation. Bei letzterem setze ich auf Lobid.

References

References
↑1 Es hat sich inzwischen als sinnovoller erwiesen, direkt die URIs zu verwenden, also z.B. http://vivoweb.org/ontology/core#Speech

GND per SPARQL

Die ZBW hat nun einen SPARQL-Endpoint für die GND (Fuseki) gebaut. Aus der dazugehörigen Mail von Joachim Neubert:

Der Endpoint ist rein experimentell und ohne jede Gewähr auf Verfügbarkeit oder Performanz. Ich würde mich freuen davon zu hören, wenn er sich für Experimente als hilfreich erweist (oder was ggf. verbessert werden könnte).

Dies ist nützlich u.a. für den Abgleich (Reconciliation) von eigenen Daten mit der GND zum Beispiel via Google Refine/OpenRefine.

Ein konkreter Anwendungsfall für Open Data

Diskussionen über Open Data bleiben oft abstrakt, die Frage nach einem konkreten Anwendungsfall schwebt immer wieder im Raum. “Wer will denn überhaupt diese Daten haben?” Um diese Frage mit einem Beispiel zu beantworten: ich.

Mein Anwendungsfall ist der Aufbau einer Hochschulbibliographie. Dort sollen nicht nur die Autoren und ihre Publikationen verzeichnet werden, das System soll vielmehr ein Abbild der Forschungsaktivität der Hochschule sein. Dazu setzen wir auf VIVO. Und VIVO arbeitet mit Linked Data.

Ich habe das System und seine Komponenten hier im Blog schon beschrieben. Um meinen Anwendungsfall zu verstehen, reicht ein Blick auf dieses Profil der Boeing Company im VIVO der Cornell University.

Man kann in VIVO also Firmen abbilden, die in irgendeiner Art mit der Forschungs-, Lehr- oder Publikationstätigkeit in Verbindung stehen. Dies ist von vielen Seiten gewünscht. Manche möchten Transparenz darüber, wer die Hochschulforschung finanziert. Andere möchten wissen, welche ProfessorInnen die fleissigsten Drittmitteleinwerber sind. Manche möchten sich dadurch einfach als industrienah präsentieren oder sind auf der Suche nach neuen Kooperationspartnern. Motive gibt es vielerlei.

Nun kann man diese Daten natürlich per Hand eingeben oder die hausintern vorliegenden Daten (die berühmten Excel-Tabellen) nachnutzen. Doch ist das wirklich notwendig? Warum muss jede Hochschule diese Daten selbst pflegen? Welcher Aufwand steckt dahinter, die Daten korrekt und vollständig zu halten? Ich kann ihn nicht beziffern, eine grobe und meines Erachtens durchaus realistische Abschätzung lautet allerdings: er ist mir zu groß.

Und hier kommt der deutsche Datengeiz ins Spiel. OpenCorporates ist ein Verzeichnis für Firmeninformationen. Eines der besonderen Art. Die Daten sind unter ODbL lizenziert, es gibt tolle Schnittstellen und es finden sich dort Infos über sagenhafte 62,035,536 Firmen. Ein beachtlicher Berg!

Davon sind 40,155 aus Albanien, 45,423 aus Aruba, 68,711 aus Pakistan, 104,852 aus Gibraltar, 535,779 aus Irland, 723,842 aus Norwegen, 1,559,918 aus Südafrika oder 8,199,109 aus Großbritannien. Aus Deutschland: 0. Keine einzige.

Nichts gegen Aruba! Eine Insel, deren Wahlspruch “Una isla feliz” (kreolisch für “Eine glückliche Insel”) sicherlich berechtigt ist. Auch die wirtschaftlichen Aktivitäten sind bei 45.000 Firmen auf etwa 100.000 Einwohnern sehr beachtlich. Aber wie kann es sein, dass Aruba schafft, was für Deutschland nicht möglich ist? Liegt es daran, dass der Wahlspruch Deutschlands “Amtsgeheimnis” lauten könnte?

Die Diskussion darüber hatte ich kürzlich erst mit OKF DE, Marian Steinbach und Friedrich Lindenberg. Es wird Zeit, dass sich etwas tut.

Google Refine

Am Mittwoch wurde Google Refine 2.0 released. Google Refine kann dazu dienen, unordentliche Datenmengen aufzuräumen und nachnutzbar zu machen. Hat man z.B. eine Datei in der unterschiedliche Schreibweisen zur Beschreibung des selben Sachverhalts genutzt wurden, kann man sie mit Refine mühelos clustern. Mehr Infos dazu gibt es im Refine-Blog oder in diesen Tutorial-Videos:

Erste Spielereien mit Refine zeigen, dass es ein mächtiges, aber durchaus schnelles Tool ist. Einsatzszenarien sind zum Beispiel die Aufbereitung von Open Government Data vor der Publikation. Vor diesem Release hieß die Software Freebase Gridworks und wurde u.a. eingesetzt, um Daten für data.gov.uk aufzubereiten. Dieses Beispiel ist neben anderen im Google-Refine-Blog zu finden.