Now what? Given the large and growing pile of data we will optimistically uncover, we will run into new frustrations. People will claim that the published data formats are not the ones that their analysis tool requires. People will be overwhelmed by dataset size, not knowing where to start. People will unknowingly recreate someone else’s data-munging workflows on the way to repeating analyses of the same data. People will become the next bottleneck if data ever ceases to be.

There’s no one answer to the concerns listed above because everyone has a different goal for the data. To handle these issues, we will need more than a place to find up-to-date datasets—-we will also need a place where it is easy for people to share ideas and strategies for tackling data. We will need a social data commons.

Whereas blogs and wikis help report findings, steps, and missteps, a social data commons can be the place to go to “talk shop” about the available data. Even if people post their solutions using decentralized means, there will be benefit to pooling all of these resources in one place on the web. Here are some tools that will help the data-tinkerers get things done:

• Data-munging war stories. The first stage in data analysis is often long and frustrating. One must digest the dataset in the form they received it, and transform, clean, and filter out the subset that they wish to analyze, visualize, or otherwise present. The workflow differs for each dataset and application, but to the extent that people can share tools and instructions for processing each dataset, these should be written up in the form of recipes for baking the data.
• Crowdsourced analysis. Datasets can be overwhelming. While many exploration tasks are easily automated, it is often easiest to leave certain tasks (e.g., “Find the interesting pictures”) to humans. Mechanical Turk gives us a hint at what this might look like, and the Guardian provides a wonderful example of crowdsourced public data analysis in action.
• Current uses showcases. To spark competition, avoid duplicating work, and inspire follow-on projects, visitors should see a showcase of the current uses of each dataset. Aside from links to sites built around a dataset, the list can include embedded visualizations of finished work.
• Analysis wishlists. Given that data released by a government reaches more than just programmers, there will be more people with ideas than people who can implement the ideas. People with ideas should be given an outlet, and passers-by should be asked to vote on these ideas to help data geeks with some free cycles discover the most insteresting unimplemented project.
• Data wishlists. If an agency were to dedicate resources to releasing another dataset, which one is in highest demand? As Ted mentioned, governments should let demand drive delivery.
• Forums. No set of tools will encompass all use cases for social data analysis. A discussion forum can lead to the formation of interest groups while serving as a catch-all for needs not served by the list above.

The US government might hit a few bumps trying to implement some of these social features. For example, a conflict of interest might arise if the showcase of uses of a dataset includes a site critical of the current administration. Having the executive branch ban spam or abusive comments on a forum draws concern over limitations of free speech. These details are not roadblocks, but they do signal that we can’t expect a social overlay to spring out of data.gov per se—-if we want these features, we may have to build and manage them on a third party.

I’m sure there’s more to the social data commons than I listed here. What did I miss, and where can we seek further inspiration?

Thanks to Ted for reading the first version of this entry.

Clay’s criticisms are well founded, but what I’d like to see more of is some brainstorming about what our ideal data.gov would look like. A recent post about the coming data.gov.uk site provides a nice foil for us, for one, as the UK seems to be taking a very different approach. But more importantly, what would you want to see in a government data site, and how would you use it?

I heard once that it is a good exercise to try to compress an idea into three sentences or less — it forces you to understand what you really want to say. So here is my three sentence suggestion:

