ODIn/Website
9
0
Fork 1
Code Pull requests Releases Wiki Activity

image scaling issues

Browse source
This commit is contained in:
Oliver Kennedy 2016-12-13 15:09:56 -05:00
parent 612e4c8ee7
commit 685296f507
1 changed files with 6 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/rants/2016-12-13-Truthiness.md
View file

@ -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)
<img alt="OS X Calendar App" src="graphics/2016-calendar-explain.png" width=300/>
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)
<img alt="iOS Phone App" src="graphics/2016-maybe-screen.png" width=300/>
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).