Plotting a Course for Data.gov

Filed under: Semantic Web, Social Computing, Thought Piece, eGovernment by Edward Benson on Wednesday, 18 November 2009 | 1 Comment

The US Government efforts to create a culture of open government data is a big deal. Hopefully it signals a shift from the “pull” model of FOIA to a “push” mindset in which data is proactively returned to the public without first having to ask (and pay). Still, data.gov has a lot of room for improvement, as Clay Johnson of Sunlight Labs mentions here and here.

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?

Information Glut, or Information Gluttons?

Filed under: Uncategorized by David Karger on Tuesday, 17 November 2009 | 2 Comments

I had an interesting discussion with my student Katrina Panovich today.  I’m intrigued by the way people use twitter for “ambient awareness”—watching what goes by, but not worrying about what they miss.   I find this paradoxical—if you don’t care about missing stuff, why watch at all?  Especially given that each arriving tweet provides some degree of distraction from whatever you’re doing?   KP actually remarked that she liked twitter better when fewer people were on it, so there was less information to follow.   Again, the paradox—you can always arrange to follow less on twitter.  The problem is the “insurmountable opportunity”—some of that new content might be really important.   But right now we are trusting to luck to see that content.

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.

Introducing FeedMe: A New Sharing Tool for Google Reader

Filed under: News, Social Computing, User Interfaces by Michael Bernstein on Monday, 16 November 2009 | 1 Comment

A few weeks ago Adam and I blogged about some of our recent work investigating how link-sharing happens on the web. In contrast to most sharing tools out there, which broadcast your shares to anyone who will listen, we found that lots of sharing happens point-to-point, from friend to friend. An interesting outcome of this friendsourced link discovery is that it is highly personalized: rather than getting what the Internet or your social network finds interesting, as you would on Digg or Facebook, you get what people think you would find interesting.

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.

Caring for Your Pet Offsite Server

Filed under: Uncategorized by Eirik Bakke on Thursday, 12 November 2009 | No Comments

While I prefer Windows XP [1] for my main work machine–that is, my laptop–nothing beats Linux when you need good, plain command-line access to every conceivable feature of a computer. For the last three years I’ve been keeping a Linux box [2] running 24/7 in a closet in my family’s house in Norway (I live in Boston), and I’ve found it useful as an SVN server, for offsite backups, proxying, and the like. Stability is a concern, though. I find that the machine crashes for unknown reasons about three or four times a year, depriving me of SSH access and requiring a hard reset. Usually a family member is around to simply push the red button, but occationally, things go awry (”screenshot” courtesy of mom):

Awry

Restarting the machine at this point would not get it far enough to gain me SSH access. A manual fsck from single-user mode was required.

In practice, I found it takes about two hours on the phone to instruct a non-technical (but very helpful!) user to hook up an otherwise headless server up to a keyboard and monitor, restart the machine, enter the root password, type “fsck /dev/VolGroup00/LogVol00″, press enter a couple of times, and restart the machine again, all while communicating verbally the contents of the screen. (Coincidentally, I think this is a really good exercise for understanding the amount of effort required by blind people to surf the web using a screen reader.)

I wish SSH access to keyboard and CGA display was a basic, low-level BIOS feature. Until then, there are remote KVM devices like this one, but they are very pricey. And you’d still need a remote power switch to allow remote hard reset.

[1] With all graphical fluff turned back to “Windows Classic” mode, of course.

[2] Originally one running Fedora (the free version of what used to be called Red Hat), then after a year I upgraded all the hardware and installed 64-bit CentOS (the free and independently maintained version of what is now sold as Red Hat Enterprise Linux). They are very similar, though I suspect Fedora package repositories might be more up-to-date and reliable (not sure; for all I know they might be equivalent).

ISWC Afterthoughts

Filed under: ISWC, Publication, Semantic Web, Thought Piece by David Karger on Wednesday, 11 November 2009 | 1 Comment

