User-centered Design and Evaluation of Overview Components for Semantic Data Exploration

Structure Abstract Purpose. The growing volumes of semantic data available in the Web result in the need for handling the Information Overload phenomenon. The potential of this amount of data is enormous but in most cases it is very difficult for users to visualize, explore and use this data, especially for lay-users without experience with Semantic Web technologies. Design/methodology/approach. The Visual Information-Seeking Mantra " Overview first, zoom and filter, then details-on-demand " proposed by Shneiderman describes how data should be presented in different stages to achieve an effective exploration. The overview is the first user task when dealing with a dataset. The objective is that the user is capable of getting an idea about the overall structure of the dataset. Different Information Architecture (IA) components supporting the overview tasks have been developed, so they are automatically generated from semantic data, and evaluated with end-users. Findings. The chosen IA components are well known to Web users, as they are present in most web pages: navigation bars, site maps and site indexes. We complement them with Treemaps, a visualization technique for displaying hierarchical data. These components have been developed following an iterative User-Centered Design methodology. Evaluations with end-users have shown that they get easily used to them despite the fact that they are generated automatically from structured data, without requiring knowledge about the underlying semantic technologies, and that the different overview components complement each other as they focus on different information search needs. Originality/value. Obtaining semantic datasets overviews cannot be easily done with the current semantic web browsers. Overviews become difficult to achieve with large heterogeneous datasets, which is typical in the Semantic Web, because traditional Information Architecture techniques do not easily scale to large datasets. This can be a serious limitation when exploring a dataset for the first time, especially for lay-users. Our proposal is to reuse and adapt existing Information Architecture (IA) components to provide this overview to users and show that they can be generated automatically from the thesaurus and ontologies that structure semantic data while providing a comparable user experience to traditional web sites.


INTRODUCTION
The growing volumes of semantic data available in the Web result in the need for handling the Information Overload phenomenon (Thomas 2007).The potential of this vast amount of data is enormous but in most cases it is very difficult and cumbersome for users to visualize, explore and use this data, especially for lay-users (Dadzie & Rowe 2011) without experience with Semantic Web technologies.From the end-user perspective, the available datasets are monolithic and opaque files, which usually can just be explored using complex semantic queries or complex user interfaces.Improving the cognition of large datasets remains a standing problem in the Semantic Web.
To interact with large datasets, the literature proposes to divide the task of exploring a dataset into different stages.Shneiderman (Shneiderman 1996) presents the Visual Information-Seeking Mantra: "Overview first, zoom and filter, then details-on-demand".The Mantra describes the fundamental set of tasks for data analysis and how data should be presented to users to achieve an effective exploration.It is presented as a guideline for how to design visual interfaces, where the first stage they present should be to gain an overview of the entire collection.Obtaining an overview is an important first step in the exploration of data.
Greene et al. (Greene et al. 1999) argued that a good overview "provides users with an immediate appreciation for the size and extent of the collection of objects the overview represents, how objects in the collection relate to each other, and importantly, what kind of objects are not in the collection".Overviews provide a general context for understanding the available information and can be used as starting point for navigation.Despite visualizing and interacting with Linked Data is an issue that has been recognized from the beginning of the Semantic Web, cf.e.g.(Geroimenko & Chen 2002), users have not embraced it yet (Shadbolt et al. 2006).This is due in part to the fact that users find it difficult to use, even for advanced users with experience in Semantic Web technologies (Heath et al. 2006).
Semantic Web browsers should provide mechanisms that allow users to navigate the information effectively and easily.As datasets grow bigger and more complex, it becomes essential to have a compact representation of the information space.However, obtaining this overview cannot be easily done with the current semantic web browsers.Most of existing browsers assume the end user will start browsing from a specific URI, but most of end users do not even know what a URI means.They need an exploration starting point.Moreover, these browsers only provide access to single (but detailed) resources sequentially, which is very slow and easily saturates the user's working memory.There is little or no support to obtain overview information quickly and easily at the beginning of the exploration of a new dataset.This can be a serious limitation when exploring a dataset for the first time, especially for lay-users.
Our proposal is to draw from the experience accumulated in the Information Architecture (IA) domain (Morville & Rosenfeld 2006) as well as to reuse and adapt existing IA components to provide this overview to users.Such IA components are well known to Web users, as they are present in most web pages: navigation bars, site maps and site indexes.We complement these components with treemaps (Shneiderman 1992), a visualization technique for displaying hierarchical data.This approach was applied in Rhizomer1 , a tool capable of publishing Semantic Web datasets while facilitating user awareness of the published content.These components have been evaluated with lay-users as part of a User-Centered Design development process (González et al. 2013).Our findings can be used as guidelines for designers of semantic web tools.They can decide which components to use depending on the concrete tasks their users need to solve and the characteristics of their datasets.
The remainder of this paper is organized as follows: Section 2 discusses related work.Section 3 introduces our approach, based on the Information Architecture domain.It also presents the development methodology and defines our target users.Section 4 describes the notion of overview in the context of Semantic Web datasets.Section 5 introduces the overview components implemented.Section 6 presents their evaluation with users performing real tasks and proposals to improve these components.Finally, Section 7 contains conclusions and future work.

