EntiTables: Smart Assistance for Entity-Focused Tables

Introduction

Tables are one of the most effective and widely used tools for organizing and working with data. Spreadsheet programs are among the most commonly used desktop applications, both in business environments and in personal use, because of their ease of use and flexibility. The overall objective of this study is to develop an intelligent personal assistant that can offer smart assistance for people working with tables. It may be imagined as the infamous Office Clippy, albeit we prefer it to be less obtrusive. This study represents the first step towards this ambitious endeavor.

The scenario we consider in this paper is the following. We assume a user, working with a table, at some intermediate stage in the process. At this point, she has already set the caption of the table and entered some data into the table. The table is assumed to have a column header (located above the first content row), which identifies each column with a unique label. We further narrow the focus of our study to tables with an entity focus. It means that the leftmost column of the table contains entities. This can also be imagined as having a designated row heading, which may contain only (unique) entities. An entity in the context of this work is a specific object with a unique identifier. (We shall show later in the paper, in §6.2, that a significant portion of tables have an entity focus.) Against this setting, our objective is to aid the user by offering “smart suggestions,” that is, recommending (i) additional entities (rows) and (ii) additional column headings, to be added to the table. We shall refer to these tasks as row population and column population, respectively. See Figure 1 for an illustration.

Let us point out here that some elements of these tasks have been addressed in prior work. Our work, however, has not only a different overall motivation, but the specific tasks we tackle have not been addressed in these flavors before. We also introduce a number of innovative elements on the component level.

The task of row population relates to the task of entity set expansion (Das Sarma et al. 2012; Bron et al. 2013; Metzger et al. 2014; He and Xin 2011; Wang and Cohen 2008; Wang et al. 2015), where a given set of seed entities (examples) is to be completed with additional entities. We also have a seed set of entities from the leftmost table column. But, in addition to that, we can also make use of the column heading labels and the caption of the table. We show in our experiments, that utilizing these can lead to substantial improvements over using only the seed entities.

The second task, column population, shares similarities with the problem of schema complement (Das Sarma et al. 2012; Lehmberg et al. 2015; Bhagavatula et al. 2013; Yakout et al. 2012), where a seed table is to be complemented with related tables that can provide additional columns. Many of these approaches utilize the full table content and also address the task of merging data into the seed table. Here, our focus is only on finding proper column headings, using the same sources as for row population (i.e., leftmost column, header row, and table caption). We show in our experiments that this task can be performed effectively.

In summary, this paper makes the following novel contributions:

We introduce and formalize two specific tasks for providing intelligent assistance with tables: row population and column population (§3).

We present generative probabilistic methods for both tasks, which combine existing approaches from the literature with novel components (§4 and §5).

We design evaluation methodology and develop a process that simulates a user through the process of populating a table with data (§6).

We perform an experimental evaluation and carry out a detailed analysis of performance (§7 and §8).

All resources developed within this study are made publicly available at http://bit.ly/sigir2017-table.

Related Work

There is a growing body of work on web tables and spreadsheets, addressing a range of tasks, including table extension, table completion, table search, table mining, etc. The task of row population is also related to the problem of entity set completion.

Extending a local table with additional columns based on the corpus of tables is a relatively new research area. The Mannheim Search Joins Engine (Lehmberg et al. 2015) operates on a corpus of web tables, searches for tabular data describing entities in the local table, and then picks relevant columns from the top-$k$ candidate tables to merge. With a focus on Wikipedia tables, Bhagavatula et al. 2013 target column-matched tables with the local table and perform correlation mining to find “interesting” numeric columns. InfoGather (Yakout et al. 2012) is a table augmentation framework based on topic sensitive PageRank for matching the local table against web tables. The context surrounding the tables is leveraged in a machine learning framework, where the similarity between two tables is captured via a set of features. Related tables can be utilized not only for column extension, but for row extension as well. Methods to detect related tables are proposed for the relatedness capture framework in (Das Sarma et al. 2012). Two types of table relatedness are identified: entity complement and schema complement. Entity complement tables can be united to produce a meaningful table, and schema complement tables can provide additional meaningful columns. Table completion refers to the task of filling missing values in a local table. Ahmadov et al. 2015 propose a hybrid data imputation approach, relying on the characteristics of missing values, in order to (i) look up missing values from web data, (ii) predict them using machine learning methods, or (iii) combine both to find the most appropriate values. To look up missing values, two keyword subqueries are created from the input table, to search entities and attributes separately. These resemble our row and column populating subtasks. However, Ahmadov et al. 2015 have a different target and merge the two search results for table selection.