After recovery from chairing ISWC 2009, I had always intended to blog about some of the changes my co-chair Avi Bernstien and I tried for the conference.   I was prompted to do it today by a very interesting post by James Landay—it describes problems with the current CHI/UIST reviewing process, and led to some fascinating discussion comments by a bunch of the biggest names in CHI.  Well worth a read.  I’m not going to address it directly here, but a bunch of what we did with ISWC was motivated by related thoughts.  I’m writing about this because I think these were mainly good ideas, and recommend them to anyone else chairing a conference.

One set of changes we made was aimed at squeezing the gap between submission and conference.  It seems obvious to me that conferences should inform us of new work.   This doesn’t happen if the conference presents work that was submitted 7 months earlier (cf CHI)!  We made a few changes to tighten things up

  1. We compressed the initial reviewing period to two weeks.  While many conferences give reviewers several months to examine their papers, I’m certain that few people look at them more than a week ahead of the deadline.  Certainly most reviews don’t arrive until day-of!  We got exactly one reviewer  rushecomplaint abodut this schedule.   Perhaps we’ll lose some unusually disciplined and organized reviewers who like to plan ahead; I’m still convinced this is a big improvement for the community.  For the same reason, we offered the program committee only a week to digest and summarize these reviews before the committee meeting.
  2. Similarly, we gave authors only a week to revise their papers for publication after acceptance.   Again, we assumed most revision happens at the last minute, so we jumped straight to the last minute.  I’d say that a paper requiring more than a week of revision probably wasn’t ready to submit anyway.
  3. We advocated moving to a model, like NIPS, of producing the printed proceedings after the conference.   Given the slow printing process, distributing printed proceedings at the conference requires that final versions be submitted long before the conference.  I haven’t opened a paper proceedings for years, but enough people are still attached to them that I don’t think the time is ripe to do away with them entirely.  But distributing them post-conference lets us keep them without keeping the delay they introduce.    In the end, we weren’t able to convince the steering committee to make this change; however, our push led the publisher to offer an unusually swift timeline for publication.

At the end, we squeezed out enough delay that the critical path became something outside our control: travel to the US.  For cheap fares, authors need to buy their airlines tickets a month before the conference.  On top of this we had to add a month for non-US authors to get visas for travel to the US (sadly, one of next year’s co-chairs could not get a visa in time, and missed the conference).  Combining these requirements with our one month review process produced our final, 3-month lag between submission and conference.

Looking ahead, I’d advocate for ISWC to eliminate the paper proceedings and to select countries with more sensible visa frameworks—Canada anyone?  This ought to let us cut the submission lag by another factor of 2.

