Skip to content

Latest commit

 

History

History
147 lines (130 loc) · 11.5 KB

Page_131.md

File metadata and controls

147 lines (130 loc) · 11.5 KB
Raw
layout title
default
Post_131

Events

Leipzig Data Events Framework

Allgemeines

Ziel dieses Teilprojekts ist es, eine Infrastruktur aufzubauen, in die Event-Daten in einheitlichem Format aus verschiedenen Quellen und von verschiedenen Akteuren eingespeist werden und der Allgemeinheit zum Gebrauch zur Verfügung stehen.

Die Infrastruktur bietet keinen elaborierten eigenen Service zur Präsentation dieser Event-Daten, sondern überlässt die Zusammenführung mit weiteren Event-Daten, Filterung und Präsentation den Anbietern, die auf diese Infrastruktur zugreifen möchten. Die prinzipiellen Möglichkeiten des Leipzig Data Events Frameworks demonstriert auch unser Leipzig Data Event Widget.

Der primäre Zugriff erfolgt über Sparql-Anfragen auf einen Sparql-Endpunkt, in dem die Event-Daten mit weiteren Daten über Veranstalter und Veranstaltungsorte aus dem Leipzig Data Teilprojekt Gelbe Seiten angereichert und zusammengeführt sind. Dazu wurden über einen längeren Zeitraum die Event-Daten der assoziierten Partner (API Leipzig, MINT-Netzwerk) zusammengeführt und einmal wöchentlich aktualisiert. Beim Design des Gesamtprozesses sind wir davon ausgegangen, dass es (zukünftig) eine Betreibergruppe der Infrastruktur gibt, in der alle wichtigen Fragen abgestimmt werden. Allerdings sind die Quellen inzwischen weitgehend versiegt, eine Zusammenführung nicht gelungen.

Das derzeit vorliegende einheitliche Format (aka Protokoll) als Ergebnis eines längeren Entwicklungsprozesses ist weiter unten genauer beschrieben. Fragen der Weiterentwicklung des Protokolls werden in der Betreibergruppe abzustimmen sein.

Um Event-Daten in die Infrastruktur einzuspielen, müssen interessierte Akteure einen Service aufsetzen, mit dem relevante eigene Daten (verfügbar etwa als RSS- oder ical-Feed) in das vereinbarte Format überführt werden. Hierzu gibt es eine Reihe von Beispielskripten. Wir beraten interessierte Akteure im Rahmen unserer Möglichkeiten, wie eine solche (nicht schwierige) Bereitstellung erfolgen kann.

Termine werden drei Monate nach Ablauf aus der Datenbasis Events herausgenommen und in die Datenbasis Alte Events übernommen. Dort werden sie nach Jahresablauf endgültig gelöscht. Werden Daten lokal weiter benötigt, so müssen diese rechtzeitig aus dem Endpunkt ausgelesen und in eigener Verantwortung gespeichert werden. Auch hierfür gibt eine Reihe von Beispielskripten.

RDF-Struktur

Relevante RDF-Graphen

Verwendete Namensräume

Klassen

  • ld:Event - einzelne Events

Beschreibung der Prädikate

ld:Event - einzelne Events
  • ld:contactPerson foaf:Person - Ansprechpartner für das Event
  • ical:contact Literal - Kontaktinformation als String
  • ical:description Literal - Beschreibung des Events
  • ld:hatVeranstaltungsort ld:Ort - Ort, an dem das Event stattfindet
  • ld:hatTreffpunkt ld:Treffpunkt - Treffpunkt für das Event
  • ld:hasAddressAddendum Literal - genauere Bezeichnung innerhalb von ical:location
  • ical:summary Literal - kurze Beschreibung (max. 100 Zeichen) des Events
  • Literale: ical:dtstart, ical:dtend (xsd:date oder xsd:datetime)
  • ld:hatVeranstalter org:Organization - Veranstalter des Events
  • ical:sentBy foaf:Agent - Quelle der Eventinformation
  • ld:hasTag ld:Tag - Tags für das Event
  • ld:zurReihe ld:Projekt - Zuordnung zu einer Veranstaltungsreihe
  • Orga-Literale ld:hasAPIRef
  • Weitere Literale: ld:Kosten

Änderungen

  • HGG 2018-02-17: Prädikate geändert
    • ical:location -> ld:hatVeranstaltungsort und ld:hatTreffpunkt
    • ical:organizer -> ld:hatVeranstalter (Wert muss nun org:Organization oder eine Unterklasse davon sein)

Eine Demo-Oberfläche als Wordpress-Plugin