RELATED WORK
Related work can be roughly classified into tools supporting Linked Data visualization and exploration as well as approaches for creating overviews of large datasets.

LINKED DATA VISUALIZATION AND EXPLORATION
Exploring and visualizing Linked Data is a problem that has been addressed by several projects.Dadzie et al. (Dadzie & Rowe 2011) analyzed some of those projects concluding that most of them do not provide overviews on the data.Moreover, most of them are designed only for tech-users, which makes even more complicated to understand what the data is about.
Semantic Web browsers such as Disco (Bojars et al. 2007), Tabulator (Berners-Lee et al. 2006) or Explorator (Araújo et al. 2009) allow users to navigate the graph structures and usually display propertyvalue pairs in tables.They provide a view of a subject, or a set of subjects and their properties, but not any additional support getting a broader view of the dataset being explored.
Graph-based tools such as Fenfire (Hastrup et al. 2008), RDF-Gravity2 , IsaViz3 provide node-link visualizations of the datasets and the relationships between them.Although this visual approach can help obtaining a better understanding of the data structure in some cases graph visualization does not scale well to large datasets (Frasincar et al. 2005).Sometimes the result is a complex graph difficult to manage and understand (Karger & Schraefel 2006).
Other tools provide visual overviews by pointing resources on a map with different icons depending on their type, e.g.DBpedia Mobile (Becker & Bizer 2009) or LinkedGeoData browser (Stadler et al. 2011).However, they are restricted to visualizing and browsing concrete domains, in this case spatial data.
To summarize, none of the existing tools provide generic and text-based overviews for RDF data.Moreover, most of them make it difficult for non-technical users to explore linked data or they are restricted to concrete domains.Consequently, it is still difficult for end users to obtain an overview of datasets, comprehend what kind of structures and resources are available, what properties resources typically have and how they are mostly related with each other.

TECHNIQUES FOR VISUALIZING AND INTERACTING WITH LARGE-SCALE DATASETS
In the Information Visualization domain we can find several useful techniques for visualization of hierarchically structured datasets (Card et al. 1999) The techniques developed for this challenge can be mainly classified in node-link diagrams and space-filling visualizations.The traditional node-link representations such as SpaceTree (Plaisant et al. 2002) or Cone Trees (Robertson et al. 1991) combine the conventional lay-out of trees with zooming interaction.However, they make poor use of the available display space and leave the root side of the tree completely empty.They do not give an effective overview of large hierarchies and nodes need to be expanded manually.When data gets larger the screen quickly becomes overcrowded with nodes and their childs.
On the other hand, space-filling techniques such as Treemaps (Shneiderman 1992) make a better use of the space by partitioning it into a collection of geometric shapes (i.e.rectangles) representing the tree structure.Some evaluations and comparisons have been performed on hierarchy visualization systems.Kobsa evaluated six visualization techniques with hierarchical data to compare their efficacy and user satisfaction with them (Kobsa 2004).Barlow et al. compared four different visualizations to evaluate the users' ability to understand the topology of the hierarchy and comparisons of node size (Barlow & Neville 2001).Their results show that each technique has its strengths and weaknesses depending on the exploration tasks and dataset characteristics.
However, these studies have mainly focused on users performing tasks related with understanding the topology and navigating through the hierarchy.None of them has performed an analysis of whether these visualization systems can be used to perform real end-users tasks and whether they provide good overviews of datasets.

