August 3, 2006

Why Graphs Suck for Exploring RDF (ie The Semantic Web)

The most popular mechanism for visualizing RDF - the underlying language to represent the Semantic Web - is a Great Big Graph. Take a look at any model you wish: rdf-gravity is a Big Fat Graph; frodo is a UML-like connected flow chart thing; there's RDF Graphs with GSS; and there's a suite of redeployed classic Node style visualizers that have been modeled and applied anew on rdf (pdf). And that's just a light sampling.

What is this obsession with using graphs to represent RDF?

At first i thought it was because Java, a tool frequently used to create these visualizations, comes default with a Touchgraph component, and its bouncy connected parts have a certain "gee whiz-ness" to them - at least the first time one sees them.

Now it seems, the use of graphs has become a (bad) habit, an overused trope, representing what David Karger calls the "pathetic fallacy" of using graphs to represent the Semantic Web ( a quiet exchange in a paper review that we're now teasing out into a Position you're reading here...).


So what's wrong with Great Big Graphs? After all, RDF is a graph. Ya well, as Karger's comments continued, so's the Web (ps), but we don't see people exploring the Web via it's bowtie shaped nodes (pdf), do we? Indeed, Kager takes this assertion further to state that "everything" can be represented by a graph, and yet we do not use graphs to represent "everything." Why not?