There has been an increasing research interest in mining and searching table content, see, e.g., (Cafarella et al. 2008; Cafarella et al. 2011; Madhavan et al. 2009; Sarawagi and Chakrabarti 2014; Venetis et al. 2011; Zhang and Chakrabarti 2013). Wikipedia’s tables contain rich, semi-structured encyclopedic content that is hard to query. Muñoz et al. 2014 extract factual content from Wikipedia tables in the form of RDF triples, contributing to recovering table semantic and discovering table relations. Apart from the factual content extraction from web tables, table mining also covers tasks like table interpretation (Muñoz et al. 2014; Cafarella et al. 2008; Venetis et al. 2011) and table recognition (Zwicklbauer et al. 2013; Crestan and Pantel 2011).

Cafarella et al. 2008 extracted 14.1 billion HTML tables from a Google crawl, estimating that 154 million of them contain high-quality relational data. The relations extracted from these represent a valuable data resource. To disambiguate web tables, Zwicklbauer et al. 2013 propose a methodology to annotate table headers with semantic type information based on the column’s content. Similarly, Crestan and Pantel 2011 present a supervised framework for classifying HTML tables into their taxonomy. In addition to factual content and relations, numeric attributes are present in a vast number of web tables. However, web tables are not systematic and cannot be used, e.g., for aggregation. To improve the usability of quantities in heterogenous web tables, a line of work aims at detecting quantity mention (Dong et al. 2014; Madaan et al. 2016; Ibrahim et al. 2016; Roy et al. 2015; Sellam and Alonso 2015) and canonicalizing table quantities (Ibrahim et al. 2016; Bhagavatula et al. 2015; Limaye et al. 2010; Mulwad et al. 2013). Another line of work focuses on extracting and fusing numeric attribute values and numeric expressions in natural language text (Dong et al. 2014; Madaan et al. 2016; Roy et al. 2015; Sellam and Alonso 2015).

Tables could be well searched and mined for question answering or for extending knowledge bases. Yin et al. 2016 investigate the task of executing queries on knowledge base tables using Neural Enquirer, which is a fully neuralized DNNs model, both for query planning and for query execution. Sekhavat et al. 2014 describe a probabilistic method that augments an exiting knowledge base (YAGO). In (Wang et al. 2012), a table search engine is applied to further expand and enrich Probase, which is a universal probabilistic taxonomy framework capable of understanding the entities, attributes and values in web tables. Knowledge Vault is created as a probabilistic knowledge base (Dong et al. 2014) by analyzing the extracted content from tabular data, along with other web resources.

The problem of row population is related to the task of set completion or list expansion, which is to generate a ranked list of entities starting from a small set of seed entities (Das Sarma et al. 2012). Bron et al. 2013 propose an approach that combines structure-based and text-based similarity between a candidate entity and the seed entities. The QBEES framework (Metzger et al. 2014) is designed as an aspect-based entity model to find similar entities based on one or more example entities. He and Xin 2011 focus on entity list data, by picking the top-$k$ entities based on relevance between the candidate entity and seed entities, and then iteratively ranking them according to a combination of relevance and coherence. Similar iterative steps are conducted in (Wang et al. 2015; Wang and Cohen 2008). Wang and Cohen 2008 use a random walk method for ranking during iterations. Wang et al. 2015 focus on web tables, instead of entity lists, with the help of a web table search engine, called WTS.

Problem Statement

In this section, we provide a formal description of the tasks we propose to undertake. We refer to Table 1 for our notation.

A table $T$ is grid of cells, which hold values, arranged in $n+1$ rows and $m$ columns. The top row is a special designated place, where the column headings reside. It is followed by $n$ regular (content) rows. We let $L=(l_{1},\dots,l_{m})$ be the list of column heading labels. In addition to the grid content, the table also has a caption $c$.