• Bring it all under one roof. The current data.gov site is like Yahoo! from the mid-90s: it is just a directory of links to other sites. This is a noble start, but we really need to get a single point of access if we want to revolutionize eGovernment. The government is an immense, heterogeneous organization, so this is as much an organizational challenge as a technical one. But there are plenty of precedents of systems which allow individual data publishers (the government agencies) to retain control over the publishing and updating of their own data, while allowing data consumers (the public) to access it all from a single location.
• .. But don’t forget to give credit. When offering a single access point for all the data, it is essential to keep metadata that tracks which data came from where. This is as important for book-keeping and data integration reasons as it is for simply giving credit where credit is due. Agencies that publish data sets of great use should be recognized for their work.
• Build it as you go. We don’t need the perfect system overnight. No single ontology, schema, or data format will be able to encompass all the government’s data. That’s OK — it doesn’t have to. Don’t let fear of not getting it perfect slow down incremental progress toward our goal. Just bringing the data under one roof is a fantastic start; you can always try to begin standardizing formats and “linking” it later. My next blog post will specifically address this topic.
• …And version data sets. The benefits of offering “versions” of datasets are threefold. First, it allows you to maintain a system in which data providers feel comfortable updating their data at will. Second, it allows the implementors of the system to feel comfortable experimenting with data integration techniques and knowing that, if it doesn’t work out, users still have access to the same system they did last week. Third, it is the ultimate expression of openness: like a subversion repository for the government, everyone will be able to see the evolution of data over time.
• Help users discover data. With the sheer volume of data available, publishing it isn’t enough — you have to help people find what they want. The current data.gov site already does a decent job of offering search functionality. We can go further, providing data “footnotes” for bloggers to link back into the data.gov site (see the DataPress project for an idea of how this might work), suggestions of “hot” data sets for particular areas of interest, or a government data blog that highlights new and important data that has been recently published.
• .. And let them tell you what they want. Your users — the citizens — are your best assets. Let them prioritize your tasks for you by allowing them to suggest and vote on features and data sets they would like to see added. This type of decentralized management strategy is making waves among the business community, and the same mindset can be applied to government.

So there are my three sentences: Bring it all under one roof, but don’t forget to give credit. Build it as you go, and version data sets along the way. Help users discover data, and let them tell you what they want.

What are your three?

I proposed researching some tools that, instead of relying on luck to determine which tweets you see, instead figure out the most valuable ones to show you.  I don’t believe that filtering by person (a big mix of different interests) and hashtag (unreliable, often nonexistent) is the best way to locate the tweets that are most useful to me.  But KP poured some cold water on this idea, arguing that tools that improved your ability to filter tweets would just lead to people following more users, such that they got swamped with tweets again.  More generally, that regardless of what information filtering tools we get, we will always push them to the limit of delivering too much information.

I realized I’ve experienced this myself—I used to visit various web sites to gather information. As I began to find it burdensome to keep up with all these web sites, I ultimately switched to an RSS reader to make it easier for me.  But that has simply allowed me to subscribe to more sources than I was following manually, such that I am again feeling swamped by my information feeds.

Does this mean that any assault on the cliched “information overload” problem is doomed, since whenever we fix it people will load up more?  It seems the only hope is to convince people that they don’t actually need the information they are gathering.

This idea actually relates to another line of our research, on note-taking.   People like to write down all sorts of little scraps of information.  But according to data we’ve logged from our list.it notetaking plugin for firefox (13,000 users—you should give it a try), a lot of those notes are never retrieved.  So why are they written down?  Perhaps it’s because people worry they might need them later, even though they never do.   Something similar seems to be going on with information streams—once they exist, people start to worry they might miss something important, even though they never worried about it before.   If we could somehow convince people that they could find anything that really mattered, they might become less gluttonous followers of information.

And this leads to another project of ours, FeedMe, described in a recent post on this blog.   I’d love to stop following a bunch of my newsfeeds, if only I could be confident that the really good bits would be brought to my attention.  There are collaborative filtering tools like Digg, but I don’t trust them to know what I like.  FeedMe is instead based on having friends forward interesting content to me.   I trust my friends more than any algorithm; if enough of them read a given blog, I can stop on the assumption that they’ll forward interesting content to me.   But right now I don’t have good feedback on how many of my friends are reading what blogs.   That might be an interesting feature to add to FeedMe.  An alternative might be for a group of friends to “divvy up” a blog, each reading a subset of the content and deciding which to forward to which friends.  This would need some supporting interfaces, of course.

We want to empower this kind of sharing to happen more. So, we’ve built FeedMe, a Greasemonkey plug-in for Google Reader on Firefox.  Today, we’re releasing it publicly!

FeedMe makes it easier to send brief e-mails to your friends to share links. Once you’ve started sharing, it starts recommending friends who might be interested in seeing the post you’re looking at. Ideally this makes it even faster to share with more people who would find content relevant, without requiring you to type or switch windows.

FeedMe has loads of other bells and whistles: optional digesting of shares, indications of whether the recipient already received the URL, how many URLs the recipient has gotten recently, and One-Click Thanks for recipients to tell you what they like (similar to the Like feature on Facebook).  If you don’t use Google Reader, you can still use FeedMe—we’ve created a bookmarklet that allows you to share any webpage!