Great Big Graphs are known to address two things that we rarely want to do on the Web: show the Shape and Density of some collection of things so that we can say things like "Oh that's really big" or "there's a lot of activity going on down there in that part of the graph, but not much up here." The classic issue with a graph, however is that to get the overview, detail gets lost. Conversely, as we zoom in, the context gets lost. This loss of context is particularly irritating in touch graphs where zooming in on a component apparently breaks it off from the rest of its graph. This focus vs context issue of any graphical representation of information where the goal is to someone show the whole thing and yet also provide detail is a classic problem in Human Computer Interaction, and the subject of considerable research {refs to follow, but in the interim, take a look at the topic "focus + context" in the ACM digital library's search box}.

At the heart of the problem is that at scale (when there is considerable data to represent), or as soon as what a system is trying to model as a complete entity takes up more than one page/screen, the detail/overview compromise kicks in. Whether the graphs are UML diagrams, flow charts, clustering graphs, maps of geographical areas or maps of streets or networks, scale forces a compromise between focus and context, but if the interest IS in exposing an entire domain at once graphs and the techniques for balancing focus+context can be extremely effective (consider the micro map of either a 3D gaming environment that shows where one is in a world from an overview perspective relative to one's first person perspective; or the similar technique used in a Photoshop document where when zoomed in to work on a small section of image a map tool shows where one is working relative to the rest of the image. This map tile outline can also be used to navigate and reposition one's work area in the image). A question emerges here, however: if graphs are typically deployed to show the WHOLE of whatever is graphed, why is that an appropriate model for providing access to the Semantic Web? And if it isn't (a) why are we using it or (b) what alternatives are there for considering how to wrap up RDF data for effective use?

A fundamental question from the HCI perspective related to the above would be: what question/task/need is a given graph or other visualization answering? or perhaps, to put the question another way, what visualizations/representations/interactions would best support the specified tasks? And to push that question one further, what is particular about the semantic web such that new types of interaction designs may be required to support the types of tasks that are semantic web specific? Indeed this last question is the subject of a workshop on the Semantic Web and User Interaction. The challenge becomes: what, if anything, is special about what the Semantic Web enables such that existing UI paradigms don't suffice?

We've suggested that Great Big Graphs (GBG) are not appropriate as a de facto way of presenting the Semantic Web because the tasks it supports are limited. This limitation is not in itself a bad thing, but that we'd suggest that there is not a strong match between what a GBG provides and the kinds of information support people who use the Web have come to expect (try doing email or buying a book with a GBG).

Part of the problem, one may assert, is that SW data is delivered with more in common with a database and its schema than a Web Page - but even that argument doesn't wash, since most commercial web sites are delivered with a database back end now - and they look like web pages. So, the question, to repurpose Freud somewhat may be not why do graphs suck for the Semantic Web, but "what does a (SW) user want?"

Another way of putting the question of what do we as SW users want may be: "what are we trying to do?" Ben Shneiderman, HCI Guru at the U of Maryland, and his student Bill Kules, have more recently been framing the question as "what do you want to know?" effectively, Shneiderman has said forget trying to show everything since we can never see everything at once anyway, and focus on the kinds of things that are of interest to the explorer. Much of shneiderman's work, from spotfire to the more current hierarchical clustering, has indeed focused on enabling researchers to focus on the kinds of questions of interest to them - such as being able to look at the results of a variety of functions when applied to sets of datas - thus being able to see for instance in what conditions are their outliers.

The advantage of keeping the question as "what do we want to do" rather than "what do we want to know" may more explicitly capture one particular attribute of the Semantic Web which it has in common with many Web 2.0 applications: the desire to DO something on the Web with the data itself. To tag it; to edit it; to share it; to push it into new and or other representations.

These attributes of edit/tag/share are possible with Web2 aps, which break one part of pre Web 2 models, where the web is interactively read only. However, the specific affordances and constraints, to use Don Norman's terms, of the Semantic Web may take us beyond even these relatively new ways of interacting with information on the Web.

Difference at Source leading Difference at Interface
One of the interesting features of the semantic web that is not harnessed by simple Great Big Graphs of RDF is the fact that it is increasingly possible to break the paradigm of the page (called for in You've Got Hyperext) and actually enable people to choose a variety of representations for the information out there, depending again on what they want to do with it. Likewise, the immediate possibilities of how one set of data might be repurposed with another set of data automatically is also a remarkable and still largely untapped affordance of the Semantic web.

This capacity is enabled by that same RDF that wraps up and makes communicatable the semantics of the data in relation to itself and to other data. Just as the schema of a database makes visualizations like Spotfire possible, the RDF of the semantic web will make richer mechanisms for engaging with data possible.


We see some of this page-breaking, cross-web, context sensitive flexible repurposing of data in Semantic Web Applications like Haystack, piggy bank, AKTive Futures and /facet (pronounced "slash facet"), and from Semantic Web/Web 2.0 hybrid applications like mSpace and mSpace mobile



AKTive Futures, for instance, uses a cartesian graph as one facet of its interface presentation. The core interaction of the UI is to select countries for one axis and ranges of years for the other to look at trends in oil production in those places and times. By clicking on a spot on a line on the graph, the stories that are associated with those confluences are presented in a secondary window. In this case, the use of a particular kind of graph is appropriate for the task the designers of the application wish to support. Date and output data from MULTIPLE resources, (not just one database), are, as numeric data, represented in a numerically relevant fashion - not as static tables but on a graph where, in Shneiderman's parlance, the person using the service is not presented with all data for all time, but is enabled to select the ranges of interest and focus on them with an appropriate format.

For this site, data is coming from all over the Web and converted where it doesn't already exist in SW format into SW format (ie rdf most usually) so that it can be rendered appropriately for this kind of explorable user interface (UI). Indeed, the graph is used to help find trends of interest (not unlike Spotfire) and to use those relations of interest as the way to find the richly associated information to tease out what may have caused that particular moment.

Pre-existing Sites with a Purpose - Predefined Semantic Web UI aps
The above sites are examples of what happens when a site with A Purpose already exists. Haystack's exemplar is the "universal information client" which integrates calendar information with other associated tasks like hotel and flight booking along with finding relevant and related email to support tasks in process. In this case, Haystack is showing the way of using the Semantic Web to do old tasks better, using familiar UI paradigms in new contexts to make it easier to do related tasks that typically draw down on information from a variety of applications: checking email for when a conference is in order to get the dates into the calendar and check out flights for those times.

mSpace's is making classical music discoverable for people who know nothing about classical music. This discoverability is enabled by adding Preview Cues, or the ability to check out not just a piece, but the sound of an area of music, like sonatas or baroque, quickly and easily. This feature in itself is not driven by the semantic web, but it is powerfully supported by it. For instance, there are other affordances that the interface provides that go beyond online music explorers and into what makes the Semantic Web interesting: the browser automatically associates information from different sources about the music in the explorer with the music - choosing "period: baroque" yields a description of that content. This ap is another case of taking familiar and largely effective models for music library exploration and play back, and enhancing them to enable either improvement of previously doable but difficult or cumbersome tasks.

These sites suck in and make shapable information related to sepecific predefined domains. They use specific graphs to present the data in the domain (calendars, maps, timelines) but these are supplemented with or are supplemental to serving other activities, based on interaction models designed specifically to support certain kinds of information exploration and discovery tasks that are well-enabled by the Semantic Web.

For instance, with mSpace, new dimensions can be added to the domain as they become known; musicological data may be supplemented with technical recording data or historical data. The UI makes it possible (to use spreadsheet language) to pivot from one domain to another on a related term - so one moves from beethoven in the context of music to beethoven in the context of history. Sure yes one can do these pivots with databases and spreadsheets. Indeed, George Roberston's Polyarchy work called "Visual Pivot" (pdf) in fact has shown exactly such pivoting in very interesting ways from one database table to another. One may suggest, however, that the Semantic Web has the potential to break from database scale to greater, messier, heterogeneous Web scale.

Dynamic, Free Form Semantic Web UI aps
One of the challenges of the Semantic Web however is to enable us to just get at that rich data via our own dynamic contexts. For instance, suppose there's an interest in finding Jazz music that may be of interest and there's no pre-made mSpace Jazz explorer? or more intrigued yet, someone is interested in not only exploring the sounds of jazz but of seeing what is happening historically both politically and in architecture at the same time as different trends in music are occurring in order to explore the question what was influencing what when?

The above kind of questions means that a person may wish to be able to start exploring from a particular seed or set of seeds from which to start building and exploring relations (though even how to express these seeds may be challenging - another matter for interaction research innovation (ever know what you want but not the terms to express it so that you can find it on google?)). The above mix query means that samples of music need to be available so someone can audition the songs (we do not assume the Questor is a jazz expert) to see what's of interest; engage historical political period data from different regions; enable this data to be contextualized not only by location but by time, and readily explorable by time and by location visualizations. What's the ideal representation for this information as it is assembled? It is NOT a Great Big Graph (alone or primarily).

Web Founder and Semantic Web co-Founder Tim Berners-Lee has been developing an idea called the Tabulator (which i can never seem to find working), Conceptually, one starts with a specific known source of semantic web data, and then rather than in a graph, one selects cells in a tabular representation of the rdf, which expand into fresh tables, etc (go see the site for an image of this - maybe you can even get the demo to work). The data collected in these expansions can then be re-visioned into either a map, a calendar or a timeline (note the term "or"). There's considerable potential here - currently the source of the data is very geeky and not that non-geek friendly - data is expressed in rdf-ease triples like "colorPicture is mentioned in TAGmobile road trip BOS-> Amerst:photo" Qu'est-ce que se?

The tabulator also seems currently to be informed by the old-school Web-as-Read-Only, where as the impetus of Web 2 (and the semantic web) is towards read/write/re-write - a very much more Ted Nelson-ish hypertext vision ( a good thing) than pre Web2 vision.

Mix and Match on the Fly
So, some of the challenges for Semantic Web UI services besides de-geeking things like Tabulator will be to support data in formats so that the application has information that is relevant to what display options may be appropriate for it (dates, map coordinates, contacts). It's not clear what the solution is: micro formats is one approach; fresnel, defined as "a generic ontology for describing how to render RDF in a human-friendly manner" - where the style sheet for a data chunk effectively travels with that data offers another. It will be interesting to see how these approaches work across heterogeneous data sources and distinct contexts. It will also mean being able to add new data/links/tags(?).

That latter observation of the context in which the data is discovered leads back to the earlier observation that UI's for semantic web data, like all other human-usable systems, need to respect and support what the human wants to do with that data. Being able to establish context for multiple intersecting data domains and data types may be as critical as being able to take advantage of a pre-asserted format for a particular data chunk.

The bottom line is that Great Big Graphs have their place, but overall, it's a pretty limited place. Great Big Graphs are generally also pretty easy. The algorithms for pumping data into many graphs are well known. As Karger says, it's a pathetic fallacy to assert that because the data model is a graph the data should therefore be displayed as a graph. It's also, let's face it, a cop out in usability terms, unless all one wants to see is how big is the data set, where are the dense bits etc. The harder question is "how might this data be used? how will we support those heterogeneous requirements - and do so dynamically, elegantly"

People at the coal face of RDF and Ontology development mayn't see it as their mission to consider that more human-oriented approach to representing information spaces for human usable, human-useful exploration. But why not? The result may well be the generation of a generic Semantic Web browser - a tool that would enable people both to explore and contribute to the rich associations possible in the ((increasingly Social and) Semantic) Web.

[update Aug 17 '06 : the version of this blog entry David and i submitted to SWUI06 is available (in html) at]

Posted by mc at 10:43 PM | Comments (0)

The mystery of single temperature faucets

200608031049Occasionally, i see things and think now that's a cultural difference that would cause a north american a double take. Seeing cars parked facing either direction on a street. That's a weird one (yes in north america cars are parked facing one way only - no just sliding over to the other side of the street and pulling up onto a curb and parking. You turn your vehicle around and parallel park the sucker into the spot).

Then there's power outlets with individual switches on them. Or windows with little wind powered fans. Or the making of tea in a cup rather than a pot, or the fact that instant coffee is on many restaurants' menus.

But one thing that constantly surprises me is the pervasiveness even in "new builds" of individual hot and cold water taps. It's not that "mixer" taps (hot and cold going into one pipe) are unknown, but that anyone would want a single tap per temperature in either a bathroom or kitchen sink, or even a bathtub is beyond me. And it's not like they're cheaper: the price of two individual the taps is either the same or more as their integrated cousins.
It's a mystery.

Posted by mc at 6:06 PM | Comments (0)