A table is said to be entity-focused, if its leftmost column contains only entities as values, and those entities are unique within the column. We let $E=(e_{1},\dots,e_{n})$ be the list of entities corresponding to the leftmost table column. I.e., the table takes the following shape:

where $v_{i,j}$ ($i\in[1..n],j\in[2..m]$) denote the cell values.

Our objective is to provide intelligent assistance for an user who is working on an entity-focused table. We shall refer to the table that is being edited by the user as seed table. We assume that the seed table has already been given a caption, and contains some heading labels (seed labels) in the top row and some entities (seed entities) in the leftmost column. Note that we do not make any assumptions about the values in the other table cells. Essentially, the $v_{i,j}$ values are immaterial, therefore, we omit them in the followings. We note that the $v_{i,j}$ values may also be utilized for row/column population. However, this is left for future work. When we talk about a table containing entity $e$, we always mean the leftmost table column.

Our goal is to present suggestions for the user for extending the seed table with (i) additional entities, and (ii) additional column heading labels. Both tasks are approached as a ranking problem: given a seed table, generate a ranked list of entities (for row population) or column labels (for column population).

Row population is the task of generating a ranked list of entities to be added to the leftmost column of a given seed table, as $e_{n+1}$.

Column population is the task of generating a ranked list of column labels to be added to the column headings of a given seed table, as $l_{m+1}$.

In the following two sections, we present our approaches for row and column population. Following prior studies (Lehmberg et al. 2015; Bhagavatula et al. 2013; Yakout et al. 2012; Ahmadov et al. 2015; Das Sarma et al. 2012; Yin et al. 2016; Cafarella et al. 2008; Venetis et al. 2011; Crestan and Pantel 2011; Sekhavat et al. 2014; Wang et al. 2012; Wang et al. 2015; Bhagavatula et al. 2015), we rely heavily on the availability of a large table corpus as an external resource (which, in our case, is extracted from Wikipedia). Additionally, we also exploit information stored about entities in a knowledge base (in our case, DBpedia). Further specifics about our data sources are provided in §6.1.

Populating Rows

In this section, we address problem of row population using a two-step approach. We assume that a seed table is given, with a list of $n$ seed entities $E$, a list of $m$ seed column labels $L$, and a table caption $c$. The task is to generate a ranked list of suggestions for entity $e_{n+1}$, which may be added to the seed table as a new row. First, we identify a set of candidate entities (§4.1), and then rank them in a subsequent entity ranking step (§4.2).

We identify candidate entities using two sources: knowledge base (KB) and table corpus (TC). In the knowledge base, each entity $e$ is described by a set of properties $\mathcal{P}_{e}$. We focus on two specific properties: types and categories. We discuss these notions in the context of DBpedia, but note that all knowledge bases employ some taxonomy of types. Types in DBpedia are assigned from a small ontology (the DBpedia Ontology, containing a few hundred classes). Categories originate from Wikipedia; these do not form a strict is-a hierarchy, and may be seen more like “semantic sets.” Categories are in the order of several 100K. Intuitively, an entity $e$ that has several types or categories overlapping with those of the seed entities represents a good candidate. Thus, we rank entities based on the overlap of these properties, and then take the top-$k$ ones as the set of candidates:

When using the table corpus, we search for tables that contain the seed entities or have a similar caption to that of the seed table. This can be efficiently performed using existing retrieval methods against an inverted index of tables. Specifically, we use either the seed table’s caption or seed entities as the search query and rank tables using the BM25 retrieval algorithm.

2. Ranking Entities

We introduce a probabilistic formulation and rank candidate entities according to the multi-conditional probability $P(e|E,L,c)$. By applying Bayes’s theorem and making a full independence assumption between table caption, seed entities, and seed column labels, we factor this probability as follows:

In the last step, we rewrote $P(E|e)$ using Bayes’ rule (which cancelled out $P(e)$ and $P(E)$). We further dropped the probabilities $P(L)$ and $P(c)$ from the denominator, since those are the same across all candidate entities and thus do not influence their ranking. Then, entities are ranked by multiplying (i) the posteriori probability $P(e|E)$ that expresses entity similarity, (ii) the column labels likelihood $P(L|e)$, and (iii) the caption likelihood $P(c|e)$. The reason for keeping the latter two probabilities conditioned on the candidate entity is that column labels and captions are very short. In those cases, the candidate entity offers a richer observation. Below, we discuss the estimation of each of these probabilities.

