Visualization for human resources

The HR data are stored in a tabular form in a relational database (RDB). To inspect such data, spreadsheet tools, such as Microsoft Excel and Google Sheets, would be the first choice. Those tools are often used to display the original data and perform fundamental aggregation, such as sorting, filtering, and visualizing using predefined charts. For example, Microsoft Excel is the most frequently used tool to manipulate tabular data for HR analysis [14]. Spreadsheet tools can compare two attributes at one point in time or they can show time-series variation in one type of attribute. However, such tools with the two-dimensional table representation are unsuitable for simultaneously analyzing two attributes with a time scale. Moreover, spreadsheet tools are not suitable for such heterogeneous or large tabular data due to aggregation and performance issues; thus, every time users must extract tables for their purposes.

Recently, BI tools such as Tableau, SpagoBI, and Qilk have been used for business analytics [15, 16]. For HR analysis, Tableau had been employed to analyze trends in job descriptions in New York using bar and line charts [17]. Although BI tools are useful for aggregation, there are two concerns. First, the backends of BI tools are based on the RDB model; thus, the data must be normalized, which requires a tremendous amount of effort. Second, once users specify the attributes to be analyzed, the tool can visualize them on a sophisticated interface. Users will employ BI tools effectively only if they can normalize all data and determine the types of visualization and aggregation that will be beneficial. Before starting tabular analysis and visualization, users need to choose the columns of focus.

If users have Python skills, they can use Jupyter Notebook [18] for inspecting data. Various kinds of visualization and inspection libraries are also available in Python. However, such libraries require advanced programming skill, thus hindering non-programmers from inspecting data by themselves.

Data heterogeneity is a major challenge for information visualization systems [19], including HR data analysis systems. Methods for visualizing HR data have been explored, and several visualization systems for HR data have been developed. Proactive [20] is a job description search engine with a rich interface. It displays a list of job descriptions in a tabular manner; however, the relevance between records is not shown on the interface. In addition, a system has been presented that displays each applicant with various metrics, such as talent or performance [21]. This system is useful for allowing users to know the attributes of each applicant; however, the relationships among attributes are not shown. In contrast, the proposed system focuses on the relationships among attributes of prospective employees.

Visual analysis of categorical data

Many categorical, albeit unnormalized, data are stored in HR databases. State-of-the-art techniques of categorical data visualization have been reviewed in previous research [22]. They categorized these techniques as Euler-based, overlays, node-link, matrix, aggregation, and scatter. The node-link diagram, also known as network graph, is used to depict categories and their elements as nodes and edges in a graph. The node-link diagram can visualize either the relationship between categories and elements as bipartite graph [23–25] or that between categories as Parallel Sets [26].

They described the advantage of the node-link diagram as highlighting elements as nodes and clustering nodes of each category, making it easy to understand. Radial Sets [25] locate the category nodes along the arc of the circle. Element nodes are located inside the circle, which belong to multiple categories. Parallel Sets [26] visualize categories as parallel coordinates plot and the frequencies of the combination of categories as edges between categories with an interactive interface. They aim to visualize complex data information in its entirety. However, first-time users might find the description difficult to understand. The major downside of a node-link diagram is that the crossing edges make it difficult to understand the diagram. Also, the number of edges in the graph is often limited to about hundreds because of increasing clutter [22]. Nevertheless, the node-link diagram can be integrated with dynamic graph visualization for temporal data. We utilize the node-link diagram for visualization of categorical heterogeneous tabular data.

Visualization for dynamic graphs

