 Hallo zusammen. Wir können jetzt endlich anfangen. Wir freuen uns, Volker Krause hier begrüßen zu können. Und er wird uns über seinen privatsphäre, respektierenden Routenplaner erzählen. Er wird auf Englisch sprechen, aber wenn sie die Übersetzung hören, möchtet, dann gibt es das hier hinten von den Dolmetschern. So, dann bitte ein herzliches Willkommen für Volker. So, worum geht es? Ihr kennt doch bestimmt alle diese Features in den, in zum Beispiel Google Mail, aber auch woanders mit Gmail kann man seine Emails lesen und dann bekommt man auch schon solche Buchungsinformationen. Es sind jetzt Bordekarten vom Flugzeug oder Zugtickets und das kann man dann direkt in seinen Kalender integrieren. Und man hat dann schon quasi die ganze Route, die ganze Reiseroute auf einer Übersicht. Das kostet auch alles nix, außer vielleicht euren Daten. Das klingt also nicht so schlecht, aber wenn man sich mal anschaut, um was für Daten es da eigentlich geht bei solchen Reisen, dann ist natürlich klar, dass da euer Name, eure Kreditkartennummer, eure Passnummer und andere Informationen verarbeitet werden. Aber das ist doch nicht mal das Schlimmste dabei. Denn diese Betreiber sehen nicht nur eure bestimmten Reisendaten, sondern wenn diese Information kombiniert wird, dann ergibt das weitere Informationen wie zum Beispiel eure Beziehungen zu anderen Leuten, eure Interessen, euren Wohnort usw. Jeder von euch ist in den letzten Tagen nach Wärtssich gereist. Wenn das alle paar Jahre passiert, dann kommt da einiges an Information zusammen. Also was können wir da machen? Eine einfache Lösung wäre ein bestimmter Dienst? Das funktioniert so lange, wie du nicht in einem anderen Land bist und die anderen Sprachen da nicht spricht. Und du dann nicht mit Sachen wie dem Schienensatzverkehr equivalent oder sowas zusammenstößt. Ab dann musst du tatsächlich verstehen, was auf deinem Trip passiert in irgendeiner Form. Idealerweise hast du dann 15 verschiedene Anwendungen, die du für deine Reise benutzt und dafür braucht man einfach was Besseres. Das führt uns dann tatsächlich dazu, was können wir selber tun? Wir können das dann also direkt vom Anfang für Privatsphäre auslegen. Das ist jetzt natürlich nicht komplett klar, dass es sofort funktionieren wird. Google, Apple, usw. haben alle verschiedene Ressourcen und verschiedene Methoden. Können wir das tatsächlich selber bauen? Lass uns doch mal anschauen, was sie brauchen, damit sie funktionieren. Stellt sich raus, es geht hauptsächlich im Daten. Es sind ein paar schwierige Kleinigkeiten in Form von Code da drin, z.B. Image Processing, solche Dinge. Alles das gibt es aber schon in Open Source als vorgefertigte Bausteine. Man muss es nur sinnvoll zusammenbauen. Lass uns also die Daten anschauen, das ist der interessantere Teil. Da gibt es dann also drei verschiedene Sorten für. Das Erste ist in Anführungszeichen persönliche Daten, also Buch, Informationen, Dokumente, usw, Tickets, der Ahnung. Du hast selber Zugriff dazu, das wird zu dir gesendet, damit kannst du es auch selber verwalten. Da hast du natürlich Schwierigkeiten, das zu extrahieren, das musst du irgendwie hinkriegen. Die zweite Art von Daten sind Static Data, das ist z.B. der Ort, wo der Flughafen ist oder die Bruststationen oder was auch immer. Das könnte sich natürlich verändern, aber es gibt auch so Romore, dass neue Flughafen gebaut werden, ich wohne in Berlin, das ist aber tatsächlich ein bisschen schwierig. Statische Daten müssen immer da sein, wo gerade die Software released wird. Ein paar Monate Delay, das kann man einfach mit Databases machen, die es schon gibt. Du bist damit nicht selber anschaubar, sondern halt nur dieser Datensatz. Die dritte Kategorie sind dynamische Daten, so Sachen, die es sehr kurz gibt, so Sachen wie ICE 505 ist verspätet, solche Dinge. Das können wir nicht lokal machen, das brauchen wir auf jeden Fall online, da müssen wir auf jeden Fall etwas anderes machen. Lass uns doch mal diese drei Kategorien nochmal in größerem Detail durchsuchen. Für die Buchdaten hatte Google das genau gleiche Problem. Die haben ihr Monopol dann also benutzt und einen Standard identifiziert, unter dem dann andere Anbieter auch handeln müssen. Das ist toll, wir können es einfach auch benutzen. Das heißt schema.org, das ist ließbar. Wenigstens in Europa und den Vereinigten Staaten kann man das einfach gut machen. Da findet man dann Events, Buchdaten und Flüge, so und so. Dann gibt es noch den Rest, das ist einfach nur unstrukturierte Daten. Das sind dann E-Mails und so weiter. Es gibt Apple Wallet Boarding Passes, das sind Apples eigene Boarding Passe. Diese werden hauptsächlich für Flugtickets und so was geschrieben. Das kann man auch mit benutzen, allerdings nicht bei jedem User. Und dann gibt es Barcodes, das kriegst du auf Boarding Passes, Zugtickets und so weiter. Wahrscheinlich kann man einen ganzen Talk mit Barcodes fühlen. Ich denke, da gab es auch vor ein paar Jahren mal einen Vortrag zu, wo gezeigt wurde, wie man damit arbeitet. Da gibt es den Instagram Hashtag Boarding Pass und da kann man eine ganze Menge Testdaten draus rausziehen. Und auch der auf deutschen Zugtickets, da gibt es auch schon eine ganze Menge Forschung zu. Und in Italien, da wurde mal der komplette Inhalt dieser binären Barcodes veröffentlicht. Und die VDV Kernapplikation E-Ticket, das ist die normale Art, wie diese deutschen Barcodes aufgebaut sind. Und wenn ihr euch dafür interessiert, da gibt es Details, eine ganze Menge zu. Dann kommen wir zu den statischen Daten. Natürlich haben wir da WikiData und da kann man eigentlich alles finden, was man braucht. Und das benutze ich auch sehr viel. Etwas, was bei WikiData noch nicht perfekt ist, ist die Zeitzone-Information. Und da greife ich meistens auf OpenStreetMap-Daten zu. In WikiData gibt es drei Arten, die Zeitzone festzulegen. Entweder ist das menschenlesbares Format wie Mittel-Europäische Sommerzeit, aber es kann auch solche Formate haben wie Europe Slash Berlin. Und dann gibt es natürlich auch noch die Zeitverschiebungsanpassung. Und wenn man jetzt zum Beispiel von den USA nach Europa fliegt, in genau der Nacht, wo die Zeitumschaltung stattfindet und wir dann eine Stunde falsch liegen, dann kann es sein, dass jemand dadurch seinen Flug verpasst und das wäre ja schlimm. Deswegen verwendet WikiData drei verschiedene Zeitzone-Formate. Und wir nehmen OpenStreetMap-Daten. So, dann ein weiterer Bereich, wo es noch Verbesserungspotenzial gibt, sind diese verkäuferspezifischen Stations-Identifier. Da gibt es zum Beispiel die Alpha America Identifiers. Das ist auch in Barcodes of Tickets enthalten. Und da kann man herausfinden, wo die Leute hinreisen und das kann auch in WikiData einfließen. Bei Flughafen ist es sehr einfach, die sind international standardisiert. Bahnhöfen ist das noch ein bisschen schwieriger. Dann haben wir noch dynamische Daten. Hier hat Google ein Monopol. Die ganze lokale Information ist in Google Maps enthalten. Und so können lokale Transportbetreiber ihre Zeitpläne an Google senden. Meistens passiert das aber so, dass sie das als offene Datenformate veröffentlichen. Und so können wir alle darauf Zugriff erhalten. Dann gibt es noch Navizia. Das ist eine kostenlose Software, mit der man seine Route planen kann. Und die speist Daten aus diesen verschiedenen Zeitplänen ein. Und wir können die dann wiederum weiterverwenden. Um beispielsweise die Zeitpläne herauszufinden, Verspätungen und so weiter. Apple Wallet hat auch Live-Updates, ein Mechanismus dafür. Aber das ist ein bisschen kritisch, weil da Daten gelegt werden, wie zum Beispiel eindeutige Identifizierung zu Passen können, dort freigegeben werden. Das kommt also nur zum Einsatz, wenn es wirklich keine Alternative gibt. Und sonst gibt es noch proprietäre APIs, die man verwenden kann. Aber oft sind die nicht kompatibel mit kostenlose Open Source Software. Zum Beispiel darf man die Apikies nicht teilen. Und da gibt es dann auch noch andere Bedingungen. Manchmal funktioniert es, aber manchmal funktioniert es eben auch nicht. Und da gibt es auf jeden Fall noch Verbesserungspotenzial. Und wir brauchen einen offenen Zugang auf die Daten. So, das war es jetzt von der Theorie. Dann lasst uns mal noch in die Praxis schauen. Und das anschauen, was ich tatsächlich gebaut habe. Es gibt zwei Backend-Komponenten. Das ist die Extraktionsbibliothek. Das ist ein Schema-Funkorg-Datenmodell für zum Beispiel Hotels, Restaurants und Veranstaltungen. Und da kann man strukturierte Daten rauslesen. Das klingt vielleicht einfach, aber es war ziemlich schwierig. Denn bei manchen Betreibern hat man zum Beispiel Jason-Ary-Encoding. Und das war ganz schön schwierig, weil man da halt die Verbindung zwischen zwei Objekten herstellen kann und muss. Und manchmal war es das ganz schön schwierig gewesen. Und wir haben da Workarounds finden müssen, Pausing. Dann gibt es noch die unstrukturierte Extraktionen. Das sind quasi kleine Skrips, die spezifisch für einzelne Betreiber geschrieben werden. Und die Regex verwenden, um die Eingarten zu verarbeiten. Ich denke, wir haben momentan etwas mehr als 50 davon, aber es ist nicht unmöglich. Wir haben die Mittel dazu und ich denke, wir können zu einem ähnlichen Ergebnis kommen, wie die entsprechenden Google-Apps. Die Abdeckung ist ein bisschen anders. Bei Apple habe ich gesehen, dass die zum Beispiel viele US-Auto-Vermietungen haben. Und wir haben zum Beispiel die Congress-Tickets. Und ich konnte tatsächlich mit der App reinkommen. Und wir ergänzen das mit Daten aus Wikidata. Die Eingangstformate sind quasi alle, die ich eh schon gesagt habe. Das ist einfach das normale Zeug, was du in der E-Mail auch bekommst von einem Provider, halt HTML und so weiter. Der zweite Teil, der Backend-Teile, ist die Transportationsbibliothek. Das ist die API für Namitia hauptsächlich. Da gibt es ja nur noch Proferitäre. Zum Beispiel das, was die Deutsche Bahn benutzt, PK Pass. Und da kann man dann automatisiert Backend-Stores schreiben. Ein paar Tage vorher wurde das auch noch unterstützt von der Wagenstands-Unzeige in Deutschland. Alles das ist quasi jetzt auch in der App drin. Dann gibt es dann noch die App selber. Es ist sehr schwierig, das gerade hier zu wesen. Das ist hauptsächlich eine Timeline mit der verschiedenen Buchinformationen, die du hast. Die kann die Wetterinformationen live einfügen. Das ist alles online Access. Das heißt, das ist optional. Das kann man auch ausmachen. Es ist halt praktisch. Man kann es wahrscheinlich nicht lesen. Aber das ist mein Zug nach Leipzig, den ich diesen Morgen genommen habe. Das ist das Ticket, mit dem ich in den Congress gekommen bin. Die Box ganz oben ist die weg machbare Gruppe für den Trip dahin. Das ist das Wetter. Man kann das Ticket anzeigen, die Barcodes und Apple Water Pass und alle speziellen Passe, die man hat. Teilweise gibt es dann da nämlich manuelle Kontrollen an zum Beispiel Flughäfen, wo sie das nicht automatisiert scannen, sondern selber vorbeikommen. Das ist dann praktisch. Dann kann man nämlich einfach seinen Barcode fortzeigen. Zumindest ich wurde dafür noch nicht verhaftet. Dann haben wir noch ein paar von meinen Lieblingsfeatures, die auch von Wikidata übernommen wurden. Das ist die Power Plug Compatibility. Das heißt, wenn du zum Beispiel nach Amerika oder in die Vereinigten Staaten, eh, in England fährst, dann hast du andere Steckdosen. In manchen Ländern weiß man natürlich bei England und den Vereinigten Staaten, aber in manchen ist es auch so, wo man es gar nicht weiß. Zum Beispiel in Italien und in der Schweiz, wo dann manche Sachen nicht funktionieren. Das Rechte ist für die, für das Königreich, wo überhaupt nichts kompatibel ist, außer deren Steckdosen. Das ist super nützlich, wenn man halt rumfährt. Natürlich hat man dann noch Integrationen mit Realtime-Daten, sodass man quasi Verspätungsinformationen oder Plattformänderungen anzeigen kann. Der Teil der Mitte ist das für Züge, wenn man ein Zugticket hat, dass man mit einer gewissen anderen Verbindung einhalten muss. Dann wird einem auch der Ersatz, falls man einen Teil dieser Kette verpasst, angezeigt. Der screenshot rechts ist die gesamte Strecke und die gesamten Statistiken der Strecke. Falls sich dein CO2-Impact interessiert, wird er da auch angezeigt. Ich war damit nicht ganz erfolgreich, hauptsächlich, weil die Daten dazu nicht ganz korrekt sind. Aber ja, da gibt es ungefähr alle Daten, die dir helfen, das zu traktieren. Um Daten da reinzubringen, haben wir noch einen Plugin für E-Mail-Client. Da kann man dann die Extraktion aus der E-Mail nehmen, zeigt dir, was darauf angezeigt wird und lässt es dich einfach nach KD-Internary verschieben. Das kannst du dann zum Kalender hinzufügen oder auf dem Kalender anzeigen oder halt zu diesem Handy schicken. Dann gibt es noch die Browser-Extension, das ist die Website-Extension, wo man dann die Extension, die Website ausliest, mitbekommt, dass dort ein Event ist und vorschlägt, das hinzuzufügen, entweder zum Kalender oder in die App. Das funktioniert auch sehr gut bei vielen Restaurant-Website oder Event-Website. Die haben diese Dateiformate und Metadaten in Indian-Website drin für die Google-Searchs. Die können wir einfach dementsprechend auch ausschließen. Dann kommt der Experimentellekram, der in den letzten paar Tagen erst fertig gemacht wurde. Das ist noch nicht mal öffentlich. Das erste ist, wenn du vorher die Timeline gesehen hast, hat das Congress-Ticket und das Zug-Ticket getrackt. Das ist aber nur die Zugstation nach Leipzig. Ich muss aber immer noch von zu Hause zur Zugstation und von der Zugstation zum Kongress kommen. Was wir jetzt haben, ist ein automatisches Skript, der diese Lücken ausfüllt mit Vorschlägen zum Vorgehen. Zum Beispiel der Trip vom Kongress zurück zur Bahnstation ist auch ein Expander, der da auch ist. Man muss immer noch ein bisschen Arbeit stecken in die tatsächliche Navigation, das Real-Time-Tracking, was da reingeht. Aber dafür sollte man auch Open-Street-Datamenten dachten nehmen können. Das ist wortwörtlich gestern passiert, deswegen sind die Grafiken davon so ein bisschen basismäßig. Das ist aber das Wagen-Layout von den Zügen, zum Beispiel von ICEs, so dass du dann weißt, wo du einsteigen musst, wo dein reservierter Sitzplatz ist und wie das geht. Danach gibt es ja noch ein Work-in-Progress-Plugin für tatsächlich alle E-Mail-Programms, für tatsächlich noch ein anderes E-Mail-Programm. Das vorherige funktioniert nur für K-Mail. Es macht funktionell genau das gleiche wie das für K-Mail. Es schlägt ja auch vor, diese Reisen in die App hinzuzufügen. Das nächste ist noch Experimenteller. Ich kann euch nur ein Bild vom Code zeigen, das beweist, dass es tatsächlich was extrahiert. Das ist die Next-Stort-Integration. Ich hoffe, wir werden im Januar tatsächlich einen funktionellen Prototyp dafür haben. Die zwei Sachen sind natürlich wichtig, damit du überhaupt zu den Buchdaten kommst, mehr so als die anderen Sachen, damit das alles andere funktioniert. Wo kann man das denn herkriegen? Es gibt ein Wiki-Link, der ist auf dem Auf der Tafel. Die App ist momentan leider weder im Play Store noch in der Astroid-Repository. Ich hoffe, im nächsten Monat werden wir offizielle Releases in die Appstores kriegen. Was wir gerade haben, ist bisschen schwierig. Sollte dir interessiert sein, um uns zu helfen, es gibt zum Beispiel Verbesserungen der Daten, die funktionieren direkt dazu, dass sich unsere Arbeit verbessert. Bessere Integration der Zugstationen hatten keinen, also wäre trotzdem hilfreich. Zum Beispiel haben Hunderte von Bahnstationen in Deutschland noch immer keine Geotracking-Daten. Dementsprechend wäre es wichtig, spezifischere und genauere Daten über die Worte und über die Properties dieser Zugstationen zu kriegen. Außerdem brauchen wir Test-Daten für die Extrektionen. Deswegen vergesst das mit Privacy erstmal, falls ihr irgendwelche persönlichen Daten habt, die ihr zum Support donaten wollt, dann könnt ihr das natürlich machen, allerdings gefällt das eure Privatsphäre. Redet mich an, falls ihr helfen wollt, indem ihr eure persönlichen Daten kurz aufgibt. Wir sind nicht Google. Fragen? Das ist ein sehr gutes Projekt, glaube ich. Haben wir denn Fragen? Wäre es möglich, Plattform Lift Daten für Bahnhöfe zu extrahieren? Ich denke, Deutsche Bahn hat ein Open-Data-API für die Live-Status der Lift. Das wäre also theoretisch sicherlich möglich. Was wir versuchen zu tun, ist, generisch genug zu sein, so dass das nicht in nur einem Land sein kann. Es ist ein europäischer Fokus, weil die meisten der Teams da sind. Aber Lift ist etwas, das auf generalisierend genug ist in einem Datenmodell. Es geht natürlich auch darum, ob diese Aufzüge nun gerade funktionieren oder nicht. Das geht dann schon stark in Richtung Indoor-Navigation oder Navigation um größere Trainstations und Airports. Das ist wahrscheinlich etwas, wo wir ein besserer overaller Display mit den Open-Street-Map-Daten nehmen. Dann wird man da besser weitergeleitet. Ist die Mobile-App auch in Qt geschrieben? Ja. Das meiste ist C++-Code. Das heißt, das C++-Code, das ist das C++-Code. Das ist das C++-Code, das ist das C++-Code. Das ist das C++-Code, das C++-Code. Das ist das C++-Code, das C++-Code. Das meiste ist C++-Code, weil das ist, was wir bei KDE benutzen. Ebenso gut der Mobile-Kleid, auch ein bisschen in Java. Ich denke nicht, dass es jemand versucht hat, nach iOS zu portieren, aber es läuft auf Linux. Du hast vor allem über Mobile-Apps gesprochen, das ist verständlich, aber es ist eine QML-Applikation, die auch auf Desktop läuft. Die zweite Frage ist, wie alle Plug-ins und verschiedene Instances auf der App funktionieren. Ja, die App läuft auf Desktop. Ich bin nicht sicher, auf welchen Bitschern die App noch angezeigt wird. Oh, thank you. And now I need to find my mouse cursor on the two screens. I think I need to end the presentation first. But short answer, of course, there we go. Die kurze Antwort noch mal, ja, das ist verständlich, läuft sie auf dem Desktop. So, that's it running on desktop. It has a mobile UI there that could of course be extended to be more useful on the desktop as well. Wir könnten sie noch erweitern, damit sie auf dem Desktop nützlich ergibt. In terms of storage, that is currently internal to the app. There is no second process accessing the actual data storage. That would just unnecessarily complicated for now, but if there is a use for that, we'll need to see. But there was an option in the email plug-in, for example, to send it to the app. Can I then only send it to my local app and not to the mobile app? Oh, the send to app, that's using KD Connect. That's an integration software that allows you to remote control your phone for the desktop. So that's basically bundling up all the information and sending it to the app on the phone. Or it can import it locally, so. Man kann es auch lokal importieren. Do we have other questions? Now we don't have time. Wir haben leider keine Fragen mehr. Das heißt keine Fragen mehr. Thank you very much, Falka. Maybe you can tell people where they can find you, if they have anything more they want to talk about. Meine E-Mail-Adresse ist hier unten. All of the four days around where everyone and I can go. So just a little bit tricky. Catch them before you run the wave. All right, so give a round of applause again. Also noch eine Klaus-Bitte für unseren Sprecher und vielen Dank.