Give it a whirl, and let us know what you think at feedme@csail.mit.edu! For you academicy types, you can check out more about FeedMe in our tech report.

To try FeedMe out, head over here, and let us know what you think.

What I’m thinking might remedy the situation is a CHI early results blog.  It would work like this: when a paper is accepted to CHI, the SIGCHI blog administrators e-mail the authors and invite them to write a short blog post describing the results that will be appearing at the conference. It should be written for a general web audience and other HCI researchers and practitioners. This would not just be the abstract and intro; the blog would highly encourage pictures, videos, and any other media. The drafts would be vetted for readability, and then posted as soon as they are ready (with some flow control to make sure we don’t post too many items at once). This means results could be posted as early as December.

If successful, this could be a great way to accelerate the dissemination of important research results, generate lots of positive buzz for the conference and the papers in it, keep research conversations going year-round, and increase the number of HCI posts on Slashdot. And I mean, Slashdot is our currency, really.

What do you think?  Would you post in a centralized SIGCHI blog when your papers get accepted?

We’ve been looking at ways to empower another source highly personalized content: our friends, family, and coworkers. They already share web pages with us by e-mail, in person, and on social networks.  Social link sharing is often high-quality and personalized: quality is vetted by people you trust, and personalization is implicit when your social network uses its notion of your interests and tastes to forward you links.  Social link sharing is not perfect either—we all have that friend that’s filling up our mailbox with e-mails that contain the subject line “Fwd: Fwd: Fwd: puppies,” and our considerate friends sometimes avoid sending us content to avoid being perceived as that person.

Michael and I have been working on a multi-stage project to understand the social processes behind web content sharing and to support those processes by introducing a novel tool called FeedMe to facilitate such sharing.  We’ve published our findings in this technical report, and have summarized the results below.  Today we’ll be sharing part 1, where we will discuss our initial exploration to understand social link sharing; in the next post, you’ll be hearing about the tool we built based on these findings, and you’ll get a chance to sign up for a public release of FeedMe!

Link-Sharing Surveys
We conducted two surveys encompassing 140 users of Amazon Mechanical Turk, one focusing on what it’s like to receive posts, and the other focusing on what people think about when sharing.

In our receiver surveys, we learned several things:

• E-mail is the dominant link-sharing medium.  Receivers cited a lack of time as a reason for why they do not visit content aggregators to find the top web content.  Sharers share content through email over all other mechanisms, because it is ubiquitous on the internet, and is a consistent protocol for sending content with anyone.  Another interesting tidbit: in addition to being the dominant link-sharing mechanism, e-mail tied regularly visiting one’s favorite websites as the the dominant information-finding mechanism.  Few users utilized feed readers, social aggregators, or social networks for links.  It turns out that e-mail is not dying in favor of Facebook and Twitter, especially not for the average user.
• Topic Interest Drives Enjoyment.  The biggest reasons receivers cited for liking shared content was the relevance and entertainment value of the content.  Off-topic shares were off-putting for them.  Sharers were conscious of this; relevance and timeliness were their biggest concerns.
• Link Sharing is Burdensome when it is a Repetitive Firehose.  Receivers disliked it most when sharers could not rate-limit themselves.  One user complained about a sharer who blindly forwards 10-20 e-mails per day.
• Small Audiences are Best.  A small recipient list is a good predictor of whether recipients will appreciate the content.
• Friends are the Most Common Target.  Sharers share more content with friends than family or co-workers, and their set of receiving friends are a small group that they regularly communicate with.
• Receivers Want Even More.  If guaranteed high-quality content, receivers claimed they would like to have more links shared with them.

From active sharers, we learned:

• Sharing Correlates with Seeking.  Individuals that identify with spending a large amount of time seeking out web content are also those that identify with sharing a large amount of content, and having their contacts in mind as they read web content.
• Sharing does not Imply Sociality.  You might think that sharing activity is guided by how much of a social butterfly you are. Not so. We measured two types of social capital, and neither was able to explain sharing practice.

Next Up…
With this information in mind, we sought out to build a tool to help heavy information seekers share more content.  Next week we’ll be sharing FeedMe, the tool we built to address this issue.  Until then, feel free to look through our technical report for the detailed results.

http://eyebrowse.csail.mit.edu