Several static graph visualization tools for general purpose, including Cytoscape, GraphViz, and Gephi [27–29], provide sophisticated methods to visualize any type of graphs; however, these tools were not designed to render dynamic graphs. Review articles have described a hierarchical taxonomy for categorizing visualization techniques for dynamic graphs [30, 31]. It can be subdivided into four types: (1) timeline node-link, (2) timeline matrix, (3) animation with a special-purpose layout, and (4) animation with a general-purpose layout. Hereafter, we describe each layout. (1) Timeline node-link approaches, such as the work of Greilich et al. (2009) [32] and Burch et al. (2011) [33], show superimposed or juxtaposed nodes for each year, which visualizes the relationship between nodes rather than the graph topology. Small multiples are categorized as the timeline node-link approach. (2) Timeline matrix approaches, such as the work of Stein et al. (2010) [34] and Burch et al. (2013) [35], are suitable for dense graphs; however, our target graphs are not dense as can be seen by the construction method. Timeline approaches visualize the time scale on the view, which requires a summarization of each time step. (3) Animation with a special-purpose layout can visualize graphs of each time step; however, the approaches need an abstract representation of nodes based on hierarchy or clusters. (4) Animation with a general-purpose layout can visualize graphs by general methods, and users can easily trace the position of nodes in each time step [36, 37]. We utilize (4) the animation general-purpose layout in the proposed system because it provides the most flexible visualization without any abstraction for each time step.

For selecting the method for visualizing dynamic graphs, the ability of the method to preserve the user’s mental image of the graph, i.e., mental map, is an important criterion [30]. The animation approach is one of the effective methods that provide a mental map by maintaining coherency among time steps [38, 39]. The animation approach enables users to gain more insight from changes between subsequent years in several cases, as demonstrated by Boyandin et al. (2012) [40]. However, as described by Hajij et al. (2018) [41], the limitation is that the graph topology can be lost on each timepoint. Several approaches to mitigate this limitation are available. For example, GraphDiaries [42] displays an animated transition of graphs between time steps, where disappearing nodes are highlighted first, followed by appearing nodes. Similarly, TempoVis [43] displays the color difference between appearing and disappearing nodes. Using a force-directed approach also mitigates the overhead of transition identification through time steps [44]. This is because this approach is able to trace the moving positions of the nodes of the previous timepoint. We utilize the force-directed approach for tracking the position of nodes.

Graph visualization for tabular data

The efficiency of graph-based visualization for tabular data has been discussed regarding Orion [9], Ploceus [10], Graphiti [11], Origraph [12], and Oniongraph [13]. These are data-wrangling tools to convert tabular data into graph and can provide a graph visualization interface. These tools based on the concept that the network structure in tabular data can be represented as graphs, and they support constructing a graph from tabular data interactively. Orion uses domain-specific languages and a visual interface to display a node-link diagram without any attributes. Ploceus and the following tools explicitly support attaching attributes on each node. Further, several tools support a multi-layer graph. For example, Graphiti handles a multi-layer graph whose layers have different types of edges. OnionGraph uses node aggregation for hierarchical abstraction and provides a filtering function for nodes or edges. Both tools assume that the topology among layers is maintained. However, the time-varying graph does not assure that the graph topology is maintained through multiple timepoints. Therefore, special care to maintain a mental map is needed.

The temporal graph visualization has been adopted for some special cases. For example, MatrixFlow [45] is used for medical data and visualizes a temporal network as timeline matrix approach. ecoxight [46] visualizes business ecosystems as an animated timeline node-link diagram, though the input must be a graph.

Although Panacea shares the same concept in handling tabular data as a graph, we focus on the temporal data visualization for temporal tabular data. For this study, we wrote custom scripts to convert the graph data and developed a visualization system to explicitly display temporal information on the node-link diagram.

Graph database

