=Paper=
{{Paper
|id=Vol-369/paper-16
|storemode=property
|title=Humboldt: Exploring Linked Data
|pdfUrl=https://ceur-ws.org/Vol-369/paper15.pdf
|volume=Vol-369
|dblpUrl=https://dblp.org/rec/conf/www/KobilarovD08
}}
==Humboldt: Exploring Linked Data==
https://ceur-ws.org/Vol-369/paper15.pdf
Humboldt: Exploring Linked Data
Georgi Kobilarov Ian Dickinson
Hewlett-Packard Labs Hewlett-Packard Labs
Bristol, UK Bristol, UK
georgi.kobilarov@gmx.de ian.dickinson@hp.com
ABSTRACT Current research in the semantic web user interface area, es-
We present Humboldt, a novel user interface for browsing pecially in semantic web powered search engines, has tended
RDF data. Current user interfaces for browsing RDF data to focus on information retrieval tasks. We characterize
are reviewed. We argue that browsing tasks require both these tasks as those in which a user has a very specific ques-
a facet browser’s ability to select and process groups of re- tion or query in mind which he tries to answer or solve. Com-
sources at a time and a ’resource at a time’ browser’s ability panies like Powerset [4] focus on providing mechanisms to
to navigate anywhere in a dataset. We describe Humboldt answer tasks such as e.g. ’what is the population of Berlin?’,
which combines these two features in a single coherent in- ’which books are written by author X?’, etc. using semantic
terface. Our approach is based on the operation of pivoting, technologies.
which enables the user to move the focus of a browsing from
one set of resources to a set of related resources. With re-
peated use of the pivot operation the user can browse any- In this paper, we focus on exploratory tasks and character-
where in the data. We describe a preliminary evaluation of ize them as follows: in exploratory tasks, a user has a more
our approach and discuss its implications for further devel- vague idea of the question he wants to answer. His interests
opment. depend upon the changing characteristics of the information
context [7] [8].
Categories and Subject Descriptors We give two business related examples for this kind of tasks:
H5.2 [Information Interfaces and Presentation]: User
Interfaces; H5.4 [Information Interfaces and Presenta-
tion]: Hypertext/Hypermedia • A product manager plans a product update. He wants
to get an overview of the new features of competi-
General Terms tors’ products. User reports of his product have been
Design, Human Factors tracked by his companies support department. His de-
velopment team came up with new ideas for innova-
Keywords tive product features. The production department has
published technical data on new methods of cost re-
user interface, semantic web, faceted browsing, rdf, linked
duction factoring. The product manager needs to de-
data
cide which changes will be made with the next product
release.
1. INTRODUCTION
As more and more large Linked Data sources such as DBpe- • A financial analyst notices an irregularity in a dataset.
dia [5] have become available over the last year, the need for He seeks for an explanation. The company works in a
improved user interaction approaches for dealing with these broad market and it might be a competitor’s news as
highly interlinked RDF [21] datasets has become more ob- well as a companies news. The company is active in
vious. The quantity of data has reached a level where users foreign markets and depends on certain suppliers. Po-
are overwhelmed and feel lost in a similar way as in earlier litical news as well as changes in the suppliers market
days of the web. That phenomenon was described as ’Lost might also have influenced the financial data.
in Hyperspace’ [14].
Both examples highlight the difficulty of having a computer
system ’solve’ these problems by providing a single answer.
These tasks require gathering together structured and un-
structured data sources. In this paper, we focus on ex-
ploratory tasks using only structured data.
In the current document-centric web, a key mechanism of
web browsers to support information exploration is the brows-
ing history. Users can follow different links to other docu-
ments and, depending on the document’s relevance, decide than interfaces tailored to a specific domain. While there
to further explore or go back and follow a different path. are certain visual representations for particular data types,
The possibility of returning to a previous decision and fol- e.g. calendars and timelines for time-related data and maps
lowing a different path makes decisions less risky. for geographical data, there are no such representations for
Browsing histories and bookmarking functionality help users most other types of complex resources, e.g. people, films,
to store discovered information in the system instead of hav- companies etc. Hence we treat those specific representations
ing to memorize it for later reuse. as additional features to a more generic user interaction ap-
proach and do not include them in our analysis.
The Semantic Web with its access to more structured infor-
mation makes data aggregation techniques more important With growing availability of Linked Data [9] on the Web,
in exploratory tasks. Structured data can more easily be we argue that there is a need for generic approaches which
aggregated, supporting better overview of large amounts of do not restrict users to specific tasks or to specific data that
data. could be used, as both might not be known a priori.
In information retrieval tasks on web documents, a goal is
to find a specific document or - in terms of graph-theory - 2.1 Browsing
finding a particular node in the graph of linked documents.
There are various different semantic web browsers for Linked
While the path to that node or the edges connecting it are
Data available, which use a similar interface design to Tim
important for localizing the node, the node’s meaning is
Berners-Lee’s Tabulator [10]. A browser interface is typi-
mostly independent of which path was used to retrieve it.
cally designed to display one RDF resource at a time, and
enables the user to browse from resource to resource. Tab-
ulator’s original design uses a tree to show the relationship
That is different in Semantic Web tasks. The path used to
between resources. Other Linked Data browsers including
locate a node or the relationship between nodes is more im-
Disco [11] or the Zitgist DataViewer [15] use a design of
portant. The meaning of just retrieving the node of a person
one resource per page. The tree-view as well as the one-
named ’Ian’ is different than retrieving it as a link from a
resource-per-page design enables the user to browse detailed
person named ’Georgi’ by following a foaf:knows link. The
descriptions of single RDF resources, while the tree-view ad-
later represents ’Ian as a friend of Georgi’. With this exam-
ditionally preserves the browsing path.
ple we want to highlight how and why exploratory tasks are
different and why the user’s exploration process and path is
more meaningful that in the web of documents.
This design reflects 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
A user will want a semantic web interface to follow a sim-
one page to another. This browsing approach has been ap-
ilar flexible approach as browsing backwards and forwards
plied to semantic web linked data, where the smallest piece
in exploratory tasks. An interface supporting that approach
of information is a RDF resource. We argue that this kind
would support user behaviour and exploration strategies, in
of interaction does not facilitate the key benefits of Seman-
which the user has a perceived low risk of making early de-
tic Web data. Much of the currently available Linked Data
cisions because he can go back and modify them later.
is either scraped from web pages, such as DBpedia, or also
available as human readable webpage as well like Geonames
[1] or Musicbrainz [3]. We do not see much benefit to users
We outline a simple example for casual end-users: a user
from viewing RDF data rendered by a Linked Data browser
might want to explore a dataset of films in order to find an
when a HTML representation of the same information is
interesting one for a movie night. He does not know upfront
available, which is specifically tailored to fit the need of
which films are available and has no specific preference of
human readers. Linked data browser will need to provide
the genre. Over the past, he has seen many movies and do
higher benefit by giving more control to the user than web
have some preferences for particular directors and actors,
pages could do.
but is willing to explore new ones.
However, this might change as more and more RDF data
The essence of this task is viewing the actual available data,
becomes available from databases, where no corresponding
which will influence his exploration strategy and might change
web pages are available. Semantic Web technologies could
his interests as described above.
serve as methods to create web documents, but the key in
browsing and analysing this data lies in our opinion in aggre-
gation of data, like the currently available Web2.0 mashups.
2. OVERVIEW OF EXISTING
APPROACHES
In this section, we review three different kinds of seman- Single resource at a time RDF browsers enable users to ex-
tic web user interfaces according to their ability to support plore large RDF datasets, but their design does not support
users in information exploration tasks. We identify the key the user in aggregation tasks. The browser design might
principles of each approach, and will then further discuss enable aggregation tasks when a kind of basket is available
how the advantages can be combined into one user interface to temporally store discovered resources, such as Piggybank
design. We are interested in generic user interfaces rather [18]. Piggybank focuses on collecting resources, while we
try to find ways of exploring these collections. Also, in their 2.3 Query Builder
current design, single resource at a time browsers give no Graph based query builders try to give the user the most ex-
suggestions of which links to follow because of their lack of pressivity in querying an RDF graph. An common approach
support in creating an overview for the user. 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 [6]. It supports the
For example, given a user’s FOAF [13] profile, browsers do user in building up triple pattern by using auto-completion
not give hints for the user which links to friends might be for triple predicates. For example if the users starts with
interesting, when users naturally want to deal with collec- the triple pattern ?film rdf:type film , auto-completion
tions of resources. A user strategy (see section 1) for ex- for next triple pattern will only show predicates which are
ploring such a list of friends with a Linked Data browser is used with actual instances in the repository of type film,
to browse to each friend, memorize details that might be of ordered by their usage number. This supports the user in
interest and repeat that procedure for other friends. This exploration tasks as he sees which relationships exist be-
strategy is very time consuming and impractical for larger tween instances. But a user has to have an explicit question
lists of friends. Here, faceted browsing or faceted filtering of in mind which he wants to formulate into a query. While
the friendlist might serve as a helpful overview method. the interface helps to analyse the relationships, it does not
show actual data while constructing a query. In addition,
users do not always have explicit queries upfront, but need
2.2 Faceted Filtering to explore the available data first in order to find out what
The method of faceted filtering [26] or clustering helps the information might be interesting to them.
user to get an overview of a given set of resources. The basic
concept of facets is to partition the information space using
orthogonal conceptual dimensions of the data. A widely Using actually available data for query construction is a con-
used customer application with a faceted filtering approach cept known in database environments as Query by Example
is iTunes, Apple’s music library and media player [20]. (QbE) [27]. Users can create queries by entering example
iTunes’ music library can be filtered according to different data and conditions, and the system then translates these
dimensions of the music files’ metadata. Users can filter the examples into a more formal query according to the actual
library on certain artists, albums or genres by selecting val- data schema. The Microsoft Access query builder uses an
ues from facets. interface which refers to the QbE concept in order to enable
casual users to construct database queries.
Exhibit [19] is a popular interface which provides a faceted 3. OVERVIEW OF OUR APPROACH
filtering view on graph based data. Exhibit’s user interface We present an interface design in which we combined the
presents different facets for a given set of resources. The key three previously discussed interaction approaches: Brows-
user interaction is faceted filtering, i.e. a list of resources can ing, Faceted Filtering and Query Building. We integrated
be filtered by selecting values within facets. E.g. films might the following three characteristics in our exploratory inter-
be filtered by selecting ’Steven Spielberg’ in a ’Director’ facet face: multi-resource at a time, browsing and implicit query
of a list of films. This action will filter down the list of films building. We argue that the multi-resource interface design
to those, whose director is Steven Spielberg. Exhibit uses a is most helpful for exploration tasks as it supports overview
declarative language to create a faceted view on a list of re- techniques and data aggregation as shown in faceted browsers.
sources. Other faceted browser like Longwell [2] or MSpace Therefore we also integrate a faceted filtering mechanism
[23] calculate facets automatically. similar to Exhibit. Our interface approach does not relate
specificly to RDF. It is applicable to any graph-based data
structure. For our experiments and demonstration we use
Faceted Filtering supports exploration tasks as it enables a highly interlinked dataset extracted from DBpedia (see
the user to quickly get an overview of what data is present. figure 1). This dataset contains data related to the movie
Compared to the previously described design of one resource domain and consists of films, directors, actors, cities, and
at a time, faceted browsers use a multi resource at a time companies. We modified the dataset in order to provide a
design. Even larger sets of resources can easily be clustered rich linking structure with n:n relations between instances,
or filtered by certain dimensions in order to quickly see what as well as circular relationships. Films have many actors,
data is available. For example, a large list of people might actors play in different films of different directors. Directors
be clustered by their birthplace or by the organization they get awards for films and work for companies which produce
work for. The user can then filter the set of people down to films.
a smaller set according to these facets.
4. INTERFACE DESIGN
We now describe the main elements of our interface (see
Current implementations work with a fixed list of resources
figure 2). The interface is presented as a fixed workspace of
on which faceted filtering is performed. With growing data-
three different elements: result list, facet list and history.
sets, the number of potential facet values also grows. A set
of thousands of films might have a facet with hundreds of
different actors. Hierarchical facets are one solution to fur- 4.1 Result List
ther cluster facet values. The core of our interface is the result list. The result list
presents a collection of RDF resources as unstructured list
prefix :
prefix p:
: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 .
Figure 1: dataset sample
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. Figure 2: Humboldt 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 A list of films could be related to a facet of people. Users
to filter the resources by their rdf:type. This can be used want to be able to restrict these relations to certain prop-
to render the output of other applications, e.g. semantic erties, e.g. to people who directed or produced a film and
search interfaces. These applications can provide the URI exclude people who acted in a film. This operation could be
of a RDF document which contains a list of resources to be understood as a drill down into the result-facet relationship.
displayed and browsed with Humboldt.
As in Exhibit, we designed facets for filtering the result list.
The user can select a value in a facet to filter down the result
4.2 Facets list to all resources that are related to the selected resource.
The main point of interaction in our interface design is a
This will cause all other faceted to be recomputed based on
list of facets, presented on the right hand side of the re-
the now filtered list of results.
sult list. Facets are computed from all resources that are
related to resources in the result list and grouped by their
rdf:type. This method differs from other faceted browsers,
For example, having a list of films loaded into the result list,
where facets are usually constructed from a predicate that
the user can select Steven Spielberg from the Director facet.
connects two resources. By using rdf:type instead we want
This will filter the list of films to those, which are related
to test the hypothesis that introducing an additional level of
to Steven Spielberg by any predicate. The user could later
abstraction reduces the number of facets. This new level of
drill down into the Director facet to select only directed by
abstraction should help the user to get an overview over the
and awarded for as relations between these films and Steven
available data more quickly. During this exploration phase,
Spielberg.
the user does not need to see all details of existing relations.
4.3 Pivot Operation
For example, a list of people (results) in a movie related In order to combine a faceted layout with browsing capabil-
dataset can be connected to a list films (facets) with many ity, we use the Pivot operation, which is similar to Siderean
different predicates like directed, stars in, has produced, Seamark [24]. Based on the operations in data drilling [16],
has written, has edited, and was awarded for. If the our approach allows multiple representations of data accord-
dataset also contains cities that are related to the people, ing to different dimensions. In our faceted interface design,
facets like born in, lives in, died in, etc would appear. a facet or dimension of the dataset is treated as a first class
By grouping by type, the only facets are film and city. The object. Pivoting on a facet means to handle the values of
user can get an overview of the available data and later drill this facet as results and rebuild a faceted view around these
down by splitting one facet into several ones based on par- results (see figure 3). In this way, we added a browsing func-
ticular predicates or sub-classes. He thereby restricts the tionality by which the whole dataset can be explored. This
relationships between results and values in a certain facet. interaction has been called refocusing in a nested faceted
browsing prototype by David Huynh [17].
source, a per user-session in-memory triple store.
A controller provides methods to compute all result list
items and all facets on a given command queue and data
source at any given time. The command queue thereby rep-
resents the implicit construction of a query via different piv-
oting steps without having to store intermediate result sets.
On every event causing a page refresh, the result list is com-
puted by parsing the whole command queue and executing
SPARQL queries on the data source, which is populated via
HTTP GETs on RDF documents.
Figure 3: Pivoting example
In the current prototype we do not have a mechanism in
Furthermore, we apply selected filters to the whole dataset place to dynamically fetch further RDF data by deferencing
and all pivoting steps. When a resource list is filtered by cer- URIs. This could be archived by using an approach similar
tain facet values and the user then pivots on another facet, to the Semantic Web Client Library [12]. Such a mechanism
the interface uses the result of the filtering for building the will be included in a future version of the prototype. The
next view. This enables the user to build up a query while primary objective of the current phase of work was to eval-
browsing actual data and instantly seeing the result of each uate the effectiveness of the user interaction model.
incremental step of building up his query. Thereby, we sup-
port the implicit construction of queries.
In our prototype there are four different commands which
can be enqueued: SelectCommand, FilterCommand, Piv-
E.g. a user who filters films on certain directors and then otCommand, and StepCommand. The SelectCommand in-
pivots on actors will see all actors in the result list, who are cludes or excludes resources from the resultlist or filters the
related to any film in the previous result list. resultlist by type. The FilterCommand restricts results by
values in a certain facet. The PivotCommand tracks the
4.4 History user’s pivot operations and the StepCommand tracks steps
In order to support the user in building an implicit query in the history.
over a number of connected list (of facets), we suggest track-
ing the user’s path through the graph. We use a separate
History control, which displays the path the user has taken Through the following chapters, we will use the following
via pivoting facets from the starting point to the current example set of interactions:
page. We chose to display the path as a linear sequence
in the history control, which enables to step back to pre-
• filter a list of film by director Steven Spielberg
viously visited pages. While this represents the implicitly
built query, filters that are applied on a graph node affect • pivot on facet ’Actors’
other nodes as well.
• pivot on facet ’Films’
When a user pivots from films to actors, filters these ac- • filter on director Martin Scorsese
tors by their birthplace, and then steps back to films, the
filtered actors themselves affects the list of films presented.
A prototype of our user interface and an example dataset is
This enables drilling-down into facets. As described previ-
available at http://humboldt-project.org.
ously, facets are partitions of data according to different di-
mensions (see section 2.2). Actors are one dimension of film
data, but actors themselves have different other dimension,
e.g. their places of birth. Starting with film, users can drill
into their actors and their places of birth, and afterwards
zoom out to films again using the history control.
5. IMPLEMENTATION
We have implemented a prototype of our interface as server-
side web application in C#. The core of the implementa-
tion is a command queue which tracks all user interactions.
This implementation design follows the Command Pattern
[25]. This programming pattern is often used to implement
undo/redo functionality in graphical user interfaces. We
used this data structure to track user interactions in order
to represent the history internally in a flexible and extend-
able way. Each command queue is associated with one data Figure 4: Humboldt’s architecture
6. USER FEEDBACK Every user was able to articulate a correct description of
In this section we describe a preliminary evaluation our user what every single operation would cause. They correctly
interface approach. We used the previously mentioned film- described operation 3 as such, that it will show a list of all
related dataset extracted from DBpedia for an evaluation films in which one or more of the currently shown actors
of our interface prototype. A small group of semantic web has starred in. However, some users showed surprise when
researchers were given the task to explore the dataset by actually executing operation 3 and viewing the result. Some
setting different filters and pivoting between facets. They users remembered that operation 1 filtered the list of films
could filter films by particular directors or actor, pivot on a to Steven Spielberg related ones, and were thereby surprised
list of actors to filter them by birthplace or by other films to see more values in the director facet. Other users had
they stared in, etc. forgotten about operation 1, but showed the same surprise
when they were reminded by us about that filtering opera-
tion. Even with an understanding of the interface operation
We will discuss the issues our evaluation group had with our and the structure of the dataset, only a few users were able
prototype. We elected not to use a formal quantitative eval- to correctly predict the outcome of the described sequence
uation process, as our interface design is in an early stage of operations.
of development and we were interesting in getting qualita-
tive feedback from users while using the interface instead of
quantitatively measuring results. We remind readers that the dataset contains a n:n relation
between films and actors, and therefore the result set of the
sequence of all three operations is a superset of the result
6.1 Filtering set of operation 1 (above).
While using Humboldt, users easily understood the faceted
filtering operation. They were able to predict and under-
stand the result of selecting resources in facets and appreci- 6.3 History
ated the newly introduced level of abstraction of type-based Our users quickly understood that each pivoting operation
facets. However, they missed the feature of narrowing a type adds a field to the history control shown in the top right cor-
based facet to certain predicated describing the relationship ner of the screen. We asked them to note that the current
between e.g. a list of films and a list of directors. This fea- representation of the history as a one-dimension sequence is
ture (see section 4.2) was not implemented in the prototype just a test and that this layout can not represent all pivot
shown during our user study. 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 possi-
As described in section 4.2, we introduced a higher level bility of navigating previous pivoting steps.
of abstraction using facets that are based on the type of
resources that are directly related to current resources in
the result list. 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
6.2 Pivot later added filtering operation would be incorporated. It
When using the pivoting operation for the first time, our was unclear if the history preserves the state or navigates
users expressed some confusion. The pivoting operation one large query.
causes every control on the screen to update. The result list
is populated with new items and new facets appear. Even if 6.4 Review of user feedback
the user was familiar with the concept of pivoting, they still
In this section we discuss our interface design and the results
showed that reaction. We showed a different prototype to
of our user feedback. We were satisfied overall with the in-
each user, in which we used an animation in order to make
troduction of our pivoting operation. This approach has
the pivoting operation easier to understand. In this anima-
shown a way to enable users to more easily explore an inter-
tion, when clicking on ’pivot’ the items in the resultlist and
linked RDF dataset at a more aggregated level compared to
all facets except the pivoted one slowly disappear, the piv-
single-resource at-a-time browsing. Using animations helped
oted facet then ’flies’ into the result list and finally the new
to understand the pivoting operation and we will incorpo-
facets appear. The users appreciated this animation and
rate these animations into our main prototype.
noted that it makes the pivot operation itself much easier to
understand.
The history and its navigation functionality complemented
the pivoting operation successfully. However we came to the
We tried to test users’ understanding of multiple pivoting
conclusion that the way the history is currently presented is
operations by asking them to express their expectations. We
not optimal. Our initial concern was that having a linear
tested that by using the following sequence of actions:
history could be a major disadvantage and changing its lay-
out to a graph based design could serve the users needs much
1. filter films by director Steven Spielberg better. We are now considering that having a separate his-
tory control in the user interface might not work at all.
2. pivot on actors
3. pivot on films Our users did not only demand a history functionality which
represents the pivoting path, but also presents previously We additionally assume that the user might have set addi-
performed filtering operations. In combination with our con- tional filters on actors and on their films.
cern about the linear layout of the history, we conclude that If the user now discovers that his first decision of filtering
the history’s function needs to be better incorporated into only on Steven Spielberg films was incorrect, he could easily
the overall interface design instead of being a separate and go back and change that filter (maybe by adding another
for the user somehow disconnected user control. 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 first
Our current interface design is layout as a fixed workspace and afterwards fine-tune the result set by adding, changing
(result list facets), where data is put into (supported by or removing filters. Enabling this interaction strategy in the
our animations). For the next experiments we will try a user interface for graph-based data is the key contribution
design of a moving workspace on top of a two-dimensional of this paper.
dataset layout. While previous discussions such as Schraefel
and Karger [22] have highlighted issues of graph visualisa-
tion tools, we argue that using a faceted graph visualisation We conclude that this strategy is especially helpful and use-
layout instead of an instance based layout could produce ful for exploratory tasks and thereby our interface design
better results. successfully addressed our outlined hypothesis.
7. EVALUATION 8. CONCLUSION
We now discuss how well our user interaction approach serves In this paper, we presented a new approach for browsing
the in section 1 described needs of users performing ex- Linked Data that combines the benefits of being able to ex-
ploratory tasks on interlinked RDF data. As outlined in plore throughout a dataset offered by single resource browsers
section 1, exploratory tasks are performed with greater user such as Tabulator with the ability to manage groups of re-
satisfaction if the following characteristics are present: sources offered by faceted browsers such as Exhibit or Long-
well. We have reviewed current most common user inter-
• the interface design is consistent with the user’s be- face designs for RDF data and identified their key principles
haviour and expectations and benefits in order to developed a user interaction design
based on these principles which is tailored to data explo-
• the user does not need to memorize details of his explo- ration strategies.
ration, because the application supports him by track-
ing his interactions
9. FUTURE WORK
• the risk of following different paths is low 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
Our user study showed that with minor tweaks, the overall
quantitatively measured usability study. We will also add
behaviour of our interface is predictable for the user. We ar-
the previously described facet splitting functionality and in-
gue that some of the issues described in the previous section,
tegrate the Semantic Web Client Library for dereferencing
e.g. the issue with n:n relations of films and people, might
URIs at runtime.
be omitted with some user training. These issues arose out
of the richness of our underlying dataset, which will be com-
mon in many RDF datasets and users might get a better 10. REFERENCES
understanding over time. [1] Geonames. http://www.geonames.org/.
[2] Longwell. http://simile.mit.edu/wiki/Longwell.
[3] Musicbrainz. http://musicbrainz.org/.
By implicitly tracking the users interaction and providing [4] Powerset. http://www.powerset.com.
a mechanism to review previous navigation steps, we also
[5] S. Auer, C. Bizer, G. Kobilarov, J. Lehmann,
satisfy the second need. Even if users were able to memo-
R. Cyganiak, and Z. Ives. Dbpedia: A nucleus for a
rize all their previous steps, they appreciate if they are not
web of open data.
expected to do so. We argue that with larger datasets users
[6] S. Auer and J. Lehmann. What have innsbruck and
were not even able to memorize their actions, and our his-
leipzig in common? extracting semantics from wiki
tory mechanism is thereby helpful as well as necessary.
content. In ESWC, pages 503–517, 2007.
Most importantly, we successfully lowered the user’s per-
ceived risk of bad decisions by disconnecting the building of [7] M. Q. W. Baldonado and T. Winograd. Sensemaker:
a query path and fine-tuning the filtering operations. We an information-exploration interface supporting the
want to highlight this argument with an example. Given contextual evolution of a user’s interests. In CHI ’97:
the previously used sequence of interaction Proceedings of the SIGCHI conference on Human
factors in computing systems, pages 11–18, New York,
NY, USA, 1997. ACM.
• filter a list of films by one particular director (Steven [8] M. J. Bates. The design of browsing and berrypicking
Spielberg) techniques for the online search interface. Online
Review, v13 n5 p407, 1989.
• pivot to all actors of these films
[9] T. Berners-Lee. Linked data, 2006.
• pivot to their films http://www.w3.org/DesignIssues/LinkedData.html.
[10] T. Berners-Lee, Y. Chen, L. Chilton, D. Connolly,
R. Dhanaraj, J. Hollenbach, A. Lerer, and D. Sheets.
Tabulator: Exploring and analyzing linked data on the
semantic web. In Proceedings of the 3rd International
Semantic Web User Interaction Workshop, 2006.,
2006.
[11] C. Bizer and T. Gauss. Disco - hyperdata browser,
2007.
http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/.
[12] C. Bizer, T. Gauss, and R. Cyganiak. Semantic web
client library. http://www4.wiwiss.fu-
berlin.de/bizer/ng4j/semwebclient/.
[13] D. Brickley and L. Miller. Foaf: the Šfriend of a
friendŠ vocabulary, 2004. http://xmlns.com/foaf/0.1/.
[14] D. M. Edwards and L. Hardman. Lost in hyperspace:
cognitive mapping and navigation in a hypertext
environment. In Hypertext: theory into practice, pages
90–105, Exeter, UK, UK, 1999. Intellect Books.
[15] F. Giasson. Zitgist dataviewer.
http://dataviewer.zitgist.com/.
[16] J. Gray, A. Bosworth, A. Layman, and H. Pirahesh.
Data cube: A relational aggregation operator
generalizing group-by, cross-tab, and sub-totals. IEEE
12th International Conference on Data Engineering,
pages 152–159, 1996.
[17] D. Huynh. Nested faceted browsing.
http://people.csail.mit.edu/dfhuynh/projects/nfb/.
[18] D. Huynh, S. Mazzocchi, and D. Karger. Piggy bank:
Experience the semantic web inside your web browser.
Web Semant., 5(1):16–27, 2007.
[19] D. F. Huynh, D. R. Karger, and R. C. Miller. Exhibit:
lightweight structured data publishing. In WWW ’07:
Proceedings of the 16th international conference on
World Wide Web, pages 737–746, New York, NY,
USA, 2007. ACM.
[20] A. Inc. itunes. http://www.apple.com/itunes/.
[21] F. Manola and E. Miller. Rdf primer, Februar 2004.
[22] m.c. schraefel and D. Karger. The pathetic fallacy of
rdf. In International Workshop on the Semantic Web
and User Interaction (SWUI) 2006,
[”lib/utils:month_12911” not defined] 2006.
[23] m.c. schraefel, M. Wilson, A. Russell, and D. A.
Smith. mspace: improving information access to
multimedia domains with multimodal exploratory
search. Commun. ACM, 49(4):47–49, 2006.
[24] Siderean. Seamark navigator, 2007.
http://www.siderean.com.
[25] Wikipedia. Command pattern.
http://en.wikipedia.org/wiki/Command Pattern.
[26] K.-P. Yee, K. Swearingen, K. Li, and M. Hearst.
Faceted metadata for image search and browsing. In
CHI ’03: Proceedings of the SIGCHI conference on
Human factors in computing systems, pages 401–408,
New York, NY, USA, 2003. ACM.
[27] M. M. Zloof. Query-by-example: a data base
language. IBM Systems Journal, 1977.