data on the Web for route planners 2. Proposal: let’s fragment our dataset instead 3. Evaluation design: replaying real query logs on different set-ups 4. Results: user perceived performance and cost-efficiency 5. Conclusion: new valuable trade-off established
online Publishing a GTFS data dump High effort required from user agents User agents need to import your data over and over again zip-file containing CSV files
of the Linked Connections interface will be found in-between 2. Linked Connections with always unique user agents 3. Linked Connections with only one user agent over the entire Web
of the Linked Connections interface will be found in-between 2 and 3 2. Linked Connections server + client 3. Linked Connections server + client with cache https://api.{myapp}/ ?from={A}&to={B} https://{myhost}/{datafragmentid} MongoDB with connections server client server server client client cache
Under low load, Linked Connections is slightly slower, yet under high load, Linked Connections gives better response times Real world between these 2 values
smartphone → Privacy by design Combining it with other datasets becomes easy Route planning becomes merely adding a library to your software project “happiest route” by @danielequercia
problem we can solve with Linked Data Connection A departureTime T1 departureStop S1 arrivalTime T2 arrivalStop S2 Rail Station S2 longitude X1 latitude Y1 name ... ParentStation Station S3 As S2 becomes reachable, others stops become reachable as well: nearby Bus Stop S4 Bus Stop S5 ... has parent stop
reuse of public transport data Data dumps Linked Connections Answer any question on the server Route planning algorithms as a service Data publishing Data services http://api.{myapp}/?from={A}&to={B} http://{myhost}/{datafragmentid} Average cache hit-rate of 78%