Schlagwortarchiv für: Linked Open Data

Basisregister und Normdaten als Wegbereiter für Linked Data

Basisregister sind zentrale Bestandteile eines Linked-Data-Ökosystems. Zusammen mit gemeinsam verwendeten Datenmodellen bzw. Ontologien sorgen sie dafür, dass Datenbestände auch über Organisationsgrenzen hinweg miteinander verknüpft werden können. Ohne sie wäre “Linked Data” nicht möglich. Ausgehend von einem laufenden Projekt, welches zum Ziel hat, die Publikation von Linked Open Data durch Schweizer Behörden voranzubringen, beschreiben wir den Status Quo und die geplanten Massnahmen, um die Publikation von relevanten Basisregistern und Vokabularen systematisch zu fördern.

Wie in einem früheren Artikel beschrieben (Estermann 2019), sollen im Rahmen eines Projekts im Auftrag von E-Government Schweiz jene Datenbestände identifiziert werden, die im Zusammenhang mit der Publikation von Linked Open Data (LOD) durch Schweizer Behörden als Basisregister oder als zentrale Vokabulare dienen können. Ihre zeitnahe Publikation als Linked Open Data würde der Verlinkung von Behördendaten Vorschub leisten. Dass die Publikation von Basisregistern oder zentralen Vokabularen in der Schweiz ein sehr wichtiges Thema ist, hat sich auch an der anfangs Juli durchgeführten  Unconference Opendata.ch/2019 gezeigt: Die Frage, welche Basisregister und Vokabulare Schweizer Behörden als LOD publizieren sollten, wurde von den Teilnehmenden als eine der wichtigsten Fragen eingestuft und in einem Workshop behandelt.

Um jene Basisregister und Vokabulare zu identifizieren, denen im Kontext von Schweizer Behördendaten das grösste Nutzungspotenzial zukommt, führte die Berner Fachhochschule im Rahmen eines Projekts von E-Government-Schweiz ein erstes Screening von Datenbeständen durch. Dabei wurden parallel zwei Ansätze verfolgt:

  • Screening von existierenden Datenbeständen von Schweizer Behörden im Hinblick auf ihre Eignung als Basisregister oder Vokabulare.
  • Screening von Wikidata bezüglich Eignung als Basisregister oder Vokabular im Zusammenhang mit der Datenpublikation durch Schweizer Behörden.

Ergänzt wurde das Screening durch die Befragung von Schweizer Behörden, welche bereits heute Daten als Linked Data publizieren oder dies in naher Zukunft vorhaben. Dabei wurden speziell im Bereich der Archive und Bibliotheken noch weitere Daten aus dem Bereich der Gedächtnisinstitutionen und der Digital Humanities identifiziert.

Nachstehend werden die Vor- und Nachteile dieser verschiedenen Arten von Datenquellen kurz erörtert und erste Shortlists präsentiert, welche anschliessend von der Schweizer LOD-Community in einem offenen Prozess kommentiert und ergänzt werden sollen.

Datenbestände von Schweizer Behörden

Die meisten Datenbestände der Schweizer Behörden werden aufgrund eines gesetzlichen Auftrages erstellt und gepflegt. Deshalb kann nicht nur davon ausgegangen werden, dass die Daten von hoher Qualität sind, sondern dass auch die Kontinuität der Datenpublikation gewährleistet ist, dass also die Daten auch in Zukunft gepflegt und verfügbar gemacht werden. Dabei gilt es allerdings zu bedenken, dass die Tatsache allein, dass die Daten von Behörden bereitgestellt werden, noch kein Garant für die Datenqualität ist. Datenqualität ist als Prozess zu denken und wird erst im Zusammenhang mit konkreten Anwendungen fassbar. Eine vielfältige und häufige Verwendung der Daten erhöht im Allgemeinen die Datenqualität, da Fehler und Unzulänglichkeiten der Daten oft erst bei deren Nutzung entdeckt werden. Bei etlichen Behördendaten (z.B. Handelsregister, Gemeindeverzeichnis) kann davon ausgegangen werden, dass sie regelmässig und in unterschiedlichen Kontexten verwendet werden; bei anderen bleiben der bisherige Verwendungskontext und die Verwendungshäufigkeit weitgehend im Dunkeln (z.B. kantonale Denkmallisten).

Leider werden heute erst wenige Datensätze der öffentlichen Verwaltung als Linked Open Data publiziert, und die Machbarkeit und Bereitschaft der verschiedenen Datenhalter im Hinblick auf eine solche Publikation muss in der Regel erst noch geklärt werden.

Basierend auf dem Screening und dem Ergebnis des oben erwähnten Workshops haben wir eine erste Shortlist von Datenbeständen von Schweizer Behörden erstellt, welche im Zusammenhang mit der Publikation von Schweizer Behördendaten als Linked Open Data als Basisregister oder als kontrollierte Vokabulare dienen könnten:

Bezeichnung Verantwortliche Behörde Kurzbeschrieb
UID-Register BFS Im UID-Register werden alle in der Schweiz tätigen Unternehmen geführt. Die Informationen zu den Unternehmen sind der Verwaltung (UID-Stellen), dem Unternehmen selbst und teilweise der Öffentlichkeit zugänglich.
Handelsregister Kantonale Handelsregisterämter In der Schweiz sind die Handelsregister dezentral organisiert und werden von den Kantonen geführt. Die Handelsregister sind öffentlich und dienen der Konstituierung und der Identifikation von Unternehmen. Sie bezwecken die Erfassung und Offenlegung handels- und gesellschaftsrechtlich relevanter Tatsachen und tragen dadurch zur Gewährleistung der Rechtssicherheit sowie zum Schutz von Dritten bei.
TERMDAT Bundeskanzlei (BK) TERMDAT ist die mehrsprachige Terminologie-Datenbank der schweizerischen Bundesverwaltung und enthält u.a. auch die offiziellen Namen aller Bundesämter. Prototypisch wurde eine Teilumsetzung als Linked Data bereits realisiert.
Nomenklaturen BFS Die Nomenklaturen des BFS umfassen insbesondere:

  • Gemeindeverzeichnis,
  • Historisiertes Gemeindeverzeichnis,
  • PLZ-Verzeichnis.

Ausserdem wäre ein versionierter Abgleich zwischen PLZ und BFS Gemeindenummern wünschenswert.

Amtliches Ortschaften- verzeichnis  swisstopo Amtliches Ortschaftenverzeichnis mit Postleitzahl und Perimeter.
Eidg. Gebäude- und Wohnungs- register (GWR) BFS Erfasst die wichtigsten Grunddaten zu den Gebäuden und Wohnungen der Schweiz für statistische und administrative Zwecke.
NOGA BFS Die “allgemeine Systematik der Wirtschaftszweige” (Nomenclature générale des activités économiques) dient zur konsistenten Verwendung von Branchennamen bei statistischen Auswertungen.
ISCO BFS Internationale Berufsnomenklatur (International Standard Classification of Occupations) zur konsistenten Verwendung von Berufsnamen bei statistischen Auswertungen.

Diese Liste ist als Vorschlag zu verstehen, welche bestehenden Datensätze aus Nutzungsperspektive mit höchster Priorität als Linked Open Data publiziert werden sollten.

Wikidata

Datenbestände in Wikidata haben den Vorteil, dass sie aufgrund des Crowdsourcing-Ansatzes einen teilweise sehr guten Abdeckungsgrad haben, und fehlende Daten unkompliziert erstellt bzw. ergänzt werden können. Ausserdem ist bei Daten aus Wikidata eine sofortige Integration mit einer weltweiten Linked-Data-Cloud gegeben, da die Rekonzilierung mit anderen Datenbeständen gleich beim Dateningest erfolgt, und nicht erst nach der Datenpublikation, wie es bei anderen Datensätzen oft der Fall ist.