We also made changes to the reviewing process.

  1. We eliminated topic tracks, instead allowing authors to choose their preferred program committee member for review of their paper (as well as an alternate).  My experience has been that most track descriptions tend to be ambiguous gobbledygook that produce tremendous ambiguity about the “right” track to submit—especially if, as often seems to be the case for me, your work seems to span multiple tracks.  Given that decisions are made by the people on the program committee rather than abstract tracks, an “end-to-end” argument says picking the person makes more sense.  Authors understand their papers well and can study committee members to identify the one most likely to favorably receive their paper.   This is analogous to the submission process for journals where one chooses an editor.   There was some worry about load balance—what if everyone picks the “nice” reviewer?   But in practice we were able to assign every paper to one of the two chosen committee members.
  2. We eliminated the paper “bidding” process.  In past ISWCs, all potential reviewers were able to survey all submissions and bid for those they wanted to review.   We felt that it made more sense for our knowledgeable program committee members to select reviewers who they thought were best suited to each paper—aiming for a “best for the paper”, rather than “fun for the reviewer” assignment of papers.  We feel this worked well, guaranteeing good reviews of each paper.  Interestingly, this was the one change on which we got negative pushback at the ISWC town hall meeting—even though it was populated by the beneficiaries of our reviewing process, the majority advocated a return to reviewer bidding.  I still think our approach is superior.
  3. By a second end-to-end argument, we eliminated generic 1-5 scoring of papers,which ultimately must be translated into an accept/reject, and replaced it with actionable descriptions: we asked each reviewer to take a position for or against acceptance of each paper, or to “give up” and indicate they didn’t care.
  4. Perhaps most important, we sought controversial papers.  The obvious and common measure of  paper quality is the average of the reviewer scores.  However, this buries one of the most important potential roles of a conference—to encourage debate about research.  Rather than a paper that everyone considers OK, a paper that half the reviewers love and half hate seems much more important to present at a conference, since it indicates a fundamental disagreement about research that is well worth airing in public, exploring, and trying to resolve.   To seek out such papers we applied two policies.  The first was that each paper with at least one vote for acceptance was discussed at the PC meeting.  The second was that any paper that, after discussion, had at least one program committee member advocate was accepted to the conference, regardless of the amount of opposition.  Because “average scoring” is so deeply embedded in reviewing practice, this change required changes to our conference management software—which were cheerfully carried out by the folks at precision conference, along with all the other great customer support they offered.  We never had to wait more than a few hours for an answer to a support request.  I highly recommend them for other conferences.
  5. We introduced conditional acceptances.  We got some pushback that this is a big burden for authors, but I don’t buy that—obviously, the authors could choose to treat this as a rejection and skip the hassle, but in fact many of our conditional accepts were worked on and turned into accepts—including one of the four papers we ultimately highlighted as a best paper.  It is certainly a big burden for the program committee, and I’d like to thank our member for being willing to tackle this extra responsibility.

Finally, we made some changes to the conference itself.

  1. We scheduled our parallel tracks based on surveys of attendees about which talks they wished to attend. It was trivial to gather this information using a google spreadsheet.   Using it, we created a schedule with almost no conflicts among the papers people stated plans to attend.
  2. We introduced a category of “general interest” papers.  These were specifically not intended to be “best” papers; rather, they were papers we felt ought to be attended to by anyone interested in achieving a broad sense of the work going on around the Semantic Web.   The Semantic Web community is made up of subcommunities that risk becoming quite isolated from one another—the description logic community, the Semantic Web user interface community, the scalability community, the standards community, and so on.   To combat isolation we need to share knowledge, so we identified papers that we felt were representative of each subcommunity but also broad enough that members of the other subcommunities could understand them.
  3. We introduced a town-hall meeting so the community could give us feedback about all the innovations I’ve just described.  The town hall was reasonably well attended even without any food or beer incentive.  With the exception of reviewer bidding, all of our changes were favored by a majority of the town hall attendees.

There were three changes we completely failed to pull off:

  1. ISWC offers “in use” and “industry” tracks with their own submissions, committees, and schedules independent of the research track.  This creates ambiuity for authors about where they should submit and ambiguity about which track should accept, and also leads to tracks that are not coordinated at the conference.  I would like to see a single committee considering all this work as a whole.
  2. We had hoped to install Semantc-Web tools for managing information at the conference—letting people annotate the papers/talks they saw, provide information about restaurants they’ve attended, coordinate meetings with others at the conference.   We failed—creating a system for this still requires too much special purpose engineering.    I see that as a (to-date) failure of the Semantic Web community to provide tools that are easy to install and use.
  3. Both Avi and I were eager to nurture the study of user interaction with the Semantic Web.  We both consider this a topic that is not being sufficiently explored—without good user interfaces, we don’t think the promise of the Semantic Web can be fulfilled. Unfortunately, our plan was frustrated by a lack of submissions in this area—it seems the work simply isn’t being done.   I wonder how we can convince the community of the importance of pursuing it.

In all, chairing the conference was surprisingly fun and easy.  For years, I’ve declined chairing requests, on the theory that with my organizational capabilities any conference I chaired would not actually take place.   For ISWC, my worries were assuaged by a fantastic and well organized (Swiss) co-chair who made sure everything actually happened on time.  So, a big thank you to Avi.

