Extracting information from tables is an important and rather complex part of information retrieval. For the task of objects extraction from HTML tables we introduce the following methods: determining table orientation, processing of aggregating objects (like Total) and scattered headers (super row labels, subheaders).
Significant amount of text information has relational structure, which is often represented in a table view. Since this view is designed for humans and contains many ambiguous elements, it follows that automatic processing of tables is rather complex.
For example, table 1 contains scattered header, complex hierarchical header, special objects, and other elements. They play particular roles in the table and, thus, should be treated in a special way. These elements are described in the rest of the paper.
Another non-trivial task is to determine table orientation: it can be horizontal (row wise, table 1) or vertical (column wise, table 2).
We consider tables in structured formats such as HTML and Wiki markup1. The main goal of our table processing is to extract objects as collections of attribute-value pairs. Thereupon we focus on determining table orientation and understanding the role of each element in the table.
Silva et al [
First of them occurs mostly in plain text and image
formats. The last task depends on kind of table usage:
generating ontology from tables [
Our work is devoted to the three last tasks while structural analysis is a principal one.
Table 1
Early works deal with tables in plain text, usually in
ASCII format [
Rus and Summers [
There are many works concerned plain text and
most of them use approaches inapplicable for HTML
tables. However there are some useful ideas, which
were explored in these works and inspired by linguistic
characteristics of table content. For example,
similarity/cohesion among different table elements
(cells/lines/columns) became a common feature in
future works including HTML tables oriented ones.
Hurst and Douglas [
Pinto et al. [
The majority of these works are devoted to performing
location and segmentation of a table (Tupaj et al. [
At a distance, Gatterbauer et al. [
A main source of HTML tables is Web pages, but many
Web-tables are created just for layout, not for
representing relational information. Wang and Hu [
Chen et al. [
Yoshida et al. [
Cafarella et al. [
What is an object in a table? Often the answer is obvious. For example, in table 2 objects are two airbuses: A310-200 and A310-200F. Table 1 is a little bit vaguer. It contains SVT vehicles manufactured in different years. Sometimes tables with nondefinable objects are found, e.g. multiplication table or table 3. Table 3
NFPA 704
0 Fire diamond for aluminium shot
As a rough definition, table object is a real world entity, whose attributes are set in the table. We assume that either row or column represents an object. So, table has either horizontal or vertical orientation.
We use 2 machine learning algorithms with the same features to determine table orientation: decision tree and naïve Bayes. All features have common nature: some function is computed on horizontal table as well as on vertical one and the difference between obtained values is found.
First feature is the difference in header depth. The function is very simple; it returns the depth of table header hierarchy. E.g. the header depth for horizontal table in figure 1 is 2, due to Power, hp, and kW cells; the header depth for the vertical table is 1. The header depths for both orientations of table 2 are 1. The motivation is following: orientation with deeper header is more likely to be correct.
Second feature is difference in maximum cell cohesion. Cell cohesion is an average string similarity of all cells in a row or in a column. Average string similarity is computed by summation of all pairwise string similarities/metrics of cells and normalization (dividing by square of total count of cells). Maximum cell cohesion for the horizontal table is simply a maximum of cell cohesion in all rows; the same stands for the vertical one with replacement of rows by columns.
Third feature is the difference in average cell cohesion. The only distinction from the previous feature is that all cell cohesions are summed and then divided by total count of rows or columns.
After experiments with a small set of Wikipedia tables (about 70) we found that the most valuable feature is the difference in average cell cohesion. All other features aren’t presented in decision tree without overlearning (see figure 1).
Figure 1
Also we experimented with introducing the third type of tables, which contain no object, but effectiveness decreased dramatically. This can be easy explained because even human can’t label classify some table into the third type with confidence. So we don't take into account tables without objects.
Some tables contain aggregating objects, which actually store information about other objects from the same table. For example, in table 4 the last row isn't an ordinary entity and should be processed in special way. Table 4
Some tables contain special rows, or scattered headers, which add structural information and are not table objects. Example is the row Sports car from table 1. We called the object extracted from such scattered header row during the initial processing the scattered header object.
We extract scattered header objects only from the object set, which corresponds to the horizontal orientation of the table. Vertical objects aren't processed, because width of any table is limited and scattered headers are useless in vertical tables.
Deciding whether each row is a scattered header (SH) is based on the assumptions that only one cell in the row is nonempty and the row must stand out against other table. In addition, we don't consider empty rows and last rows.
We divide all SHs into three subclasses: single-cell SH, middle SH, first-cell SH.
1) Single-cell SH is a row with just one cell in a table where other rows have more than 1 cell (in HTML terms, a row with colspan greater than 1).
The example is given in table 5 (row Central Asia). Table 5
We consider such row to be an SH without other criteria.
2) Middle SH is a row with just one nonempty cell, located in the middle of the table.
The 4th row Bonus track of table 6 is a middle SH. Table 6
We require the nonempty cell of such row to be decorated.
In addition, we check the table to be non-sparse. Sparse table is a table with many empty cells, e.g. table 7. It is evident that the heuristic for determining middle SH doesn't work correctly with sparse tables. Table 7
So we check the rows near the concerned middle SH row (3 rows above and 3 below). If they have empty cells, then the row under review isn't a middle SH. Of course, the row with empty cells can be another middle SH; to address this issue we don't take such rows into account while checking their cells. But previous and next rows must differ from the concerned one, because scattered headers never have the same structure and content with another SH.
Thereby table 7 contains no SH.
3) First-cell SH is a row whose only nonempty cell is first.
For example, the third row Cities (10 Largest) of table 8 belongs to this type.
Table 8
The criteria for this type are the same as for the previous type.
Scattered header object are removed from the original set before the aggregating objects processing. Therefore created aggregating objects have no information about scattered header objects.
We update attributes of all objects by adding the new field; currently its name is Type. Every table object located below the current scattered header and above the next scattered header (if it exists) is updated by adding a new value, which is the content of the corresponding scattered header.
In this paper we concerned on the task of objects extraction from HTML tables, gave a short survey of occurring problems, and introduced methods (mostly heuristics) for their solving. Of course, there are many cases uncovered by this paper, e.g. accurate detection of table header, processing of non-aggregating special objects and so on. It's the scope of future research.
The most common usage of extracted objects is to
map them to predefined relational scheme. Embley et
al. [