Der Crowdsourcing-Ansatz führt aber auch zu gewissen Problemen, insbesondere hinsichtlich der Datenqualität. Diese lässt sich nur mit zusätzlichem Aufwand sicherstellen, z.B. durch die Identifikation von und Einschränkung auf verlässliche Quellen. Ausserdem besteht in diversen Bereichen ein beträchtlicher Bedarf hinsichtlich Datenbereinigung sowie Harmonisierung der Modellierungspraxis.

Auch hier haben wir basierend auf dem Screening eine erste Shortlist von Datenbeständen in Wikidata erstellt, welche im Zusammenhang mit der LOD-Publikation von Schweizer Behördendaten als Basisregister oder als kontrollierte Vokabulare dienen könnten:

Bezeichnung Wikidata-Query Anz. Einträge 

(Juni 2019)

Verwaltungseinheiten der Schweiz https://w.wiki/53U 5139
Schweizer Organisationen https://w.wiki/53x 12596
Schweizer Gedächtnisinstitutionen https://w.wiki/5Gm 2169
Menschen, die in der Schweiz geboren sind https://w.wiki/53V 24537
Menschen, die in der Schweiz gestorben sind https://w.wiki/53X 13396
Menschen mit Schweizer Nationalität https://w.wiki/53Z 31006
Menschen mit Schweizbezug (Bürgerrecht, Geburts- oder Sterbeort, Arbeitsort oder Wohnsitz) https://w.wiki/53c 40549
Bauwerke in der Schweiz https://w.wiki/53f 20147
Schweizer Kulturgüter von nationaler oder regionaler Bedeutung (KGS-Inventar) https://w.wiki/53j 13121
Sprachen https://w.wiki/53m 12987
Taxons https://w.wiki/53o 2549556
Gewässer in der Schweiz https://w.wiki/53q 2942
Berge in der Schweiz https://w.wiki/53r 7965
Chemische Verbindungen https://w.wiki/53$ 162545
Menschliches Geschlecht oder Gender (Vokabular) https://w.wiki/546 10+
Stoffe, aus denen Objekte gefertigt werden (Vokabular) https://w.wiki/548 3318
Farben, die dazu verwendet werden, um Objekte zu identifizieren (Vokabular) https://w.wiki/54D 61
Farben https://w.wiki/54C 191

Interessant könnte es auch sein, offizielle Behördendaten direkt in Wikidata zu publizieren. Das hätte den Vorteil, dass damit direkt ein hohes Nutzungspotential im internationalen Kontext erschlossen werden kann, da die Daten einfacher mit Daten aus anderen Ländern kombiniert werden können. Besonders sinnvoll ist ein solches Vorgehen bei Themen, die auch im Rahmen von Wikipedia-Artikeln abgehandelt werden sollen. Um die semantische Interoperabilität der Daten über die Ländergrenzen hinweg zu gewährleisten, bedarf es einer entsprechenden Koordination zwischen den datenpublizierenden Stellen. Falls diese nicht schon anderweitig erfolgt, kann diese Koordination direkt im Rahmen der Wikidata-Community stattfinden.

Daten aus dem Bereich der Gedächtnisinstitutionen und der Digital Humanities

Seitens der Nationalbibliothek und der beiden befragten Archive wurde zudem auf die Bedeutung von internationalen Normdaten und Vokabularen hingewiesen. Dazu gehören beispielsweise die Gemeinsamen Normdatei (GND), welche von der Deutschen Nationalbibliothek und den deutschsprachigen Bibliotheksverbünden kooperativ geführt wird, sowie das Virtual Internet Authority File (VIAF) und die Dewey Decimal Classification, welche beide vom US-amerikanischen Online Computer Library Center (OCLC) betrieben werden.

Im Hinblick auf die Vernetzung von Schweizer Beständen spielen zudem weitere Normdaten und Verzeichnisse eine Rolle, die sich speziell auf die Schweiz beziehen:

Bezeichnung Betreiber Kurzbeschrieb
Gemeinsame Normdatei (GND) Deutsche Nationalbibliothek Normdatei für Personen, Körperschaften, Kongresse, Geografika, Sachschlagwörter und Werktitel, die vor allem zur Katalogisierung von Literatur in Bibliotheken dient, zunehmend aber auch von Archiven, Museen, Projekten und in Web-Anwendungen genutzt wird.
Virtual International Authority File (VIAF) OCLC Virtuelle internationale Normdatei, welche 25 nationale Normdateien über eine Konkordanzdatei verlinkt.
Dewey Decimal Classification OCLC Online Computer Library Center Die international am weitesten verbreitete Klassifikation für die inhaltliche Erschliessung von Bibliotheksbeständen. Sie wird hauptsächlich im anglo-amerikanischen Sprachraum eingesetzt..
Fotografie-Metadaten Foto CH Metadaten zu Schweizer Fotografen und Fotografiebeständen (Fotografen, Arbeitsorte, Institutionen, Bestände, Ausstellungen).
Inventar der Forschungsbibliotheken der Schweiz Swissbib/UB Basel Daten zu den rund 900 Schweizer Forschungsbibliotheken, die an den Bibliotheks-Metakatalog von Swissbib angeschlossen sind.
Authority files on Swiss history histHub Named Entities (Personen, Orte), Typologien (Berufe, Ortstypen) und Vokabulare (Vornamen, Konzepte), die im Zusammenhang mit historischen Beständen zur Schweiz von Relevanz sind. Einige davon befinden sich noch im Aufbau.
Metadaten des Historischen Lexikons der Schweiz HLS Metadaten zu den Einträgen im Historischen Lexikon der Schweiz (Koordinaten, Personen, Organisationen, Verlinkung auf GND und VIAF).
Metagrid SAGW / Dodis Konkordanz-Datei für historische Normdaten mit Schweiz-Bezug.

Historisierte Datenbestände als grosse Herausforderung

Eine besondere Herausforderung stellt die Verfügbarkeit und Nutzung von historisierten Datenbeständen dar. Dieses Thema wird in Gesprächen über die Publikation von Open Government Data als Linked Data immer wieder hervorgehoben, so auch am oben erwähnten Workshop. Dabei geht es nicht nur um die Verfügbarkeit an sich, die heute noch unvollständig ist (zum Beispiel Gemeindeperimeter). Sondern es geht auch darum, wie verschiedene historisierte Datenbestände verknüpft werden können: Dies ist heute oft nicht einfach, da bei der Historisierung der verschiedenen Datenbestände unterschiedliche Historisierungsansätze verfolgt wurden.

Nutzungsszenarien

Wie aus der Befragung von Schweizer Behörden hervorgeht, welche bereits heute Daten als Linked Data publizieren oder dies in naher Zukunft vorhaben, wird der zusätzliche Aufwand, der in die Aufbereitung und die Verknüpfung der Daten mit anderen Beständen gesteckt wird, damit motiviert, dass damit:

  1. künftig eine verbesserte Suche in den Beständen angeboten werden kann (z.B. mehrsprachige Suche in historischen Beständen des Bundesarchivs; geolokalisierte Suche in Beständen des Staatsarchivs Basel-Stadt);
  2. neue Erkenntnisse generiert werden können (z.B. Verknüpfung von Datenbeständen des BAFU oder der Angaben aus dem Handelsregister mit statistischen Kennzahlen des BFS; Integration von semantisch angereicherten Archivkatalogen in Forschungsumgebungen); und
  3. die Transparenz erhöht wird (z.B. Tarif der Schweizer Stromversorger; Daten aus der Strommarkt-Überwachung).

