[OSM-S] Semantische Graphen - Nutzen und Use-Cases

[Stefan Kaufmann]

Am 07.08.24 um 08:30 schrieb Seifert, Dietmar:

> Ich mußte mich erstmal kurz bei Wikipedia schlau machen bzgl. GLAM und Knowledge Graphen. Letzteres hatte ich zwar schon mal kurz im Blick, aber mir ist noch nicht klar, was für einen Nutzen die Verwaltung dadurch für sich und die Öffentlichkeit erzeugen kann.
> 
> Kennst Du einen Anwendungsfall im Transportbereich, egal ob ÖV oder nicht?

Sorry fuer die Abkuerzung :) Bei Galerien, Bibliotheken, Archiven und 
Museen (was dann oft mit GLAM zusammengefasst wird), gibt es haeufig 
eine bessere Ver-Datung ihrer Informationen als in anderen Bereichen.

Gerade im Archiv- und Bibliotheksbereich ist man da der klassischen 
Verwaltung wirklich meilenweit voraus. Aus dem Bibliothekswesen kommen 
so Ideen wie Dublin Core, mit denen Medien beschrieben werden koennen 
(<https://de.wikipedia.org/wiki/Dublin_Core>). Die sind da auch sehr 
genau mit Bezeichnungen und Ontologien: Ist mit "Moby Dick" das Werk, 
die Expression, eine bestimmte Manifestation oder ein physisches 
Exemplar gemeint? :D (siehe 
<https://www.buecherei-praxishandbuch.de/n2020/index.php?id=282>)

Eine Zeit lang wirkte es auch so, als wuerden Ideen wie Dublin Core und 
Co. ein maschinenlesbares Web einlaeuten. Darauf bezog sich Berners-Lee 
in The Next Web 2009, wo auch die Idee von 5-Sterne-Open-Data herkommt: 
<https://www.youtube.com/watch?v=OM6XIICm_qo>.

Damals war aber die Idee noch eine andere, und das sieht man auch bei 
den Beispielen von 2010 z.B. auf 
<https://5stardata.info/de/examples/gtd-4/>. Dort geht man davon aus, 
dass man so Dinge wie Mikroformate 
<https://de.wikipedia.org/wiki/Mikroformat> oder good old semantic Web 
einsetzt, um der menschenlesbaren Dimension eine maschinenlesbare 
Dimension an die Seite zu stellen.

Das gaebe dann implizit auch einen Graphen, die moderne Idee stellt sich 
fuer mich aber etwas anders dar.

Anstatt Informationen in einer relationalen Datenbank oder – mangels 
einer solchen – in einzelnen Excel-Sheets zu speichern, legt man sie in 
einer Graphdatenbank ab. Informationen sind dann nicht mehr als Tabelle 
organisiert z.B. beim Baumkataster, wo dann jeder Baum eine Zeile mit 
1…n Feldern hat.

Stattdessen wird ein Objekt (ein Baum, eine Strasse, ein Konzept) mit 
Tripeln beschrieben, die die Grammatik Subjekt-Praedikat-Objekt haben. 
Also z.B.

Stuttgart
ist eine
Grossstadt

Stuttgart und Grossstadt sind Objekte, die mit dem Praedikat „ist eine“ 
verbunden werden. "Stuttgart" wird aber auch mit "Regierungsbezirk 
Stuttgart" verbunden: Stuttgart - ist Teil von - Regierungsbezirk Stuttgart.

Im Beispiel des Baumkatasters ist ein bestimmter Baum dann z.B. ein 
Individuum des Taxons Linde. Er hat eine geographische Koordinate, eine 
Hoehe (z.B. in Zentimetern, das ist dann kein Objekt sondern ein 
Literal) und weitere Parameter, die alle so ausgedrueckt werden.

Prinzipiell kann fast alles, was als Excel-Sheet abgelegt wird, auch als 
solch ein Graph mit Tripeln ausgedrueckt werden. Der wesentliche 
Unterschied ist, dass die Datenobjekte und die Praedikate durch URIs 
bezeichnet und dadurch auch maschinell interpretierbar sind – und dass 
man dabei auf Wissen verweisen kann, das anderswo liegt. Beim Import 
solcher Daten muss ich daher nicht die Semantik jeder Zeile haendisch 
zuordnen, sondern die kommt mehr oder weniger automatisch mit. Bislang 
kann ich halt haendisch per Augenabgleich sagen, okay, das ist eine 
Linde. Hier kann ich aber direkt codieren, dass das Konzept "Linde" in 
der GRIN-Datenbank unter dem URI 
<https://npgsweb.ars-grin.gov/gringlobal/taxon/taxonomygenus?id=12151> 
codiert ist und in der OSM als "Tag:genus=Tilia".

Das muss ich dann nicht einmal selber pflegen, denn das ist am Ende der 
Clou mit Linked Data. Ich kann in meinem lokalen Knowledge Graph fuer 
die Baumdatenbank sagen, der Baum XY ist Instanz des Taxons Linde. Das 
Taxon Linde lege ich an – da schreibe ich aber nur rein, dass das 
dasselbe ist (sameAs) wie <http://www.wikidata.org/entity/Q127849>. Dort 
stehen dann GRIN-ID und OSM-Tag drin – das brauche ich gar nicht mehr 
aktuell halten und pflegen. Ich habe lokal quasi nur einen Platzhalter, 
der das Objekt definiert und an eine andere Stelle verlinkt.

Genau dasselbe Konzept ist auch bei den typischen Problemfaellen gerade 
im Kommunalbereich zu finden. In der Regel findet man fuer jede einzelne 
Strasse in den verschiedenen Datensets einer Kommune so drei bis acht 
verschiedene Schreibweisen. Ein Matching ueber mehrere Datenquellen 
hinweg ist dann jedes Mal ein Krampf. Hier koennte man dann auch sagen, 
dass es einen beliebigen fuehrenden Knowledge Graph fuer das 
Strassenverzeichnis gibt – und sei es Wikidata, ganz ketzerisch gesagt. 
Hauptsache es gibt stabile URIs als Identifier. Und dann kann ich diesen 
URI in allen anderen Systemen anstelle des Strassennamens nehmen.

(Theoretisch kann man natuerlich auch immer z.B. den numerischen 
Strassenschluessel einer kommunalen Strassendatenbank o.ae. waehlen. 
Wenn man aber vom einen Graph den anderen verlinkt, kann ich mir das in 
der Ansicht durch das Label des verlinkten Elements ersetzen lassen. Ich 
tippe im UI quasi den Name/das Label des Datenobjekts ein, habe eine 
Autovervollstaendigung, waehle das Datenobjekt aus und bekomme einfach 
nur das Label/den richtigen Namen angezeigt. Hinter den Kulissen ist 
aber der URI verlinkt)


> Ich würde da gerne etwas einsteigen und mehr erfahren wollen. Kannst Du Dir vorstellen, zu dem Thema einen Vortrag, z.B. im OpenTransportMeetup, zu halten?

Tatsaechlich schraube ich mit einer Kollegin seit einer ganzen Weile 
daran herum, passendes Lernmaterial auszuarbeiten. Das koennte ich aber 
zB im OTM auch mal testen, wenn es mehr Form angenommen hat.

regards,
-stk