It currently requires Firefox/Iceweasel and works on all major platforms.  All data that is collected is public and available to anyone who wants it (we do not horde or claim to own any of your data. We like Twitter’s model.)  We will soon provide a nice interface with daily tarballs of the database in RDF, XML and CSV.

Why would you want to share your web trails?

1. For Science!  It’s not fair that certain Search Engine Companies can do web trail research because they have access to massive repositories of data.  There should be public corpora for IR researchers around the world.  And these should be OPEN.

2. For your friends!  You look at lots of cool stuff on the web every day.  You might not think of explicitly sharing every single thing you read.  Eyebrowse is lightweight enough that you just have to tell it once per site you want to share.  I’ve already discovered tons of weird things that my friends are looking at that they would not have bothered to share explicitly.

3. To understand your own browsing habits.  How many times do you read ACM/IEEE every day? I bet you don’t know. Now you can get quantitative statistics and visualise long-term journal revisitation patterns – and other things.

Will it violate my privacy?

1. We give you control.  You have to tell eyebrowse explicitly what you want to share on a site-by-site (host) basis. You can take things off the whitelist at any time.  You can also go back and delete things that it has logged in the past all through our web interface.   It also respects Private Browsing (aka pornmode) and will not log any data regardless during this mode.

2. It fosters contemplation/awareness: We are trying to also raise awareness of what OTHERS (e.g. Google Analytics) are collecting about you as you surf the web, by showing you what you can learn from yourself by selectively publishing your own data feeds.

By letting people selectively publish web trails in an open, non-invasive way, we are hoping to foster a discussion of how we can use our web browsing behavior to build more adaptive and effective interfaces that respect people’s privacy.

Feedback is appreciated.  Please email us directly at : eyebrowse@csail.mit.edu

Oh and eyebrowse is free and open source software, licensed under the MIT License.  The source is available as part of the list-it codebase here: http://code.google.com/p/list-it

Of course, you can only draw limited confidence from this kind of simulation.  Their simulated users fit their model of the world (spammers labeled late) so of course a tool designed to their model will do well on their simulated users.  I wonder, would it have been that hard to just do manual labeling of expertise on some real delicious users?  This would obviously give more trustable results than simulations.   Indeed, they found that by manual examination, the top 50 users of the tag “mortgage” were spammers.  However, they say that the problem was finding a good ground truth for experts.   But that suggests it would still be possible to evaluate differentiation of spammers from non-spammers, even if you can’t evaluate differentiation of experts.

As for the model, they posit that each thread has several topics (which kind of contradicts the “pure” notion of thread, but is certainly true in practice).  Conversely, they assume each post in the thread is just a couple of topics.  They try to approximate each post as a linear combination of the (topics of the) previous posts, but a sparse one (only a few nonzeros to meet the idea that each post is narrow).   For training, they used forums like slashdot which do track replies to a specific comment.

You can recognize these attempts because they often appear as Facebook messages to you and 19 (or so) others, from someone you probably haven’t talked to in years.  They direct you to look at some link that requires a bit of extrapolation on your part – at least eliminating a space in the middle of the URL, or changing (dot) to an actual period.

Clicking through is exactly what you’d expect – a website looking like Facebook in all easily discernible ways, asking for your account name in password.  Since these URLs (seem to) come from friends, we’re likely to not spend an extra moment thinking about them.  One friend even got such a message from his advisor.  Statistically speaking you’re much more likely to click these links if they come from friends.

Research points to the most effective phishing teaching moment to be right after someone has fallen victim to a scam.  On Facebook, with instant notifications of these messages and the ability to possibly prevent new victims, there is a new social component to teaching.  I have a copy-and-paste-able message that I respond with by default:

You got phished!  Don’t click the link.  Just to re-articulate – whenever you’re asked for a name and password to log in to something, check the domain name very carefully, even if the website looks right. something like facebook.com.com is not actually facebook, for instance! People are incredibly likely (statistically speaking) to fall victim to phishing scams like this one when they’re sent through friends, so treat these as carefully as you’d treat emails from mysterious Nigerian princes.

Simply acting as one person alone, however, we can’t make as much of an educational dent as would be ideal.  There have got to be social computing ways to handle this.  Perhaps routing suspicious URLs to a few trusted – or even random – friends first, with the express skepticism required to catch these phishing attempts?  What do you think?