Nächste Schritte

Die oben aufgeführten Tabellen reflektieren den aktuellen Stand bezüglich der Basisregister und Vokabulare, die aus Nutzerperspektive mit höchster Priorität als Linked Data verfügbar gemacht werden sollten. In den nächsten Wochen werden wir weitere Inputs seitens der Schweizer LOD-Community einholen, um die Tabellen und die Auflistung möglicher Nutzungsszenarien zu ergänzen, so dass wir am Ende über eine breit abgestützte und priorisierte Liste von Basisregistern und Vokabularen verfügen.

In einem nächsten Schritt werden wir diese Liste im Dialog mit den Datenhaltern abarbeiten, um neben der Dimension des Nutzungspotenzials auch den Bewertungskriterien der “Machbarkeit” und der “Bereitschaft des Datenhalters” (siehe Estermann 2019) Rechnung zu tragen. Ergebnis dieses nächsten Schrittes werden mehrere zu LOD aufbereitete Datensätze sein, wie auch eine Analyse zu den Herausforderungen und Hürden im Hinblick auf die Konversion weiterer Datenbestände zu Linked Data. Basierend auf dieser Analyse sollen anschliessend Empfehlungen zum weiteren Vorgehen formuliert werden.

Der erste Teil des Artikel ist bereits erschienen.


Bibliographie

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

«Daten als Infrastruktur werden Realität sein»

Der Verein opendata.ch hat gestern Abend einen neuen Präsidenten gewählt. Andreas Kellerhals, der frühere Direktor des Bundesarchivs übernimmt das Amt des scheidenden André Golliez. Ein Gespräch über die neue Strategie des Vereins.

Herr Kellerhals, Sie waren bis Januar dieses Jahres Direktor des Bundesarchivs, noch bis Ende Jahr sind Sie Beauftragter des Bundes für OGD und nun wurden Sie zum Präsidenten von opendata.ch  gewählt– was ist Ihre Motivation?

Andreas Kellerhals

Andreas Kellerhals: Mit dem Abschluss der Redaktion der neuen Strategie ist auch meine Arbeit als Beauftragter für OGD abgeschlossen. Ich werde ab Jahresbeginn im Ruhestand sein und kann mich voll und ganz opendata.ch widmen, ohne dass mein Amt in Konflikt geraten könnte mit weiteren beruflichen Verpflichtungen. Das Thema Open Data beschäftigt mich schon seit der ersten Open Data Konferenz in der Schweiz 2011 im Schweizerischen Bundesarchiv. Ich war massgeblich verantwortlich für die Realisierung des ersten gesamtschweizerischen Portals opendata.admin.ch (2013) bzw. von dessen Nachfolgeportal opendata.swiss (2016).
Bei diesen Projekten bemühte ich mich vor allem auch darum, möglichst viele Daten zu publizieren und auf dem Portal zu referenzieren sowie die Nutzung dieser Daten anzuregen. Zu einer wirksamen Förderung einer Open Data-Kultur, wie das schon in der ersten bundesrätlichen Strategie geheissen hat, fehlten damals leider die nötigen Mittel. Aber die Plattform und die bis heute publizierten Datensätze sind dennoch ein ziemlicher Erfolg. Es ist jedoch auch klar, dass sowohl publikationsseitig wie nutzungsseitig noch vieles zu tun bleibt. Da will opendata.ch unterstützen und anregen. Die weitere Entwicklung sollte nicht einfach angebotsseitig, sondern im Dialog mit allen Stakeholdern definiert werden. Da gibt es also viele Betätigungsfelder, die ein Engagement lohnen.

Wie profitieren Sie von Ihren vorherigen Ämtern, und wie sieht Ihr Ideal aus?

Die Erfahrungen aus der Verwaltung, aus dem Prozess der Strategiedefinition ebenso wie aus der konkreten Arbeit der Strategieumsetzung halte ich für eine gute Voraussetzung, um das bisher schon erfolgreiche Werk von opendata.ch weiterzuführen. Das Ideal ist immer noch eine transparentere Welt mit klar wahrgenommenen Verantwortlichkeiten und folglich auch einer selbstverständlichen Rechenschaftsbereitschaft, in der Lösungen partizipativ entwickelt und Ideen im Dialog umgesetzt werden.

Was wollen Sie als Präsident mit dem Verein erreichen – Stichwort neue Strategie?

Die neue Strategie von opendata.ch – ebenso wie die neue Strategie des Bundesrates – orientiert sich eigentlich immer noch an den gleichen „grossen“ Zielen: mehr Transparenz, mehr Partizipation, bessere Rechenschaftsfähigkeit – der allgemeine Kontext der Open Data Bewegung bleibt auch weiterhin der massgebliche Bezugsrahmen. Für die Umsetzung muss alles konkreter und damit automatisch auch bescheidener formuliert werden, aber die Ambitionen bleiben: Es ist klar mein Ziel, mit opendata.ch dazu beizutragen, dass mehr Daten publiziert werden. Alle neuen Daten sollten automatisch als offene Daten genutzt werden können und auch die bereits bestehenden sollten, wenn möglich thematisch aufeinander abgestimmt und nachfrageorientiert, offen publiziert werden.

Generell geht es mir darum, dass dank offener Verwaltungsdaten nicht nur an Abstimmungssonntagen Demokratie praktiziert wird, sondern bereits viel früher in Verwaltungsprozessen eine breite Partizipation der Betroffenen und Beteiligten möglich wird.

Die publizierten Daten sollen ausreichend beschrieben sein und in nutzbaren Formaten vorliegen, d.h. vorzugsweise als Linked Open Data. Daneben gibt es natürlich noch die Fragen der rechtlichen und finanziell unentgeltlichen Zugänglichkeit. Zu deren Lösung kann opendata.ch einiges beitragen. Weiterer Schwerpunkt muss zudem die Förderung der so genannten Digital Skills und der Data Literacy sein, ohne die ein kompetenter Umgang mit Daten nicht möglich ist. Auch dazu hat opendata.ch schon viel geleistet und wird dies auch künftig tun.

Ein Blick in die Zukunft: die Schweiz in 10 Jahren im Bereich Open Data und OpenGLAM – Ihre Vision?

In zehn Jahren werden alle Verwaltungsdaten von Bund, Kantonen und Gemeinden als offene Verwaltungsdaten publiziert und die schon bestehenden Datenbestände, an denen sich ein öffentliches Interesse manifestiert hat, sind ebenfalls frei zugänglich. Daten als Infrastruktur werden weltweit Realität sein und die Schweiz wird eine gute Position in diesem Daten-Ökosystem einnehmen. Daten aus dem GLAM-Bereich müssen unbedingt dazu gehören. Alle diese Daten werden rege genutzt, sowohl in demokratischer Absicht, zu Bildungszwecken oder auch mit wirtschaftlichen Zielsetzungen.

Wenn Sie speziell den GLAM-Bereich ansprechen, dann sind viele Nutzungsmöglichkeiten denkbar, aktuell in politischer Perspektive z.B. speziell auch für die Provenienzforschung resp. den transparenten Provenienznachweis.

