We present Humboldt, a novel user interface for browsing RDF data. Current user interfaces for browsing RDF data are reviewed. We argue that browsing tasks require both a facet browser's ability to select and process groups of resources at a time and a 'resource at a time' browser's ability to navigate anywhere in a dataset. We describe Humboldt which combines these two features in a single coherent interface. Our approach is based on the operation of pivoting, which enables the user to move the focus of a browsing from one set of resources to a set of related resources. With repeated use of the pivot operation the user can browse anywhere in the data. We describe a preliminary evaluation of our approach and discuss its implications for further development.
As more and more large Linked Data sources such as
DBpedia [
Current research in the semantic web user interface area,
especially in semantic web powered search engines, has tended
to focus on information retrieval tasks. We characterize
these tasks as those in which a user has a very speci c
question or query in mind which he tries to answer or solve.
Companies like Powerset [
In this paper, we focus on exploratory tasks and
characterize them as follows: in exploratory tasks, a user has a more
vague idea of the question he wants to answer. His interests
depend upon the changing characteristics of the information
context [
We give two business related examples for this kind of tasks: A product manager plans a product update. He wants to get an overview of the new features of competitors' products. User reports of his product have been tracked by his companies support department. His development team came up with new ideas for innovative product features. The production department has published technical data on new methods of cost reduction factoring. The product manager needs to decide which changes will be made with the next product release.
A nancial analyst notices an irregularity in a dataset. He seeks for an explanation. The company works in a broad market and it might be a competitor's news as well as a companies news. The company is active in foreign markets and depends on certain suppliers. Political news as well as changes in the suppliers market might also have in uenced the nancial data.
Both examples highlight the di culty of having a computer system 'solve' these problems by providing a single answer. These tasks require gathering together structured and unstructured data sources. In this paper, we focus on exploratory tasks using only structured data.
In the current document-centric web, a key mechanism of web browsers to support information exploration is the browsing history. Users can follow di erent links to other documents and, depending on the document's relevance, decide to further explore or go back and follow a di erent path. The possibility of returning to a previous decision and following a di erent path makes decisions less risky. Browsing histories and bookmarking functionality help users to store discovered information in the system instead of having to memorize it for later reuse.
The Semantic Web with its access to more structured information makes data aggregation techniques more important in exploratory tasks. Structured data can more easily be aggregated, supporting better overview of large amounts of data.
In information retrieval tasks on web documents, a goal is to nd a speci c document or - in terms of graph-theory nding a particular node in the graph of linked documents. While the path to that node or the edges connecting it are important for localizing the node, the node's meaning is mostly independent of which path was used to retrieve it. That is di erent in Semantic Web tasks. The path used to locate a node or the relationship between nodes is more important. The meaning of just retrieving the node of a person named 'Ian' is di erent than retrieving it as a link from a person named 'Georgi' by following a foaf:knows link. The later represents 'Ian as a friend of Georgi'. With this example we want to highlight how and why exploratory tasks are di erent and why the user's exploration process and path is more meaningful that in the web of documents.
A user will want a semantic web interface to follow a similar exible approach as browsing backwards and forwards in exploratory tasks. An interface supporting that approach would support user behaviour and exploration strategies, in which the user has a perceived low risk of making early decisions because he can go back and modify them later. We outline a simple example for casual end-users: a user might want to explore a dataset of lms in order to nd an interesting one for a movie night. He does not know upfront which lms are available and has no speci c preference of the genre. Over the past, he has seen many movies and do have some preferences for particular directors and actors, but is willing to explore new ones.
The essence of this task is viewing the actual available data, which will in uence his exploration strategy and might change his interests as described above.
In this section, we review three di erent kinds of
semantic web user interfaces according to their ability to support
users in information exploration tasks. We identify the key
principles of each approach, and will then further discuss
how the advantages can be combined into one user interface
design. We are interested in generic user interfaces rather
than interfaces tailored to a speci c domain. While there
are certain visual representations for particular data types,
e.g. calendars and timelines for time-related data and maps
for geographical data, there are no such representations for
most other types of complex resources, e.g. people, lms,
companies etc. Hence we treat those speci c representations
as additional features to a more generic user interaction
approach and do not include them in our analysis.
With growing availability of Linked Data [
There are various di erent semantic web browsers for Linked
Data available, which use a similar interface design to Tim
Berners-Lee's Tabulator [
This design re ects a common user interaction on the web
of documents. There, the smallest piece of information is a
web page, and a web browser enables users to navigate from
one page to another. This browsing approach has been
applied to semantic web linked data, where the smallest piece
of information is a RDF resource. We argue that this kind
of interaction does not facilitate the key bene ts of
Semantic Web data. Much of the currently available Linked Data
is either scraped from web pages, such as DBpedia, or also
available as human readable webpage as well like Geonames
[
However, this might change as more and more RDF data
becomes available from databases, where no corresponding
web pages are available. Semantic Web technologies could
serve as methods to create web documents, but the key in
browsing and analysing this data lies in our opinion in
aggregation of data, like the currently available Web2.0 mashups.
Single resource at a time RDF browsers enable users to
explore large RDF datasets, but their design does not support
the user in aggregation tasks. The browser design might
enable aggregation tasks when a kind of basket is available
to temporally store discovered resources, such as Piggybank
[
For example, given a user's FOAF [
The method of faceted ltering [
Exhibit [
Faceted Filtering supports exploration tasks as it enables the user to quickly get an overview of what data is present. Compared to the previously described design of one resource at a time, faceted browsers use a multi resource at a time design. Even larger sets of resources can easily be clustered or ltered by certain dimensions in order to quickly see what data is available. For example, a large list of people might be clustered by their birthplace or by the organization they work for. The user can then lter the set of people down to a smaller set according to these facets.
Current implementations work with a xed list of resources on which faceted ltering is performed. With growing datasets, the number of potential facet values also grows. A set of thousands of lms might have a facet with hundreds of di erent actors. Hierarchical facets are one solution to further cluster facet values.
Graph based query builders try to give the user the most
expressivity in querying an RDF graph. An common approach
is to provide a triple based user interface which helps to build
triple pattern to express queries. One example of such an
interface is the DBpedia Query Builder [
Using actually available data for query construction is a
concept known in database environments as Query by Example
(QbE) [
We present an interface design in which we combined the three previously discussed interaction approaches: Browsing, Faceted Filtering and Query Building. We integrated the following three characteristics in our exploratory interface: multi-resource at a time, browsing and implicit query building. We argue that the multi-resource interface design is most helpful for exploration tasks as it supports overview techniques and data aggregation as shown in faceted browsers. Therefore we also integrate a faceted ltering mechanism similar to Exhibit. Our interface approach does not relate speci cly to RDF. It is applicable to any graph-based data structure. For our experiments and demonstration we use a highly interlinked dataset extracted from DBpedia (see gure 1). This dataset contains data related to the movie domain and consists of lms, directors, actors, cities, and companies. We modi ed the dataset in order to provide a rich linking structure with n:n relations between instances, as well as circular relationships. Films have many actors, actors play in di erent lms of di erent directors. Directors get awards for lms and work for companies which produce lms.
We now describe the main elements of our interface (see gure 2). The interface is presented as a xed workspace of three di erent elements: result list, facet list and history.
The core of our interface is the result list. The result list presents a collection of RDF resources as unstructured list prefix : <http://dbpedia.org/resource/> prefix p: <http://dbpedia.org/property/> :Catch_Me_if_You_Can p:has_director :Steven_Spielberg . :Catch_Me_if_You_Can p:starring :Tom_Hanks . :Catch_Me_if_You_Can p:starring :Leonardo_DiCaprio . :The_Departed p:has_director :Martin_Scorsese . :The_Departed p:starring :Jack_Nicholson . :The_Departed p:starring :Leonardo_DiCaprio . :Martin_Scorsese p:birthPlace :Queens . :Steven_Spielberg p:birthPlace :Cincinnati . :Leonardo_DiCaprio p:birthPlace :Los_Angeles . :The_Departed p:distributor :DreamWorks . :DreamWorks p:keyPeople :Steven_Spielberg . of items without exposing their relations. The result list is used in two ways: for displaying an external RDF document and for displaying query results from within the browser. When an external document is loaded, all resources in this document get rendered into a plain list independently of their relationship. A tag cloud on top of the list can be used to lter the resources by their rdf:type. This can be used to render the output of other applications, e.g. semantic search interfaces. These applications can provide the URI of a RDF document which contains a list of resources to be displayed and browsed with Humboldt.
The main point of interaction in our interface design is a list of facets, presented on the right hand side of the result list. Facets are computed from all resources that are related to resources in the result list and grouped by their rdf:type. This method di ers from other faceted browsers, where facets are usually constructed from a predicate that connects two resources. By using rdf:type instead we want to test the hypothesis that introducing an additional level of abstraction reduces the number of facets. This new level of abstraction should help the user to get an overview over the available data more quickly. During this exploration phase, the user does not need to see all details of existing relations. For example, a list of people (results) in a movie related dataset can be connected to a list lms (facets) with many di erent predicates like directed, stars in, has produced, has written, has edited, and was awarded for. If the dataset also contains cities that are related to the people, facets like born in, lives in, died in, etc would appear. By grouping by type, the only facets are lm and city. The user can get an overview of the available data and later drill down by splitting one facet into several ones based on particular predicates or sub-classes. He thereby restricts the relationships between results and values in a certain facet. A list of lms could be related to a facet of people. Users want to be able to restrict these relations to certain properties, e.g. to people who directed or produced a lm and exclude people who acted in a lm. This operation could be understood as a drill down into the result-facet relationship. As in Exhibit, we designed facets for ltering the result list. The user can select a value in a facet to lter down the result list to all resources that are related to the selected resource. This will cause all other faceted to be recomputed based on the now ltered list of results.
For example, having a list of lms loaded into the result list, the user can select Steven Spielberg from the Director facet. This will lter the list of lms to those, which are related to Steven Spielberg by any predicate. The user could later drill down into the Director facet to select only directed by and awarded for as relations between these lms and Steven Spielberg.
In order to combine a faceted layout with browsing
capability, we use the Pivot operation, which is similar to Siderean
Seamark [
E.g. a user who lters lms on certain directors and then pivots on actors will see all actors in the result list, who are related to any lm in the previous result list.
In order to support the user in building an implicit query over a number of connected list (of facets), we suggest tracking the user's path through the graph. We use a separate History control, which displays the path the user has taken via pivoting facets from the starting point to the current page. We chose to display the path as a linear sequence in the history control, which enables to step back to previously visited pages. While this represents the implicitly built query, lters that are applied on a graph node a ect other nodes as well.
When a user pivots from lms to actors, lters these actors by their birthplace, and then steps back to lms, the ltered actors themselves a ects the list of lms presented. This enables drilling-down into facets. As described previously, facets are partitions of data according to di erent dimensions (see section 2.2). Actors are one dimension of lm data, but actors themselves have di erent other dimension, e.g. their places of birth. Starting with lm, users can drill into their actors and their places of birth, and afterwards zoom out to lms again using the history control.
We have implemented a prototype of our interface as
serverside web application in C#. The core of the
implementation is a command queue which tracks all user interactions.
This implementation design follows the Command Pattern
[
In the current prototype we do not have a mechanism in
place to dynamically fetch further RDF data by deferencing
URIs. This could be archived by using an approach similar
to the Semantic Web Client Library [
Through the following chapters, we will use the following example set of interactions:
lter a list of lm by director Steven Spielberg pivot on facet 'Actors' pivot on facet 'Films'
lter on director Martin Scorsese A prototype of our user interface and an example dataset is available at http://humboldt-project.org.
In this section we describe a preliminary evaluation our user interface approach. We used the previously mentioned lmrelated dataset extracted from DBpedia for an evaluation of our interface prototype. A small group of semantic web researchers were given the task to explore the dataset by setting di erent lters and pivoting between facets. They could lter lms by particular directors or actor, pivot on a list of actors to lter them by birthplace or by other lms they stared in, etc.
We will discuss the issues our evaluation group had with our prototype. We elected not to use a formal quantitative evaluation process, as our interface design is in an early stage of development and we were interesting in getting qualitative feedback from users while using the interface instead of quantitatively measuring results.
While using Humboldt, users easily understood the faceted ltering operation. They were able to predict and understand the result of selecting resources in facets and appreciated the newly introduced level of abstraction of type-based facets. However, they missed the feature of narrowing a type based facet to certain predicated describing the relationship between e.g. a list of lms and a list of directors. This feature (see section 4.2) was not implemented in the prototype shown during our user study.
As described in section 4.2, we introduced a higher level of abstraction using facets that are based on the type of resources that are directly related to current resources in the result list.
When using the pivoting operation for the rst time, our users expressed some confusion. The pivoting operation causes every control on the screen to update. The result list is populated with new items and new facets appear. Even if the user was familiar with the concept of pivoting, they still showed that reaction. We showed a di erent prototype to each user, in which we used an animation in order to make the pivoting operation easier to understand. In this animation, when clicking on 'pivot' the items in the resultlist and all facets except the pivoted one slowly disappear, the pivoted facet then ' ies' into the result list and nally the new facets appear. The users appreciated this animation and noted that it makes the pivot operation itself much easier to understand.
We tried to test users' understanding of multiple pivoting operations by asking them to express their expectations. We tested that by using the following sequence of actions:
Every user was able to articulate a correct description of what every single operation would cause. They correctly described operation 3 as such, that it will show a list of all lms in which one or more of the currently shown actors has starred in. However, some users showed surprise when actually executing operation 3 and viewing the result. Some users remembered that operation 1 ltered the list of lms to Steven Spielberg related ones, and were thereby surprised to see more values in the director facet. Other users had forgotten about operation 1, but showed the same surprise when they were reminded by us about that ltering operation. Even with an understanding of the interface operation and the structure of the dataset, only a few users were able to correctly predict the outcome of the described sequence of operations.
We remind readers that the dataset contains a n:n relation between lms and actors, and therefore the result set of the sequence of all three operations is a superset of the result set of operation 1 (above).
Our users quickly understood that each pivoting operation adds a eld to the history control shown in the top right corner of the screen. We asked them to note that the current representation of the history as a one-dimension sequence is just a test and that this layout can not represent all pivot operation. Although we could have chosen to represent the history as a graph in order to give it the more expressivity, we decided to just test how users would react to the possibility of navigating previous pivoting steps.
The users' understanding upfront was mixed. It was not clear to them whether using the history would take them to the same resultset as it was at that time, or whether the later added ltering operation would be incorporated. It was unclear if the history preserves the state or navigates one large query.
In this section we discuss our interface design and the results of our user feedback. We were satis ed overall with the introduction of our pivoting operation. This approach has shown a way to enable users to more easily explore an interlinked RDF dataset at a more aggregated level compared to single-resource at-a-time browsing. Using animations helped to understand the pivoting operation and we will incorporate these animations into our main prototype.
The history and its navigation functionality complemented
the pivoting operation successfully. However we came to the
conclusion that the way the history is currently presented is
not optimal. Our initial concern was that having a linear
history could be a major disadvantage and changing its
layout to a graph based design could serve the users needs much
better. We are now considering that having a separate
history control in the user interface might not work at all.
Our users did not only demand a history functionality which
represents the pivoting path, but also presents previously
performed ltering operations. In combination with our
concern about the linear layout of the history, we conclude that
the history's function needs to be better incorporated into
the overall interface design instead of being a separate and
for the user somehow disconnected user control.
Our current interface design is layout as a xed workspace
(result list facets), where data is put into (supported by
our animations). For the next experiments we will try a
design of a moving workspace on top of a two-dimensional
dataset layout. While previous discussions such as Schraefel
and Karger [
We now discuss how well our user interaction approach serves the in section 1 described needs of users performing exploratory tasks on interlinked RDF data. As outlined in section 1, exploratory tasks are performed with greater user satisfaction if the following characteristics are present: the interface design is consistent with the user's behaviour and expectations the user does not need to memorize details of his exploration, because the application supports him by tracking his interactions the risk of following di erent paths is low Our user study showed that with minor tweaks, the overall behaviour of our interface is predictable for the user. We argue that some of the issues described in the previous section, e.g. the issue with n:n relations of lms and people, might be omitted with some user training. These issues arose out of the richness of our underlying dataset, which will be common in many RDF datasets and users might get a better understanding over time.
By implicitly tracking the users interaction and providing a mechanism to review previous navigation steps, we also satisfy the second need. Even if users were able to memorize all their previous steps, they appreciate if they are not expected to do so. We argue that with larger datasets users were not even able to memorize their actions, and our history mechanism is thereby helpful as well as necessary. Most importantly, we successfully lowered the user's perceived risk of bad decisions by disconnecting the building of a query path and ne-tuning the ltering operations. We want to highlight this argument with an example. Given the previously used sequence of interaction
lter a list of lms by one particular director (Steven Spielberg) pivot to all actors of these lms pivot to their lms We additionally assume that the user might have set additional lters on actors and on their lms.
If the user now discovers that his rst decision of ltering only on Steven Spielberg lms was incorrect, he could easily go back and change that lter (maybe by adding another director) while retaining all other operations.
Hence, he can use a strategy of exploring a dataset and building up a query graph by navigating the dataset rst and afterwards ne-tune the result set by adding, changing or removing lters. Enabling this interaction strategy in the user interface for graph-based data is the key contribution of this paper.
We conclude that this strategy is especially helpful and useful for exploratory tasks and thereby our interface design successfully addressed our outlined hypothesis.
In this paper, we presented a new approach for browsing Linked Data that combines the bene ts of being able to explore throughout a dataset o ered by single resource browsers such as Tabulator with the ability to manage groups of resources o ered by faceted browsers such as Exhibit or Longwell. We have reviewed current most common user interface designs for RDF data and identi ed their key principles and bene ts in order to developed a user interaction design based on these principles which is tailored to data exploration strategies.
In the future we would like to try optimizing the workspace layout in order integrate the history functionality in a more consistent way. We want to evaluate that layout in a more quantitatively measured usability study. We will also add the previously described facet splitting functionality and integrate the Semantic Web Client Library for dereferencing URIs at runtime.