Note that entities may be ranked using any subset of the components in Eq. (1). We explore all possible combinations in our experimental section (§7). It is our expectation that using all three sources of evidence (seed entities, seed column labels, and table caption) would result in the best performance.

3. Entity Similarity

The estimation of $P(e|E)$ corresponds to the task of entity list completion (also known as set/concept expansion or query by example): given a small set of seed entities, complement this set with additional entities. The general idea is to measure the semantic similarity between the candidate entity and the set of seed entities. One line of prior work (Bron et al. 2013; Metzger et al. 2014) relies on a knowledge base for establishing this semantic similarity. Another family of approaches (Das Sarma et al. 2012; Wang and Cohen 2008; Wang et al. 2015) leverages a large table corpus for collecting co-occurrence statistics. We combine both these sources in a single model:

where $P_{KB}$ is based on the knowledge base and $P_{TC}$ is the estimate based on the table corpus.

Bron et al. 2013 create a structured entity representation for each entity from the RDF triples describing that entity. The structured representation of an entity is comprised by the set of relations of the entity. Each relation $r$ is modeled as a pair, by removing the entity itself from the triples. E.g., given the triple $\langle$dbr:Japan, dbo:capital, dbr:Tokyo$\rangle$ describing the entity Japan, the corresponding relation becomes $($dbo:capital, dbr:Tokyo$)$. We write $\hat{e}$ to denote the structured representation of entity $e$. Formally, given a set of subject-predicate-object $(s,p,o)$ triples describing the entity (i.e., the entity stands either as subject or object):

Similarly, each seed entity is represented as a set of pairs: $\hat{e}_{1},\dots,\hat{e}_{n}$. The set of seed entities is modeled as a multinomial probability distribution $\theta_{E}$ over the set of relations. The probability $P(e|E)$ is then obtained by considering all relations that appear in the representation of the candidate entity:

Instead of using a single model built for the set of seed entities, we also explore an alternative approach by taking the average pairwise similarity between the candidate and seed entities (similar in spirit to (He and Xin 2011; Das Sarma et al. 2012)):

where $\mathcal{L}_{e}$ is the set of outgoing links of $e$ (i.e., entities $e$ links to) and $|\mathcal{E}|$ is the total number of entities in the knowledge base. The second similarity function is the Jaccard coefficient, based on the overlap between the outgoing links of entities:

3.2. Estimation Using a Table Corpus

Another way of establishing the similarity between a candidate entity $e$ and the set of seed entities $E$ is to obtain co-occurrence statistics from a table corpus (as in (Das Sarma et al. 2012; Ahmadov et al. 2015)). We employ a maximum likelihood estimator:

where $\#(e,E)$ is the number of tables that contain the candidate entity together with all seed entities, and $\#(E)$ is the number of tables that contain all seed entities. Provided that the table corpus is sufficiently large, we expect this simple method to provide an accurate estimate.

4. Column Labels Likelihood

For computing $P(L|e)$, we consider the tables from the table corpus where the entity appears in the leftmost column. We obtain and combine two different estimates. The first one is the representation of the entity in terms of the words of the column labels, i.e., an unigram language model (LM). The second one is a maximum likelihood estimate using exact label matching (EM), i.e., without breaking labels up to words. We consider each individual label $l$ from the seed column labels and combine the above two estimates using a linear mixture:

The first component is a Dirichlet-smoothed unigram language model, calculated using:

where $tf(t,e)$ is the total term frequency of $t$ in column heading labels of the tables that include $e$ in their leftmost column. One may think of it as concatenating all the column heading labels of the tables that include $e$, and then counting how many times $t$ appears in there. The length of the entity $|e|$ is the sum of all term frequencies for the entity ($|e|=\sum_{t^{\prime}}tf(t^{\prime},e)$). The background language model $P(t|\theta)$ is built from the column heading labels of all tables in the corpus.

The exact label matching probability is estimated using:

where $\#(l,e)$ is the number of tables containing both $e$ and $l$, and $\#(e)$ is the total number of tables containing $e$.