The selection of a graph database is a design decision. Categorical data visualization by a node-link diagram internally converts categorical data into a graph-based representation. Storing all categories into a graph database is a persistent and scalable way to query from the frontend each time. To store graph data in a graph-based database, mainly two definitions of graphs are available, i.e., the resource description framework (RDF) [47] and property graph (PG) [8]. RDF is a normalized data structure to describe relations between entities. PG is a more flexible graph format and is compatible with several graph databases, including Neo4j (https://neo4j.com). RDF is well normalized but is occasionally complex to visualize and to query because all entities must be nodes. Therefore, in the proposed system, we utilize PG as the data format for storing graphs.

Further, we employed Neo4j as a backend graph database. Neo4j has a company-provided visualization tool, i.e., the Neo4j browser. However, we needed to hold the position of specified nodes for preserving the mental map. Since the Neo4j browser does not support this feature, we wrote a custom frontend with vis.js (https://visjs.org). Several studies have implemented their own visualization system on top of Neo4j. For example, Onoue et al. (2018) [48] employed Neo4j as a backend graph database, and Caldarola and Rinaldi (2016) [49] used Cytoscape but stored data using Neo4j. Neo4j is state-of-the-art software to employ as the backend of the visualization system. We thus implemented our custom visualization modules on top of Neo4j.

Data model and preprocessing

Multi-partite graph G is expressed as G = ((A, V₁, V₂, …, V_n), E), where E ⊆ A × V_i such that A represents applicants, each of V₁, V₂, …, V_n is an applicant attribute, and E represents the relationships between an attribute and applicant. Each record in the table corresponds to a single applicant node. There is an edge e ∈ E if and only if the applicant a ∈ A has an attribute v ∈ V_n. From the frontend, users select two attributes V_x, V_y from V₁, V₂, …, V_n. Queries to retrieve subgraphs are encoded in Cypher, which is a query language for Neo4j. Based on the definition of PG, nodes can have properties. Here we set the type property of each attribute node to describe the category name of attributes, e.g., academic credential or internship history. We also set the year property of each applicant node to specify the year to explicitly encode the time scale on a graph.

Since we have already determined the design requirements, defining a custom conversion to satisfy these requirements is more reasonable than writing domain-specific languages or using data wrangling tools. Indeed, manual curation using existing data wrangling tools is not practically suitable to convert large and temporal tabular data into a time-varying graph. Therefore, we implement novel custom scripts to encode the temporal tabular data into a time-varying multi-partite graph.

In the HR database, each row is an applicant, and each column is an attribute. We simply regard each column as (1) a single-column attribute, (2) a property of the applicant node, or (3) a multi-column attribute. For example, academic credential should be assigned as (1). Name should be categorized as (2) because name is tightly linked to the attribute; therefore we do not want to regard name as an independent attribute. Let us consider internship history as an example of (3). There are three columns labeled as internship history1, internship history2, and internship history3. These columns contain company names as string datatype where applicants worked as an intern. These columns should not be assigned as independent attributes because the three columns are just an inflated array of internship histories. Thus, we assign these columns to the same type on attribute nodes to merge these columns into one category. Such columns represent poor database design because the columns are not normalized. Instead, we should have an internship company table with a unique key for each company and an intermediate table with two keys for applicants and companies. However, we could not modify the original table structure due to the limitations of the recruitment management system. Most of the columns are categorized as (1), but we find that several columns should be categorized as (2) or (3). There are several models to convert tabular data to PG [51, 52]; however, they do not convert (3) a multi-column attribute. The advantage of graph representation is that graph can handle such kinds of unnormalized relational data smoothly.

The entire procedure to convert the HR data into the graph is as follows. An empty graph G is initialized, and the following procedure is repeated for each record in the table: First, the applicant node a ∈ A is inserted into G with properties from all elements that are a property (2). Next, for all elements that are an attribute node (1) or (3), a tuple of two nodes and an edge (a, e, v) s.t. a ∈ A, e ∈ E, v ∈ V₁, …, V_n is inserted into G. At last, graph G is imported into Neo4j.

Overview of systems

Panacea’s frontend has two view modules, i.e., graph and configuration views, as shown in Fig 3. The graph view visualizes two attributes and temporal information between two arbitrary timepoints. With the combination of components, we provide an “overview first, zoom and filter, then details-on-demand” system, as introduced in Shneiderman’s Visual Information-Seeking Mantra [53]. We can visualize two attributes throughout the timepoint. Two attributes are classified as primary and secondary attributes. The primary attribute is highlighted by using a color or position on the graph view, thus working as a criterion to be compared with the secondary attribute.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. Screenshot of Panacea.

The interface has (A) graph and (B) configuration views. The graph view shows an example of the relationship between two attributes. The small green nodes are applicants; the large blue nodes are primary attributes; and the other large nodes are secondary attributes. The green edges represent relationships between applicants and attributes.

https://doi.org/10.1371/journal.pone.0247587.g003

The subgraph G(year, x, y) = ((A_year, V_x, V_y), E) is displayed in the graph view (Fig 3A). Here, each attribute node has a Japanese label (omitted in all figures; English labels were superimposed as necessary). Each applicant node is not labeled because the applicant nodes vary across years. The primary attributes V_x are displayed with star layout, which places the node with the maximum degree at the center, and the remaining nodes surround the central node on the circumference. Then, A and V_y are visualized using a force-directed layout with the ForceAtlas2 algorithm [54]. V_x and V_y are large nodes with different appearances. A is visualized as small green nodes. Users wish to see what attributes that an applicant has, especially if the applicant appears as an outlier due to the node location. A small pop-up appears to show the entire list of an applicant’s attributes when users click A. Edge E connects between A and V. Due to the limitations of performance and perception, we do not recommend visualizing more than a hundred nodes at the same time. Limit of primary attributes and offset of primary attributes parameters are useful for reducing the number of entire nodes. Since primary attributes are sorted by the occurrence of each attribute, users can retrieve subgraphs including an arbitrary range of primary attributes.

The force-directed layout calculates the positions of nodes based on physical simulations. Gravity makes two nodes closer, whereas repulsion makes two nodes more distant. All nodes are separated due to repulsion between nodes, but node pairs connected by an edge make closer. As more and more edges connect nodes, the connected nodes can be closer. As a result, the distance between attribute nodes is adjusted across the entire graph, which helps users to see the relationship between attributes.

The primary attributes are anchored on the initial position, whereas the secondary attributes and applicant nodes can move. Only users can move primary attribute nodes to an arbitrary position, which enables them to perform manual clustering of nodes based on a category, feature, etc. When users move the position of a primary attribute node, the position of the remaining nodes is recalculated and moves at the same time. Our initial implementation was to visualize all nodes using the force-directed layout without constraints on positions. However, the visualization between the primary or secondary attributes was obscure because the two attributes were superimposed or mixed. To avoid this, we suspend the position of the primary attribute. Further, the graph can be zoomed in/out using a mouse scroll. With the force-directed layout and zooming, users can intuitively see correlations among the primary and secondary attributes.

The animated force-directed layout enables users to observe the transition across multiple years. When users select a year to be displayed, applicant nodes and all edges are removed and re-rendered. We employ two techniques to preserve the mental map by reducing differences between timepoints. First, the positions of the primary and secondary attribute nodes are maintained at this time. Second, the applicant nodes are maintained if and only if the target node has the same edges over the years. Then, all edges are drawn between nodes, and the positions of secondary attributes and applicant nodes begin to change. This animation illustrates the dynamic transition across different years, which helps users to see the trends. The transition is not limited to consecutive years, i.e., the users can observe dynamic differences between distant years.

Example A. Location of university versus self-declared english skill

We present the first case study to demonstrate the transition over three years using the animated force-layout rendering in Panacea. Fig 4 shows the graph view between location of university versus self-declared English skill of prospective employees. Here, the three large blue nodes correspond to three regions in Japan, i.e., Kanto, Kansai, and Chubu, which are arranged in a circle. Kanto is the central-eastern part of Japan’s main island and includes Tokyo. Kansai is the central-western area and includes Osaka. Chubu is the central area and includes Nagoya. The large colored nodes (except for the blue nodes) are self-declared English skills collected from the submitted resumes, and the small green nodes are prospective employees. In this case, the colors differ based on the applicant’s level of English: brown is entry-level, orange is conversational, yellow is business, and gray is native. In FY 2018 and 2020, the yellow node (business level English skills) is generally located between two blue nodes. However, the yellow node moved from the blue node Kanto to the blue node Kansai in FY 2019. This shows a trend in FY 2019 such that there were more employees with business-level English skills in Kansai, but fewer applicants had the same skill in Kanto and Chubu. Further, the gray node moves dynamically because its degree is less than that of the other large nodes. We also observe an attribute with a small number of applicants, which is often ignored by quantitative analyses. This result is an example of trend observation via time-varying graph visualization.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. Example showing location of university versus self-declared English skill from FY 2018 to 2020.

https://doi.org/10.1371/journal.pone.0247587.g004

Example B. Major in university (liberal arts or sciences) versus job field

Fig 5 shows an example of integration with prior knowledge of HR specialists and the corresponding visualization. Traditionally, the selection process in most companies in Japan depends on the student’s future occupational class. Students majoring in social sciences, law, or humanities (referred to as liberal arts) will enter administrative jobs such as accounting, HR, personnel, sales, or purchasing. Students majoring in engineering or sciences (referred to as sciences) will enter technical jobs [4]. They are assigned a department after job training in a company for several months. Panasonic Corporation had employed applicants in administrative or technical jobs, mainly. Recently, Panasonic Corporation has started another recruitment policy where each department directly hires applicants. This example shows the transition of major in university versus job field from FY 2019 to 2020.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Example showing the transition of major in university versus job field from FY 2019 to 2020.

https://doi.org/10.1371/journal.pone.0247587.g005

Here, the two blue nodes are major in university (liberal arts or sciences). The highlighted orange node is the HR department. The blue node connected to the highlighted orange node in FY 2019 is the liberal arts node. This indicates that all new employees who were assigned to the HR department in FY 2019 majored in liberal arts. However, in FY 2020, the highlighted orange node moves to the middle of the two blue nodes (shown by the red arrow), which indicates that the HR department began to employ people who majored in sciences or engineering. Similarly, three nodes are shown between the two blue nodes (shown in the purple circle). These three job fields employed people who majored in either liberal arts or sciences. The number of orange nodes located between the two blue nodes indicates that an increasing number of job fields tends to employ applicants regardless of their university major. Note that this trend does not mean that university majors are not considered; rather, it indicates that diverse expertise is in demand in various job fields. These results show an example of observing the changes in recruitment policies for job fields.

Example C. Academic credential versus self-declared english skill

Fig 6 shows an example of the manual clustering of primary attributes. Here, the primary attribute is academic credential, and the secondary attribute is self-declared English skills. In the original data, the academic credential fields store five values: bachelor’s degree new graduate, bachelor’s previous graduate, master’s new graduate, master’s previous graduate, and doctoral graduate. This is because Japanese recruitment custom distinguishes applicants by degrees and graduation time. Fig 6A shows the initial layout with five primary attribute nodes (shown in blue) and four secondary attribute nodes (shown in red, orange, gray, and brown). Due to differences in the number of applicants in each primary attribute, relationships become difficult to interpret, which is a non-negligible burden for visual understanding.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Example showing academic credential versus self-declared English skill of prospective employees: (A) initial layout; (B) layout after manual clustering.

https://doi.org/10.1371/journal.pone.0247587.g006

Panacea allows the users to easily move the positions of the primary nodes. HR specialists move the position of the primary nodes to two distant locations in Fig 6B. This procedure is a kind of clustering because the two distant positions can be seen as two clusters, i.e., bachelor’s and master’s/doctoral, which emphasizes the difference between degrees by ignoring the difference between new or previous graduates. Here, the top cluster is bachelor’s, and the bottom cluster is master’s/doctoral. The gray node is a native speaker, and the yellow node is a business-level English speaker. As can be seen, most native and business-level speakers have the academic credentials of bachelor. This trend is not unexpected because most master’s/doctoral students are employed in technical jobs and most work in factories or research centers in Japan. In contrast, a large part of bachelor’s students are employed in administrative jobs, including international sales, purchasing, and HR. English skills are one of the criteria for assigning prospective employees to these positions. This example with the manual clustering function is more attractive for HR specialists. Users can also cluster graphs based on other criteria, e.g., whether applicants have already graduated. The proposed system can combine such empirical knowledge with data visualization.

Expert feedback

We invited three HR specialists (denoted T1, T2, and T3) from various positions in an HR department as testers to evaluate the proposed system. To mitigate bias, these HR specialists were not the same as those who participated in the previously discussed biweekly meetings. The user evaluation phase lasted an hour per person. We made a presentation (this lasted for 20 minutes) explaining how to use the proposed system, and then we watched how the users tested this system and interviewed the user (this lasted for 40 minutes). We observed that the users operated the system without special training. The questions we asked the users during the interview are as follows.

1. (Q1). How did you feel when you used the system? (General usability)
2. (Q2). Which part of the system was helpful for information discovery? (Visual design)
3. (Q3). Which part of the system did you find unfamiliar to use at first instance? (System usability)
4. (Q4). What additional features do you think could be integrated into the system to help with further knowledge discovery? (Additional data source)
5. (Q5). What did you discover using this system? (Knowledge discovery)

We summarized the testers’ responses as follows:

1. (A1). They had a good impression of the system because this kind of visualization was novel to them, and they could intuitively understand the relationship between attributes.
2. (A2). The graph view is the most important component because the topology and transition of the graph are displayed simultaneously, which helps them recognize trends.
3. (A3). What surprised the testers the most was that the primary nodes can move everywhere, although several testers did not recognize this function at first. With this function, the testers clustered primary attributes based on their criteria. For example, a university can be categorized by grade or location depending on what the tester wishes to observe. Thus, clustering nodes based on individual criteria attracted more interest than the provided layout.
4. (A4). After the user evaluation, the testers requested to import other data. For example, they would like to visualize the time-varying visualization on the snapshot of each day, which means the transition of the daily trend during a single recruitment period. The daily log must be stored in the database to track daily changes. However, such data are currently not stored in the database because it stores only finalized information. As a result, the testers realized that they must have a log tracking system during the recruitment period.
5. (A5). They all achieved knowledge discovery through the system, as described in several case studies in this section.

The testers noticed two issues with the attribute normalization. (1) Several job fields that shared similar names disappeared and appeared at the same time during the transition between two years. However, some of these appear to be artifacts. Indeed, the restructuring of the organization has occasionally led to changes in the names of several divisions. (2) Unnormalized data were stored in the database. Even in a snapshot of a specified year, the users observed several different words representing the same object in the internship history attribute. This issue is often referred to as “employer normalization” [55, 56], which requires effort to annotate the different name entities to be the same. This unexpected appearance of the graph also suggests room for improvement to highlight the disappearing or appearing nodes, as seen in TempoVis or GraphDiaries [42, 43]. Through the proposed system, unnormalized data could be detected via unexpected appearance in the graph layout.

We summarized the comments from each tester as follows. T1, who is a section manager in the recruitment branding team, appreciated the overview of two specified attributes, which mitigated their burden compared with the conventional use of spreadsheets or BI tools. T1 suggested that the system would be useful for continuous improvement of employment policies because the system could visualize trends from all available data. T2, who is a chief of the recruitment team for technical jobs, highlighted that the number of the edges corresponds to the correlation between two attributes, which provides clues on how to inspect these two attributes extensively. T3, who was assigned to the HR department only three months prior to the test, easily caught up with the latest recruitment trends. T3 highlighted that the dynamic visualization of time-varying graphs shows the volatility of each attribute, which contributes to recognizing changes in trends. These comments indicate that the system was widely accepted by the testers regardless of their expertise or position.

Limitations and future works

We demonstrated Panacea’s usability in a large Japanese company. The system can also be extended to other countries and other large companies with a closer number of prospective employees. However, there is still room for improvement for all applicants to be inspected. Note that applicants are selected and filtered out as the recruitment process proceeds. As a result, the database becomes sparse, which is more suitable for the graph structure than tables. Meanwhile, we need to explore the visualization technique for a larger number of applicants. Furthermore, we need to explore better shape and color of attribute nodes if the number of attributes increases. Nevertheless, the scalability of the pre-processing and backend system is maintained even for future visualization updates owing to graph databases and modeling.

The Panacea system has the potential to employ other visualization techniques. Applicant nodes are useful for understanding the number of applicants, but this is sometimes redundant and raises performance issues. One method for mitigating this is to remove applicant nodes and to connect attribute nodes directly. Since the proposed system supports multi-column attributes, removing applicant nodes makes visualization difficult. If the degree of applicant nodes is restricted to two, we can easily remove the node and connect adjacent nodes using a single edge. However, removing a node whose degree is greater than three generates a hypergraph [57] whose edge connects greater than two nodes. In fact, if there is an inflated array such as internship history with greater than two items, the graph becomes a hypergraph by definition. Although a hypergraph is the generalization of the graph used here, rendering a hypergraph is more complicated than the current method. Thus, we do not employ a hypergraph approach. Another method is to bundle the same edges by merging applicant nodes whose edges have the same destination, like Parallel Sets [26] or RadialNets [25]. However, both methods lose a simple interface to see each applicant’s information when users click each node. There is room for exploring more effective visualization.

We showed that HR specialists can find trends from 12 columns. The data model and pre-processing pipeline can convert all of the columns into a multi-partite graph. However, an efficient way of selecting two attributes from more than thousands of columns has not been implemented, and the efficient way to provide this remains unknown. For example, categorizing names of columns requires the HR expert’s prior knowledge or natural language processing. At the moment, we display only 12 columns by depending on HR specialists’ prudent choice in advance. We tried to add a visualization module for selecting the attributes, but however, we found that it would not be effective without any categorization by HR specialists in advance. We plan to explore an effective recommendation method to help HR specialists select columns.

We succeeded in observing a few years of trends in the case studies. Since we aimed to visualize a long-term range transition, we applied the animation method to visualize the entire duration. Unfortunately, HR specialists were unable to observe any drastic transition in the trends throughout the entire duration using the system. We suspect that there was hardly any drastic transition of employment trends in Panasonic Corporation probably because the economic growth in Japan was stable and thus the unemployment rate was kept low [58]. Further, we did not evaluate the recruitment policies during the research period because the recruitment period in Japan is limited to once per year. These concepts are reserved for future work in the field of HR management.

One potential application of interactive graph clustering would be in tackling the problem of name identification such as employer normalization. Previous studies have employed heuristic and machine learning methods with manual annotation, web resources, and business database [55, 56]. Still, continuous manual effort is required. Name variants decrease the analysis reliability; however, curation for normalizing such entities is often time-consuming. Since unexpected data can be found more easily with the visualization, we suggest that further research should be undertaken in an interactive name identification system using graph visualization.

The proposed graph model can be extended to other future applications. For example, bibliometric networks are used for showing the relationship between articles [59], often visualized as a node-link diagram [60]. In most tools, bibliometric networks are represented as a homozygous graph (nodes are publication, edges are the relationship between publication). However, the categories of publications like keywords or author’s affiliation can be represented as primary/secondary nodes. Still, this would require a more general framework to convert data into graphs. The Panacea system is potentially extensible for other types of data sources by implementing data conversion and visualization modules based on the Panacea graph model.