LEO – Die Leipzig Ontology

Das Leipzig Data Projekt hat sich das Ziel gestellt, einen gewissen Grundstock an Referenzdaten und insbesondere URIs im RDF-Format zu sammeln, mit denen sich Ereignisse und Aktiviäten in der Leipziger Stadtlandschaft referenzieren und damit beschreiben lassen. Mit Blick auf die geringen verfügbaren Ressourcen liegt der Schwerpunkt dabei auf Daten mit geringem Änderungsbedarf, die in unserem git Repo vorgehalten werden.

Mit dem Projekt wird der Ansatz verfolgt, Daten möglichst aktuell vorzuhalten, was nur im Rahmen der verfügbaren Personalressourcen gelingt. In jedem Fall bedeutet diese Policy,

dass Daten, die als nicht mehr aktuell identifiziert wurden, aus dem Datenbestand gelöscht werden

und höchstens noch über die git-Historie rekonstruiert werden können.

Nach Abschalten der Linked Data Strukturen nach mehrfachen DOS-Attacken im August 2017 sind die aus unserem git Repo herunterladbaren Quellen die primären Datenquellen, die regelmäßig in einen RDF Data Store geladen werden, über dessen SPARQL Endpunkt auf die Daten zugegriffen werden kann.

Inhalt dieser Seite

  • Übersicht über die einzelnen RDF-Graphen
  • Allgemeine Übersicht über den Datenbestand
  • Vorhaben in der Diskussion und Bearbeitung

Übersicht über die einzelnen RDF-Graphen

Die Daten liegen jeweils als RDF-Graphen im Turtleformat vor und werden außerdem über unseren Sparql Endpunkt ausgeliefert. Sie sind auch in unserem git-Repo verfügbar. Sie sind nach Sachthemen geordnet:

Allgemeine Übersicht über den Datenbestand

Kern dieses Datenbestands sind aktuell Akteure, Orte, Adressen und Geodaten, die zusammen ein System von White Pages bilden, mit denen Geolokalität auf einheitliche Weise referenzierbar (und damit auch aufeinander beziehbar) wird. Basis dieses Systems sind die aus dem API-Leipzig Projekt und damit letztlich von der Stadt Leipzig übernommenen und weiter aktualisierten über 65.000 Datensätze Adressdaten, von denen knapp 63.000 mit Geokoordinaten (Übernahme aus Nominatim mit anschließender weiterer Konsolidierung und Qualitätssicherung) versehen sind. Damit lassen sich Leipziger Orte an Geodaten binden und so auf Karten lokalisieren. Die höhere Qualität gegenüber eine reinen Referenzierung der Geokoordinaten etwa über die Google-API ergibt sich aus der vorgenommenen Disambiguierung, die etwa dem Unterschied zwischen der Verwendung von Rechneradressen und Rechnernamen entspricht, sowie der Möglichkeit, an diese Adress- oder Orts-URIs weitere Information zu binden. Diese White Pages werden vor allem im Leipzig Data Event Projekt fortgeschrieben.

Leipzig Data ist nicht das einzige Projekt mit diesem Anspruch. So kennt etwa API Leipzig ebenfalls eine größere Zahl von “Hosts” und “Venues” und OpenStreetMap taggt als “Ways” im Kartenmaterial präsente Gebäude mit Zusatzinformationen. Für Referenzzwecke ist es wichtig, hier entsprechende Übersetzungstabellen vorzuhalten und zu verwalten, was für API Leipzig mit den “API-References” und für OSM mit einem geonames:nearbyFeatures Verweis nach linkedgeodata.org erfolgt.

Daneben gibt es Einzelprojekte, mit denen Daten aus verschiedenen Quellen aufbereitet worden sind wie MINT-Orte, Schulen, Polizeidirektion, Seniorenbüros.


Zur Herstellung von Interoperabilität auf Datenebene ist es erforderlich, sich über das dabei verwendete Vokabular zu einigen. Der relevante Abstimmungsprozess soll und wird im Rahmen der Leipzig Data Initiative wenigstens für längerfristig persistente Datenbestände im Leipzig Data Seminar verhandelt.


Vorhaben in der Diskussion und Bearbeitung

Vorgenommene Änderungen

Siehe auch die Änderungsanmerkungen in den untergeordneten Webseiten.

  • HGG 2018-01-07: Aktualisierung der Links in Jugendstadtplan.ttl und Ergänzung einiger Geodaten
  • HGG 2017-09-12: Einarbeiten von Informationen, die aus jedeschule.de extrahiert wurden, in Schulen.ttl
  • HGG 2017-09-10: Erweiterung UniversitaetLeipzig.ttl zu Hochschulen.ttl, Umbenennungen API-Referenzen.ttl zu Referenzen.ttl sowie StadtLeipzig.ttl zu Stadtverwaltung.ttl
  • HGG 2017-09-04: Traeger.ttl aufgelöst, siehe Akteure
  • HGG 2017-08: Abschalten des Linked Data Zugangs zu unseren Daten über OntoWiki wegen dauernder DOS-Attacken
  • HGG 2013-10-20: Adress-URIs einheitlich in die Form Data/<plz>.<ort>.<strasse>.<nr> gebracht, Straßenübersicht aus Adressen.ttl entfernt
  • HGG 2013-03-24: ical:sentBy foaf:Agent ergänzt. foaf:Agent Instanzen bei Traeger.ttl ergänzt
  • ld:relatedBundle hat als rdfs:range nun ld:Ort oder ld:Traeger
  • ical:contact als Literal für Kontaktinformation
  • HGG 2013-03-10: Strassenverzeichnis.ttl aus Adressen.ttl
  • HGG 2013-03: WeitereAdressen.ttl aufgebaut
  • HGG 2013-04-12: Personen nach foaf transformiert
  • Namensraum ‘cal:’ nach standardmäßiger Benennung ‘ical:’ umgesetzt.

Fragen und Vorhaben in Diskussion

  • Das Adressverzeichnis ist nicht vollständig, es fehlt zum Beispiel die gesamte Georg-Schwarz-Straße.
  • Tagging in Richtung Key-Value-Paare weiterentwickeln wie bei den OSM Map Features http://wiki.openstreetmap.org/wiki/Map_Features
    • Claus Stadler fragen, Muto-Ontologie anschauen
  • Infos zu einzelnen Einträgen, die sich nicht strukturiert abbilden lassen, werden dem Eintrag als rdfs:comment zugeordnet.