Information stored in the Semantic Web is becoming more and more interesting for average Web users. Due to the complexity of existing tools, however, accessing it is difficult. In this paper we therefore introduce tFacet, a tool that uses well-known interaction concepts to enable hierarchical faceted exploration of semantic data for non-experts. The aim is to facilitate the formulation of semantically unambiguous queries to allow a faster and more precise access to information in the Semantic Web for the broader public.
The amount of information available as semantic data is growing rapidly. As of June
2011, the Linking Open Data (LOD) cloud [
A disadvantage of using SPARQL is, however, that users have to learn the
language first in order to access information through SPARQL queries; making it
rather a language for experts. In order to meet the needs of all users, a simpler user
interface is required to create semantically unambiguous and complex queries without
the need to learn the complex syntax of a query language. One approach to solve this
problem is based on the concept of faceted exploration [
Several applications exist that implement the concept of faceted exploration in
order to allow users to access semantic data. Examples are mSpace [
For that reason we introduce tFacet, a tool that uses well-known interaction concepts in order to make the power of faceted exploration available also for inexperienced users.
tFacet, like the other tools, uses the concept of faceted exploration to access semantic
data. However, it thereby applies interaction concepts that are well-known from other
applications and thus allows the widespread use of already existing knowledge in the
formulation of semantically unique queries. It is implemented using the Adobe Flex
Framework [
Each exploration within tFacet starts with an initial limitation of the search space. This step is necessary to reduce the number of possible results as well as the number of facets to a displayable amount. The user selects a base result class from a tree representation of all classes contained in the dataset. The better the user knows what he is looking for, the more precisely he can restrict the search space. For example in the DBpedia Ontology he could select “Eurovision song contest entry” as a very specific base class limiting the search space to 1054 objects. On the other hand, if he is not able to specify his search goal in detail in advance, he could choose a more abstract base class such as “film”; containing 53619 objects (see Figure 1). By pre-selecting a base class, the exploration is limited to objects of that class. Thus in Figure 2 only objects of the class “film” are displayed in the result set (A). On the left side a directory tree representation of facets is shown. It displays all facets that can be used to filter objects in the result set. At first, only the top hierarchy of the tree is visible, containing all facets related to direct attributes of the result set. In case of films, for instance, it contains facets such as directors or actors of the corresponding movies. In addition, some elements of the tree can be expanded in order to show lower hierarchy levels with additional facets. Those facets refer to indirect attributes of the result set. For movies these could be, for example, the birthplace of the director of the movie.
The user now can select individual facets from the tree to show the facet’s detail view in the right area (Figure 2, C). Facets in the detail view are arranged vertically and always contain all remaining search options as selectable attributes to explore or filter the result set. By selecting individual attribute values, the result set is reduced to objects having that value. For instance, by selecting a director, the result set is filtered to show only movies from that director. Attributes in different facets are combined using the AND-operator while attributes within one facet are combined using the ORoperator. In this manner, the result set can be refined iteratively until the information wanted has been found.
In addition to the result set, a filter operation also updates all other facets that are shown in the detail view. All attributes that would lead to an empty result set when selected are hidden. Furthermore, the expected number of results when selecting a certain attribute is shown in brackets besides this attribute. This feature helps to avoid dead-ends and allows a user to estimate the outcome of a specific filter operation.
All facets available in the directory tree can be extracted automatically from semantic data by using SPARQL queries. All properties of the selected base class are collected and displayed in the tree. If a property leads to a literal this is represented by a document symbol in the tree and cannot be further explored (see “release date” in Figure 2, B). If a property leads to objects of another ontological class it is represented by a directory symbol and can be further explored (see “director: Person” in Figure 2, B). The name of such a sub-directory is composed of two components: (1) the type of the property (here “director”) and (2) the class of the objects (here “Person”). Representing object properties as sub-trees allows also deeply nested information to be used for faceted exploration. In this way, the birthplaces of the directors of the movies in the result set can be used as hierarchical facet to show, for example, only movies that were directed by directors born in Stuttgart (Figure 2, C).
Until now we have used the linked structure of the Semantic Web only for faceted exploration. It is also possible to use this structure to enhance the presentation of the result set by additional details. To demonstrate this, tFacet implements a functionality that allows users to add additional columns to both the result set as well as the facets and also to use those columns for sorting.
In order to add an additional column, the user can click the button "Visible Properties" to see all properties and choose the ones that should be visible in the list (Fig. 2, D). For example, in this way it is possible to use information about the actors of a movie ("Starring") both to filter and sort the result set. Furthermore, having the properties available as additional columns allows the relations between information to be directly visible for the user (e.g. the relations between movies and actors) in contrast to the separated representation via facets.
But often there is more than one value for a property (e.g. usually more than one actor plays in a movie). In that case, the current implementation of tFacet uses a simple list to display multiple values. This can cause problems however, if many values exist for a property, for example, if a movie has many actors. To avoid this problem an abbreviated list could be shown initially or just the number of entries, with the possibility to expand the view if necessary. With numerical data it would also be possible to show an aggregated view.
In general, the idea of additional columns is not only limited to direct properties, but can be implemented also for indirectly related properties. For that, one could imagine displaying a directory tree like in Fig. 2 D to select information only connected indirectly. However, one problem with such an implementation would be how to maintain the clarity of the presentation as many trees and their hierarchical directory structures could confuse the user more than help him create search requests. 2.4
tFacet uses several interaction concepts that are known from common applications in order to ease the use of faceted exploration. The most important ones are: Directory tree: In many applications, directory trees are used for the navigation in and the management of hierarchical data. A logical conclusion was therefore the representation of hierarchical facets in a directory tree within tFacet. Like in popular file managers, nodes shown as folder symbol can be explored further while nodes shown as file symbol represent a leaf node.
interface into an overview (directory tree), a detailed view (right pane) and a result view is frequently used. The possibility to show multiple detail views (in this case facets) at the same time is not widespread, for the definition of filters in more than one facet, however, necessary.
Organization into columns: In many grid-based applications (for example, in Windows or Mac OS applications) the user can determine individually, which columns are of interest for him and have these displayed. In a similar way in tFacet he can display a menu of all properties he might be interested in and add or remove individual columns. The same is true for sorting by individual columns by clicking on the column header.
In this paper, we proposed tFacet, a new application to enable all users to create semantically unambiguous search requests using the concept of faceted exploration. The aim was to enable the full potential of this concept by keeping its usage as simple as possible through the use of well-known interaction concepts. Through the use of a directory tree even remote information can be included in the query as hierarchical facets and the possibility to show connected properties in additional columns facilitates control over the level of detail of the information displayed.
Thus, tFacet offers interesting approaches to make the potential of semantic data accessible for everyone. A key part of this is the strategy to transfer already known concepts into the specific interaction environment of the Semantic Web.
In the future we plan further development of tFacet to make its usage even simpler. For example, data-specific visualizations, such as sliders or maps could be used to ease the creation of queries and improve the presentation of results. An integration of the approaches discussed in Section 2.3 to extend the columns functionality to use hierarchical properties could be useful for a consistent and powerful implementation of this concept. Furthermore, an evaluation of the user interface would be helpful, especially to see if the use of known interaction concepts can help users to reach their goal faster. Including a comparison to similar tasks and tools in order to measure empirically, whether the intended goal of tFacet, a simplified usage, has been achieved.