5. Caption Likelihood

To estimate the caption likelihood given an entity, $P(c|e)$, we combine two different term-based entity representations: one from the knowledge base and one from the table corpus. Formally:

The knowledge base entity representation is an unigram language model constructed from the entity’s description (specifically, its abstract in DBpedia). Smoothing is done analogously to the column labels language model, but the components of the formula are computed differently:

where $tf(t,e)$ denotes the (raw) term frequency of $t$ in the entity’s description, $|e|$ is the length (number of terms) of that description, and $P(t|\theta)$ is a background language model (a maximum likelihood estimate from the descriptions of all entities in the KB).

To construct a term-based representation from the table corpus, we consider the captions of all tables that include entity $e$:

where $\#(t,e)$ denotes the number of tables that contain term $t$ in the caption as well as entity $e$ in the leftmost column. The denominator $\#(e)$ is the total number of tables containing $e$. We also experimented with constructing a smoothed language model, similar to how it was done for the KB, but that gave inferior results.

Populating Columns

In this section, we address the problem of column population using a two-step approach: we identify a set of candidate column heading labels (or labels, for short), and then subsequently rank them.

We use (i) the table caption, (ii) table entities, and (iii) seed column heading labels to search for similar tables. The searching method is the same as in §4.1, i.e., we use BM25 similarity using either of (i)–(iii) to get a ranking of tables from the table corpus. From these tables, we extract the column heading labels as candidates (excluding the seed column labels). When searching is done using the seed column labels as query, our method is equivalent to the FastJoin matcher (Wang et al. 2014) (which was also adopted in (Lehmberg et al. 2015)).

2. Ranking Column Labels

We are interested in estimating the probability $P(l|E,c,L)$, given $j$ seed labels, the table caption, and a set of entities from the rows.

Das Sarma et al. 2012 consider the “benefits” of additional columns. The benefit of adding $l$ to table $T$ is estimated as follows:

where $L$ denotes column labels and $cs$ is the AcsDB (Cafarella et al. 2008) (Attribute Correlation Statistics Database) schema frequency statistics, which is given in Eq. (4). It is more effective to derive the benefit measure by considering the co-occurrence of pairs of labels, rather than the entire set of labels (Das Sarma et al. 2012). Eq. (4) determines the consistency of adding a new label $l_{2}$ to an existing label $l_{1}$:

where $\#(l_{1},l_{2})$ is number of tables containing both $l_{1}$ and $l_{2}$, and $\#(l_{1})$ is the number of tables containing $l_{1}$.

2.2. Our Approach

Instead of estimating this probability directly, we use tables as a bridge. We search related tables sharing similar caption, labels, or entities with the seed table. Searching tables with only one aspect similarity is thought as a single method, e.g., searching tables with similar caption has the probability of $P(T|c)$. All these related tables are candidate tables acting as bridges. Each candidate table is weighted by considering its relevance with each candidate label, denoted as $P(l|T)$.

By applying the law of total probability, we get:

where $P(l|T)$ is the label’s likelihood given a candidate table (see §5.3), and $P(T|E,c,L)$ expresses that table’s relevance (see §5.4).

3. Label Likelihood

Label likelihood, $P(l|T)$, may be seen as the importance of label $l$ in a given table $T$. The simplest way of setting this probability is uniformly across the labels of the table:

4. Table Relevance Estimation

Table relevance expresses the degree of similarity between a candidate table and the seed table the user is working with. Tables with higher relevance are preferred. Specifically, we search for tables by considering the similarity of the set of entities, table caption, and column labels. The probability of a candidate table is factored as:

Notice that an independence assumption between $E$, $c$, and $L^{(j)}$ was made. Further, assuming that the prior probability of a table follows a uniform distribution, the denominator can be dropped. The components of this model are detailed below.

When selecting a candidate table, the coverage of the tables’ entity set is a important factor (Das Sarma et al. 2012; Ahmadov et al. 2015). We compute the fraction of the seed table’s entities covered by candidate table as:

We note that the same concept is used in (Das Sarma et al. 2012), where it is referred to as entity coverage.

4.2. Caption Likelihood