APPROACH
Our starting point is the fundamental set of tasks for data analysis proposed by Shneiderman (1996).In the following, we present each task associated with the chosen interaction pattern for web design (Kalbach 2007): • Overview: to get a full view of the entire collection.We propose to apply the Global Navigation interaction pattern4 or the Directory Navigation pattern5 .• Zoom & Filter: to select items of interest and filter out uninteresting items through exploratory search.The proposal is the Faceted Navigation pattern6 .• Details: after filtering resources, the user can view detailed information about of them.The proposal is the Details on Demand pattern7 .• History: to keep a history of actions and support undo and replay actions.We propose to apply the Breadcrumb Navigation pattern 8 .
In this paper we focus on the Overview task, which should be the first stage for data analysis.Our proposal is to elaborate the selected interaction patterns to perform this task in the context of semantic data.We have chosen these patterns because they are simple and very common so users are very comfortable using them.They are part of the "culture" about how information is presented in the Web so they can be easily learned.Although they look like the common ones, these ones should be capable of giving access to the richer semantic data they are built on top of.
The Global Navigation pattern proposes to design a persistent set of links that enables users to get to the key areas or functions of a website.These links should be visible to users from every page, so they can move directly from one section to another.On the other hand, the Directory Navigation pattern proposes to organize the items or pages into several groups.This pattern should be implemented when there are a large number of items, so users can select and focus on an item out of a large set.
Once users have obtained an overview of the data they can select those kinds of items they are interested in.Then, exploratory search can be used to navigate through different instances and their properties.However, the other tasks are out of the scope of this paper and the reader can find more information about how we implemented them in (Brunetti et al. 2013).

INFORMATION ARCHITECTURE
To implement the Global Navigation and Directory Navigation patterns, our proposal is to draw from the experience accumulated in the Information Architecture (IA) domain (Morville & Rosenfeld 2006) and adapt existing IA components to the context of semantic data.
Information Architecture (IA) is the art and science of organizing information.In the context of the World Wide Web, Information Architecture is the discipline that organizes and labels the information on websites.This discipline includes analyzing the contents, organizing web pages and designing the navigation systems.We have explored the most appropriate Information Architecture components to implement the Global Navigation and Directory patterns.The objective is to adapt existing IA components to provide this overview to users.
The challenge of structuring and presenting semantic data to end-users can be addressed with the experience accumulated in the Information Architecture domain.Information Architecture focuses its efforts in this problem, especially in complex systems and situations with large amounts of information.
A good IA can improve the quality of a website and users can find easier the information they are looking for.
Traditionally, User-Centered Design techniques like Card Sorting (Spencer 2009) are used to develop the Information Architecture of websites.However, this technique requires much time from developers and most of this effort is wasted as soon as the content structure is established.Then, the Information Architecture becomes something static.If new kinds of items are introduced or a part of the content becomes more relevant, the Card Sorting should be repeated, at least in part.
In the case of web sites build on top of semantic data we have the opportunity to automate part of the process of generation and maintenance of the information architecture.The RDF data model enables the use of automatic tools to process it in a more sophisticated way.This is possible because semantic data is structured by thesauri and ontologies, which hierarchically organize the kinds of things described in the dataset.They specify all the classes or concepts but also which entities belong to a certain class or are related to a certain concept.

USER PROFILES
Our aim is to make it possible that lay users, not just Semantic Web technologies experts, can reach the Semantic Web.Using the Personas approach (Garrett 2010) (Pruitt & Adlin 2006), we can illustrate the target audience as shown in Table 1.Personas are also useful to elaborate on the associated scenarios and derive contextualized user tasks.In our case, we will use Christina Warren and Michael Harper personas to motivate the set of user tasks related with DBPedia valuated during user tests in Section 6.
Christina Warren is a 23 years old journalist who has recently finished her studies and is currently in charge of the Films section of an online journal.She likes to write about curious facts like "who appears most in films where Woody Allen is both the director and an actor".However, these kinds of things are really difficult to find out using resources like Wikipedia or IMDb.
(Picture by flickr.com/photos/electricnerve) Michael Harper is a 30 years old freelance developer that creates and commercialize mobile applications using online application stores.He works mainly in solo projects and without any financial support.He is currently developing a mobile application that supports bird watching and as a way to reduce development costs to a minimum he is trying to reuse as much as possible available data about bird species, habitats, etc.
Table 1.Personas illustrating the intended users