Paper Awards at ISWC

Filed under: ISWC, Publication, Semantic Web by David Karger on Sunday, 8 November 2009 | 2 Comments

Having gotten ISWC’s Ontology Panel off my chest, I want to take the time to discuss the Best Paper Awards we gave at the conference.  The papers that got these awards received uniformly high ratings from their reviewers, were recommended for awards by the program committee, impressed the program chairs, and had good presentations at the conference.

Best paper went to Ugur Kuter and Jennifer Golbeck for “Semantic Web Service Composition in Social Environments”.   This paper reflected a nice linking of two disparate fields.  The first is semantic web service composition.   This area looks ahead to when users will create workflows by composing—chaining together—a series of “web services” (processes on the web with exposed APIs that can be invoked from elsewhere on the web), passing data from one to the next in order to perform some computation.  Generally, web service composition is looked at as a logic problem—figuring out which web services can be composed to meet a particular specification.  Kutur and Goldbeck instead look at a trust problem.   Many of these services on the web might not be completely trustworthy—perhaps they are fault-prone or even malicious.   The paper framed the problem of choosing, among many compositions, the most trustworthy one.  The algorithms in the paper are heuristic and surely not the last word, but real value of the paper was in framing the problem.

The best student paper, by Vicky Papavassiliou, Giorgos Flouris, Irini Fundulaki, Dimitris Kotzinos, and Vassilis Christophides, “On Detecting High-Level Changes in RDF/S KBs”,  was also a problem-framing paper.   Ontologies are obviously an important part of the Semantic Web (my last post notwithstanding) and are already heavily used to characterize data in a variety of domains (medical being a significant one).    Over time, these ontologies will evolve.   People will need to make sense of the changes to these ontologies.  It’s easy to describe “atomic” changes (this element was added, this removed) but these atomic changes are likely to occur in groups to achieve some higher level change.  It is these higher level changes that will serve as the most meaningful description to an end user.   This paper poses the two related questions of “how should these higher level changes be described?” and “how can they be detected from the raw description of atomic changes to the ontology?” Again, there is likely to be followon work, but this paper did a nice job initiating study of the problem.

We also awarded an honorable mention in each category.  For best paper, honorable mention went to Daniela Petrelli, Suvodeep Mazumdar, Aba-Sah Dadzie, Fabio Ciravegna for “Multi Visualization and Dynamic Query for Effective Exploration of Semantic Data.” Working at Rolls-Royce, they mapped a large amount of information (about jet engine design) into a Semantic Web framework and deployed a new user interface for visualizing and navigating that information.  They then studied its use and usefulness in the company and reported conclusions.   The paper was a real user study; something of whichwe see far too little in the semantic web community.  It was particularly nice to give this award after hearing a researcher declare the previous day that “there is no scientific method for evaluating semantic web user interfaces.”  The community needs more papers of this sort.

An honorable mention went to Jacopo Urbani, Spyros Kotoulas, Eyal Oren, and Frank van Harmelen for ” Scalable Distributed Reasoning using MapReduce.”  This was a performance paper, showing how to do typical semantic-web logical inference tasks on a large parallel cluster.  As is usual, the main problem is data communication bottlenecks between the processors, and this paper showed how a very limited amount of replication could dramatically reduce those communication bottlenecks.

Blogs and the Dissemination of Scientific Research

Filed under: Social Computing, Thought Piece by Michael Bernstein on Wednesday, 4 November 2009 | 6 Comments

HCI research needs to get better at spreading the word, sooner, in the Web 2.0 era.  Typically, by the time that CHI rolls around, the research being presented is at least 7 months old.  When (or if) a group decides to post PDFs early, the papers are so distributed that interested readers can’t find them. What’s more, the research that is posted isn’t presented in a web-friendly way: how many web pages do you read in PDF form?  But, when HCI research is made available in an interesting and accessible form, it often gets great press.

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?