Having similar captions is a strong indicator that two tables are likely to have similar contents. An effective way of calculating caption similarity is to use the seed table’s caption as a query against a caption index of the table corpus. We can use any term-based retrieval model (like BM25 or language modeling) for measuring caption similarity:

4.3. Column Labels Likelihood

Finally, we estimate the column labels likelihood similar to Lehmberg et al. 2015, who rank tables according to the number of overlapping labels:

Experimental design

We present the data sets we use in our experiments and our evaluation methodology. We develop an approach that simulates a user through the process of populating a seed table with data.

We use the WikiTables corpus (Bhagavatula et al. 2015), which contains 1.6M tables extracted from Wikipedia. The knowledge base we use is DBpedia (version 2015-10). We restrict ourselves to entities which have an abstract (4.6M in total).

We preprocess the tables as follows. For each cell that contains a hyperlink we check if it points to an entity that is present in DBpedia. If yes, we use the DBpedia identifier of the linked entity as the cell’s content (with redirects resolved); otherwise, we replace the link with the anchor text (i.e., treat it as a string).

2. Entity-Focused Tables

Recall that we defined an entity-focused table as one that contains only unique entities in its leftmost column (cf. §3). In addition to being an entity-focused table, we require that the table has at least 6 rows and at least additional 3 columns (excluding the entity column). We introduce these constraints so that we can simulate a real-world scenario with sufficient amount of content.

In Table 2, we report statistics based on what percentage of cells in the leftmost column contains entities. Let us note here that only those entities are recognized that have a corresponding Wikipedia article. Thus, the reported numbers should be treated as lower bound estimates. It is clear that many tables have an entity focus.

To be able to perform an automated evaluation without any human intervention, we apply the most strict conditions. Out of the tables that contain 100% unique entities in their leftmost column and have at least 6 rows and at least 4 columns (53 K in total), see Table 2, we randomly select 1000 tables as our validation set (used for parameter tuning) and another 1000 tables as our test set. We use a different random selection of validation/test tables for row and column population. The validation and test sets are excluded from the table corpus during training. It is important to note that we use all other tables from the corpus when computing statistics, and not only those that classify as entity-focused.

3. Simulation Process

We evaluate row/column population by starting from an actual (complete) entity-focused table, with $n$ content rows (with an entity in each) and $m$ column headings. We simulate an user through the process of completing that table by starting with some seed rows/columns and iteratively adding one row/column at a time.

For evaluating row population, we take entities from the first $i$ rows ($i\in[1..5]$) as seed entities $E$, and use the entities from the remaining rows as ground truth, $\hat{E}$. We use all column heading labels.

For evaluating column population, we take labels from the first $j$ column ($j\in[1..3]$) as seed column labels $L$, and use the labels from the remaining columns as ground truth, $\hat{L}$. We use all entities from the table’s rows.

See Figure 2 for an illustration. Notice that we are expanding in a single dimensions at a time; populating both rows and columns at the same time is left for future work.

4. Matching Column Labels

For the column population task, we are matching string labels (as opposed to unique identifiers). Let us consider Date as the ground truth column label. When the suggested labels are compared against this using strict string matching, then date, Dates, date:, etc. would not be accepted as correct, despite being semantically identical. Therefore, we apply some simple normalization steps, on both the ranked and ground truth column labels, before comparing them using strict string matching. When multiple ranked labels are normalized to the same form, only the one with the highest score is retained.

5. Evaluation Metrics

Given that the relevance judgments are binary, we use Mean Average Precision (MAP) as our main evaluation metric. In addition, we also report on Mean Reciprocal Rank (MRR). We measure statistical significance using a two-tailed paired t-test. To avoid cluttering the discussion, we report significance testing only for our main metric.

Evaluation of Row Population

This section presents the evaluation of row population.

In §4.1, we have introduced four individual methods to select candidates: entity category (A1) and entity type (A2) from the knowledge base, and table caption (B) and table entities (C) from the table corpus. These methods involve a cut-off threshold parameter $k$; the top-$k$ entities are considered as candidates for the subsequent ranking step. A larger $k$ value typically implies higher recall. At the same time, each of the candidate entities will need to be scored, which is a computationally expensive operation. Therefore, we wish to find a setting that ensures high recall, while keeping the number of candidate entities manageably low (to ensure reasonable response time). We use the validation set to explore a range of $k$ values: $2^{6}$, $2^{8}$, $2^{10}$, and $2^{12}$. For each method, we select the $k$ value that produces the best recall and candidate entity number ratio.