METHODOLOGY
Rhizomer's development methodology is based on the MPIu+a development process (Granollers 2003) and the RITE Method (Medlock et al. 2002) (Rapid Iterative Testing and Evaluation).MPIu+a is a development framework for interactive systems that integrates the discipline of Software Engineering with the basis of Human-Computer Interaction, Usability and Accessibility.MPIu+a has the user is the most important part of the process.User-Centered Design (UCD) is a type of design process for interactive systems focused on the users who will use the system.In UCD the user participates in all the stages of the design process.User requirements are considered from the beginning and included into the whole development cycle.
The RITE Method is an iterative development process based on short iterations.Each iteration, or reduced set of iterations, includes an evaluation of the Information Architecture components with a small group of users.This makes the evaluations differ from traditional ones mainly in the sense that much smaller groups of users are recruited for the tests, though tests are performed much more frequently.Consequently, results for individual test iterations are less significant from a statistical and quantitative point of view.The main results from just a testing session are basically qualitative and are used to guide the next development iteration.However, as many evaluation iterations are accumulated along the development process, it is possible to perform a quantitative analysis of the quality in use properties measured during each iteration and validate the evolution of the quality in use from a quantitative point of view.Moreover, the overall costs of the evaluation are significantly reduced.
Overview is the first user task when dealing with a dataset.The objective is that the user is capable of getting an idea about the overall structure of the dataset.However, overviews become difficult to achieve with large heterogeneous datasets, which is typical in the Semantic Web.As datasets grow bigger and more complex, it becomes more difficult to understand the overall structure and to browse them efficiently (Hirsch et al. 2009).A common approach to obtain an overview and support the exploration of large datasets is to structure them hierarchically (Elmqvist & Fekete 2010).Hierarchies allow users to visualize different abstractions of the underlying data at different levels of detail.They can improve the navigation as they allow users to create a mental model of the content structure (van Ham & van Wijk 2002).
In the case of Semantic Web and Linked Data, this overview is usually about which are the main kinds of things in the dataset and how they are structured, i.e. the more instantiated classes and their hierarchical structure.It is also possible to obtain an overview from the point of view of the more common subjects the data is about and how they are structured, for instance as thesaurus.

OVERVIEW GENERATION
The overview is generated from the hierarchy structure of the dataset, i.e. its schema.For each class, we store information about the number of instances of the class, its URI, its labels and a list of its subclasses.All this information is retrieved using a set of SPARQL queries.Listing 1 shows the SPARQL query to obtain the root classes, i.e. those non-blank without a superclass different from owl:Thing or rdfs:Resource.Listing 1: SPARQL query to obtain the root classes Listing 2 presents the SPARQL query to get direct subclasses for a given class marked with the placeholder "%classURI%", i.e. there is not an intermediary class between them in the hierarchy.Once the class hierarchy is generated, we store it in a local file so it can be reused by the overview components.If the dataset is modified, i.e. some resources are added or removed, this file is updated.We use the vocabulary (Alexander & Hausenblas 2009) to describe the dataset, its class hierarchy and the number of instances of each class.The property is used to provide descriptions of parts of the dataset, i.e. subsets.The property expresses the number of distinct subjects (number of instances) that occur in the dataset or subset.By using these properties, each class-based partition describes a subset of instances that belong to a particular class.The file also provides metadata about the dataset that can be reused by other applications and users.Listing 4 shows a part of the VoID description for the DBPedia dataset.

OVERVIEW COMPONENTS
The overview components are created from the hierarchy structure generated.For datasets without a schema it is also possible to use these components but their structure will be flat.Next, we describe the overview components that have been implemented.