Does the Semantic Web Need Ontologies?

Filed under: ISWC, Semantic Web, Thought Piece by David Karger on Tuesday, 3 November 2009 | 8 Comments

Ever since returning from the 2009 International Semantic Web Conference last week I’ve been bursting to discuss a panel that took place there on the topic “Does the Semantic Web need Ontologies?”.    But the WWW2010 deadline was today and we had 3 papers to write.  With that deadline now 10 minutes past, I can finally post!  When it was first proposed, I was concerned because panels need controversy to be fun, and I didn’t think there’d be debate on this topic.  However, the organizer was confident that he’d be able to arrange different viewpoints on the panel.

When I attended the panel I was sorry to discover that the panelist did in fact all agree.  Far worse, they all said “yes” and wanted to debate what kind of ontologies were needed. Those who’ve followed my slow conversation with Stefano Mazzocchi won’t be surprised at my reaction—ajump to the audience microphone to voice a strong “no!”   I asserted that a bunch of data presented in spreadsheets was already a big step forward over our current unstructured web.  This led to some interesting discussion that helped me clarify some points in my mind that I’ll try to lay out here.

The panelists’ general reaction was amazement that I could be opposed to ontologies.  Without ontologies, how could any tool actually use the data?  What good would that data be without an explanation of what it meant?

Tim Berners Lee tried to mediate by suggesting that I did support ontologies.  After all, a spreadsheet has an ontology: the ontology specifies rows, columns, cells, and the relationship between them. But by this definition, any structured data necessarily has an (implicit) ontology, and saying “ontology” is just another way of saying “structured data”.   And I think this diverges from the standard meaning of “ontology” in the Semantic Web community, which I would read as “an explicitly recorded, machine readable description of the ontology of the given data.”   While I am a big proponent of structured data I’m going to bet that the panelists would not consider their implicit ontologies to be ontologies in the Semantic Web sense.   So we do in fact disagree.

Why then do I think we don’t need (explicit) ontologies?   Because I’m focused on the ways that human beings, rather than machine agents, will consume the data being shared.  And for humans, a machine-readable explanation of the data’s meaning is often unnecessary because the human who is consuming that data can figure it out in other ways.  For example, the meaning of the data elements might be explained in English, a “caption” of the data I am inspecting.     Even without captions, if I get a data table with column headings, I can use my comprehension of English to understand the meaning of those headings and from it infer the roles of the columns.  Even if there aren’t column headings, the “shape” of the data can tell me a lot—I’ll recognize standard person names, phone numbers, addresses, prices, book titles, and such from the textual patterns or from matches to my large wetware database of known entities.  And if I see enough examples I can draw conclusions about the values in the column (indeed, Google Squared suggests that you might not even need a human in the loop to make these inferences).

So humans can understand data without (explicit) ontologies, but is it any use?  Sure!  Just to plug some of my own group’s tools, they can use Exhibit to throw it into a rich visualization—a map, timeline, or list with faceted browsing and sorting.   Or they can combine it with another data set using Potluck, and throw the combined data into an Exhibit visualization.  I can make a post on ManyEyes or throw the data into DabbleDB for further processing.  These activities typically require me to match certain properties (columns) of the data set into roles in the UI (Exhibit, ManyEyes) or to properties in the other data set (Potluck, DabbleDB)—a straightforward task.  They don’t require the machine to understand the data, because I’m the one taking these actions.  They do require that the data be structured, since otherwise there’s no way for me to say “which column” to the tools I’m trying to use.

That’s the argument I wanted to make at the panel, but it’s a bit hard to squeeze into 20 seconds at the audience-feedback microphone.  So I’m afraid the panelists instead thought that I was arguing against ontologies, asserting that they should not be deployed at all.

