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 http://eprints.ecs.soton.ac.uk/12911/]
mSpace more than anything is an idea about access and exploration: improving access to information; helping people make connexions from one idea to another.
mSpace has been expressed as an interaction model (ah03 paper; ht04 paper): the idea of an interaction model is to look at what attributes you want to support for an interaction, and see how they can be formalized. From the formalism, it becomes possible to see how it can be applied to situations in general that may wish to use the model.
More recently, mSpace has been deployed as an evolving software framework based on Semantic Web technologies ( demo, software download, framework docs(pdf, 1.6m)), which embodies many attributes from the interaction model. The mission with the framework is to enable folks interested in this open standards approach to making connexions among data to do so - to at least try one way of exploring data that can be hooked up in such an associative way.
And just yesterday, mSpace became an example.
In this case, an example "for someone trying to make use of data on the web, the web is one huge heterogenous data integration problem."
The great thing is that the person who turned to the project is Mike Linksvayer, CTO of the Creative Commons project, looking at getting more information to more people in less entangled ways.
Of course the other happy thing is that none of our team knows Mike personally, so it's nice to see that mSpace is moving out beyond the shores of its home in ECS at the U of Southampton.
And one more great thing is that mSpace was used as an example in the context of a talk given on a panel called "“The Semantic Web: Promising Future or Utter Failure”" at SXSW; it was placed on the side of Promising Future - perhaps in no small part because, as Linksvayer put it, "it won’t be obvious to an end user that they’re [using] a semantic web technologies application, and that’s as it should be." Here here!
Future Note: While we've put up an mspace browser for classical music, the model can be applied to any domain. If IMDB used Mike's Creative Commons licensing, we'd be able to put out an mSpace of movies (it's built, but we can't show it to you, since that would cost us 10k). But other mSpaces are sprouting up (one in the Sculpteur project is to use the model rather than the framework as a java applet-based ontology browser in a museums context). We'll link to these mspaces as they become available.
Among other things, we're also working on supporting the intersection of multiple mSpace domains (via a meta-mSpace), so that people can move as easily to tangents among domains, as they do now within domains.
Geek Note: you don't have to have a formal ontology to build an mSpace. If you have one, that's nice, and you get the added benefits of inferencing and connection which an ontology makes possible, but if you want to start light, you only need to define what we've been calling a "domain model" for your info. It's what might be seen as an implicit schema. We're working on a tool set to make constructing a model file dead simple. In the meantime, instructions are in the software docs on sourceforge included in the download.
If you want to see a full bore semantic web ap on steroids which uses an ontology, and is a precursor in its implementation to mSpace (it doesn't have all the sorting/swapping/slicing features of an mSpace), take a look at CS AKTive Space (CAS), an ap for exploring who's doing what research in computer science in the UK (described in the paper "CS AKTive Space or how we stopped worrying and learned to love the Semantic Web").
CAS won the Semantic Web Challenge of 2003 in part because it: got data from a host of heterogeneous sources, used them in ways for which the data's initial deployment was not presented, demonstrated the power of an ontology for doing inference over data (like who collaborates with who which is not in any of the data explicitly; what other stuff not already known about have these people done), it could scale (this thing handles tens of millions of triples - the manner of storing data in rdf for SW deployment) - and it lets folks explore complex queries in simple direct manipulation kinds of ways.
We took the lessons learned from deploying CAS in order to make a first pass at (a) implementing the richer set of interactions we wanted to support, like picking what things you want to explore, and being able to reorganize these on the fly, and (b) making it easier to sling an mSpace across RDF data without requiring all the heavy lifting of an ontology, but letting designers use and benefit from it when they had one.
In the meanwhile, thank you for using mSpace as an example. We're developing new ways to keep it light: to make it easy for folks to use the advantages of the semantic web without them (you and me) having to know that they're/we're using it.
Yesterday (fri Feb 18 05), mSpace was slashdot'd. (Thanks to Marko Daniel for pointing out the significance of this).
My first experience with the slashdot community. As Spock would say, "Fascinating."
Interesting to me how ready people there were to hold forth - some at length - about their assumptions about the system without actually exploring beneath a cursory glance at the article the set off the steam release: an article in
the Register, http://www.theregister.co.uk/2005/02/17/semantic_web/.
Most of the entries for instance seized on the fact that currently the demo only supports mozila-based browsers. There was a tussle over whether or not it was right to ignore Microsoft's Internet Explorer. Judgements were flying about this - happily assuming or assigning intent, one way or the other, about goodness or badness of this decision.
Interestingly again, based on the likely number of developers on the site, i don't think anyone suggested Time as a possible factor in terms of deciding what to support: working with w3c standards compliant DOM manipulations gives us multiple browser support. Trying then to figure out how to adapt this for IE is possible, but for a research team, takes extra cycles that, in a time-limited project, were really much better spent elsewhere.
Even more interesting, that great discussion could largely be seen as a tangent to the issue at hand.
Don't mean to sound down on the slashdot exchange: met some cool folks the team wouldn't otherwise have encountered, and learned about some related projects that were new to all of us. That was great. Thank you to the person who kicked that off.
Also learned that we may need to do some work to expose more about the underlying part of the work so people at a glance can see what the semantic-webness of the project is.