NAVIGATION MENUS
Navigation menus, in the case of websites and as shown in Fig. 1, let users navigate through different sections and pages of the site.They tend to be the only consistent navigation element, being present on every page of the site.The objective is to generate a global navigation menu that takes into account all the classes considered in a dataset but also how they are instantiated.Consequently, if there are few instances of some classes or they are not instantiated at all, they should be less relevant in the menu bar.On the contrary, classes that do have a lot of instances should be shown prominently in the menu bar.This approach makes it possible to show the user the navigation bar that best fits the data in the dataset at that particular moment.This component can generate both global and local menus, i.e. a menu for the whole dataset or for a subset of it.The site administrator can also configure some parameters such as the number of levels in the menu, the number of items of each level, the order of items and a list of classes or namespaces to omit.According to these parameters, this component generates the menu applying a recursive algorithm that mainly performs two operations: • Split those classes with a large amount of instances in subclasses.
• Group those classes with few instances in a superclass.These operations are recursively performed until the menu is completed.Figure 2 illustrates the process of generating the navigation menu for a subset of DBPedia, with 7 elements in the first level.In the original hierarchy there are only 3 classes in the first level.Therefore, there are 4 free spots in the menu.To cover these free spots, the algorithm identifies which classes are appropriate to divide, taking into account their number of instances and their number of subclasses.First, the Eukariote class is removed and its subclasses, Plant and Animal, are moved up to a higher level in the hierarchy.After this step, the navigation menu contains 4 elements: Plant, Animal, Bacteria and Archaea.From here, the algorithm is applied recursively until the menu is completely generated.In the next step, the Animal class is chosen and divided.However, in this case, there is not space for all its subclasses in the first level of the menu.For this reason, the subclasses with a higher number of instances are moved up to the main level of the menu while the rest of subclasses are grouped inside Other Animal.This algorithm is applied recursively until the menu is completely generated.

HTML SITE MAPS
Navigation menus are quite effective because lay-users are comfortable with them, most website feature them and they are used to interacting with them.However, they just provide an overview of the most frequent classes, those more instantiated.In order to gain a more detailed overview, web sites usually apply the Directory Navigation pattern through different sorts of sitemaps.Site maps act as a navigation aid by providing an overview of the site's content at a first glance.A site map is a web page that lists all the pages of a website, normally organized hierarchically.
In the case of large sites, instead of containing links to all the pages, they can list the main pages (e.g.categories) of the site.When the site contains many levels in the structure and many elements on each level the site map functions as a navigation alternative to navigation menus.
We have implemented two different versions of the sitemap and users can switch between them.The first one is related with the structure of navigation menus, which has been generated from the original hierarchy.It complements the main site navigation and users can find there options that were are not directly available from navigation bars.It can be seen as a summarized version of the complete hierarchy structure.The second one reflects the original hierarchy of the dataset.It is showed as a tree with multiple levels and the users can expand it.Figure 3 shows the two site map versions.

TREEMAPS
One of the most popular methods for displaying hierarchical data is Treemaps (Shneiderman 1992).They produce space-efficient overviews of hierarchically structured datasets.They visualize hierarchical relationships of the data elements but also display quantitative information regarding the distribution of elements by their size.Treemaps use a rectangle to show the tree root and its children.Each child has a size proportional to the cumulative size of its descendants.They are a good method to display the size of each node in a hierarchy, i.e. its number of instances.
We have implemented the Treemap visualization following recommended design issues (Turo & Johnson 1992) and using the JavaScript Infovis Toolkit 9 .The generated Treemaps, like the one shown in Figur 4, show two hierarchy levels but allow users to zoom in.We used squarified Treemaps as the tilling algorithm.It produces rectangles with low aspect ratio, which makes it easier to compare their sizes.Different colors are used for each class and its subclasses.Label size is proportional to the number of instances of each node.

SITE INDEX
A site index is a navigational and informational tool that lists all the pages or categories alphabetically.Users can spend a lot of time looking for a concrete page through the site map.While a site map provides a general view of the overall site contents, an A-Z index provides access to particular content.An alphabetical list, like the one shown in Figure 5, can better suit users' mental model when they are searching for a specific page.
However, while site maps can give users context, site indexes provide no context.Non-related categories appear in the site index without giving users any additional information.Therefore, we have implemented the site index so that it provides also context information of each class.When the user moves the pointer over an element an overlay appears showing its parent and its subclasses.

EVALUATION
The goal of the evaluation was to determine whether solving tasks with the 4 different components differs with respect to task completion times, response accuracy and user satisfaction.Comparisons between the different components can provide valuable information about the effectiveness and usability of these systems depending on the use case.We do not aim to face the systems against each other but to provide a basis for design recommendations and guidelines.

