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.
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:
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.
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 wurde im Rahmen der Leipzig Data Initiative wenigstens für längerfristig persistente Datenbestände im Leipzig Data Seminar verhandelt.
Siehe auch die Änderungsanmerkungen in den untergeordneten Webseiten.