Im Kalender sind die Events nach Eventdatum einsortiert, Klicken auf den Tag zeigt die Liste der Events für diesen Tag, Klick auf einen Event-Link zeigt eine (rohe) Übersicht über die Informationen zu diesem Event mit weiteren Links in die Leipzig Data Datenbasis. Hier kann (und da endet die Nutzerfreundlichkeit der prototypischen Implementierung, mit der allein die Möglichkeiten des Konzepts gezeigt werden) nach Linked Data Prinzipien weiter navigiert werden.

[sparqalendar] (Wordpress Plugin, aktuell nicht eingebunden)

Stand der Umsetzung

Die Basisentwicklungen wurden im Rahmen des Projekts Leipzig Open Data ausgeführt.

Folgender Workflow ist dazu mit den assoziierten Partnern besprochen:

  • Neue Einträge werden laufend aufgenommen und in Events.ttl eingearbeitet. Einträge, die mehr als einen Monat zurückliegen, werden in AlteEvents.ttl umgetragen und nach einem Jahr komplett entfernt.
  • Die Event-Daten werden in unregelmäßigen Abständen in den Sparql-Endpunkt des Event-Projekts übernommen, von dort (automatisiert) neu ausgerollt und die Widget-Sichten auf die Event-Daten aktualisiert:

Aktivitäten

  • 12.10.2013: Einspielen der Wordpress-Demo als weitere Sicht auf die Daten (Johannes Frey)
  • 26.04.2013: Vorstellung des Projekts auf dem Abschlusstreffen des Leipzig Open Data Projekts (Andreas Nareike, Johannes Frey)
  • 11.-19.01.2013: Arbeiten im Rahmen der Ideenbörse
  • 20.07.2012: Vorstellung und Diskussion der Arbeiten an einer Präsentationsplattform basierend auf dem Exhibit-Framework (Johannes Frey)

Vom Projektteam entwickelte Lösungen

  • API Leipzig Events - wird derzeit vor allem von Kreatives Leipzig genutzt
    • Ein Beispiel-Perl-Skript (getAPIEvents.pl) greift auf die Webschnittstelle von APILeipzig zu
    • 2017-09: API Leipzig wurde abgeschaltet.
  • API Leipzig Rückbindung: Christoph Pieloth hat einen Beispiel-Client in Java geschrieben, der auf die LD.Events Schnittstelle (also den Sparql Endpunkt) eine calendarAPI aufsetzt, welche die API.Leipzig Event-API Spezifikation erfüllt. Damit können parallel Events aus LD.Events und aus API.Leipzig ausgelesen und zu einem Upstream federiert werden. Dieser Upstream wird von city:cult verwendet, um die eigene Android-App mit Daten zu füttern.
    • https://github.com/LeipzigData/JavaExamples/tree/master/src/calendarApi
    • Es sind nicht alle Services implementiert, wer diese jedoch braucht, kann dies schnell per Copy & Paste implementieren. Aktuell funktionieren z.B. die Venue-Details nicht und ohne Veranstaltungsort erscheinen die Events aktuell bei City:Cult auch nicht :( Daran werden wir bei Gelegenheit arbeiten.
    • (Aug 2017) Die Plattform API Leipzig ist nicht mehr am Netz.
  • Mehr als Chillen Grünau
    • Beispiel-Perl-Skript (getMehrAlsChillenEvents.pl) greift auf einen lokal eingespielten Datenbank-Dump zu.
    • Mehr als Chillen hat die Zusammenarbeit inzwischen eingestellt.
  • Netzwerk Energie und Umwelt
    • Beispiel-Perl-Skripte greifen auf ics-Export (neu-ics.pl) sowie RSS-Feed (neu-xml.pl) zu.
    • Identifizierung der Events erfolgt über eine MD5-Summe als Wert des Prädikats ld:hasMD5Sum, die über DTSTART, SUMMARY und DESCRIPTION eines von NEU übernommenen ical-Events gebildet wird.
    • (2016) Nach der Neukonzeption der NEU-Plattform ist der Service nicht mehr verfügbar.
Die Präsentationsschicht ist unabhängig von der Datenhaltung gestaltbar - über eine Sparql-Anfrage (konzeptionell vergleichbar mit einer SQL-Anfrage an eine lokale Datenbank) werden die relevanten Daten ausgelesen und auf die gewünschte Weise präsentiert.

Als Proof of Concept hat Johannes Frey das Javascript-Frameworks Exhibit für eine Widget-Lösung verwendet und dokumentiert, mit der sich schnell Webseiten mit Suchmasken und Tagwolken herstellen lassen. Die zur Präsentation verwendeten Widgets setzen dieses Framework ein.

Weitere Projekte ähnlicher Ausrichtung