EXPERIMENTAL DESIGN
The tests were conducted at the UsabiliLAB10 where sessions were registered using Morae Recorder together with Morae Observer11 to analyze test data.The software collected the task time and the effectiveness (completed, not completed and partially completed).Users were presented Rhizomer with the DBPedia dataset and the four components to use.They were encouraged to use the think aloud protocol (Lewis 1982) to express their opinion and thoughts on the system while performing tasks.
We asked 10 participants to participate in the study (6 males, 4 females), having a unique profile characterized by good knowledge of information technology; they work regularly with computers and use the Internet.None of them had expertise in Semantic Web technologies or had previously used the DBPedia.The chosen tasks comprise the common information needs when users navigate and want to find something in a web site (Morville & Rosenfeld 2006): known-item seeking, exhaustive research, refinding.The items to find slightly vary for each task and component to reduce the effect of learning12 : 1. Known-item seeking: find one node for different levels of the hierarchy using navigation menus (1), site map (2), Treemap (3) and site index (4).
In total, users had to perform 6 tasks using navigation menus, 6 with the site map, 6 with the Treemap and 4 using the site index.12 tasks belong to known-item seeking, 6 to exhaustive research and 4 to refinding.We ran the evaluation as a within-subject design, where each participant performed all tasks using all four components, except for tasks 4 and 5, which was not performed using the site index because it does not provide the context information needed to perform these kind of tasks.Users were given a maximum of 2 minutes to perform each task.

RESULTS AND DISCUSSION
Figure 6 shows the average task completion times.The results show that user's performance depended on a combination of the task and the component used.Overall, all tasks were correctly completed except task 3, which is explained later.The results are discussed in the next subsections.

KNOWN-ITEM FINDING
Navigation menus were the fastest component to find large known-items located in the first level of the hierarchy (e.g.Work).Users could see the most important items at a single glance in a horizontal line.However, their efficiency decreases when users have to find items located deeper in the hierarchy (e.g.Monument or Reptile).
With the site map, users could easily find nodes located in the first or second level of the hierarchy (e.g.Place or Insect).However, the summarized site map only shows two levels of the hierarchy and users had to switch to the full site map to find items located deeper (e.g.Sports team).Only 2 users were able to find this option and were able to complete the task.
Something similar occurs with the Treemap.Users could easily find large nodes located in the first or second level of the hierarchy (e.g.Event) but it was more difficult for them to find smaller nodes (e.g.Aircraft) because their label was not visible until they zoomed-in.
It was difficult for users to find nodes located deep in the hierarchy (e.g.Aircraft, Hospital) using the Treemap, site map or navigation menus.They needed to understand how the dataset was hierarchically structured and guess where the item could be located.In these cases, the site index was the fastest component because users did not need to understand the site structure.They only needed to locate the item in the alphabetical index.
Fig. 6.Average task completion time

EXHAUSTIVE RESEARCH
The Treemap was the fastest component to compare node sizes.Rectangle areas allowed users to easily compare different nodes.On the other hand, using navigation menus or the site map users had to manually compare the number of instances.Several users pointed out that it was difficult because thousands were not separated by dots.
The Treemap was also the best component to understand the topology and to find a class and its subclasses.Different colors allow easily identifying groups of related nodes.However, in this case there is not a big difference compared to navigation menus and the site map.

RE-FINDING
Users found previously visited nodes (T6) faster than the first time (T2) with all components.The site map was significant faster than navigation menus.The Treemap was the worst component to perform this task.The visual representation of nodes did not help much users to remember where was located the item to find.

USER SATISFACTION
After finishing the tasks with each component, we gave users a written questionnaire to evaluate their confidence, satisfaction or frustration with it.Users were asked to rate the following statements from 1 to 7, being 1 the most negative and 7 the most positive.Table 2 shows the questions and user ratings.Overall, users had a good impression of the overview components.Users prefer navigation menus, the site map and the site index instead of the Treemap.They are used to common web components more than to interactive visualization methods.Most of them had never seen a Treemap before and required some time to learn how to use it.There were no significant differences between traditional web components in terms of use preference.It is important to notice that the site index was considered the best component to find concrete information (Q3) but the worst to understand the site structure (Q4).

PROPOSAL
From test results and their analysis, we have elaborated the following proposals to improve the existing overview components.