Generell geht es mir darum, dass dank offener Verwaltungsdaten nicht nur an Abstimmungssonntagen Demokratie praktiziert wird, sondern bereits viel früher in Verwaltungsprozessen eine breite Partizipation der Betroffenen und Beteiligten möglich wird. Ausserdem werden in zehn Jahren neue wirtschaftliche Aktivitäten Alltag geworden sein, die auch auf diesen Daten basieren und – vielleicht – werden sogar die Unternehmen gemerkt haben, dass die Publikation ihrer Daten nicht das Ende erfolgreicher Geschäftsführung bedeutet, sondern ein wichtiger Faktor für wirtschaftlichen Erfolg ist.

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

The Linked Data Service of the Federal Spatial Data Infrastructure

In this article we provide some insights and lessons learned acquired with the realization and the maintenance of the Linked Data Service of the Federal Spatial Data Infrastructure (FSDI) geo.admin.ch. We also try to identify pitfalls and areas where engagement and investments are needed in order to facilitate unlocking the potential of the Geographic Information and bringing it on the Web.

Geographic Information and the Web

The Geographic Information (GI) and the Web appear to be good friends: GI is pervasive on the Web and Web technologies are used by the GI community to provide access to geodata. In August 1991 Tim Berners-Lee announced the WWW Project on the newsgroup alt-hypertext; the Xeroc Parc Map Viewer was one of the first Web applications and went online in 1993. Since then the GI community has evolved around the concept of spatial data infrastructures (SDIs) with the main idea to use the Web in order to connect isolated GI Systems and exchange GI. The implementation of SDIs has been supported by an international, top down and highly centralized standardization effort driven by organizations like the Open Geospatial Consortium (OGC) and ISO Technical Committee 211.

The Web has instead moved with a complete different approach, more agile, decentralized and bottom up. Just consider, for example, that the GeoJSON (a geospatial data interchange format based on JSON) and the JSON-Schema (the vocabulary to annotate JSON documents) specifications sum up to some fifty pages, while the OGC standard GML (an xml-based modeling language and interchange format) is about four hundred pages.

At the end of the story, the Web is today mostly agnostic about SDIs. The discovery of information resources in SDIs is delegated to catalog services providing access to metadata and users generally cannot simply follow links to access data. OGC Web services do not address indexing of the resources by general purposes search engines.
To address this and other related issues, OCG and the W3C have teamed up to advise on best practices for the publication of spatial data on the Web based on Linked Data.

The Linked Data Service of geo.admin.ch

With these considerations in mind, we at swisstopo started to consider the possibility to publish geodata as Linked Data in 2016. We launched a project with the objective to publish a selection of geodata: the result is the Linked Data Service of geo.admin.ch, the Federal Geoportal. The service is operational since March 2017 and we publish so far two main datasets: swissBOUNDARIES3D (administrative units versioned since 2016) of swisstopo and the Public Transport Stops of the Federal Office of Transport.
We use a standard process for the publication of data according to the Linked Data principles, implying the serialization of the data in RDF (here we use the GeoSPARQL standard), the storage of the triples in a triple store and the setup of a Linked Data Frontend.
We use the Virtuoso Open Source Edition as triple store and the open source product Trifid as Linked Data frontend for URI dereferencing and content negotiation.

Both software components are dockerized: we use Rancher as composer.

The good

Providing geodata as Linked Data results in a mutual exchange of benefits between the GI community and the Linked Data / Web community. The GI community brings new ways of querying data: the GeoSPARQL standard is in fact not just a vocabulary for encoding geodata in RDF, since it provides above all extensions to the SPARQL language, enabling to query resources based on their spatial relations. Queries like “Find all resources of type A (with a point geometry) within the resource of type B (with a polygon geometry)” or “Find all resources of type A within a distance of X kilometers from point C” are simply not possible with standard SPARQL.

On the other hand the Linked Data / RDF approach to data modeling can ease the burden of communicating data semantics. Data modeling within the GI domain is based on the “model driven approach”, where data semantics resides in (complex) conceptual and database schemas and has been traditionally very hard to share.

Linked Data users do not need to understand / know all this complexity to adequately use the data, since data semantics is in the data itself. Here not only objects (resources) are on the Web but also objects properties (what we call attributes in the GI domain and predicates in RDF) are first class objects and are on the Web: objects types and predicates are described via web-accessible open agile vocabulary definitions and this definitions are reusable.

The bad

The bad news is that Virtuoso Open Source does so far not support GeoSPARQL (there are plans to support it according to this tweet). It actually supports spatial queries but these are based on built-in spatial functions instead of using those defined by the GeoSPARQL standard. Within the open source community we don’t see so far a valuable alternative to Virtuoso, on the other hand the interest about GeoSPARQL is  growing more and more and commercial solutions exist, that start to support it. GraphDB for example has a good support and so should the new Stardog version (to be tested).

We argue that the standard approach to Linked Data publication built around a triple store is not very adequate when:

  • A data publication pipeline is already in place, as is the case for the FSDI. Here one has to deal with data redundancy and synchronicity;
  • Data to be published is somehow massive and dynamic, meaning there is a high update frequency (daily, hourly).

To address these issues we are investigating alternative solutions based on virtual graphs. The idea here is to have a proxy on top of the main data storage and let the proxy provide RDF serialization at runtime.

Again the problem is that open source solutions are very few: D2RQ, a reference system for accessing relational databases as virtual RDF graphs, is a very old technology and does not seem adequate for a production environment; ontop seems a promising technology but does not support so far GeoSPARQL (there are plans to support it according to this post).

One more issue about usage: we are monitoring the service and the statistics do not show so far big numbers. We will have to work in this sense maybe by supporting showcases and make developers aware of the power of the Linked Data approach: one simple data model (RDF) with enough semantics enabling easy understanding of the data and a unique interface (SPARQL).

The ugly

When we started our project, one of the objectives was to try to improve the indexing of our data by the main search engines: Linked Data is an easy and valuable way to bring geodata to the Web and to improve geodata visibility and cross-domain interoperability.
We were aware that we had to work with the schema.org vocabulary and we spent some time in trying to debug our RDF serialization with the Google structure data tools. We eventually had to realize that Google does not really follow the “open world assumption” to Linked Data publication: the structured data tool have an issue with mixed vocabularies, simply said they only recognize schema.org definitions, while definitions from other vocabularies produce errors.

Now schema.org is simply not sufficient to describe geodata. Let us make a simple example: to tag a resource of type “administrative units” one can use the schema.org type “AdministrativeArea” but there is no possibility to specify the level of the administrative unit (is it a Municipality or a Canton?). Schema.org fails on one of the main Linked Data principles: reuse. It just does not care about existing standards and vocabularies.

Google has recently launched a new “Dataset Search” service with a bit more “openness”, since here they also support the “Data Catalog Vocabulary” (DCAT) from the W3C beside schema.org.

Amazon has also recently launched its “Registry of Open Data on AWS” for discovery and sharing of datasets available as AWS resources.

The Frictionless Data initiative from Open Knowledge International is yet a further approach to data publication and sharing.
In the quest for unlocking the potential of (geo)data, data providers have to navigate on sight in a sea full of alternative and competing «same-but-different» solutions.

We argue that the Linked Data approach is the one with the higher, yet unexplored potential.

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Semantische Suchabfragen mit der Linked Open Data Cloud generieren

“S-O-WAS” – Semantic-and -Ontology-based-Web-Applications-Searchform” erlaubt die maschinengestützte Formulierung von semantischen Suchanfragen in normierten Metadatenfeldern, gezeigt am Beispiel einer Autoren- und Schlagwortsuche mittels Identifikator der Gemeinsamen Normdatei. Unsere AutorInnen haben eine Konzeptstudie während des OpenGLAM.at Kulturhackathons 2018 erarbeitet.

