 So the next presentation is by Mr. Falka and he's going to talk about KDE itinerary. So please give him a round of applause over to you. Thank you. Yeah, so I'm going to talk about KDE itinerary or digital travel assistance. What do we mean when we say that? You probably know services like TripIt or some of the travel assistance features in Google Now. They all more or less work the same, right? So they read your email. They find tickets, boarding passes, bookings, that kind of stuff in there. They put it into your calendar or create a nice timeline and then guide you through that and give you real-time updates on delays and that kind of stuff. All of that is available for free in the sense that you don't pay for it, at least not by money, but with your data. And how bad is that? So the first thing that comes to mind is like the data you directly leak to those services, right? So your name, your birthday, your credit card number, your passport number, that kind of stuff. And maybe you're okay with sharing that with those services, but the thing people think less about is kind of the indirectly leaked data. So if you and I travel to Brussels on the first weekend in February, that might be pure coincidence, right? But I guess for many of us, that isn't the first time that has happened, right? So two or three times, same destination, same time. That is no longer a coincidence, right? So if you have enough of that travel data, that actually tells you a lot on relations between people. So what you are interested in, who you work for, where your family lives, all that kind of stuff, right? So in that point, giving your travel data to someone like Google is not just impacting yourself, but everyone else as well. So not ideal. What do we do about that? So one approach might be let's just not use those services. And that works until you find yourself traveling in a foreign country where you don't speak any of the local languages and then get introduced to their counterpart of Schien-Essatzverkehr or Tarif-Zorn-Randgebiet. And then you really want some assistance, right? So that brings us to another approach to deal with this. If you don't like something that, well, if you don't like the available options, right? Let's build one on our own. So let's have a look at what this would take. Turns out the problem is actually more about data rather than about code. There's also quite some code necessary, but a lot of building blocks already exist. The main challenge seems to be getting the various pieces of data we need. And I grouped this into three general categories. The first one is the personal data. So that is you booked a hotel or a train to a specific location. That data usually comes to you in the form of emails or PDF documents or you find it on a website. The second category of data is what I would call the static data. So that is information on where exactly is a specific airport or in which time zone is that airport. I come from Berlin, so their airports are actually static. In other parts of the world, people apparently manage to build new airports. So static here refers to kind of the release cycle of the software, right? So a few months at most. So that is data that is practical to ship for offline use. And the third category is what I would call dynamic data. So delay information, for example, or gate changes. So extremely short-lived information that you need to query from some online service. So let's look at those three categories in a bit more detail. Fortunately, we are not the first one with those specific problems, right? Google built the same system and they also needed to get their hands on those data. And the way Google usually solves this is they define a standard and encourage everyone else to follow that. And that's what they did for the booking data. They came up with the schema.org data model, which they also use for the search engine. But that contains like structured annotations that they expect in emails about your flight or your train and so on. Depending on where you live, that seems to be present in about 30 to 50% of booking-related emails. So that's a good starting point. Then, of course, you have random unstructured emails. So just meant for human consumption that we have to deal with. Then for flights, there is Apple wallet passes as something that is fairly popular. And then there's barcodes. Barcodes I can probably fill an entire talk with on what you can extract from data. So kind of structured information, but not meant for our purpose. But so that's at least something to work with. For static data, we also have quite some stuff to work with. Most prominently, weekly data. So that is structured data of pretty much everything imaginable. And OpenStreetMap covering the local specific parts. And also the time zone maps. Time zones is something really important for that use case. Areas where we still have some gaps, I would say, is adding vendor-specific station identifiers to weekly data. That is, for example, necessary to match to barcode content. And then the whole problem of indoor navigation and navigation to your specific seat on the train and those kind of information. And for dynamic data, again, Google did some groundwork there. They defined the GTFS standards as an interface for public transport operators to feed that information to Google Maps. But many of them luckily do that as open data. So we can consume that by free software as well. And there's two big free software implementations of such journey querying services based on top of GTFS. That's Navitea and OpenTrip planner. So that's at least covering the train and bus part. Then we have the Apple wallet boarding passes again. They also have a built-in update API that's useful for gate changes, for example. But that has the disadvantage that it leaks user information, so not ideal. And then, of course, there's plenty of vendor-specific online APIs. Many of them, unfortunately, not really compatible with free software or open data requirements. So you have some terms of conditions that aren't really compatible with our use cases. Or you need API keys that you're not allowed to publish. So problems like this. But that's the theory. So let's have a look at what we have actually built over the last two years. The first component is the K itinerary data extraction library. So that implements the schema.org data model for flights, trains, buses, hotels, events. And I'm forgetting one. Well, basically those are restaurant reservations, that's the other one. And it has an extraction system that can handle the structured data. So if there are structured annotations in emails, it can consume that. And it has an unstructured extraction mechanism, both generically. And it has support for, like, vendor-specific scripts. So for, I think, a bit more than 50 vendors where we, where the generic approaches or the structured approaches don't work, you can write a small JavaScript that does the extraction for that specific render. And that's then a few lines of regular expressions or express queries. The output of that is then augmented by informations we draw from VikiData. So that's filling in time zones or geo-coordinates for stations and airports. And that can consume basically all the data formats in which you might get these documents, anything you find in an email, PDF, the app-related boarding passes and so on. And if you, if anyone of you has seen the next talk from just earlier today, they showed the integration with the attenuator extraction, that's using exactly that system. Another building block we created is the K-Public Transport Library. So that's covering basically the dynamic data problem. Giving you API for querying for locations, departures, and arrivals at those locations and journeys between locations. This can talk to free software services, Navizia and OpenTurk planner, as well as to a few proprietary backends. And we have about 50 or so configurations for different services that then use any of those backends to actually get the data form. And the library picks the right service for the location you are looking at, and then gives you the results for that. And of course we have the actual KDI Generator application. That's a mobile app giving you a timeline of your trip that automatically groups the various bits on your itinerary together. So that's my FOSSTEM trip, this life weather report in between. I can show you the boarding passes. And it can pull you delay information for trains or gate and platform changes. If you miss your train, it allows you to find an alternative connection to get to your destination. Having all the data available, it provides you some statistics on how much you traveled in the last year. So if you're watching out for your CO2 impact, for example, that gives you trends on if you're improving over the years. One of my favorite features, because nobody else has it, is the PowerPlug compatibility warning powered by Vicky Data. So if you're traveling to the UK, you probably know they have weird PowerPlug, but some more normal countries like Switzerland or Italy coming from Germany also need an adapter, and I tend to forget that. So the app seeing that I travel to those countries or through those countries reminds me to bring the corresponding adapter. Something that is pretty new is an assistance feature to automatically fill the gaps in your itinerary. So I arrive at the main station in Brussels. I have my hotel somewhere. How do I get to the hotel? It now suggested me to take the metro number two to wherever I needed to go. So that's actually moving from just managing data to actively supporting you on this. That's another brand new thing. That's the train layout display. So it shows me where on the platform I need to go to find my reserved seat. Right. And then finally, how do we actually get the data into the app? For that we have plugins for a number of different email applications. Starting in Kmail, of course. That's where we came from. So that shows you a nice to read banner on what it found in the email. Next cloud you might have seen earlier today doing something similar. Released two weeks ago. The third one is Thunderbird. That isn't released yet, but it's basically going to have the same functionality available there as well. And last but not least, we have the browser plugin basically doing the same for websites you're looking at. Right. And then I'm done almost exactly in time. One last bit. Forget about all the privacy stuff I said. We need test data to improve the data extraction, so please donate that. If you want to learn more about that, meet us in building K at the KDE stand or at the next cloud stand around the corner. Thank you. To respect the time and the time delay we're having, if there are no burning questions, my advice is please reach out to Falker and address the question in person and we can move on to the next presentation. Thank you so much.