There has been a large growth of available semi-structured data on the Web, spurred both by governmental requirements for publishing public data, and by private sector, for various purposes. One such large initiative is the Linked Open Data Cloud. An increasingly important activity is to make sense of such published data, often exploring it as a prelude or as initial steps to perform some information-processing task. Exploration is then a generalization of the traditional search task, as it involves other operations beyond finding specific information. The design and evaluation of exploratory frameworks is a complex, multi-disciplinary endeavor, with important challenges for both aspects. In this paper, we will argue the need to separate the conceptual exploratory operations users may carry out over semi-structured data from the particular interface designs used to give users access to such operations. We illustrate the problems using practical examples and state-of-the-art tools and discuss how this separation of concerns allows more accurate evaluation of the relevant aspects of any proposed tool or framework that aims at supporting Explorations.
The exploration of (semi) structured data is a highly interdisciplinary research area
[
Exploratory Search is usually considered a process that combines searching and
browsing activities aiming at knowledge acquisition [
Despite the attempts to identify the various concerns in Information Exploration,
such as operations, interaction patterns and visualizations [
In this work we will shed some light on how to adopt a pragmatic model-driven separation of concerns in order to characterize the information exploration tools by both the set of operations they provide and the physical interface dialogue structure that support the execution of those operations. 2
Although the separation of user tasks, operations and goals from interface design
details has been widely recognized as valuable approach in HCI since the existence of
task models, such as the Goals, Operations, Methods and Selection rules (GOMS)
family [
The separation of concerns in information exploration proposed in this paper is
consistent with Norman’s theory of gulf traversal [
As mentioned previously, the user’s intentions and actions at the cognitive level
can be captured as exploration functions. Our research is based on Pirolli’s levels of
explanation of the user’s interaction with information [
KeywordSearch(Keywords): perform a search for the occurrence of the
provided keywords over the dataset and returns the set of items matching
the keywords;
• Pivot: changes the focus of exploration to another related item, or adds a
pivot to the current focus in case of multi-pivoting exploration. In the
simplest case, the Pivot operation just puts another related element as the
pivot of exploration in a one-to-one style similar to the traditional
hyperlink navigation between web pages (for example, American President to
birth place). In more advanced forms, Pivot can express many-to-many
pivoting from a set of items to another related set of items – Pivot(Items,
relation) –, e.g., Pivot(AmericanPresidents, wife) returns the set of
American President’s wives;
• Query(Characteristics): retrieves information items through the
specification of their characteristics. For example, consider a user retrieving all
theaters in London by specifying the type of the element and the
location: Query(type:Theater, location:London);
• Project(Items,Characteristic): projects some set of results along a
property. For example, projecting a set of works by the year of publication to
be plotted over a line chart: Project(Works, publicationYear);
• GroupBy(Items, Characteristic): groups a result set based on the values
of some characteristic of the information items. As an example, consider
a user grouping European companies by their areas of expertise;
• Refine(Items, Filters): refines a set of items through the application of
filters received as parameters, e.g., Refine(Publications, {year > 2004});
• FindPath: finds structural connections between sets of information items
[
We can model the process as functional compositions by considering the exploration process as a sequence of function applications over a dataset, where the output of one function is used as input of the next,. The extent of possible functional compositions that is supported by some exploration tool depends on the set of primitive functions it implements, ultimately determining its expressivity to support Information Exploration. We expect that comparisons addressing expressivity issues would shed some light on how well the exploration tools assist the user during the task execution as well as the types of tasks that are better supported. The more expressive is the set of exploration functions for a given task, the shorter is the semantic distance to bridge in both the execution and the evaluation gulfs. 2.2
In this section we will illustrate and discuss how the same functions can be
articulated differently in different tools, and how we can capture those differences in a
conversational model for qualitative comparisons. For this discussion we selected the
Pivot and Query functions and show how they can be composed through several
interaction patterns. To illustrate our point, we examined two state-of-the-art tools –
Liquid Query [
MoLIC interaction diagrams are organized around dialogues between the user and the system, considered as the designer’s deputy, and dialogue scenes, which represent user-system dialogues about a certain topic. There are also transition utterances, which reporetshent the turn taFkiingg uinr ethe1c4onversation. Tthheescenes are represented as er four. shows exploration scenes and their dialog white namterdabnoxseist.iTohne su.ser-system utterances are represented as labeled arrows and usually cause scene transitions. Utterances emitted from the user have “u:” indication while the designer’s deputy utterances have a “d:” indication. The black boxes represent a system processing step. Inside the scene boxes the information items involved in the user-system dialogue are presented.
d: Here are the possible way u: Define query parameters for Topic X pre: {there are parameters for the topic X} pre: {no search option available}
Sel u:Define Query for Topic X by Charac pre: {there are parameters
Define Query u: No results f
pre: {s
The interaction with both tools starts through some ubiquitous access (gray ellipses). In Liquid Query (Fig. 1) the user first executes the Query in the “Define Query” scene. After that, the user can Pivot in the “Explore Results” scene by asking the designer’s deputy to expand the result set using some topic relationship between sets of information items (utterance “u: expand the results for set(Item) using TopicRelation X” in Fig. 1). In SeCo, the execution of the Query function in the “Define Query” scene can only be achieved before the user selects a topic of search (“Select a Topic” scene in Fig. 2) and how the information items will be queried (“Select Search Option” scene in Fig. 2). The Pivot function in SeCo is also revealed through a different interaction pattern. In SeCo the user can ask the system to pivot through a result set expansion (utterance “u: expand the results by selecting a related topic” in Fig. 2). This solicitation causes a scene transition that leads the user-system dialogue to the topic selection and search option scenes. From this example, we conclude that both the exploration functions and the way they can be composed can assume different interaction patterns that clearly influence the articulatory distance to bridge the gulfs. r. Figure 14 shows the exploration scenes and their dialogue structures and s. Fig. 2. SeCo dialogue structure for Query and Pivot functions
d: Here are the possible ways to search for Topic X
Looking only at the Pivot function we can observe that it may be defined in
different ways, such as one-to-one [
Patent Analysis is a kind of activity that can often be characterized as an
exploration task [
Consider the following scenario: “Company X is aiming to invest in a different area of its current investments in order to diversify its activities. A promising area of investment is the development of Lithium-ion traction batteries. However, Company X lacks knowledge in the area and decided to hire a patent analyst to trace a profile of the main players in the area in order to better understand it. The patent analyst should prepare a report containing the following information: • Trace and compare the activity of each company in the last 10 years. • What are other areas of investment in addition to Lithium-ion Traction Batteries that the players are addressing? What are the activities in those areas?”
In order to analyze how well is the support of an exploration tool for the execution of the scenario, we selected one of the state-of-the-art tools for patent exploration, the Patent Lens system1. First we simulate the ideal execution in Patent Lens and then we show how we can improve the process by augmenting the expressivity of its set of functions.
Patent Lens is a faceted system with many visualization options, such as line charts, pie charts, and bar charts. The facets available for exploration, among others, 1 http://www.lens.org/lens/search are: Date, Jurisdiction, Inventor, Owner, Applicant and Classification. In order to explore the dataset, users have to select one or more values for the facets and refine the current result set. When the user selects one of the facets, the current result set is grouped by the possible values of the selected facet. Fig. 3 shows some possible values for the Jurisdiction and Owner facets along with the number of results they achieve. We capture the intention of grouping the result set along the facet values in the GroupBy exploration function.
In order to solve the first problem of tracing the activity of each player the shortest strategy the user can employ is: 1. 2. 3. 4.
As we can observe, it is only possible to project one result set at a time, generating a loop on the set of patent owners. If we extend the expressivity of the Project function to receive one or many sets of items to project, the task would have lower costs in terms of number of actions.
Another interesting example is the problem of tracing other areas of investment of the Lithium-ion traction battery players. Using Patent Lens, the shortest execution strategy is: 1. 2.
For each owner in GroupBy(Owner)
Annotate owner using an external tool For each class in GroupBy(Classification)
Annotate class using an external tool
The key strategy to solve this subtask is to find the disjoint classes from the classes of patents related to the keyword “Lithium-ion Traction Batteries”. First the user has to annotate the owners and the classifications using an external tool. After that, the user has to clean all filters and return to the initial state, which contains all patent documents. Next, he has to refine the result set to keep just the patents of the previously annotated Lithium-ion traction battery players since the tool does not feature any function to save and reuse the set of owners found in previous steps. Finally the user has to refine the set for each classification that was not in the set of annotated classes related to Lithium-ion traction batteries. As a conclusion, we can observe that the higher cost actions are the ones that involve loops for each information item. We can minimize the cost by adding some set-based functions to the set of exploration functions of Patent Lens.
If we improve the expressivity of the set of exploration functions by adding Pivot and set difference – Diff – functions, we can reduce drastically the complexity of finding the disjoint classes by eliminating the loop. Therefore, the actions could have the following structure:
2. Pivot (R1, classification) -> R2 3. Pivot (R1, owner) -> R3 4. Pivot(R3, hasPatent) -> R4 5. Pivot(R4, classification) -> R5 6. Diff(R5, R2) -> DisjointClasses
The Pivot function changes the focus of exploration by generating a set of related information items, such as the set of classifications of patents related to the keywords in step 2. The Diff function generates the difference between two sets and is applied in the last step to extract all classes that are not in the set of classifications of patents related to “Lithium-ion Traction Batteries” keyword.
From the examples above, we conclude that it is possible to improve the expressive power of an exploration tool by adding new primitives to the set of exploration functions. Once an adequate functional model is devised for the target exploration tasks and the target users, the system interface should be modeled to aid the translation of the functions in interface controls. In the next section we will show the benefits of modeling the information exploration as a composition of functions.
In the previous section we have argued for the existence of two layers that are usually addressed indiscriminately: the functional layer and the interaction layer. In the functional layer the users’ cognitive exploration actions and strategies can be modeled as functions and functional compositions, respectively. The interaction layer is concerned with the translation of those functions in interface controls. In this section we give more details of the functional layer showing the benefits of addressing it formally and separately from interface design and implementation concerns. We also illustrate how a framework of exploration functions can enable comparisons and evaluations of information exploration tools. 3.1
The most frequent problem in the experiments addressing the exploration tools is
the inability of assessing the exploration process. It is not possible to assess to what
extent and how good is the tool support for exploring information. As an example, we
selected different tools to analyze only their functional aspect. For demonstration
purposes, consider the following exploration task, which is an extension of the
problem presented in [
The cost of the process required to solve this task can be significantly different depending on the expressivity of the set of exploration primitives available in exploration tools. Fig. 4 shows the steps required to solve the task with Explorator.
In Fig. 4 the user starts with a keyword search for the topic “American Presidents” (step 1) and refines the set of presidents by their party (step 2). Next, the user pivots from the set of presidents to the set of presidents’ children (step 3). In order to find the schools the presidents’ children have attended, the user pivots again using the “School” relationship (step 4). At this step, the user recognizes the need to also add the set of presidents’ schools as another pivot (step 5). Finally the schools who have received both presidents and presidents’ children is achieved in the step 6 by intersecting the set of schools achieved in step 4 with the set of schools achieved in step 5.
Multi-pivoting can be defined as the possibility of adding distinct sets of elements
as the focus of exploration, hence, leveraging operations over multiple pivots, such as
finding relations between them [
In the execution presented in Fig. 4, while in Explorator the set of primitives
includes set operations and multi-pivoting, which allows the user to intersect the results
of two pivoting operations in steps 4 and 5, Parallax [
As a conclusion, we showed that it is possible to compare exploration tools just considering the available set of exploration functions. By doing this, we reinforce both the existence of an additional layer that should be considered in the design process independently of interface concerns and the benefits that a formal exploration framework can bring for tool evaluation and comparison concerns. 4
Although the separation of the conceptual model of user operations from the interface details is a widely accepted principle in HCI design, it has hitherto not been properly applied in the context of information exploration tools. Consequently, the evaluations and experiments usually fail in explaining the reasons of observed successes or failures. Moreover, it is difficult to compare these tools regarding the adequacy for information exploration tasks without a common framework of operations. Given this scenario, the contributions of this paper are two fold. First, we demonstrate through use cases how exploration tools can be assessed both in terms of the operations set and in terms of the dialogue structure present in the user interface. Second, we propose new usage of two distinct models for qualitative evaluation and comparison of exploration tools. The first model, which is still in construction, is a framework of exploration operations. The second model is the Modeling Language for Interaction as Conversation, which is an abstraction to analyze tools regarding their conversational structure.
Modeling the user’s exploration as a nested sequence of function applications over a dataset allows us to represent the process as functional compositions. We claim that the expressivity of exploration tools can be assessed by the range of functional compositions that can be formed using the set of primitive exploration functions offered. Therefore, a formal framework of exploration operations would leverage the usage of expressivity to more accurately evaluate and compare exploration tools independently of interface design issues. In order to illustrate this position we used examples of real exploration problems and showed how the same exploration functions can be presented with different interaction patterns and how we can improve the exploration process simply by evolving the set of primitive functions.
As future work, we plan to elaborate a formal description of a framework of exploration operations and evaluate how well it leverages the description and representation of the Information Exploration process. We will evaluate and compare exploration tools regarding the expressivity of the set of primitive exploration functions. We also plan to study how the same framework can be used as a formal base for reuse of exploration patterns and knowledge sharing among communities of users.
The authors were partially supported by CNPq project 557128/200-9 National Science, Technology Institute on Web Science, CAPES, and Google Research Program. 5