Die zahlreichen und vielfältigen Bestände von Galleries, Libraries, Archives and Museums (GLAM) sind im Laufe von Jahrhunderten entstanden. Die umfangreichen Sammlungen stellen KuratorInnen vor die Aufgabe, geeignete Ordnungsprinzipien zu etablieren und effiziente Suchmöglichkeiten anzubieten. Eine besondere Herausforderung stellen Rechercheanfragen dar, die selbst Ungenauigkeiten bergen oder mit Unbekannten operieren. Dem klassischen enzyklopädischen Weg einer Vorrecherche kann mittels semantischer Suchabfragen aus Linked-Open-Data-Quellen eine moderne Alternative entgegengestellt werden. In Verbindung mit dem in GLAM-Institutionen verbreiteten Einsatz von Normdaten1 zur Beschreibung von geistigen Schöpfern, mitwirkenden Personen und unterschiedlichen Schlagworten können solche Suchabfragen abseits einer potentiell unscharfen Textsuche auch durch den Einsatz von Normdaten-Identifikatoren eine hohe Trefferpräzision erreichen.

Unscharfe Suche in scharfen Metadaten

Die Beschreibung von Bestandsobjekten in GLAM-Institutionen hat eine lange Tradition und baut auf allgemein verbreiteten Regelwerken und Standards auf.2 Diese Metadaten bilden dann bereits einen Textkörper, der dann auch mit Volltextelementen wie Beschreibungen, Abstracts ergänzt werden kann. Die Indexierung der verfügbaren Textbausteine erlaubt eine Textsuche. Die grösste Herausforderung dabei ist die Genauigkeit, die mit Hilfe von Methoden der Informationswissenschaft gemessen wird. Eine der häufig verwendeten Methoden ist, mit dem sogenannten F-Mass sowohl Genauigkeit (precision) als auch Trefferquote (recall) gewichtet zu ermitteln, so dass die Ergebnisliste möglichst wenige unerwünschte Objekte enthält (“false positives”) und andererseits möglichst wenige gewünschte Objekte ausgelassen werden (“false negatives”).

Die Verschlagwortung im speziellen und die Nutzung von Normdaten auch im Bereich formaler Beschreibungen, wie bei den an einem Bestandsobjekt beteiligten Personen, dient nun dem Zweck, diese Genauigkeit bei der Suche zu verbessern. Statt einer rein technischen Extraktion von Wörtern werden diese im inhaltlichen Bereich intellektuell zugewiesen. Das Wort “Logikkalkül” ist dann nicht einfach nur ein Wort, das zufällig im Text auftaucht, sondern es beschreibt einen wissenschaftlichen Themenbereich, der dem Bestandsobjekt (hier beispielsweise ein Buch über Logik) bewusst zugeordnet wird. Ist der Suchbegriff Teil der Schlagwortliste, so liegt es nahe, die Relevanz gegenüber den Objekten, die den Begriff nur beinhalten, höher einzustufen. In formalen Fragen helfen Normdateien bei der Suche nach Personen, diese eindeutig, trotz häufig vorkommender vollständig identer Namen zu unterscheiden und die Genauigkeit der Recherche zu erhöhen.

Das Semantic Web hilft

In vielen GLAMs wird die manuelle Verschlagwortung durch eine wachsende Anzahl von Einzelobjekten zunehmend schwieriger. In den Bibliotheken betrifft dies vor allem die neuen Netzpublikationen3 , die aus diesem Grund zunehmend mit maschineller Unterstützungen verschlagwortet werden (Faden und Gross 2010; Hinrichs et al. 2016). Eine der grössten Herausforderungen der automatisierten Verschlagwortung ist dabei, eine mit der manuellen Verschlagwortung vergleichbare Qualität zu erreichen.

Das Ziel der hier vorgestellten Überlegungen ist es, die manuell vergebenen, aber normierten Metadaten für eine präzise Suche in den Beständen der GLAMs zu nutzen. Mit Hilfe von Semantic Web Suchtechnologien und auf der Basis der in der Linked-Open-Data-Cloud verfügbaren Daten wird zunächst eine Suche nach Personen durchgeführt, die anschliessend mit einer Suche im Bestandskatalog nach Einzelobjekten auf der Basis manuell vergebener Schlagworte verknüpft wird. Bibliotheken, Sammlungen, Archive und Museen können auf diese Weise das Potential ihrer Metadaten, wie beispielsweise der manuell und aufwändig vergebenen Schlagworte, besser nutzen und mit Hilfe des Werkzeugs “S-O-WAS” ihrem Publikum eine semantische Suche ermöglichen.

Zur Ermöglichung einer semantischen Suche soll zunächst der Informationsreichtum der Linked Open Data Cloud genutzt werden. Insbesondere steht dabei die freie Wissensdatenbank Wikidata4 im Vordergrund, die eine umfangreiche Sammlung von Objekten beinhaltet, die das Wissen in Form von Aussagen und Fakten über diese Objekte strukturiert. Um die Nutzung der Wissensdatenbank zu ermöglichen, stellt Wikidata unter anderem eine Schnittstelle für die Abfrage der Daten mit der Abfragesprache SPARQL5 bereit.

Die Funktionsweise der Abfrage wird im Folgenden anhand eines konkreten Beispiels erläutert.

Semantische Suche nach Personen

Nehmen wir zum Beispiel an, es wird nach einer Person gesucht, die bestimmte Kriterien erfüllen soll. Der Name der Person sei zunächst nicht bekannt. Zum Einen wissen wir, dass die Person ein Autor (männlich) ist, was jedoch zunächst keine Rolle spielt. Wir wissen, dass diese Person im 19. Jahrhundert geboren wurde, in Grossbritannien lebte und von Beruf Mathematiker war. Das Venn-Diagramm in Abbildung 1 veranschaulicht die Einschränkung auf eine diesen Kriterien entsprechende Schnittmenge.

Abbildung 1: Person, lebte in Grossbritannien, geboren im 19. Jahrhundert, Mathematiker.

 

Allein mit Hilfe dieser Kriterien lässt sich eine semantische Abfrage formulieren, die als Ergebnis eine Liste der Personen zurückliefert, die den Kriterien entsprechen:

  •  SELECT DISTINCT ?Person ?PersonLabel ?GND WHERE {
  • SERVICE wikibase:label { bd:serviceParam wikibase:language «(AUTO_LANGUAGE),en». }
  • ?Person wdt:P27 wd:Q145.
  • ?Person wdt:P569 ?Gebdatum.
  • ?Person wdt:P21 wd:Q6581097.
  • ?Person wdt:P227 ?GND.
  • ?Person (wdt:P106/wdt:P279*) ?Beruf. FILTER(?Beruf IN(wd:Q14565331, wd:Q4964182)). FILTER NOT EXISTS {?Person wdt:P106 wd:Q49757. } FILTER((YEAR(?Gebdatum)) >= 1800)
  • FILTER((YEAR(?Gebdatum)) < 1900) }

Betrachten wir zum Beispiel einen Teil der Abfrage, der die Abfragekriterien enthält: ?Person wdt:P27 wd:Q145.