On the  contrary, I like ontologies.  But I’m convinced that ontologies are a luxury, not a necessity. They’re certainly nice to have, and there are some things you can only do if you have them–for example, theycan help me understand column headings written in Russian or Spanish by connecting them to explanations in English.  But I remain captivated all the opportunities that arise just by making data easily accessible in raw form.   Too often, what people want to do with information is perfectly easy to explain, but impossible to do without serious programming, for silly reasons.

And it’s that enthusiasm for open data that keeps me energetically arguing that we don’t need ontologies.  If we need ontologies, then work on freeing data needs to stop until we get them.  I think that’s a very dangerous perspective.  It’s the one that says “there’s no point to building tools for scientists to publish their data, until we’ve figured out the right huge ontology that we’ll force them all to publish in.”

Instead, I think we should go right ahead with our research on ontologies and tools for them, but in the meantime, let the data fly!

P.S. When someone rose to support me, arguing that we should forget ontologies and concentrate on Linked Open Data, I mudied things further by asserting that we don’t really need the “Linked” part, and Open Data is useful in its own right.  While it comes from the same place as my perspective on ontologies above, that’s the substance of my discussion with Stefano, and I won’t repeat it here.

Tales of a Semantic Web Skeptic

Filed under: Semantic Web, Thought Piece by Michael Bernstein on Sunday, 25 October 2009 | 9 Comments

Right now the world’s premiere semantic web conference is happening in Washington, D.C. As a graduate student of the fellow who’s chairing the conference this year, and working down the hall from Sir Linked Data himself, I’ve had my fair share of semantic web experiences. But my background is not in Semantic Web technology, so joining a group so focused on the semantic web threw some of its core tenets into sharp relief for me.

So here, from the perspective of a human-computer interaction guy, is what I’d like to see changed about the semantic web:

Stop Calling Everything ‘Semantic’

At worst, the term ’semantic’ in a title can mean “we re-did existing research using {RDF, RDFa, N3, OWL, SPARQL, DBpedia, Semantic MediaWiki},” without a clear notion of why this would be a good thing. The strength of the semantic web is its ability to interoperate heterogeneous data, yet the inclination is to ignore this and work on the problem, any problem, in a semantic web framework. Semantic web research papers can feel like a bunch of hammers running around in search of a nail. And there are plenty of oft-hammered nails: semantic query visualizations, semantic desktops, semantic wikis, semantic ontology alignment, and semantic web service composition, to name a few. Why do these benefit from being semantic, any moreso than taking another approach?

At best, the term is still very unclear about what it implies. ‘Semantic’ should mean more than a language or a framework. It is an idea, and the idea should drive the research. Saying that something is semantic should imply something as clearly as saying that it is a proof by reduction, or a tangible user interface, or a static code analysis technique.

Who’s the User? (And Why Would They Ever Use This?)

That’s not a jab. It composes two specific critiques:

To solve important problems, you need to know who your users are. What are their problems? What biases and constraints do they bring to your system? This is true whether you’re composing web services or creating a Linux desktop. Semantic web technology’s greatest strength and greatest weakness is that it is very general. Too many projects focus on trying to help everybody; but too often, “everybody” is too vague to give you a good foothold, and it trends toward “semantic web-interested people”. This leads to many issues with the research, not the least of them is the Big Fat Graph solution to every semantic web problem and the requirement that I manually author RDF triples. When you’re defining the problem, define the set of users! “Everybody” is too vague; start with some personas or scenarios, or build systems that aim at some subset of the world. This will give you the insights necessary to generalize back out to “everybody”.

Second, there are some serious questions about user motivation. The semantic web suffers from a real cold start problem — how to get all that data into linked format.  Again, no single motivator will work for everybody, so the resulting motivators are so general, or so tied to implicit semantic web assumptions, that few get off the ground. Nobody wants to sit and re-encode their data into semantic web format.  But given a real problem, and the promise of a solution that just so happens to involve RDF, it will happen.