The results are reported in the top block of Table 3. We observe that more seed entities we have, the better recall gets. This is expected behavior. Out of the two entity properties from the knowledge base, categories and types, categories performs far better. For types, even with $k=4096$, the recall is still unsatisfactory. This is because many of the DBpedia entities have no ontology type information assigned to them. Moreover, ontology types are more general than categories and result in too many candidates. The best individual method is (C) table entities; it is the most effective (achieves the highest recall) and the most efficient (produces the lowest number of candidates) at the same time.

To further enhance performance, we combine the individual methods. However, we exclude type (A2) from this combination, because of its low performance. We find that all combinations improve over the single methods. This means that they capture complimentary aspects. Combining all three methods (A1+B+C) leads to the best overall performance. The last two lines of Table 3 show the performance of this combination (A1+B+C) using two different $k$ values. We find that with a high $k$ value (4096), we are able to achieve close to perfect recall. The number of candidates, however, is a magnitude larger than with a low $k$ (256). Motivated by efficiency considerations, we decided not to pay this price and chose to use $k=256$, which still gives us very high recall.

2. Entity Ranking

Our entity ranking model is comprised of three components: entity similarity ($P(e|E)$), column labels likelihood ($P(L|e)$), and caption likelihood ($P(c|e)$). Each of these methods involve an interpolation parameter ($\lambda_{E}$, $\lambda_{L}$, and $\lambda_{c}$, respectively). We train these parameters on the validation set, by performing a sweep in $0.1$ steps over the $[0..1]$ range. The effect of varying the parameter values is shown in Figure 3. It can be seen that the value $0.5$ provides the best setting everywhere. We also found that there is very little difference in terms of performance when $\lambda$ is in the $0.3..0.7$ range (hence the choice of showing the $0.1$ and $0.9$ values on the plots).

We start by discussing the performance of individual components, reported in the top block of Table 4. The two-component entity similarity model combines estimated based on the knowledge base and the table corpus (cf. Eq. (2)). For the former, we compare three alternatives: using relations of entities, as in (Bron et al. 2013) (A1), and two similarity methods based on outgoing links of entities: WLM (A2), and Jaccard similarity (A3). Out of the three methods, (A1) Relations has the best performance. However, (A3) has only marginally lower retrieval performance, while being computationally much more efficient. Therefore, we choose (A3), when it comes to combining it with the other elements of the entity ranking model. Compared to entity similarity ($P(e|E)$), the other two components (B and C) have much lower performance. The differences (A3) vs. (B) and (A3) vs. (C) are highly significant ($p<10^{-5}$). This means that the knowledge base contributes more.