Es wird ersichtlich, dass nicht die Bezeichner selbst, sondern Identifier für Objekte (beginnend mit “Q”) und Prädikate (beginnend mit „P“) verwendet werden. In diesem Teil der Abfrage bezieht sich ?Person auf die gesuchte Entität, die in der ersten Zeile als Variable definiert wurde, Q145 referenziert das Objekt “United Kingdom” und P106 repräsentiert das Prädikat “country of citizenship”. Die Eigenschaften von Objekten und Prädikaten (z.B. Bezeichner in anderen Sprachen) können auf der Wikidata-Seite zum Objekt (hier Q1456) oder zum Prädikat (hier P1067) eingesehen werden.

Das Ergebnis8 der Abfrage ist (erstellt am 26. September 2018) eine Liste von 71 Personen, beginnend mit den folgenden 4 Personen:

Wikidata-ID Personenname (WikidataLabel) GND-ID
1.    wd:Q334846 Edmund Allenby, 1st Viscount Allenby 119161311
2.    wd:Q722472 Homer H. Dubs 11623167X
3.    wd:Q725050 John Burnet 117175056
4.    wd:Q310794 Karl Pearson 118982141

Dieses Ergebnis diente der vorläufigen Einschränkung des Suchraumes mit Hilfe logisch-semantischer Bedingungen. Im Folgenden wird gezeigt, wie dieses Ergebnis mit Hilfe einer konkreten Abfrage in Bezug auf Bestandsobjekte von GLAMs bzw. hier konkret in Bezug auf Werke einer Bibliothek genutzt werden kann.

Suche nach Unterbegriffen

Im letzten Abschnitt haben wir ein Suchbeispiel vorgestellt, in welchem nach einer Person gesucht wird. Stellen wir uns nun vor, dass wir spezifischer nach einem Autor suchen, der ein Werk verfasst hat, das inhaltlich im Feld der Logik angesiedelt ist, und dass wir aufgrund der Spezialisierung davon ausgehen können, dass eines der in relevanten Werken vergebenen Schlagworte ein Unterbegriff von Logik (z.B. Aussagenlogik, Prädikatenlogik, etc.) ist. Im deutschen Sprachraum findet die sogenannte Gemeinsame Normdatei (GND) verbreitet Anwendung. Diese ist nicht nur eine Begriffssammlung, sondern stellt zugleich auch eine Ontologie dar. Diese ermöglicht es uns beispielsweise innerhalb der Sachschlagwörter der GND nach über- oder untergeordneten Begriffen zu recherchieren. Mit der Plattform lobid.org steht eine frei nutzbare REST-API9 zur Verfügung, die es erlaubt, die GND maschinenlesbar abzufragen. Dies ermöglicht bei Kenntnis der Feldstruktur eines indexierten Dokumentes, den Aufbau komplexer Suchabfragen durch Eingabe der jeweiligen Feld-/”Spalten”namen.10

Die Suche nach Sachschlagwörtern, deren übergeordneter Begriff Logik ist, hat als HTTP-Request die folgende Form: http://lobid.org/gnd/search?q=type%3ASubjectHeading+AND+broaderTermGener%20al.label%3ALogik&format=json&size=120

An die REST-Schnittstelle von lobid.org werden hier drei Paramter übergeben:

  • q: übergibt die eigentliche Suchabfrage.
    • type=SubjectHeading – sucht nach GND-Einträgen die Sachschlagwörter darstellen
    • broaderTermGeneral.label=Logik sucht nach Einträgen deren übergeordneter Begriff Logik enthält.
  • format: definiert das auszugebende Format des Ergebnisses
  • size: Anzahl der zurückgegebenen Treffer einer Anfrage

Aus dem Ergebnis kann für die weiterführende Suche im Zielkatalog je nach Sinnhaftigkeit und Einsatzmöglichkeit der Identifier des Begriffes oder aber auch die Ansetzungsform des Schlagwortes verwendet werden.

Verknüpfung der Personen- mit der Schlagwortsuche

Die in den beiden zuvor gezeigten Schritten maschinenlesbar gewonnen Ergebnisse erlauben nun die anfänglich unscharfe Suchabfrage in Form eines Suchbefehls zu bringen, der die einzelnen Schlagwörter mit den jeweiligen Autoren kombiniert, idealerweise sogar ausschliesslich durch die Verwendung von Identifikatoren der im Zielkatalog der Institution eingesetzten Normdatei.

Eine Voraussetzung für die Implementierung ist, dass für die in den Bestandsmetadaten existierenden Schlagworte die entsprechenden GND Identifier angereichert werden. Bezüglich der methodisch vergebenen Sachschlagwörter kann eine eindeutige Zuweisung durch die Lobid-Abfrage erreicht werden. Kommen jedoch frei vergebene Schlagworte oder Personennamen hinzu, so müssen die Terme eventuell durch Hinzuziehen vonKontext-Informationen disambiguiert werden. Die Anreicherung der Metadaten mit Schlagwort-GND-Identifiern kann unabhängig von der späteren Abfrage auf dem gesamten Metadatenbestand im Vorhinein durchgeführt werden.

In Abbildung 2 wird der Ablauf beginnend von der Formulierung der Suchanfrage bis zur Ergebnisdarstellung schematisch dargestellt. Der horizontale Querbalken im unteren Bereich der Grafik stellt die Systemgrenze dar. Die oder der BenutzerIn formuliert eine Abfrage mit den semantischen Bedingungen und dem konkreten Begriff zu einem Sachgebiet.

Der QueryBuilder ist eine Komponente, die aus der Suchanfrage die Systemanfragen sowohl an die lobid-API als auch an Wikidata generiert.

Die Semantische Abfrage wird als SPARQL-Abfrage an die Wikidata geschickt (Schritt 1a und 2a in Abbildung 2), die als Ergebnis die Menge der Wikidata-Identifier IP der Menge der Personen P=(p1, p2, …, pn) liefert, die den semantischen Kriterien entsprechen.

IP=(gndp1, gndp2, …, gndpn)

Im ersten Schritt wird die Menge der GND-Identifier I der Unterbegriffe Us=(u1, u2, …, un) zum Themengebiet s (in diesem Beispiel s=»Logik») mit Hilfe der lobid-API in Form einer REST-Abfrage ermittelt (Schritt 1b und 2b in Abbildung 2).

IUs=(gndu1, gndu2, …, gndun)

Unter der Voraussetzung, dass in den Metadaten eines Bestandsobjekts r die GND-Identifier IAr für Personen (=AutorInnen) und die GND-Identifier ISr für Sachschlagworte zugewiesen sind, ist die Ergebnismenge R=(r1, r2, …, rn) der Bestandsobjekte dadurch definiert, dass mindestens ein Autor ip unter den Autoren schlagworten IAr und mindestens ein Unterbegriff iu unter den Schlagworten ISr in den Metadaten des Bestandsobjekts vorhanden sein muss (Schritt 3 und 4 in Abbildung 2):

R = {r | Ǝ ip ∈  IAr ∧  Ǝ iu ∈  ISr r}

Abbildung 2: Schema der Generierung eine Suchmaschine mittels Linked Open Data Quellen

Verwandte Arbeiten

Die Verwendung von Wikidata zur Community-basierten Zuordnung von Namen und anderen Entitäten aus Normdateien wurde von Joachim Neubert vorgestellt (Neubert, 2017). Der wesentliche Unterschied ist, dass die externen Identifier selbst, die eine Organisation verwaltet, in die Wikidata integriert werden. Auf diese Weise können dann Links zurück auf das Bestandsobjekt im Katalog generiert werden (Lemus-Rojas et al., 2018).

Ausblick

