From 685296f50727bf035bfce4865338f75bd4413efa Mon Sep 17 00:00:00 2001 From: Oliver Kennedy Date: Tue, 13 Dec 2016 15:09:56 -0500 Subject: [PATCH] image scaling issues --- src/rants/2016-12-13-Truthiness.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/rants/2016-12-13-Truthiness.md b/src/rants/2016-12-13-Truthiness.md index f5fb9686..9c6fe277 100644 --- a/src/rants/2016-12-13-Truthiness.md +++ b/src/rants/2016-12-13-Truthiness.md @@ -17,17 +17,21 @@ System designers must decide between presenting erroneous data as truthful or ri Here, industry has done significantly better than the database research community. For example, personal information managers like Apple Calendar and the iOS Phone App increasingly use facts data-mined from email to automatically populate databases in their contacts and calendar applications. For example, the OS X Calendar app finds events in your email and schedules them. -![OS X Calendar App](graphics/2016-calendar-explain.png) +OS X Calendar App Similarly, the iOS Phone App makes use of phone numbers it finds in your email to predict who's calling you. -![iOS Phone App](graphics/2016-maybe-screen.png) +iOS Phone App Both examples illustrate a number of good design elements: 1. The interface keeps uncertain facts distinct or clearly marks them as being guesses. + * The Calendar App uses greyed out boxes and a special calendar for guessed events + * The Phone App explicitly prefixes guessed names with "Maybe: " 2. The interface includes intuitive provenance mechanisms that help to put the extracted information in context. + * Both Apps provide a "Show In Mail" link in the detailed information view. 3. The interface includes overt feedback options to help the user correct or confirm uncertain data. + * "Add To Calendar" or "Ignore" We as a database community need to start adapting these techniques to more general data management settings. The presentation layer isn’t the only problem, as identifying sources uncertainty requires developers to invest lots of upfront effort rethinking how they write code. We need to make it worth their while. For example, we might provide infrastructure support to help developers [draw generalizations from ambiguous choices](http://odin.cse.buffalo.edu/papers/2015/HotMobile-maybe-final.pdf). We might streamline [imperative language support for uncertainty](https://books.google.com/books?hl=en&lr=&id=17riBQAAQBAJ&oi=fnd&pg=PP1&dq=Probabilistic+programming&ots=7QUU6HLw0F&sig=zJCPZLhJLZhI6w2ELo-CyGnNKFU). Or, we might define [higher-order](https://pdfs.semanticscholar.org/bbf9/946752cc6456a333e16413583e2e98ef8554.pdf) [data transformation primitives](http://odin.cse.buffalo.edu/papers/2015/VLDB-lenses-final.pdf).