NAVIGATION MENUS
The proposal for navigation menus is to improve the algorithm that generates them.Right now, the main factor considered to generate the menus is the number of instances of each class.As a result, it is possible that some options in the first level of the generated menu do not have subclasses.For example, in our evaluation with DBpedia, the class appeared in the first level but did not have any subclasses.Then, we cannot use a submenu for this class and we waste space in the navigation menu that could be used to show more options.Meanwhile, other classes with fewer instances but with more subclasses do not appear in the first level.The proposal is to study how to generate the navigation menus considering both factors: the number of instances and the number of subclasses for each class.

SITE MAP
As the results show, users did not understand the difference between the two site map versions and did not know how to switch between them.The first one reflected the original hierarchy of the dataset, displayed as a tree with multiple levels.The second one, related with the structure of navigation menus, was a summarized version with the main classes.Only two users were able to find how to switch between both versions.In other studies regarding site map usability (Tedesco 2008), participants successfully used site maps that were not organized to reflect the site's main navigation.
Moreover, these studies suggest that multi-column site maps work better because users need less scrolling to get an overview of the site's structure.Therefore, our proposal is to keep only the full site map and display it using two columns.The full version allows reaching all the classes in the original hierarchy while the summarized version only shows the main classes.

TREEMAP
The main issue with Treemap was to find small nodes.In some cases, there was not enough space to show their labels inside small rectangles.Users could only see these labels when they moved the mouse pointer over the rectangles.Our proposal is to study how to group small nodes into a supernode.Then, when zooming into this supernode, it would be easier to locate small nodes.We also propose to complement the Treemap with a keyword search that could allow finding these nodes.

CONCLUSIONS AND FUTURE WORK
We presented four components that support the overview task proposed by Shneiderman in his visual seeking mantra.These components are useful for obtaining a broad view of the datasets, their main types and the relationships between them.The RDF data model being prevalent on the Data Web enables us to create these overviews in a generic and automatic way.A good overview provides users an appreciation of the collection of objects and can help achieving their information seeking goals.Rhizomer, with these overview components, allows users to explore datasets even if the publisher of the data does not provide any exploration or visualization means.
Our evaluation shows that each component has its strengths and weaknesses depending on the use case.Navigation menus are useful to find the main important classes but they can only show a limited number of options.Site maps provide a general top-down view of the overall site contents but users need to understand the site structure to find concrete items.Treemaps are useful to get an overview of the data, compare node sizes and identify groups of related items through different colors.However, it is very difficult to locate those nodes that have a small area.A site index provides easy access to particular content but does not give information about how a website is structured.
The previous findings are aligned with current knowledge about how these user interface components contribute to the users experience while seeking information in "classical" web sites.Consequently, from these similarities and the quantitative and qualitative results obtained during user testing, it has been shown that it is possible to obtain a comparable user experience, even for very large semantic datasets like DBPedia, using components automatically generated from the underlying data, ontologies and vocabularies.
Our future work focuses on improving these components and their usability, as described in Section 6.4.We will further study these components with other datasets to evaluate how they adapt to different datasets depending on their size and structure, and also how users perform similar tasks using them.This will also provide insights about the particularities of the user experience when exploring big datasets using automatically generated user interface components like the ones generated.This will also better motivate alternative mechanism for data exploration.
For instance, another possibility to create overviews is to apply clustering algorithms.Clustering is the process of classifying similar resources into groups called clusters.This could allow us to create navigation menus with a limited number of options that represent the whole dataset.Clustering could be also used to create overviews of datasets without a schema.Finally, we also plan to develop a search system.Some users asked for it and they even used the search option available in the web browser.A search system would allow users to easily find known-items without needing to know where it is located in the hierarchy.

Listing 3 :
SPARQL query to count the number of instances of each instantiated class

Fig
Fig. 5. Site index ), site map (2) and Treemap (3).o Place, Agent and Species (1).o Work, Place and Mean of transportation (2).o Eukaryote, Person and Musical Work (3).-Task 5: topology understanding.Using navigation menus (1), site map (2) and Treemap (3) find subtypes of: o Mean of Transportation (1), Species Listing 2: SPARQL query to obtain direct subclasses for a given class Finally, Listing 3 shows the SPARQL query to obtain the number the number of instances of each instantiated class.

Table 2 .
User satisfaction questionnaire for navigation menus (NM), site map (SM), Treemap (TR) and site index (SI)