Die während des zweiten openglam.at Kulturhackathons 201811 entstandenen und hier dargestellten konzeptuellen Überlegungen zeigen die Innovationspotentiale von Linked Open Data (LOD) in GLAM-Institutionen auf, und zwar in der Verbindung zwischen externen LOD-Quellen und lokalen, klassischen textbasierten Suchmöglichkeiten der jeweiligen Institutionen. Letztere haben durch ihre langjährige Erfahrung und den Einsatz normierter Datenbestände wie der gemeinsamen Normdatei (und ihrer Vorgängerkorpora) eine nicht zu unterschätzende Grundlage für die Kopplung an moderne Open Data Tools geschaffen.

Die freie Wissensdatenbank Wikidata erlaubt mit SPARQL auch komplexe Anfrage formulieren zu können und bietet die Möglichkeit GND-IDs als Antwort zu senden. Mit der freien Plattform lobid.org/gnd kann die GND selbst auf simple Art und Weise auch in ihrer Ontologie maschinenlesbar durchsucht werden. Eine Query-Builder-Applikation steuert entsprechende Anfragen und bereitet diese vor, kombiniert die aus LOD-Cloud stammenden Antworten und baut eine Suchabfrage an den lokalen Bestandskatalog vor.


Referenzen

1 Für den deutschen Sprachraum bildet die gemeinsame Normdatei (http://www.dnb.de/DE/Standardisierung/GND/gnd_node.html) einen weitverbreiten Standard.

2 Im Bibliotheksbereich gelten beispielsweise für die formale Katalogisierung RDA (Ressource Description and Access) oder RAK (Regeln für den alphabetischen Katalog) oder für die inhaltlichen Beschreibung RSWK (Regeln für den Schlagwortkatalog).

3 Bei der Deutschen Nationalbibliothek: Reihe O: http://www.dnb.de/DE/Service/DigitaleDienste/DNBBibliografie/reiheO.html

4 www.Wikidata.org

5 https://www.w3.org/TR/rdf-sparql-query/

6 https://www.Wikidata.org/wiki/Q145

7 https://www.Wikidata.org/wiki/Property:P27

8 Ergebnis in Echtzeit abrufbar unter: http://tinyurl.com/y7l3wh4n

9 http://lobid.org/gnd/api

10 Aufbau erweiterter Suchabfragen übersichtlich erklärt: http://blog.lobid.org/2018/07/06/lobid-gnd-queries.html

11 http://www.openglam.at


Weiterführende Literatur

Faden, Manfred; Gross, Thomas: Automatische Indexierung elektronischer Dokumente an der Deutschen Zentralbibliothek für Wirtschaftswissenschaften. In: Bibliotheksdienst 44 (2010), Nr. 12, S. 1120 – 1135.

Hinrichs, I., Milmeister, G., Schäuble, P., & Steenweg, H. (2016). Computerunterstützte Sacherschliessung mit dem Digitalen Assistenten (DA-2). O-Bib. Das Offene Bibliotheksjournal / Herausgegeben Vom VDB, 3(4), 156-185.

Neubert, J. Wikidata as a Linking Hub for Knowledge Organization Systems? Integrating an Authority Mapping into Wikidata and Learning Lessons for KOS Mappings NKOS@TPDL, CEUR-WS.org, 2017, 1937, 14-25.

Lemus-Rojas, M., Pintscher, L. (2018). Wikidata and Libraries: Facilitating Open Knowledge. In M. Proffitt (Ed.), Leveraging Wikipedia: Connecting Communities of Knowledge (pp. 143-158). Chicago, IL: ALA Editions.

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Wie Linked Data die Zugheizung startet

Die SBB ist nicht nur die grösste Eisenbahn in der Schweiz, sie betreibt auch eine Anwendungslandschaft mit mehr als 1000 Anwendungen. Jede dieser Anwendungen benötigt Daten für ihren reibungslosen Betrieb. Werden diese miteinander verknüpft, können sie beispielsweise bei jedem Wetter die richtige Temperatur im Zugabteil garantieren.

 In der Anwendungslandschaft der SBB sind diese Anwendungen historisch unabhängig voneinander entwickelt worden und nicht immer wird Gleiches gleich dargestellt. So kommt es, dass in verschiedenen Anwendungen Schlüssel oder Formate nicht auf einander passen.

Bei der Entwicklung von neuen Anwendungen muss die SBB oft Daten von mehreren bestehenden Anwendungen verknüpfen. Damit schnell mit richtigen Daten gearbeitet werden kann, ohne dass aufwändige Schnittstellen gebaut werden müssen, exportieren die Anwendungen Daten.

Hier kommen nun die Linked Data ins Spiel. Die Datenexporte werden analysiert und eine entsprechende Ontologie erstellt. Diese Analyse ermöglicht gleichzeitig den Aufbau des Domänenwissens und die Dokumentation desselben für die zukünftigen Nutzer. Der Bestimmung der URI (Unified Ressource Identifikator) kommt in diesem Schritt grosse Bedeutung zu. Soll doch mit dieser URI in der späteren Nutzung des Datenexports die Anreicherung mit Daten aus anderen Anwendungen möglich werden.

Mit der Überführung des Datenexports in RDF – Tripels in der definierten Ontologie ist man dann schon beinahe am «Integrationsziel» angelangt. Sind die Tripels einmal im Tripelstore drin, ist es einfach möglich die verschiedenen Graphen zu verknüpfen.

Mehrere Akteure spielen zusammen

Die SBB hat in der Studie «Meteobasiertes Vorheizen von Zügen» diese Art von Datenintegration versucht. In der Zürcher S-Bahn setzt die SBB zu Hauptverkehrszeit zusätzliche Züge ein. Diese Doppelstockzüge müssen vor dem Einsatz geheizt werden, so dass für die Passagiere eine angenehme Temperatur herrscht. Dieses Vorheizen ist soweit automatisiert, dass der Zug 90 Minuten vor dem ersten fahrplanmässigen Einsatz beginnt zu heizen. Diese 90 Minuten stellen sicher, dass der Zug niemals zu kalt ist. Es stand die Hypothese im Raum, dass man diese Zeit reduzieren kann und durch den Einbezug von Wetterparametern sicherstellt, dass es immer noch ausreichend warm im Zug ist.

Verschiedene Organisationen (Zazuko GmbH, HEVS) haben unabhängig voneinander die Daten die Daten exportiert und die Triples in den Tripelstore von LINDAS importiert. Eine dritte Organisation (Universität Bern, Forschungsstelle Digitale Nachhaltigkeit) hat dann die Steuerung basierend auf den Graphen implementiert. Durch diese Entkopplung und der Selbstdokumentation von Linked Data war die Universität Bern rasch in der Lage, eine funktionsfähige Steuerung zu implementieren.

Aus der Rollmaterialplanung werden alle 30 Minuten die aktuellen Formationen (Reihung der Wagen) exportiert, von MeteoSchweiz werden alle 6 Stunden die Wetterprognosen (Temperatur, Globalstrahlung) geladen. Die Anwendung der Universität Bern berechnet dann basierend auf dem Depotstandort des Zuges, des voraussichtlichen Temperaturverlaufs, der eintreffenden Globalstrahlung und dem nächsten Einsatz des Zuges den optimalen Zeitpunkt, um die Heizung einzuschalten. In der Übergangszeit konnte so die standardmässige Vorheizzeit deutlich reduziert werden und ansehnliche Mengen Energie eingespart werden. Somit konnte durch die Studie die Hypothese unterstützt werden. Um die Ergebnisse einer breiteren Leserschaft bekannt zu machen, wurde zusätzlich eine Visualisierung erstellt. Hier hat sich nochmals gezeigt, dass durch die einfache Verfügbarkeit der Daten rasch eine lauffähige Visualisierung geschaffen werden kann. Da alle Daten (inkl. der Logs) im Tripelstore vorlagen, konnten alle wichtigen Daten mit einem Query zusammen geholt und visualisiert werden.

Schlussfolgerung

Bei der Entwicklung von Prototypen mit Daten aus verschiedenen (teils Legacy-)Systemen ist die Verwendung von Linked Data eine Hilfe. Nicht nur, weil die Implementierung des Prototypens auf Basis der Linked Data relativ einfach ist, sondern auch, da viel implizites Wissen, welches in der Programm-Logik der zu integrierenden Systemen steckt, explizit gemacht wird. Diese Studie hat aber auch aufgezeigt, dass grosse Datenmengen, wie es die Wetterdaten sind, heute noch Optimierungsschritte brauchen, damit sie effizient in den Tripelstore geladen werden können.

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Daten als Innovationstreiber der intelligenten Stadt

Daten sind schon als das “Öl des 21. Jahrhunderts“ bezeichnet worden. Daten werden aber auch die Grundlage bilden für viele Prozesse in der intelligenten Stadt der Zukunft – der Smart City. Dazu wir eine Plattform notwendig sein, in der Daten von unterschiedlichsten Quellen – Sensoren und dem Internet der Dinge, offenen Daten, Behördendaten, Daten aus sozialen Medien sowie von weiteren Drittanbietern – verarbeitet, verknüpft und analysiert werden können, um wertvolle Informationen zu extrahieren und als Linked Open Data verfügbar zu machen. Darauf aufbauend können sowohl Städte wie auch private Anbieter neuwertige Anwendungen und Dienstleistungen anbieten; die Plattform wird dadurch zu einem Standortfaktor und zu einem Innovationstreiber.

Mit der zunehmenden Digitalisierung kommen neue Herausforderungen auf die Gesellschaft zu. Gleichzeitig findet eine verstärkte Urbanisierung statt. Die gesellschaftlichen Herausforderungen manifestieren sich so in der Stadt am deutlichsten: Verdichtung, öffentlicher Verkehr, effizienter Umgang mit Ressourcen wie Energie und Wasser, Sicherheit, und – zentral für den Stadtbewohner – Verbesserung der Lebensqualität. Deshalb ist es lohnenswert, die gesellschaftlichen Herausforderungen zuerst im urbanen Umfeld anzugehen; auch eine neuere OECD-Studie (OECD, 2015)  bezeichnet „Städte als Hub für datengetriebene Innovation“.

Im Juli 2016 ist dazu ein von der BFH koordiniertes Forschungsprojekt mit dem Namen „City Platform as a Service – Integrated and Open“, oder kurz CPaaS.io, gestartet. Das Projekt ist ein Kollaborationsprojekt zwischen Partnern aus Europa und Japan und wird unter Horizon 2020 sowie von der japanischen NICT gefördert. Es hat zum Ziel, eine Cloud-basierte Plattform für Städte und urbane Regionen zu bauen, die die Basis für eine urbane Dateninfrastruktur und für Innovation in der Stadt darstellt. Die Notwendigkeit einer solchen Plattform wird z.B. durch eine Studie (Vega-Gorgojo et al., 2015) gestützt: In der Studie wird betont,  dass „die Stadt Plattformen benötigen wird, welche die Digitalisierung sowie die Nutzung von Daten, kulminierend in Big Data, unterstützt“, und dass „die Smart City mit Plattformen arbeiten muss, auf welchen Daten analysiert und mit anderen Quellen geteilt werden können.“

smart-city-innovation

Das Ziel einer Innovationsplattform ist hoch gesteckt. Es geht nicht nur um die Realisierung einer technischen Plattform, oder um die Verbindung von komplementären Technologien wie das Internet der Dinge, Big Data und Cloud. Das machen andere Projekte auch. Smart City Innovation bedeutet, dass mit der Plattform bzw. mit neuartigen Anwendungen und Dienstleistungen, welche auf der Plattform aufsetzen, ein echter Mehrwert für die Gesellschaft und für die Akteure in der Stadt – Einwohner, Besucher, Privatunternehmen sowie die öffentliche Verwaltung – erbracht wird.

Um dies zu erreichen, muss die Plattform offen sein, sowohl was die Einbindung von weiteren Datenquellen betrifft, als auch den Zugang von Dritten zu den Daten (Stichwort Open Data), natürlich unter Wahrung des Datenschutzes. Im städtischen Umfeld ist hier insbesondere die Einbindung von offenen Behördendaten von Interesse. Dem Projekt kommt hierbei zu Gute, dass immer mehr Behörden diesem Trend folgen und ihre Daten auf Open Data Portalen publizieren – in der Schweiz z.B. auf opendata.swiss, aber auch die Stadt Zürich ist einer der Pioniere auf diesem Gebiet. CPaaS.io wird hier noch einen Schritt weitergehen und die relevanten Daten auch als Linked Data zur Verfügung stellen. Damit sind die Daten semantisch annotiert und auch mit Metadaten versehen, z.B. zur Provenienz und der Qualität der Daten. Dies erst ermöglicht eine vereinfachte maschinelle Einbindung und Nutzung der Daten in weiteren Anwendungen. Davon kann beispielsweise während Grossveranstaltungen profitiert werden: In welche Richtung bewegen sich Besucherströmen? Wie wurde der öffentliche Verkehr auf die aktuelle Situation angepasst? Wie wird auf Gefahrensituationen, Unfälle, Wettersituationen etc. reagiert?

Um für die Gesellschaft nutzbringende Anwendungen zu identifizieren, im Projekt zu implementieren, und damit auch den Nutzen der Plattform validieren zu können, ist die Einbindung von Städten von zentraler Bedeutung. Das Projekt hat dazu Kooperationen mit mehreren Städten aufgleisen können, welche bereits über Erfahrungen in den Bereichen Open Data oder Smart City verfügen. In Europa sind das Amsterdam, Murcia und Zürich, und in Japan Sapporo, Yokosuka und Tokyo. In mehreren von diesen Städten sind Feldversuche geplant.

Wir sind davon überzeugt, dass je länger je mehr Daten eine wichtige Grundlage bilden, um die gesellschaftlichen und wirtschaftlichen Herausforderungen meistern zu können. Basierend auf Dateninfrastrukturen, wie sie CPaaS.io liefern werden, werden neue Anwendungen und Dienstleistungen angeboten, und die Transparenz wird erhöht. Und für Städte wird dies zu einem wichtigen Standortfaktor, denn innovative Unternehmen werden sich bevorzugt dort ansiedeln, wo solche Plattformen vorhanden sind, die sie für die Erbringung ihrer Dienstleistungen nutzen können.


Projektdetails
Laufzeit: 30 Monate. Partner: Berner Fachhochschule, AGT, NEC, Odin Solutions, The Things Network, Universität Surrey, YRP Ubiquitous  Networking Laboratory, ACCESS Co., Microsoft Japan, Ubiquitous Computing Technology Corporation, Universität Tokyo.

Danksagung
logo-euDas Projekt wird finanziert durch das Forschungs- und Innovationsprogramm Horizon 2020 der Europäischen Union (Grant Agreement n° 723076) sowie der NICT in Japan (Management Number 18302).


Quellen

  • OECD (2015). Data-Driven Innovation: Big Data for Growth and Well-Being. Paris: OECD Publishing, S. 379ff.
  • Vega-Gorgojo, G., et al. (2015). Case study reports on positive and negative externalities. EU FP7 Project BYTE, S. 141 & 138.
PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.