Learning Semantic Annotations for Tabular Data (1906.00781v1)

Published 30 May 2019 in cs.DB, cs.IR, and cs.LG

Abstract: The usefulness of tabular data such as web tables critically depends on understanding their semantics. This study focuses on column type prediction for tables without any meta data. Unlike traditional lexical matching-based methods, we propose a deep prediction model that can fully exploit a table's contextual semantics, including table locality features learned by a Hybrid Neural Network (HNN), and inter-column semantics features learned by a knowledge base (KB) lookup and query answering algorithm.It exhibits good performance not only on individual table sets, but also when transferring from one table set to another.

Authors (4)

Jiaoyan Chen (85 papers)
Ian Horrocks (50 papers)
Charles Sutton (74 papers)
Ernesto Jimenez-Ruiz (15 papers)

Citations (53)

View on Semantic Scholar

Summary

This paper addresses the problem of semantic type prediction for columns in tabular data, particularly focusing on tables lacking explicit metadata. The core contribution is a deep learning model designed to leverage both the contextual information within the table itself and external knowledge derived from a Knowledge Base (KB).

Methodology

The proposed model integrates two primary components to capture distinct aspects of table semantics: a Hybrid Neural Network (HNN) for intra-table context and a KB lookup/query answering module for inter-column semantics and external grounding.

Hybrid Neural Network (HNN) for Table Locality Features

The HNN is designed to learn representations that capture the contextual semantics within a table, often referred to as table locality features. It typically processes individual columns or cells considering their surrounding context.

Input Representation: Cells within a column are often represented using pre-trained word embeddings (e.g., GloVe, FastText) or character-level embeddings derived using CNNs or LSTMs. This allows the model to handle out-of-vocabulary words and capture morphological similarities.
Contextual Encoding: The sequence of cell representations within a column is processed using recurrent neural networks (RNNs), typically LSTMs or GRUs, to capture sequential dependencies and patterns inherent in column data (e.g., numerical sequences, date formats). Convolutional Neural Networks (CNNs) might also be employed, potentially across rows or columns, to capture local spatial patterns or n-gram features within cells or across adjacent cells.
Feature Aggregation: The encoded representations from the cells within a column are aggregated (e.g., via max-pooling, average-pooling, or an attention mechanism) to produce a fixed-size vector representation for the entire column, summarizing its internal characteristics and context.

The "hybrid" nature often refers to the combination of different neural architectures (e.g., CNNs for character-level features, LSTMs for sequential cell context) to extract a rich set of features from the raw table data.

Knowledge Base Lookup and Query Answering for Inter-Column Semantics

This component aims to leverage external structured knowledge to understand the relationships between columns and ground the table's content in real-world entities and concepts.

Entity Linking: Cells or entire columns are linked to entities in a target Knowledge Base (e.g., Wikidata, Freebase, DBpedia). This step typically involves candidate generation (finding potential KB entities matching cell text) and disambiguation (selecting the most likely entity based on context, possibly including coherence with other linked entities in the same row or table).
Type/Relation Extraction: Once entities are linked, their types and relationships are retrieved from the KB. For column type prediction, the types associated with the linked entities in a column provide strong evidence for the column's semantic type. Relationships between entities linked in different columns of the same row can reveal inter-column dependencies (e.g., the relationship between a 'City' column and a 'Country' column).
Feature Generation: Features are derived from the KB lookup results. These might include:
- A distribution over KB types based on the types of linked entities within the column.
- Embeddings of the most frequent KB types or relations found.
- Features indicating the presence of specific relationships between linked entities across columns.
- Scores reflecting the confidence or consistency of entity links within the column. The paper may employ a query answering mechanism where, given the linked entities or partial type information, the system queries the KB to infer the most likely semantic type for a column, potentially considering consistency with other columns.

Feature Integration and Prediction

The features extracted by the HNN (capturing intra-table context) and the KB module (capturing external semantics and inter-column relations) are combined. This is typically done by concatenating the respective feature vectors. The combined vector is then fed into one or more fully connected layers followed by a final output layer (e.g., softmax) that predicts the probability distribution over a predefined set of semantic column types. The model is trained end-to-end using a standard classification loss, such as cross-entropy.

$P(\text{type}| \text{column}) = \text{softmax}(W_{out} [ \mathbf{h}_{HNN} ; \mathbf{h}_{KB} ] + b_{out})$

where $\mathbf{h}_{HNN}$ is the feature vector from the HNN and $\mathbf{h}_{KB}$ is the feature vector derived from the KB lookup.

Implementation Details

Implementing this model requires careful consideration of several aspects:

Preprocessing: Tables need to be parsed and cleaned. Cell values are tokenized, potentially using specialized tokenizers for numerical data, dates, or code identifiers.
Embeddings: Pre-trained word embeddings (e.g., 300-dimensional GloVe) are commonly used. Character embeddings might be learned using CNNs with filters of varying widths.
HNN Architecture: Specific choices involve the type of RNN (LSTM vs. GRU), number of layers, hidden state dimensions (e.g., 128-256), use of bidirectional RNNs, and CNN filter configurations if used. Dropout is typically applied for regularization.
KB Integration: Requires an efficient entity linking system. Tools like DBpedia Spotlight, OpenTapioca (for Wikidata), or custom dictionary lookups combined with disambiguation models (potentially trained using context features) are needed. Access to a local KB dump or efficient API endpoints is crucial. Querying might involve SPARQL endpoints or graph traversal algorithms on a local graph representation.
Training: Adam optimizer with a suitable learning rate (e.g., 1e-3 or 1e-4) is common. Training requires labeled data (tables with annotated column types). Mini-batch training is standard. Handling tables of varying sizes (rows, columns) might require padding or dynamic batching strategies.
Type Ontology: A predefined target ontology of semantic types (e.g., derived from schema.org, DBpedia ontology, or a custom set) is necessary for classification.

Experimental Evaluation

The paper typically evaluates the model on standard benchmarks for semantic type prediction.

Datasets: Commonly used datasets include subsets of WebTables (e.g., Dresden Web Tables Corpus, WikiTables) and datasets from Limaye et al. (2010). These datasets vary in size, domain coverage, and quality.
Baselines: Performance is compared against:
- Lexical matching methods (e.g., regex-based, dictionary lookups).
- Traditional machine learning models (e.g., SVM, CRF) using handcrafted features.
- Other deep learning approaches, potentially simpler architectures or those relying solely on table context or KB features.
Metrics: Standard classification metrics like Precision, Recall, and F1-score (often macro-averaged or micro-averaged) are reported per type and overall. Mean Average Precision (MAP) might also be used if the model outputs ranked predictions.
Results: The paper reports significant improvements over baselines, particularly lexical methods and traditional ML. F1-scores often demonstrate the effectiveness of combining HNN and KB features. For instance, F1 scores might improve from ~0.7-0.8 for simpler methods to >0.9 for the proposed model on certain benchmarks. Performance transfer across different table corpora (e.g., training on WikiTables, testing on Dresden) is also evaluated to assess generalization, with the proposed model often showing better robustness.
Ablation Studies: These are crucial to validate the contribution of each component. Experiments typically involve training versions of the model without the HNN features, without the KB features, or with simplified versions of either component. Results usually confirm that both HNN and KB features contribute positively to performance, and their combination yields the best results.

Practical Implications and Considerations

This research has direct implications for automating data preparation, data integration, and data discovery tasks.

Applications: Automatic column type annotation enables:
- Semantic search over tabular data.
- Schema matching and data integration across disparate tables.
- Automated data cleaning and validation based on inferred types.
- Augmenting knowledge bases by identifying new instances and relationships from web tables.
- Facilitating downstream tasks like automated visualization or ML model building (AutoML).
Computational Requirements: Training deep learning models, especially with large pre-trained embeddings and KB integration, can be computationally intensive, requiring GPUs and significant time. Entity linking against large KBs can also be a bottleneck. Inference is generally faster but still requires loading the model and potentially performing KB lookups.
Scalability: Applying the model to millions or billions of tables (e.g., web-scale) requires efficient implementation, potentially distributed processing for entity linking and model inference. The size and accessibility of the KB are critical factors.
Limitations:
- KB Dependence: Performance heavily relies on the coverage and quality of the underlying KB and the accuracy of the entity linking step. Columns with concepts or entities not present in the KB are challenging.
- Out-of-Ontology Types: The model can only predict types present in its predefined target ontology.
- Ambiguity and Noise: Handling ambiguous cell values or noisy tables remains difficult.
- Complex Types: Representing and predicting complex semantic types (e.g., 'Address' involving multiple components) may require more sophisticated modeling.
- Domain Shift: While transfer performance is evaluated, significant domain shifts between training and deployment data can still degrade performance.

Conclusion

The paper presents a robust deep learning framework for semantic column type annotation by effectively combining intra-table contextual signals captured by a Hybrid Neural Network and external world knowledge grounded via Knowledge Base integration. The methodology demonstrates strong empirical performance on benchmark datasets and offers a promising direction for enhancing semantic understanding of tabular data in various applications, though practical deployment necessitates careful consideration of computational resources, KB availability, and potential limitations.

PDF Markdown

Related Papers

Find Related Papers

GitHub

GitHub - alan-turing-institute/SemAIDA: Semantic Technologies for the AIDA project (38 stars)