Introduction
Table is a special and valuable information that could be found almost everywhere from the Internet. We target at the task of content-based table retrieval in this work. Given a query, the task is to find the most relevant table from a collection of tables. Table retrieval is of great importance for both natural language processing and information retrieval. On one hand, it could improve existing information retrieval systems. The well-organized information from table, such as product comparison from different aspects and flights between two specific cities, could be used to directly respond to web queries. On the other hand, the retrieved table could be used as the input for question answering BIBREF0 .
Unlike existing studies in database community BIBREF1 , BIBREF2 that utilize surrounding text of a table or pagerank score of a web page, we focus on making a thorough exploration of table content in this work. We believe that content-based table retrieval has the following challenges. The first challenge is how to effectively represent a table, which is semi-structured and includes many aspects such as headers, cells and caption. The second challenge is how to build a robust model that measures the relevance between an unstructured natural language query and a semi-structured table. Table retrieval could be viewed as a multi-modal task because the query and the table are of different forms. Moreover, to the best of our knowledge, there is no publicly available dataset for table retrieval. Further progress towards improving this area requires richer training and evaluation resources.
To address the aforementioned challenges, we develop a ranking based approach. We separate the approach into two cascaded steps to trade-off between accuracy and efficiency. In the first step, it finds a small set (e.g. 50 or 100) of candidate tables using a basic similarity measurement. In the second step, more sophisticated features are used to measure the relevance between the query and each candidate table. We implement two types of features, including manually designed features inspired by expert knowledge and neural network models jointly learned from data. Both strategies take into account the relevance between query and table at different levels of granularity. We also introduce a new dataset WebQueryTable for table retrieval. It includes 21,113 web queries from search log, and 273,816 web tables from Wikipedia.
We conduct comprehensive experiments on two datasets, a real world dataset introduced by us, and a synthetic dataset WikiTableQuestions BIBREF0 which has been widely used for table-based question answering. Results in various conditions show that neural network models perform comparably with carefully designed features, and combining them both could obtain further improvement. We study the influence of each aspect of table for table retrieval, and show what depth of table understanding is required to do well on this task. Results show the difference between question and web query, and present future challenges for this task.
This paper has the following contributions. We develop both feature-based and neural network based approaches, and conduct thorough experiments on real world and synthetic datasets. We release an open-domain dataset for table retrieval.
Task Definition
We formulate the task of table retrieval in this section. Given a query $q$ and a collection of tables $T=\lbrace t_1, ..., t_N\rbrace $ , the goal of table search is to find a table $t_i$ that is most relevant to $q$ .
Typically, a query $q$ is a natural language expression that consists of a list of words, such as “major cities of netherlands”. A table $t$ is a set of data elements arranged by vertical columns and horizontal rows. Formally, we define a table as a triple $t=\lbrace headers,\ cells,\ caption\rbrace $ that consists of three aspects. A table could have multiple $headers$ , each of which indicates the property of a column and could be used to identify a column. A table could have multiple $cells$ , each of which is a unit where a row and a column intersects. A table could have a $caption$ , which is typically an explanatory text about the table. Figure 1 gives an example to illustrate different aspects of a table.
It is helpful to note that tables from the web are not always “regular”. We regard a table as a “regular” table if it contains header, cell and caption, and the number of cells in each row is equal to the number of header cells. In this work, we make a comprehensive study of table retrieval on regular tables, and would like to release benchmark datasets of good quality. It is trivial to implement heuristic rules so as to convert the irregular tables to regular one, so we leave it to the future work.
Approach Overview
In this section, we give an overview of the proposed approach. To build a system with high efficiency, we separate the task into two cascaded modules, including candidate table retrieval and table ranking. Candidate table retrieval aims to find a small set of tables, such as 50 or 100. These candidate tables will be further used in the table ranking step, which uses more sophisticated features to measure the relevance between a query and a table. In the following subsections, we will give the work-flow of candidate table retrieval and table ranking. The detailed feature representation will be described in the next section.
Candidate Table Retrieval
Candidate table retrieval aims to get a small candidate table set from the whole table set of large scale, which is hundreds of thousands in our experiment. In order to guarantee the efficiency of the searching process, we calculate the similarity between table and query with Okapi BM25 BIBREF3 , which is computationally efficient and has been successfully used in information retrieval. Specifically, we represent a query as bag-of-words, and represent table with plain text composed by the words from caption and headers. Given a query $q = {x_1, x_2, ..., x_n}$ , a table $t$ and the whole table set $T$ , the BM25 score of query $q$ and table $t$ is calculated as follows.
$$BM25(q, t) \\ = \sum _{i=1}^{n} idf(x_{i}) \frac{tf(x_{i}, t) \cdot (k_1+1)}{tf(x_{i}, T) + k_1 (1-b+b \frac{|t|}{avg_{tl}})} \nonumber $$   (Eq. 4)
where $tf(x_{i}, t)$ is the term frequency of word $x_i$ in $t$ , $idf(x_i)$ is its inverse document frequency, $avg_{tl}$ is the average sequence length in the whole table set $T$ , and $k_1$ and $b$ are hyper-parameters.
Table Ranking
The goal of table ranking is to rank a short list of candidate tables by measuring the relevance between a query and a table. We develop a feature-based approach and a neural network approach, both of them effectively take into account the structure of table. The details about the features will be described in next section. We use each feature to calculate a relevance score, representing the similarity between a query and a table from some perspective. Afterwards, we use LambdaMART BIBREF4 , a successful algorithm for solving real world ranking problem, to get the final ranking score of each table. The basic idea of LambdaMART is that it constructs a forest of decision trees, and its output is a linear combination of the results of decision trees. Each binary branch in a decision tree specifies a threshold to apply to a single feature, and each leaf node is real value. Specifically, for a forest of $N$ trees, the relevance score of a query-table pair is calculated as follow,
$$s(q,t) = \sum _{i=1}^{N} w_i tr_i(q,t) \nonumber $$   (Eq. 7)
where $w_i$ is the weight associated with the $i$ -th regression tree, and $tr_i( \cdot )$ is the value of a leaf node obtained by evaluating $i$ -th tree with features $\left[ f_1(q,t), ... ,f_K(q,t) \right]$ . The values of $w_i$ and the parameters in $tr_i(\cdot )$ are learned with gradient descent during training.
Matching between Query and Table
Measuring the relevance between a query and a table is of great importance for table retrieval. In this section, we present carefully designed features and neural network architectures for matching between a query and a table.
Matching with Designed Features
We carefully design a set of features to match query and table from word-level, phrase-level and sentence-level, respectively. The input of a feature function are two strings, one query string $q$ and one aspect string $t_a$ . We separately apply each of the following features to each aspect of a table, resulting in a list of feature scores. As described in Section 2, a table has three aspects, including headers, cells and caption. We represent each aspect as word sequence in this part.
(1) Word Level. We design two word matching features $f_{wmt}$ and $f_{mwq}$ . The intuition is that a query is similar to an aspect of table if they have a large amount of word overlap. $f_{wmt}$ and $f_{wmq}$ are calculated based on number of words shared by $q$ and $t_a$ . They are also normalized with the length of $q$ and $t_a$ , calculated as follows,
$$f_{wmt}(t_{a}, q)&=\frac{\sum _{w \in t_{a}} \delta (w, q) \cdot idf(w)}{\sum _{w^{\prime } \in t_{a}} idf(w^{\prime })} \nonumber \\ f_{wmq}(t_{a}, q)&=\frac{\sum _{w \in t_{a}} \delta (w, q) \cdot idf(w)}{\sum _{w^{\prime } \in q} idf(w^{\prime })} \nonumber $$   (Eq. 9)
where $idf(w)$ denotes the inverse document frequency of word $w$ in $t_{a}$ . $\delta (y_j, q)$ is an indicator function which is equal to 1 if $y_j$ occurs in $q$ , and 0 otherwise. Larger values of $f_{wmt}(\cdot )$ and $f_{wmq}(\cdot )$ correspond to larger amount of word overlap between $t_a$ and $q$ .
(2) Phrase Level. We design a paraphrase-based feature $f_{pp}$ to deal with the case that a query and a table use different expressions to describe the same meaning. In order to learn a strong and domain-independent paraphrase model, we leverage existing statistical machine translation (SMT) phrase tables. A phrase table is defined as a quadruple, namely $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $ , where $src_i$ (or $trg_i$ ) denotes a phrase, in source (or target) language, $p(trg_i|src_i)$ (or $p(src_i|trg_i)$ ) denotes the translation probability from $srg_i$ (or $trg_i$ ) to $trg_i$ (or $src_i$ ). We use an existing SMT approach BIBREF5 to extract a phrase table $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $0 from a bilingual corpus. Afterwards, we use $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $1 to calculate the relevance between a query and a table in paraphrase level. The intuition is that, two source phrases that are aligned to the same target phrase tend to be paraphrased. The phrase level score is calculated as follows, where $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $2 is the maximum n-gram order, which is set as 3, and $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $3 and $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $4 are the phrase in $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $5 and $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $6 starts from the $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $7 -th and $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $8 -th word with the length of $PT = \lbrace  \langle src_i,trg_i, p(trg_i|src_i), p(src_i|trg_i) \rangle \rbrace $9 , and $src_i$0 and $src_i$1 .
$$f_{pp}(t_{a},q)= \frac{1}{N}\sum _{n=1}^N \frac{\sum _{i,j} score(src_{i,n}^{t_q}, src_{j,n}^{q})}{|t_a|-N+1} \nonumber \\ score(src_x;src_y)=\sum _{PT}p(tgt_k|src_x) \cdot p(src_y|tgt_k) \nonumber $$   (Eq. 10)
(3) Sentence Level. We design features to match a query with a table at the sentence level. We use CDSSM BIBREF6 , which has been successfully applied in text retrieval. The basic computational component of CDSSM is sub-word, which makes it very suitable for dealing the misspelling queries in web search. The model composes sentence vector from sub-word embedding via convolutional neural network. We use the same model architecture to get query vector and table aspect vector, and calculate their relevance with cosine function.
$$f_{s1}(t_a, q)=cosine(cdssm(t_a), cdssm(q)) \nonumber $$   (Eq. 11)
We train model parameters on WikiAnswers dataset BIBREF7 , which contains almost 12M question-similar question pairs. In addition, since vector average is an intuitive way to compute sentence vector and does not induce additional parameters, we calculate another relevance score by representing a query and a table aspect with element-wise vector average. We use a publicly available word embedding which is released by mikolov2013w2v.
$$f_{s2}(t_a, q)=cosine(vec\_avg(t_a), vec\_avg(q)) \nonumber $$   (Eq. 12)
Matching with Neural Networks
We present neural network models for matching a query with a table. As a table includes different aspects such as headers, cells and caption, we develop different strategies to measure the relevance between a query and a table from different perspectives. In this subsection, we first describe the model to compute query representation, and then present the method that measures the relevance between a query and each aspect.
A desirable query representation should be sensitive to word order as reversing or shuffling the words in a query might result in totally different intention. For example, “list of flights london to berlin" and “list of flights berlin to london" have different intentions. We use recurrent neural network (RNN) to map a query of variable length to a fixed-length vector. To avoid the problem of gradient vanishing, we use gated recurrent unit (GRU) BIBREF8 as the basic computation unit, which adaptively forgets the history and remembers the input, and has proven to be effective in sequence modeling BIBREF9 . It recursively transforming current word vector $e^q_t$ with the output vector of the previous step $h_{t-1}$ .
$$&z_i &= \sigma (W_{z}e^q_{i} + U_{z}{h}_{i-1}) \nonumber \\ &r_i &= \sigma (W_{r}e^q_{i} + U_{r}{h}_{i-1}) \nonumber \\ &\widetilde{h}_i &= \tanh (W_{h}e^q_{i} + U_{h}(r_i \odot {h}_{i-1})) \nonumber \\ &{h}_{i} &= z_i \odot \widetilde{h}_i + (1-z_i) \odot {h}_{i-1} \nonumber $$   (Eq. 14)
where $z_i$ and $r_i$ are update and reset gates of GRU. We use a bi-directional RNN to get the meaning of a query from both directions, and use the concatenation of two last hidden states as the final query representation $v_q=[ \overrightarrow{h}_n , \overleftarrow{h}_n ]$ .
A table has different types of information, including headers, cells and caption. We develop different mechanisms to match the relevance between a query and each aspect of a table. An important property of a table is that randomly exchanging two rows or tow columns will not change the meaning of a table BIBREF10 . Therefore, a matching model should ensure that exchanging rows or columns will result in the same output. We first describe the method to deal with headers. To satisfy these conditions, we represent each header as an embedding vector, and regard a set of header embeddings as external memory $M_h \in \mathbb {R}^{k \times d}$ , where $d$ is the dimension of word embedding, and $k$ is the number of header cells. Given a query vector $v_q$ , the model first assigns a probability $\alpha _i$ to each memory cell $m_i$ , which is a header embedding in this case. Afterwards, a query-specific header vector is obtained through weighted average BIBREF11 , BIBREF12 , namely $v_{header} = \sum _{i=1}^{k}\alpha _i m_i$ , where $\alpha _i \in [0,1]$ is the weight of $m_i$ calculated as below and $\sum _{i} \alpha _i = 1$ .
$$\alpha _i = \frac{exp(tanh(W [m_i; v_q] + b))}{\sum _{j=1}^k exp(tanh(W [m_j; v_q] + b))}\nonumber $$   (Eq. 15)
Similar techniques have been successfully applied in table-based question answering BIBREF13 , BIBREF14 . Afterwards, we feed the concatenation of $v_q$ and $v_{header}$ to a linear layer followed by a $softmax$ function whose output length is 2. We regard the output of the first category as the relevance between query and header. We use $NN_1()$ to denote this model.
$$f_{nn}(header, q)=NN_{1}(M_{h}, v_{q}) \nonumber $$   (Eq. 16)
Since headers and cells have similar characteristics, we use a similar way to measure the relevance between a query and table cells. Specifically, we derive three memories $M_{cel}$ , $M_{row}$ and $M_{col}$ from table cells in order to match from cell level, row level and column level. Each memory cell in $M_{cel}$ represents the embedding of a table cell. Each cell in $M_{row}$ represent the vector a row, which is computed with weighted average over the embeddings of cells in the same row. We derive the column memory $M_{col}$ in an analogous way. We use the same module $NN_1()$ to calculate the relevance scores for these three memories.
$$f_{nn}(cell, q)&=&NN_{1}(M_{cel}, v_{q}) \nonumber \\ f_{nn}(column, q)&=&NN_{1}(M_{col}, v_{q}) \nonumber \\ f_{nn}(row, q)&=&NN_{1}(M_{row}, v_{q}) \nonumber $$   (Eq. 17)
Since a table caption is typically a descriptive word sequence. We model it with bi-directional GRU-RNN, the same strategy we have used for modeling the query. We concatenate the caption vector $v_{cap}$ with $v_{q}$ , and feed the results to a linear layer followed by $softmax$ .
$$f_{nn}(caption, q)=NN_{2}(v_{cap}, v_{q}) \nonumber $$   (Eq. 18)
We separately train the parameters for each aspect with back-propagation. We use negative log-likelihood as the loss function.
$$loss = -\frac{1}{|D|}\sum _{(t_a, q) \in D} \log (f_{nn}(t_a,q)) \nonumber $$   (Eq. 20)
Experiment
We describe the experimental setting and analyze the results in this section.
Dataset and Setting
To the best of our knowledge, there is no publicly available dataset for table retrieval. We introduce WebQueryTable, an open-domain dataset consisting of query-table pairs. We use search logs from a commercial search engine to get a list of queries that could be potentially answered by web tables. Each query in query logs is paired with a list of web pages, ordered by the number of user clicks for the query. We select the tables occurred in the top ranked web page, and ask annotators to label whether a table is relevant to a query or not. In this way, we get 21,113 query-table pairs. In the real scenario of table retrieval, a system is required to find a table from a huge collection of tables. Therefore, in order to enlarge the search space of our dataset, we extract 252,703 web tables from Wikipedia and regard them as searchable tables as well. Data statistics are given in Table 1 .
We sampled 200 examples to analyze the distribution of the query types in our dataset. We observe that 69.5% queries are asking about “a list of XXX”, such as “list of countries and capitals” and “major cities in netherlands", and about 24.5% queries are asking about an attribute of an object, such as “density of liquid water temperature”. We randomly separate the dataset as training, validation, test with a 70:10:20 split.
We also conduct a synthetic experiment for table retrieval on WikiTableQuestions BIBREF0 , which is a widely used dataset for table-based question answering. It contains 2,108 HTML tables extracted from Wikipedia. Workers from Amazon Mechanical Turk are asked to write several relevant questions for each table. Since each query is written for a specific table, we believe that each pair of query-table can also be used as an instance for table retrieval. The difference between WikiTableQuestions and WebQueryTable is that the questions in WikiTableQuestions mainly focus on the local regions, such as cells or columns, of a table while the queries in WebQueryTable mainly focus on the global content of a table. The number of table index in WikiTableQuestions is 2,108, which is smaller than the number of table index in WebQueryTable. We randomly split the 22,033 question-table pairs into training (70%), development (10%) and test (20%).
In the candidate table retrieval phase, we encode a table as bag-of-words to guarantee the efficiency of the approach. Specifically, on WebQueryTable dataset we represent a table with caption and headers. On WikiTableQuestions dataset we represent a table with caption, headers and cells. The recalls of the candidate table retrieval step on WikiTableQuestions and WebQueryTable datasets are 56.91% and 69.57%, respectively. The performance of table ranking is evaluated with Mean Average Precision (MAP) and Precision@1 (P@1) BIBREF15 . When evaluating the performance on table ranking, we filter out the following special cases that only one candidate table is returned or the correct answer is not contained in the retrieved tables in the first step. Hyper parameters are tuned on the validation set.
Results on WebQueryTable
Table 2 shows the performance of different approaches on the WebQueryTable dataset.
We compare between different features for table ranking. An intuitive baseline is to represent a table as bag-of-words, represent a query with bag-of-words, and calculate their similarity with cosine similarity. Therefore, we use the BM25 score which is calculated in the candidate table retrieval step. This baseline is abbreviated as BM25. We also report the results of using designed features (Feature) described in Section "Matching with Designed Features" and neural networks (NeuralNet) described in Section "Matching with Neural Networks" . Results from Table 2 show that the neural networks perform comparably with the designed features, and obtain better performance than the BM25 baseline. This results reflect the necessary of taking into account the table structure for table retrieval. Furthermore, we can find that combining designed features and neural networks could achieve further improvement, which indicates the complementation between them.
We further investigate the effects of headers, cells and caption for table retrieval on WebQueryTable. We first use each aspect separately and then increasingly combine different aspects. Results are given in Table 3 . We can find that in general the performance of an aspect in designed features is consistent with its performance in neural networks. Caption is the most effective aspect on WebQueryTable. This is reasonable as we find that majority of the queries are asking about a list of objects, such as “polish rivers", “world top 5 mountains" and “list of american cruise lines". These intentions are more likely to be matched in the caption of a table. Combining more aspects could get better results. Using cells, headers and caption simultaneously gets the best results.
Moreover, we investigate whether using a higher threshold could obtain a better precision. Therefore, we increasingly use a set of thresholds, and calculate the corresponding precision and recall in different conditions. An instance is considered to be correct if the top ranked table is correct and its ranking score is greater than the threshold. Results of our NeuralNet approach on WebQueryTable are given in 2 . We can see that using larger threshold results in lower recall and higher precision. The results are consistent with our intuition.
We conduct case study on our NeuralNet approach and find that the performance is sensitive to the length of queries. Therefore, we split the test set to several groups according to the length of queries. Results are given in Figure 4 . We can find that the performance of the approach decreases with the increase of query length. When the query length changes from 6 to 7, the performance of P@1 decreases rapidly from 58.12% to 50.23%. Through doing case study, we find that long queries contain more word dependencies. Therefore, having a good understanding about the intention of a query requires deep query understanding. Leveraging external knowledge to connect query and table is a potential solution to deal with long queries.
We illustrate two examples generated by our NeuralNet approach in Figure 3 . The example in Figure 3 (a) is a satisfied case that the top ranked result is the correct answer. We can find that the model uses evidences from different aspects to match between a query and a table. In this example, the supporting evidences come from caption (“ramadan" and “malaysia"), headers (“dates") and cells (“2016"). The example in Figure 3 (b) is a dissatisfied case. We can find that the top ranked result contains “life expectancy" in both caption and header, however, it is talking about the people in U.S. rather than “german shepherd". Despite the correct table contains a cell whose content is “german shepherd", it still does not obtain a higher rank than the left table. The reason might be that the weight for header is larger than the weight for cells.
Results on WikiTableQuestions
Table 4 shows the results of table ranking on the WikiTableQuestions dataset.
We implement two baselines. The first baseline is BM25, which is the same baseline we have used for comparison on the WebQueryTable dataset. The second baseline is header grounding, which is partly inspired by VLDB2011GG who show the effectiveness of the semantic relationship between query and table header. We implement a CDSSM BIBREF6 approach to match between a table header and a query. We train the model by minimizing the cross-entropy error, where the ground truth is the header of the answer. Results are given in Table 4 . We can find that designed features perform comparably with neural networks, and both of them perform better than BM25 and column grounding baselines. Combining designed features and neural networks obtains further improvement.
We also study the effects of different aspects on the WikiTableQuestions dataset. Results are given in Table 5 .
We can find that the effects of different aspect in designed features and neural networks are consistent. Using more aspects could achieve better performance. Using all aspects obtains the best performance. We also find that the most effective aspect for WikiTableQuestions is header. This is different from the phenomenon in WebQueryTable that the most effective aspect is caption. We believe that this is because the questions in WikiTableQuestions typically include content constrains from cells or headers. Two randomly sampled questions are “which country won the 1994 europeans men's handball championship's preliminary round?" and “what party had 7,115 inactive voters as of october 25, 2005?". On the contrary, queries from WebTableQuery usually do not use information from specific headers or cells. Examples include “polish rivers", “world top 5 mountains" and “list of american cruise lines". From Table 1 , we can also find that the question in WikiTableQuestions are longer than the queries in WebQueryTable. In addition, we observe that not all the questions from WikiTableQuestions are suitable for table retrieval. An example is “what was the first player to be drafted in this table?".
Related Work
Our work connects to the fields of database and natural language processing.
There exists several works in database community that aims at finding related tables from keyword queries. A representative work is given by VLDB2008GG, which considers table search as a special case of document search task and represent a table with its surrounding text and page title. VLDB2010india use YAGO ontology to annotate tables with column and relationship labels. VLDB2011GG go one step further and use labels and relationships extracted from the web. VLDB2012IBM focus on the queries that describe table columns, and retrieve tables based on column mapping. There also exists table-related studies such as searching related tables from a table BIBREF16 , assembling a table from list in web page BIBREF17 and extracting tables using tabular structure from web page BIBREF18 . Our work differs from this line of research in that we focus on exploring the content of table to find relevant tables from web queries.
Our work relates to a line of research works that learn continuous representation of structured knowledge with neural network for natural language processing tasks. For example, neelakantan2015neural,pengcheng2015 develop neural operator on the basis of table representation and apply the model to question answering. yin2015NGQA introduce a KB-enhanced sequence-to-sequence approach that generates natural language answers to simple factoid questions based on facts from KB. mei-bansal-walter:2016:N16-1 develop a LSTM based recurrent neural network to generate natural language weather forecast and sportscasting commentary from database records. serban-EtAl:2016:P16-1 introduce a recurrent neural network approach, which takes fact representation as input and generates factoid question from a fact from Freebase. table2textEMNLP2016 presented an neural language model that generates biographical sentences from Wikipedia infobox.
Our neural network approach relates to the recent advances of attention mechanism and reasoning over external memory in artificial intelligence BIBREF11 , BIBREF12 , BIBREF19 . Researchers typically represent a memory as a continuous vector or matrix, and develop neural network based controller, reader and writer to reason over the memory. The memory could be addressed by a “soft” attention mechanism trainable by standard back-propagation methods or a “hard” attention mechanism trainable by REINFORCE BIBREF20 . In this work, we use the soft attention mechanism, which could be easily optimized and has been successfully applied in nlp tasks BIBREF11 , BIBREF12 .
Conclusion
In this paper, we give an empirical study of content-based table retrieval for web queries. We implement a feature-based approach and a neural network based approach, and release a new dataset consisting of web queries and web tables. We conduct comprehensive experiments on two datasets. Results not only verify the effectiveness of our approach, but also present future challenges for content-based table retrieval.

Question: What loss function is used?
Answer: negative log-likelihood

negative log-likelihood

negative log-likelihood

Question: Do they use the unstructured text on the webpage that was the source of the table?
Answer: No

No

Question: Does their method rely on the column headings of the table?
Answer: Yes

Yes

Question: Are all the tables in the dataset from the same website?
Answer: No, they come from the top ranked web pages relevant to a query and from Wikipedia 

Yes

Question: How are the tables extracted from the HTML?
Answer: Unanswerable

Unanswerable