This is why I think Semantic Web UIs is something of a misnomer. It’s like “Java Swing UIs” or “UIs based on a relational database backend and a PHP frontend”. The critical irony of a good semantic web UI is that there should be no indication that it’s semantic. You could do this using a standard database and data model, but it’s easier because it uses semantic web technologies. Again, the interface should flow from the problems, not from the data model (flexible as it is).

I’d love to hear a semantic web researcher’s critique of human-computer interaction. Or your thoughts on my thoughts…

Thoughts on NoteWorthy Composer

Filed under: User Interfaces, Workflows by Eirik Bakke on Thursday, 22 October 2009 | 2 Comments

Many years ago I discovered NoteWorthy Composer, and I’ve been using it for music notation ever since.

NoteWorthy Composer

Unfortunately, I find that NoteWorthy doesn’t scale very well in several important dimensions. In particular, it lacks the ability to:

  • Let the user manipulate multiple staves at once (even just for copying/cutting and pasting a horizontal section of music from one place/time to another).
  • View several staves as a single “condensed” score.
  • Save vertical screen estate by hiding staffs containing only rests for a given interval (Stravinsky-style “cutout scores”) .
  • Switch rapidly between transposed and untransposed views of the parts in the music, and handle copy/paste between transposed parts. For instance, (Bb) trumpet parts are “written” two semitones higher than they “sound”, so when you copy a melody from a piano part (untransposed) to the trumpet, it should appear as if it was transposed up by two semitones.
  • Hide presentation details from the user. I spend much time adjusting the location of staff items (like an “mf” dynamic marking) so they don’t collide. Also, copy/paste works on a too low level (see above), so if you copy a melody from a treble clef part into a bass clef part, or from a location with one key signature to one with another, the result will be incorrect until fixed manually. Also, the current clefs and time/key signatures are not shown to the left of the screen like they ought to.
  • Associate note velocities recorded with a MIDI keyboard with notes in the score for improved expressiveness in future playback. Actually, I want more than this: I also want the ability to record volume changes (e.g. from an external MIDI expression pedal), and the ability to record tempo variances (rubato, fermata, and all the little things that make human performances better than plain computer playback from a digital score) in the same way.

For these reasons, I every now and then decide to stray away and try the latest version of Finale or Sibelius, most recently the latter. I find these full-fledged music notation packages can do almost anything, except letting the user manipulate the score efficiently. Whereas in NoteWorthy, there is almost never any reason to reach for the mouse, Sibelius forces you to click all the time. In general, I find NoteWorthy’s editing model beats that of Sibelius by great margin when it comes to entering music on a single staff.

Granted, NoteWorthy’s model is very unconventional and quite weird. It regards every staff as a separate list of staff “items” (which includes notes, rests, bar lines, clefs, key signatures, and such), and editing is done word processor-style: there is a cursor which goes between staff items (unlike in Sibelius, where it seems the cursor can be either between or on an item), and the staff items behave like characters, meaning you can delete them with the backspace or delete keys, select them by moving the cursors left or right while holding down Shift, and so on. Measures work like to words, meaning you can move the cursor quickly between them via Ctrl+Left/Right. This all works extremely well for single staves, and when entering multi-staff music linearly from beginning to end. However, NoteWorthy’s editing model fails horribly if you make a mistake while editing the middle of a piece of music with multiple staves:

NoteWorthy Misalignment

Notice how the error propagates to the entire rest of the piece, and how the user him/herself has to figure out where there’s a missing note and what that missing note’s duration might be. In fact, the situation above needs not even be an error: if you wanted to replace the contents of one measure in the middle of the piece, the staves would inevitably be misaligned (like above) during the editing operation. This forces the user to think very hard about editing—if you lose track of what you’re doing for just a second, it’s a pain to figure out how to realign the staves again.

Despite all of this, I find I can work so much faster in this environment than in say, Sibelius, that I’m sticking with NoteWorthy for now. But future blog posts shall reveal my glorious plans to fix all of this by writing my own music notation software (no, NoteWorthy is not open source, unfortunately)…

Next Page »