Next, we combine the individual components to further enhance performance. The middle block of Table 4 reports results when two components are used. We find that these combinations improve significantly over the individual methods in all cases ($p<10^{-5}$). It is interesting to note that while (C) caption likelihood outperforms (B) column labels likelihood in the individual comparison (significantly so for $\#1..\#3$ seed entities, $p<0.001$), the two perform on a par when combined with (A3) entity similarity.

As expected, using all three component (A3 & B & C) results in the best performance. The differences between this vs. (A3 & C) and vs. (B & C) are significant for any number of seed entities ($p<0.001$); regarding (A3 & B & C) vs. (A3 & B), the differences are significant only for seed entities $\#1$ and $\#5$ ($p<0.05$). This means that combining information from the knowledge base with column labels from the table corpus yields significant benefits; considering the captions of tables on top of that leads to little additional gain.

For baseline comparison, we employ the method by (Bron et al. 2013), which combines text-based and structure-based similarity. Note that we used only the structure-based part of their method earlier, as (A1); here, we use their approach in its entirety. It requires a keyword query, which we set to be the table caption. We find that our methods substantially and significantly ($p<10^{-5}$) outperforms this baseline; see the bottom two rows in Table 4.

One final observation is that performance climbs when moving from a single to two and three seed entities; after that, however, it plateaus. This behavior is consistent across all methods, including the baseline. The phenomena is known from prior work (Bron et al. 2013; Metzger et al. 2014; Pantel et al. 2009).

3. Analysis

Now that we have presented our overall results, we perform further examination on the level of individual tables. Figure 4 shows the average precision (AP) scores for the 1000 test tables, ordered by decreasing score. Statistically, there are 285 tables having $AP=1$, 193 tables having $0.4<AP<0.6$, and 42 tables having $AP=0$. To understand the reasons behind this, we check the recall of the candidate selection step for these three categories; see Figure 5. In this figure, we can observe that higher recall generally leads to better AP. Delving deeper, we compute the average number of tables containing at least one ground truth entity, for each of the three groups. When $AP=0$, the number is $18$, for $0.4<AP<0.6$ it is $79$, and for $AP=1$ it is $127$. It appears that we could provide excellent suggestions, when there were enough similar tables to the seed table in the table corpus. However, for tables that are “too unique,” we would need alternative methods for suggestions.

Evaluation of Column Population

This section presents the evaluation of column population. This task relies only on the table corpus; the data set is exactly the same as for row population, see §6.1.

In §5.1, we have introduced three individual methods to select candidates: table caption (A), column heading labels (B) and table entities (C). Method (B) actually corresponds to the FastJoin matcher in (Wang et al. 2014). These methods also involve a cut-off threshold parameter $k$, for the same reasons we already discussed in §7.1. The results are reported in the top block of Table 5. We observe that the more seed labels we have the better recall gets when using labels. We also explore combinations of pairs of methods as well as using all three. We find that all combinations improve over the single methods, and that combining all three methods leads to the best overall performance. Our selected method is the second to last in Table 5, motivated by efficiency considerations; for comparison, we also show the performance for $k=4096$.

2. Column Label Ranking

Our column label ranking model is comprised of two components: table relevance and label likelihood. For estimating candidate table relevance, we have three individual methods, using table caption (A), column labels (B), and table entities (C). All methods use the same estimation of label likelihood (cf. §5.3).

We start by discussing the performance of individual methods, which is reported in the top block of Table 6. Of the three, method (C) outperforms the other two, and does significantly so ($p<10^{-5}$). Looking at the tendency of MAP, the increasing number of seed column labels only contributes to method (B). When combining two of the methods, all combinations improve significantly over the individual methods ($p<10^{-5}$). Out of the three, (B) & (C) performs best in terms of both $MAP$ and $MRR$. In the end, putting together all three individual methods delivers the best results. Also, this combination (A & B & C) improves significantly over the combination of any two of the methods ($p<10^{-5}$).

For baseline comparison, we employ the method by Das Sarma et al. 2012. They consider the “benefits” of adding additional columns, which expressed in Eq. (3). We find that our three-component method substantially and significantly ($p<10^{-5}$) outperforms this baseline. It should be noted that the baseline in (Das Sarma et al. 2012) uses our candidate selection method to make it comparable; this actually performs better than their original approach.

3. Analysis

Figure 6 plots the performance of individual (test) tables, in decreasing order of average precision score. We find that there are 427 tables having $AP=1$, 122 tables having $0.4<AP<0.6$, and 186 tables having $AP=0$. We examine these three table groups, based on performance, in terms of their corresponding recall values from the candidate selection step. Figure 7 shows these values (averaged over all tables that fall in the given performance group). Looking at the number of tables containing at least one ground truth column heading label, it is 204 for $AP=0$, 403 for $0.4<AP<0.6$, and 1114 for $AP=1$. We can draw similar conclusions here as we did for entity ranking.

Conclusion

In this paper, we have introduced the idea of a smart table assistant and have taken the first steps towards its realization. Specifically, we have concentrated on tables with an entity focus, and investigated the tasks of row population and column population. We have devised methods for each task and showed experimentally how the different components all contribute to overall performance. For evaluation, we have developed a process that simulates a user through her work of populating a table with data. Our overall results are very promising and substantially outperform existing baselines.

In future work, we plan to extend the capabilities of our assistant to be able to populate data cells as well with values. Further along the road, we also wish to relax our requirement regarding the entity focus, and make our methods applicable to arbitrary tables.

References