面向大规模语义表解读与数据质量评估的可解释、以表头为中心的框架

# An Explainable Header-Centric Framework for Large-Scale Semantic Table Interpretation and Data Quality Assessment
Source: [https://arxiv.org/html/2610.10541](https://arxiv.org/html/2610.10541)
\\copyrightclause

Copyright for this paper by its authors\. Use permitted under Creative Commons License Attribution 4\.0 International \(CC BY 4\.0\)\.\\conferenceWorkshop on Quality of Knowledge Graphs at ESWC 2026, May 11, 2026, Dubrovnik, Croatia

\[ email=marcelo\.valentim@bcb\.gov\.br, orcid=0000\-0003\-4592\-2968 \]\\cormark\[1\]\\cortext\[1\]Corresponding author\.

\[ email=hannes\.herrmann@curtin\.edu\.au, orcid=0000\-0002\-3160\-4988 \]

\[ email=v\.maxville@curtin\.edu\.au, orcid=0000\-0001\-8842\-7364 \]

###### Abstract

Knowledge Graph \(KG\) quality is influenced not only by downstream graph validation, but also by the quality of the tabular metadata used prior to integration\. In metadata\-only Semantic Table Interpretation \(STI\), where cell values are unavailable, noisy, or unsuitable for use, column headers become a critical source of semantic evidence\. This is directly relevant to metadata quality, provenance\-aware traceability, and quality\-aware preparation for knowledge\-graph integration\.

We present an explainable, header\-centric framework for metadata\-only Column Type Annotation \(CTA\) and Data Quality Assessment \(DQA\)\. The framework maps headers to a compact layer of 39 interpretableFinalFormattypes using curated lexical resources, while preserving token\-level traceability throughSourceKeywords\. Each assigned type activates predefined validation rules grounded in a structured taxonomy of Data Quality Issues \(DQI\), producing cell\-level DQI instances such as missing data, duplicates, domain violations, wrong data type, and temporal mismatch\. These detections are aggregated intoHeadersIQ, a lightweight and intentionally unweighted data source\-level data quality metric relevant to the SemTab 2024 IsGold? track and related KG quality assessment work, such as KG2Tables\. Illustrative case studies from real data sources show that identifier semantics simultaneously trigger completeness and uniqueness constraints, whereas bounded numerical formats expose domain violations\.

The framework was evaluated across heterogeneous benchmarks, including UCI, Prague, Kaggle, VizNet/Sato, SOTAB, T2Dv2, and the SemTab 2024 Metadata\-to\-KG track, comprising around 120,000 header columns\. This large\-scale evaluation demonstrates broad practical coverage across noisy real\-world metadata, while a parallel KG\-mapping pathway supports alignment to DBpedia and Schema\.org\. On the SemTab 2024 Metadata\-to\-KG track, the official GT\-strict evaluation was modest\. Still, a blinded diagnostic audit indicates that many mismatches reflect benchmark granularity, aliasing, and ontology\-selection effects rather than wholly implausible header\-centric predictions\. We report this audit as diagnostic evidence on the structure of disagreements, not as revised benchmark performance\. Overall, the paper presents a reusable and auditable workflow for metadata\-driven semantic annotation, data source\-level quality monitoring, and KG\-oriented benchmark diagnosis\. This positions the framework as a practical contribution to quality\-aware tabular preparation and the broader goal of sustaining trustworthy knowledge graph ecosystems\.

###### keywords:

Semantic table interpretation\\sepcolumn type annotation\\sepknowledge graphs\\sepdata quality assessment

## 1Introduction

In recent years, the rapid expansion of open data repositories and domain\-specific tabular data sources has made Table Understanding \(TU\) a central challenge for semantic integration and interoperability with knowledge graphs\[ref36\]\. Most real\-world tables remain poorly annotated or lack explicit semantic types, making semantic integration difficult and prone to errors\. Within TU, Semantic Table Interpretation \(STI\) addresses this need by linking tabular data to ontologies and knowledge graphs such as DBpedia\[ref4\]and Schema\.org\[Guha2015SchemaorgEO\]\. In this setting, the Column Type Annotation \(CTA\) subtask assigns semantically meaningful types to table columns, supporting semantic alignment and enabling richer metadata for downstream data quality assessment and knowledge\-graph integration\.

![Refer to caption](https://arxiv.org/html/2610.10541v1/x1.jpg)Figure 1:Example of Bad Data/Dirty Dataset\.Figure[1](https://arxiv.org/html/2610.10541#S1.F1)illustrates a realistic "dirty" dataset with duplicates, missing values, and obvious typographical problems\. In our framework, such problems are detected and explained through the semantic types inferred from the terms that appear in bold in the column headers\.

### 1\.1Historical context and renewed interest

Influential research such asSherlock \(2019\)\[ref13\]discouraged header\-centric features, arguing that matching\-based approaches \(i\) recognise only a limited range of types and \(ii\) are not robust to malformed or context\-dependent data, particularly when relying on dictionary or regular\-expression matching\. This influenced community practice, where unrecognised headers often fall back to primitive types\.

Recent findings challenge this view\. A survey byLiu et al\. \(2023\)\[ref23\]reports that competitive CTA systems increasingly exploit header signals:“The table header often directly explains the contents of the column”and that using header information can help predict column types or properties more efficiently\.

Since 2019, the Semantic Web Challenges on Tabular Data to Knowledge Graph Matching \(SemTab Challenges\)\[ref16,ref17,ref8,ref11,ref7,ref36\]have reinforced this shift\. In particular, the SemTab 2024 edition\[ref11\]introduced a Metadata\-to\-KG track in which cell values could not be used, reflecting practical concerns such as privacy, sensitive data, and large\-scale processing\. SemTab 2024 also included theIsGold? track\[ref1\], which further emphasized automateddata quality assessment\.KG2Tables \(Abdelmageed et al\., 2025\)\[ref2\]also highlighted data quality as an open gap \(diversity, annotation accuracy/clarity, structural coherence\)\. These developments further reinforce the relevance of scalable and interpretable metadata\-based methods\.

In particular, AdaTyper \(2023\)\[ref15\], from the Sherlock/Sato group, prioritises header analysis before cell\-based fallback, further supporting the value of header semantics\.

Taken together, these developments motivate an approach that mitigates the limitations noted by Sherlock\[ref13\]\. Dynamic dictionary expansion increases coverage beyond the limited type range typically associated with matching\-based systems\. Normalisation and abbreviation mappings improve robustness to noisy, malformed, and lexically variable metadata that would otherwise defeat dictionary\-based matching\. In addition, theFinalFormatlayer extends semantic coverage beyond simple primitive categories, although context\-dependent ambiguity remains a challenging case\.

### 1\.2Approach and Contributions

This work extends a previous header\-centric semantic typing and data quality framework\[ref37\]into a broader framework for metadata\-only Semantic Table Interpretation \(STI\) and Data Quality Assessment \(DQA\)\. Its central premise is that column headers can provide the primary semantic evidence needed for interpretable column typing and downstream quality assessment, especially when cell values are noisy, unavailable, sensitive, or unsuitable for use\.

The framework follows a header\-centric workflow in which headers are normalised and expanded through curated lexical resources\. After preprocessing, the pipeline branches into two parallel pathways\. In the first, semantic type detection maps headers to interpretable semantic types in theFinalFormatlayer\. These assignments activate targeted data quality checks grounded in a structured taxonomy ofData Quality Issues\. In the second, a separate KG\-mapping pathway aligns preprocessed headers to DBpedia and Schema\.org for KG\-oriented interpretation and benchmark comparison\.

Traceability is preserved throughSourceKeywords, and detected violations can be aggregated throughHeadersIQfor data source\-level quality monitoring\. The framework is then evaluated across heterogeneous benchmarks to assess practical coverage and robustness under noisy metadata conditions\. Here,FinalFormatdenotes the paper’s compact semantic type layer,SourceKeywordsare the matched header tokens that justify each assignment, andHeadersIQis the resulting data source\-level summary metric derived from activated DQA checks\.

This paper makes four main contributions:

1\. Framework\.We propose an explainable header\-centric framework for metadata\-only semantic typing that links inferred semantic types to rule\-grounded data quality assessment, while a parallel KG\-mapping pathway supports KG\-oriented interpretation and benchmark comparison\.

2\. Semantic layer and traceability\.We define a compactFinalFormatabstraction layer, supported by curated lexical resources and token\-level traceability mechanisms to enable interpretable and auditable semantic assignments\.

3\. Large\-scale evaluation\.We provide a broad empirical study across heterogeneous benchmarks to examine the scalability, coverage, and robustness of header\-centric annotation under noisy real\-world metadata conditions\.

4\. Quality monitoring and benchmark diagnosis\.We introduceHeadersIQfor data source\-level quality monitoring and show how header\-centric outputs can support diagnostic analysis of benchmark and ground\-truth limitations in KG\-oriented evaluation\.

Taken together, these contributions position the framework as a scalable, explainable, metadata\-only approach to semantic type annotation, provenance\-aware traceability, and KG\-oriented analysis\.

In addition, ongoing work includes aStatistical Auditdesigned to provide correctness\-oriented evidence forFinalFormatassignments beyond the coverage\-focused indicators reported in this paper\. A replication package, including appendices and implementation details, is publicly available at\[ref38\]\. Subsequent references to supplementary materials in the paper refer to this package\.

## 2Related Work

### 2\.1Column Type Annotation \(CTA\) Paradigms

In this paper, the relevant setting is metadata\-only CTA, where semantic inference relies on headers and related metadata rather than cell values\.

Following Liu et al\.\[ref23\], CTA systems can be grouped into four paradigms:

\(i\) heuristic dictionary\-based systems that match header tokens against controlled vocabularies or KG labels, such as Wang et al\.\[ref44\], C2\[ref19\], MAGIC\[ref40\], and Alobaid et al\.\[ref3\];

\(ii\) heuristic and iterative methods that propagate constraints or distribute semantic cues across table elements, including TableMiner\+\[ref47\], CSV2KG\[ref41\], T2K\[ref34\]and the MTab family\[ref29,ref30,ref31\];

\(iii\) feature\-based machine learning approaches that use engineered features over values and/or headers, for example, Limaye et al\.\[ref22\], and Mulwad et al\.\[ref27,ref28\]; and

\(iv\) deep learning and embedding\-based methods, including Sherlock\[ref13\], Sato\[ref45\], TURL\[ref10\], Doduo\[ref42\], RECA\[ref39\], and DAGOBAH\[ref6\], which exploit representations learned from large table corpora\. Only a small subset of systems \(12 in Liu’sT0 category\) deal with headers, and even fewer operate without access to cell values, leaving an underexplored region in the CTA landscape and motivating our header\-centric, metadata\-driven design\. A broader comparative analysis, including additional recent models, is provided inAppendix A\[ref38\]\.

### 2\.2Attribute\-Level Data Quality Dimensions

Building on a previous framework\[ref37\], which established the link between semantic type assignments and executable validation rules, the present work extends this integration with a formally grounded DQI \(Data Quality Issues\) taxonomy and large\-scale empirical evaluation\.

Attributes \(columns\) constitute the primary semantic units of tabular data\. Classical data quality literature identifies several core dimensions associated with attribute\-level assessment\[BatiniScannapieco2016,DasuJohnson2003\]\. These include:

- •Accuracy: the closeness between a recorded value and the corresponding real\-world entity or state\.
- •Completeness: the degree to which expected values are present \(absence of missing tuples or values\)\.
- •Consistency: the absence of violations of semantic or structural rules \(e\.g\., type constraints, integrity constraints\)\.
- •Uniqueness: the absence of unintended duplicates that represent the same real\-world entity\.
- •Timeliness: the validity of temporal information with respect to expected time bounds or recency\.

Many data quality problems can be interpreted as violations of one or more of these dimensions\. However, without semantic interpretation of attribute labels, automated profiling tools often fail to determine which constraints should apply\. In this work, semantic type detection provides the missing link between metadata interpretation and dimension\-aware validation\.

### 2\.3Data Quality Issues \(DQIs\) and Taxonomic Grounding

To operationalise dimension\-aware validation, we adopt the structured taxonomy of 22 Data Quality Issues \(DQIs\) compiled by Visengeriyeva and Abedjan \(2020\)\[VisengeriyevaAbedjan2020\]\. This taxonomy maps concrete error patterns to specific Data Quality Dimensions\.

Examples of DQIs particularly relevant to attribute\-level validation include

- •DQI \#1 \- Missing Data\(Accuracy, Completeness\): null values, blank entries, disguised placeholders\.
- •DQI \#5 \- Extraneous Data\(Consistency, Uniqueness\): additional unexpected content within attribute values\.
- •DQI \#9 \- Duplicates\(Uniqueness\): repeated tuples or values representing the same entity\.
- •DQI \#13 \- Temporal Mismatch\(Accuracy, Timeliness\): invalid or structurally incorrect temporal values\.
- •DQI \#15 \- Domain Violation\(Accuracy\): values violating semantic constraints of the attribute\.
- •DQI \#17 \- Wrong Data Type\(Consistency\): values violating declared or inferred data type\.
- •DQI \#19 \- Uniqueness Violation\(Uniqueness\): explicit violation of identifier\-level uniqueness constraints\.

Although certain DQIs \(e\.g\., referential integrity violations across relations\) require cross\-table analysis and fall outside the scope of this study, a substantial subset can be deterministically activated through attribute\-level semantic interpretation\.

## 3Methodology

![Refer to caption](https://arxiv.org/html/2610.10541v1/x2.jpg)Figure 2:Pipeline for Semantic Type Detection, Knowledge Graph Mapping, and Data Quality Assessment\.Figure 2 summarises the end\-to\-end workflow\. After preprocessing, the pipeline branches into two parallel pathways: semantic type detection, which supports downstream data quality assessment, and knowledge graph mapping, which supports KG\-oriented interpretation and benchmark comparison\. NIL analysis feeds back into dictionary curation\.

### 3\.1Data Ingestion

The ingestion stage serves as the entry point for tabular data from various sources, ranging from relational databases to datasets distributed in file\-based formats such as CSV files, text files, and spreadsheets, particularly those obtained from large repositories such as UCI\[ref24\]or Kaggle\[ref18\]\. Because these sources vary widely in structure, ingestion handles multiple file formats and extracts initial metadata such as column headers, optional descriptions, and, when available, indicators of primary or foreign keys\. Basic validation filters incomplete or malformed tables, and character encodings are normalised to ensure consistent downstream processing\. The resulting metadata forms the basis for dictionary expansion and header preprocessing\.

A key component of the framework is a pair of curated dictionaries:

\(i\) aformats dictionary\(formats\_dictionary\.txt\[ref38\]\) that maps normalised header tokens \(synonyms, variants, and domain\-specific terms\) to 39FinalFormattypes \(see Table 2, Section 3\.3\), and

\(ii\) anabbreviations dictionary\(abbreviations\_dictionary\.txt\[ref38\]\) that expands shorthand forms into terms registered in theformats dictionary\.

Formats DictionaryCreation and Growth\.

Theformats dictionary\[ref38\]was initially derived from header tokens inearlier work\[ref37\]and later expanded with DBHeaders\[ref9\], derived from Web Data Commons\[ref21\]over more than 90 million tables in the Web Table Corpus\[ref5\]\. Through iterative NIL\-driven review over almost 119,000 analysed columns, it grew to roughly 2,800 entries and now supports 39FinalFormattypes\. Table 1 illustrates representative mappings\. These mappings ensure that semantically related or ambiguous headers are consistently normalised to interpretableFinalFormattypes, such asname, city, binary, categorical, andpostalcode\. The coverage results reported in Sections 4\.2 and 4\.4 reflect the dictionary snapshot available when each benchmark was processed\.

Table 1:Example mappings from terms toFinalFormats\(informats dictionaryfile\[ref38\]\)Term→\\rightarrowFinalFormattypeTerm→\\rightarrowFinalFormattypeid→\\rightarrowIDcolumnauthor→\\rightarrownameday and time→\\rightarrowdatetimewebsite→\\rightarrowURLformatboolean→\\rightarrowbinaryday of week→\\rightarrowweekdayqualitative→\\rightarrowcategoricaladdress→\\rightarrowstreetheight→\\rightarrownumerical\>=0postal code→\\rightarrowpostalcodebirthplace→\\rightarrowcityinternet protocol→\\rightarrowIPformatterritory→\\rightarrowstatecellphone→\\rightarrowphoneAbbreviation DictionaryCreation and Expansion\.

To complement theformats dictionary, we maintain a dedicatedabbreviations dictionary\[ref37\],\[ref38\]that contains over 1,000 mappings from shorthand or compressed forms to their expanded variants that map to terms present in theformats dictionary\.This expansion is crucial for decoding terse headers \(e\.g\.,“DOB” →dateof birth → dateor“pct” → percentage\)\. Figure[3](https://arxiv.org/html/2610.10541#S3.F3)illustrates representative abbreviation categories, covering acronyms, misspellings \(e\.g\.,“addre” → address, “phn” → phone,drawn partly from NameGuess\[ref46\]\), domain jargon and truncations\. In this figure, the bold terms in the Expansion column correspond to theSourceKeywordsthat trigger theFinalFormatassignment\. In every case, at least one term in the expanded form links to aFinalFormattype; for example,CEO → chief executiveofficer→ name\.Here theSourceKeywordisofficer, which is linked toFinalFormatnamein theformats dictionary\.

![Refer to caption](https://arxiv.org/html/2610.10541v1/x3.jpg)Figure 3:Abbreviation categories and their expansions\.Like the mainformats dictionary, theabbreviation dictionaryalso grows iteratively through NIL analysis and expert review, supporting continual adaptation as new data sources and types of noise are encountered\.

Alignment with the SemTab 2025 Challenge Priorities\.This combined strategy of dictionary growth and abbreviation expansion aligns with several key priorities highlighted in SemTab 2025\[ref7\], particularly robust alias/acronym resolution, noise resilience, NIL detection for unmappable headers, and ambiguity handling in tabular metadata\.

### 3\.2Column Header Preprocessing

Preprocessing converts raw column headers into actionable semantic annotations using theFinalFormattype system\. The main stages are the following\.

1\. Metadata Extraction and Normalisation\.Extract header terms, normalise case and punctuation, and split compound or camelCase tokens to standardise heterogeneous naming conventions\.

2\. Abbreviation and Variant Handling\.Expand over 1,000 abbreviations and spelling variants, enabling robust treatment of noisy, truncated, or misspelled headers commonly found in real\-world data\.

3\.SourceKeywordsExtraction\.Extract and record the dictionary\-matched trigger token\(s\) from the cleaned header and optional description \(after abbreviation expansion\) that led to theFinalFormatassignment, providing token\-level traceability\.

For example, inhas context, “has”is recorded as theSourceKeywordthat triggers theFinalFormatbinary; similarly,“bp”expands to“blood pressure”, which is recorded as theSourceKeywordtriggering the assignment toFinalFormatbloodpressure\.

### 3\.3Semantic Type Detection

TheFinalFormatsystem provides the semantic backbone of the framework, defining 39 interpretable types, listed in Table 2, that sit between coarse atomic data types \(e\.g\., string, integer, date\) and fine\-grained ontology classes in DBpedia or Schema\.org\. This layer is expressive enough to support meaningful data\-quality checks while remaining simple and explainable\.

Definition and Scope\.

FinalFormattypes cover categories such as:

•Numerical: generic numeric, non\-negative, and bounded numerical types\.

•Geographical:city, country, postalcode, state, street\.

•Temporal:date, datetime, day, hour, month, time, week, weekday, year\.

•Categorical: Keywords such as “class”, “status”, “type”, etc\.

•Name: Keywords such as “director”, “actor”, “publisher”, or “firstName”\.

•Identifiers:IDcolumn\(e\.g\.“ISBN”, “SSN”\),URLformat, IPformat, phone\.

•Binary: Boolean fields or fields identified through cues \(“has”\)\.

•Textual: descriptive, free text, assigned toFinalFormatstring\.

\\captionof

tableThe 39FinalFormats\. Blue shading indicates bounded numericalFinalFormats\.FinalFormatFinalFormatFinalFormatacidityheartratepercentageagehourpHalkalinityIDcolumnphoneangleIPformatpostalcodebinarylatitudesaltnessbloodpressurelongitudestatecategoricalmodelnamestreetcitymoneystringcountrymonthtimedatenameURLformatdatetimenormalizedweekdaynumericalweekdayE\-mailformatnumerical\>=0year

Matching and annotation\.Semantic type assignment is performed through deterministic rule\-based matching\. Exact, substring and fuzzy matching are applied to assignFinalFormattypes using the curatedFormatsandAbbreviations dictionaries\.SourceKeywordsrecord the supporting header or description tokens for explanation and auditing\.

### 3\.4Knowledge Graph Mapping

Each column was linked to the most semantically aligned property in DBpedia\[ref4\]and Schema\.org\[Guha2015SchemaorgEO\]\. This mapping stage operates as a parallel pathway after preprocessing, placing header\-centric metadata into a knowledge\-graph vocabulary space for KG\-oriented interpretation and benchmark comparison\.

Figure 4 illustrates real mappings from the KG\-mapping pathway, showing header normalisation, abbreviation expansion, dictionary matching,FinalFormatassignment,SourceKeywordextraction, and ontology alignment with DBpedia and Schema\.org\. The examples highlight how preprocessing improves semantic alignment, as abbreviated or compressed headers such as Wt, Yr, ISO, OS, NOC, and obp are expanded before mapping\. Several cases produce accurate ontology matches, such as weight, year, Organization, operatingSystem, and percentage, while others reveal limitations in ontology coverage or granularity, including NIL results in Schema\.org and the more specific copyrightYear returned for Yr\.

These cases show that KG\-based annotation can benefit from abbreviation expansion, but semantic accuracy still depends on the available vocabulary and modelling choices of the target ontology\. Importantly, such KG\-mapping limitations do not affectFinalFormatassignment or downstream DQA activation\. After preprocessing, semantic type detection and KG mapping proceed as parallel pathways:FinalFormatassignment supports DQA, whereas KG mapping is used for ontology\-oriented interpretation and benchmark comparison\.

![Refer to caption](https://arxiv.org/html/2610.10541v1/x4.jpg)Figure 4:Examples ofFinalFormatassignments and KG mappings\.Overall,FinalFormatdelivers semantically richer classifications than atomic data types, while remaining more compact and operational than ontology mappings, thereby enhancing interpretability and data\-quality profiling\.

### 3\.5Data Quality Assessment

As introduced in earlier work\[ref37\], each inferredFinalFormatactivates one or more predefined sets of data quality validation functions\. These checks include, for example, uniqueness enforcement for identifier formats, bounded\-range validation for numerical formats, and structural validation for dates and categorical fields\.

In the present study, rule activation is grounded in the DQI taxonomy \(Section[2\.3](https://arxiv.org/html/2610.10541#S2.SS3)\)\. Each validation function yields cell\-level DQI instances, which are aggregated intoHeadersIQ\(Subsection[3\.5\.1](https://arxiv.org/html/2610.10541#S3.SS5.SSS1)\)\.

Representative examples include:

- •check\_numerical\_ge\_zero: enforces non\-negative constraint \(DQI \#1, \#15, \#17\)\.
- •check\_numerical\_between: validates bounded numeric ranges \(DQI \#1, \#15, \#17\)\.
- •check\_id\_attributes: validates identifier properties \(DQI \#1, \#9, \#15, \#17, \#19\)\.
- •check\_date: validates temporal structure and bounds \(DQI \#1, \#6, \#13, \#15\)\.
- •check\_postal\_code: validates structural constraints \(DQI \#1, \#15, \#17\)\.
- •check\_email\_format: enforces email syntax validity \(DQI \#1, \#15\)\.

For bounded numericalFinalFormats,check\_numerical\_betweenapplies a predefined interval associated with the inferred semantic type\. For example, a column assigned toFinalFormatageis validated against the adopted interval 0–130, whilepHis validated against 0–14\. The validator, therefore, does not require additional per\-dataset input at runtime; it uses the interval linked to the assignedFinalFormat\. These bounds are maintained as configurable domain parameters linked toFinalFormattypes rather than hard\-coded properties of individual datasets, so they can be revised independently as domain requirements or governance policies evolve\.

This mapping ensures that rule activation is not heuristic, but is grounded in a predefined taxonomy of violations aligned with classical data quality theory\. Each detected violation is recorded as a cell\-level DQI instance\.

#### 3\.5\.1HeadersIQ: A Metric for Data/Information Quality Monitoring

HeadersIQwas developed as a lightweight, unweighted summary metric for monitoring data source\-level quality\. It reflects the proportion of evaluated cells with no detected violations under the activated data quality rules\. The nameHeadersIQreflects both its foundation in column headers and its focus on Information Quality \(IQ\)\.

##### Formal definition\.

LetNcN\_\{c\}be the number of columns,NrN\_\{r\}the number of rows, and𝒳\\mathcal\{X\}the set of evaluated cells\. Since all cells are evaluated, the total number of evaluated cells is

T=\|𝒳\|=Nc×Nr\.T=\|\\mathcal\{X\}\|=N\_\{c\}\\times N\_\{r\}\.
For eachx∈𝒳x\\in\\mathcal\{X\}, define

v​\(x\)=\{1,if at least one activated data quality rule detects a violation in cell​x,0,otherwise\.v\(x\)=\\begin\{cases\}1,&\\text\{if at least one activated data quality rule detects a violation in cell \}x,\\\\ 0,&\\text\{otherwise\.\}\\end\{cases\}
Then

V=∑x∈𝒳v​\(x\)V=\\sum\_\{x\\in\\mathcal\{X\}\}v\(x\)
denotes the number of distinct cells with one or more detected violations\.

TheHeadersIQscore is defined as

HeadersIQ=\(1−VT\)×100\\mathrm\{\\textit\{\{HeadersIQ\}\}\}=\\left\(1\-\\frac\{V\}\{T\}\\right\)\\times 100\(1\)
It produces a normalised 0\-100 score representing the proportion of evaluated cells for which no violations were detected under the activated rules\.

### 3\.6Feedback, NIL Analysis & Knowledge Curation

NIL\-labelled headers are reviewed through a controlled, evidence\-based human\-in\-the\-loop feedback cycle that evolves with each benchmark iteration\.

NIL Token improvement process\.All columns withFinalFormatlabelled as NIL follow this protocol:

• Aggregate and rank all unmatched tokens by frequency\.

• Filter out meaningless or unstable entries\.

• Manually review high\-frequency candidates for domain relevance\.

• Integrate only validated and interpretable terms into theformatsandabbreviations dictionaries\.

## 4Results and Coverage Analysis

This section presents a comprehensive evaluation of the header\-centric semantic type detection framework across a diverse suite of tabular data benchmarks, including both classical STI datasets and large, real\-world sources\. We report coverage forFinalFormatassignments and Knowledge Graph mappings \(DBpedia and Schema\.org\), and complement quantitative results with qualitative interpretability evidence viaSourceKeywords\.

Sherlock\[ref13\]highlighted two main limitations of matching\-based, header\-dependent systems: they tend to recognise only a limited range of types, and they lack robustness when confronted with noisy or context\-dependent attributes\. The evaluation presented in this chapter directly addresses both points\. Broad lexical coverage is demonstrated through thedictionaries \(formatsandabbreviations\)and the 39FinalFormattypes\. Robustness is demonstrated through consistently high assignment rates across heterogeneous and noisy repositories, such as Kaggle and VizNet, where normalisation, abbreviation expansion,SourceKeywords, and NIL\-driven feedback enhance resilience under conditions where matching\-based systems have previously been shown to fail\.

### 4\.1Data Sources and Benchmarking Scope

Scalability, robustness, and practical coverage were evaluated across seven heterogeneous benchmarks \(Table 3\)\. The evaluation spans structured repositories \(UCI\[ref24\], Prague Relational Learning Repository\[ref26\]\), large collections of web tables \(Sato\[ref45\],VizNet\[ref12\]\), user\-generated real\-world tables \(Kaggle\[ref18\]\)and KG\-grounded benchmarks \(SOTAB\[ref20\],T2Dv2\[ref35\]\)\.

Table 2:Structural Statistics of Benchmarks\. T2Dv2 Domains \(\*\) correspond to DBpedia classes\.BenchmarkDomainsData SourcesColumnsColumns per Data SourceUCI65092218\.4Prague95052010\.4SatoN/A2,2544,5872\.0VizNetN/A11,19974,9156\.7Kaggle173,36449,72714\.8SOTABN/AN/A737N/AT2Dv239\(\*\)2371,1724\.9Universe definitions\.

Universe A\- All seven benchmarks\.

Universe B\- Union of unique header labels extracted from Kaggle and VizNet, comprising 118,639 unique headers \(after deduplicating identical header strings across both sources\)\. Used to study distribution, long\-tail behaviour and bounded\-numerical coverage at scale\.

### 4\.2Semantic Type Detection: Coverage and Diversity

We measure three aspects of semantic coverage across all benchmarks:

•FinalFormatTypes: number detected in each data source group\.

•SourceKeywords: unique, normalized header tokens extracted across all\.

• DBpedia/Schema\.org Types: number of distinct ontology classes/properties successfully linked from column headers to the respective ontologies after normalisation and abbreviation expansion\.

Table 4 summarises coverage\. VizNet and Kaggle yield higherSourceKeywordscounts due to scale; notably, Kaggle attains fullFinalFormattype coverage \(39/39 types\)\.

Table 3:Coverage ofFinalFormat,SourceKeywords, and KG TypesBenchmarkFinalFormatTypesSourceKeywordsDBpedia TypesSchema\.org TypesUCI33248162161Prague23139136129Sato15767663VizNet351,7921,0451,010Kaggle391,9201,0461,138SOTAB23349246684T2Dv221234213172A key result is thatonly 15 coreFinalFormatsdeterministically cover the entire76\-label Sherlock/Sato spacein many\-to\-one mappings\. Two extra labels from Sherlock do not appear in Sato \(File size and Team name\)\.

The consolidation preserves distinctions important for data quality \(e\.g\.,IDcolumn, date, postalcode\), and redundant semantic variants \(e\.g\., creator\-type labels\) merge naturally into compact categories, such asnameorcategorical\.

WithinUniverse B \(Kaggle \+ VizNet\), these 15 formats alone cover∼\\sim80%of the more than 118,000 headers\. The distribution is heavily concentrated in a few operationally critical types \(categorical, numerical\>=0, IDcolumn, string, numerical\)\. The complete list of these 15 types and their mappings to Sherlock/Sato is shown inAppendix B\[ref38\]\.

Beyond the 15 core types,Universe Bexhibits an additional 24FinalFormats, primarily bounded numerical values and domain\-specific formats such aspercentage, chemical \(ph, acidity\), health \(heartrate\), geography \(latitude/longitude\), among others\. These collectively represent∼\\sim6% of headers,totalling over 7,000 in this universe, which remain substantial in absolute terms,and enable finer\-grained Data Quality Issues \(DQI\) checks not supported in the Sherlock/Sato taxonomy\. The complete list is also reported inAppendix B\[ref38\]\.

AcrossUniverse B, NIL is approximately 13 percent \(thus Valid is∼\\sim87 percent\)\. Here, NIL denotes headers that did not match anyFinalFormatafter normalisation and abbreviation expansion\.

##### Scalability\.

The modest increase of 80% from∼\\sim2,100 dictionary entries \(UCI phase\[ref37\]\) to∼\\sim3,800 entries supported a growth of∼\\sim103 times in practical coverage, increasing valid assignments from∼\\sim1,000 to∼\\sim103,000 headers\. Details are provided in Table 5\.

Table 4:Scalability evidencePhaseDictionary sizeHeaders evaluatedValid headers assignedUCI baseline\[ref37\]1,800 \+ 300∼\\sim2,100∼\\sim1,000∼\\sim1,000 \(near perfect\)Kaggle\+VizNet2,800 \+ 1,000∼\\sim3,800118,639∼\\sim103,000 \(∼\\sim87%\)Bounded numerical formats\. Appendix C\[ref38\]lists all adopted bounds used in this study\. These intervals support finer\-grained DQI checks and help disambiguate numeric families within theFinalFormattaxonomy\.

### 4\.3NIL Token Improvement Process

A qualitative review of the top 100 NIL cases inUniverse Bshows that most unresolved headers are extremely short codes or symbols \(e\.g\.,no, so, ga, po\) that carry little or no semantic information and therefore fall outside any meaningfulFinalFormatmapping\.

A smaller subset of cases \(e\.g\.,streak, medal, designation, msrp\) exhibits domain\-specific or plausible abbreviations\. These are added only when their meaning is stable, and the mapping is interpretable\.

These observations confirm that the remaining NIL proportion mainly reflects low\-information tokens or highly specialised terminology rather than systematic gaps\. The complete ranked list of 100 NIL tokens is included inAppendix D\[ref38\]\.

### 4\.4Validity, NIL Rates, and Robustness

Table 6 reports NIL counts and Valid percentages for \(i\)FinalFormatassignments and \(ii\) KG mappings to DBpedia and Schema\.org acrossUniverse A\(all seven benchmarks\)\.

Definition of NILandValid%: NILindicates the absence of a match after all normalisation and expansion steps\. For all systems,Valid%is computed as \(\(Total Columns−\-NIL\) /Total Columns\) × 100\. AValid%column inFinalFormatcorresponds to a successful mapping to one of the 39 defined semantic types after all dictionary expansions\. For DBpedia and Schema\.org,Valid%measures the fraction of columns whose normalised header \(after the same cleaning and abbreviation expansion steps\) could be aligned to at least one ontology property/class by the KG mapping component described earlier\. This KG alignment is derived directly from header to ontology label similarity and is therefore independent of theFinalFormatassignment\.

Table 5:NIL Counts and Valid Percentages forFinalFormat, DBpedia and Schema\.orgBenchmarkTotal ColumnsFinalFormatDBpediaSchema\.orgNILValid%NILValid%NILValid%UCI9221298\.743353\.041355\.2Prague5200100\.09481\.99382\.1Sato4,5870100\.00100\.042390\.8VizNet74,9159,43587\.421,24471\.623,79568\.2Kaggle49,7277,27485\.416,54666\.717,46764\.9SOTAB737599\.316377\.9799\.1T2Dv21,17226777\.230574\.046960\.0Key Observations\.

•FinalFormatconsistently achieves the highest Valid percentages across the benchmarks, reflecting the broader lexical coverage provided by the curated dictionaries and the traceability supported bySourceKeywords\.

• Sato obtains 100% Valid forFinalFormat, indicating full coverage of this benchmark and compatibility with the Sherlock/Sato label space\.

• Sato also reaches 100% Valid for DBpedia, since its annotated semantic labels correspond directly to DBpedia classes, demonstrating strong compatibility between this benchmark and the ontology vocabulary\.

• By contrast, KG mapping coverage is notably lower for UCI and Kaggle, which is consistent with their more heterogeneous headers, greater use of domain\-specific vocabulary, and cases in which suitable ontology properties or classes are unavailable or similarity\-based alignment yields NIL\.

### 4\.5Handling Ambiguous Headers

Beyond straightforward headers, the system also resolves complex, abbreviated, and domain\-specific cases through the combined effect of normalisation, abbreviation expansion andSourceKeywordsextraction\. These mechanisms enable the framework to interpret signals such as“is”, “has” \(binarycues\),“range” \(categoricalcontext\),“birth place”\(geographical semantics\) or medical abbreviations such as“trestbps” \(bloodpressure\)\. This avoids misclassification in cases where multiple semantic cues coexist or where the lexical form is highly compressed\.

These challenging cases demonstrate the system’s ability to surpass surface\-level matching and produce interpretable, rule\-alignedFinalFormats, even in noisy or unconventional metadata\. A detailed description of the rule\-based preprocessing, normalisation, abbreviation expansion and KG annotation steps, together with an extended set of worked examples showing howSourceKeywordsandFinalFormatsare assigned to complex headers, is provided inAppendix E \(Table G\)\[ref38\]\.

### 4\.6SemTab 2024 Metadata\-to\-KG Evaluation

Ground\-truth note\. As detailed inAppendix F\[ref38\], theSemTab\-2024 Metadata\-to\-KG ground truth \(GT\)exhibits typical large\-benchmark issues, including duplicates, label\-granularity mismatches and occasional errors\. We therefore reported results in two layers:

1. 1\.Theofficial GT\-strict scores, which enable head\-to\-head comparison with other systems, and
2. 2\.Blindedinternal diagnostics for our own outputs, which characterise disagreement patterns under header\-centric metadata\-only evidence\.

Official \(GT\-strict\) results\.Using the organisers’ ground truth and scripts, the system correctly annotated 63/141 columns \(Hit@1 = 0\.45, 95% CI≈\\approx\[0\.36, 0\.53\]\) and 67/141 \(Hit@5 = 0\.48, 95% CI≈\\approx\[0\.40, 0\.56\]\)\. Baselines for Adwan\[ref43\]and for CVA/ MetaLinker\[ref25\]were taken from the SemTab\-2024 official report\[ref11\]\. These head\-to\-head figures appear inPanel A of Table 7\.

Table 6:Comparative analysis on the SemTab 2024 Metadata\-to\-KG trackPanel A \- Official \(GT\-strict\) SystemHit@1Hit@5Ours \(GT\-strict\)0\.45 \[0\.36, 0\.53\]0\.48 \[0\.40, 0\.56\]Adwan \(Vandemoortele et al\., 2024\)\[ref43\]0\.750\.92CVA / MetaLinker \(Martorana et al\., 2024\)\[ref25\]0\.550\.70Panel B \- Diagnostic \(ours only\) CategorySupport@1Support@5B1:Strict \+ C\.1 \(GT\-Confirmed\)0\.45 \[0\.36, 0\.53\]0\.48 \[0\.40, 0\.56\]B2:B1 \+ C\.2 \(GT\-Refinement\)0\.75 \[0\.68, 0\.82\]0\.78 \[0\.70, 0\.84\]B3:B2 \+ C\.3 \(Alternative\)0\.79 \[0\.72, 0\.85\]0\.83 \[0\.75, 0\.88\]

Internal diagnostic audit \(ours only\)\.A blinded post\-hoc audit of our predictions was conducted using the predefined rubric described inAppendix F\[ref38\]:

C\.1 GT\-Confirmed \(same canonical entity\),

C\.2 GT\-Refinement \(ontology\-consistent and more appropriate for the header\),

C\.3 Ontology\-Consistent Alternative \(plausible but not in GT\), and C\.4 Incorrect\.

Panel B of Table 7reports the cumulative diagnostics \(B1 strict \+ C\.1, B2 \+ C\.2, B3 \+ C\.3\) together with95% CI\. These figures are not revised benchmark scores and are not directly comparable to the official GT\-strict results inPanel A\. Here, C\.2 GT\-Refinement contributed43/141 \(30\.5%\)cases and C\.3 Alternatives6/141 \(4%\)\. Cumulative diagnostic support rises from 0\.45 under strict GT to≈\\approx0\.75 with C\.2, and to≈\\approx0\.79 with C\.3\. This suggests that a substantial subset of GT\-strict mismatches is associated with label granularity, aliasing, or ontology\-selection effects, rather than with wholly implausible header\-centric predictions\. This audit, therefore, highlights recurringSemTab\-2024 GTlimitations under metadata\-only evidence and supports the framework’s use for KG\-oriented benchmark diagnosis and quality analysis\.

### 4\.7Illustrative Case Studies from Real Datasets

To demonstrate the operational behaviour of the framework, we highlight representative examples from real\-world datasets\.

##### Dataset 352 \- Online Retail\.

TheDescriptionattribute, classified asString, triggered:

- •DQI \#1 \(Missing Data\): 1,454 blank or null values\.
- •DQI \#17 \(Wrong Data Type\): one numeric value incorrectly present in a textual field\.

TheCustomerIDattribute, classified asIDcolumn, revealed layered violations:

- •DQI \#1 \(Missing Data\): 135,080 missing values\.
- •DQI \#9 \(Duplicates\): 541,830 repeated identifiers\.
- •DQI \#19 \(Uniqueness Violation\): 537,536 explicit uniqueness violations\.

This illustrates how identifier semantics activate simultaneous completeness and uniqueness constraints\.

##### Dataset 45 \- Heart Disease\.

The attributethalach\(maximum heart rate\), classified as numerically bounded \(FinalFormatheartrate\), triggered a domain violation of DQI \#15 due to a value exceeding the medically plausible upper bound\.

In contrast, the attributeage, also a numerically bounded type \(FinalFormatage\), passed all validation checks with observed values within the expected range \(29\-77\), demonstrating the correct semantic alignment\.

### 4\.8HeadersIQ: Data Source\-Level Data Quality Measurement

Applying the metric defined in Subsection[3\.5\.1](https://arxiv.org/html/2610.10541#S3.SS5.SSS1), we compute data source\-level quality scores across the evaluated benchmarks\.

For example, Dataset 45 \(303 rows, 14 columns;T=4242T=4242\) containsV=7V=7cells with at least one detected violation:

HeadersIQ=\(1−74242\)×100≈99\.83\\textit\{\{HeadersIQ\}\}=\\left\(1\-\\frac\{7\}\{4242\}\\right\)\\times 100\\approx 99\.83
Scores close to 100 indicate few detected violations, while lower values reflect increasing levels of detected structural, semantic, or representational issues\. Because the metric is normalised by data source size, it enables direct comparison across heterogeneous tabular sources\.

HeadersIQsupports quality\-aware data preparation by enabling ranking and monitoring of tabular sources prior to knowledge graph integration\. In this sense, it provides a lightweight governance signal relevant to data source\-level reliability in settings such asSemTab 2024 “IsGold?”and related KG quality assessment work, includingKG2Tables\.

Representative examples and the full results table are provided inAppendix G\[ref38\], together with implementation details in theAttribute\-BasedDataQualityAssessment\.ipynbnotebook\[ref38\]\.

## 5Discussion

### 5\.1Reassessing Header\-Centric Type Detection

Header\-centric annotation has often been regarded as unreliable, partly influenced by early approaches such as Sherlock\[ref13\]and Sato\[ref45\]\. Our results challenge this view\. With systematic preprocessing, curated and incrementally enriched dictionaries, and abbreviation expansion, headers alone contain enough semantic structure to support precise and scalable type assignments\. The 39FinalFormattypes provide a compact operational layer between primitive data types and fine\-grained ontology classes: richer than atomic types, more compact than the Sherlock/Sato label space, and simple enough to trigger interpretable data quality rules, whileSourceKeywordspreserve finer\-grained lexical evidence for auditing and KG\-oriented interpretation\.

These comparisons should be interpreted in light of task setting\. Systems such as Sherlock and Sato were designed primarily for broader semantic type detection scenarios that may exploit richer supervision or table\-value context, whereas the present framework targets metadata\-only, header\-centric interpretation with explicit traceability and DQA activation\. The goal is therefore not to outperform value\-aware systems on their native setting, but to show that interpretable header\-centric typing remains practically effective at scale under metadata\-only constraints\.

### 5\.2General\-Purpose Core and Domain\-Specific Long\-Tail Modelling

A modest dictionary expansion \(approximately 80% more entries\) enabled more than 100\-fold growth in practical coverage, increasing valid assignments from approximately 1,000 in the UCI phase to roughly 103,000 across more than 118,000 heterogeneous headers\. This suggests that NIL\-driven feedback can expand lexical coverage substantially without requiring equally large growth in the dictionaries\. At the same time, the 76 Sherlock/Sato types map cleanly into only 15 coreFinalFormatcategories\. An additional 24 domain\-specific types extend the taxonomy to cover real\-world long\-tail cases without creating an overly fragmented label space\. Consistent results across UCI, Prague, Sato/VizNet, Kaggle, SOTAB, and T2Dv2 indicate that the same set of 39FinalFormatsremains broadly usable across heterogeneous benchmarks, while the parallel KG\-mapping pathway maintains alignment with DBpedia and Schema\.org\. In this sense, the 39FinalFormatsfunction as a compact operational vocabulary: large enough to support interpretable DQA activation and real\-world long\-tail cases, yet small enough to remain auditable, stable, and reusable across diverse data sources\.

### 5\.3Data Source\-Level Quality viaHeadersIQ

HeadersIQprovided intuitive data quality scores across sources of varying sizes, offering a scalable way to monitor detected issues in large repositories\. Its design is relevant toSemTab 2024 “IsGold?”andKG2Tables\-style data source reliability questions and illustrates the practical value of linking semantic typing with automated data\-quality assessment\.

### 5\.4Interpreting Ground Truth in SemTab 2024

OfficialSemTab 2024 Metadata\-to\-KGresults yielded Hit@1 = 0\.45 and Hit@5 = 0\.48\. A blinded header\-centric audit indicates that a substantial subset of GT\-strict mismatches is associated with granularity, aliasing, or ontology\-selection effects\. This diagnostic evidence suggests that rigid GT matching can obscure semantically plausible metadata\-only predictions and supports future CTA benchmarks with multi\-label or graded evaluation, together with explicit human\-in\-the\-loop validation\.

### 5\.5Limitations and Future Work

The main limitations are \(i\) dependence on meaningful headers and \(ii\) difficulty with long\-tail terms\. Several results in this paper are coverage\-oriented rather than direct correctness measures; ongoing work includes aStatistical AuditforFinalFormatcorrectness and a KG vocabulary\-gap analysis of frequentSourceKeywordswithout exact DBpedia or Schema\.org terms\. Future work should combine header and value signals, integrate multilingual models, and explore LLM\-based disambiguation for sparse, overloaded, or over\-specialised metadata

## 6Conclusion

This paper presents an explainable, header\-centric CTA framework for metadata\-only semantic typing that combines normalization, curated dictionaries, andSourceKeywordsto assign 39FinalFormattypes\. The same abstraction layer supports mappings to DBpedia and Schema\.org, grounding cell\-level data quality checks that aggregate into the data source\-level scoreHeadersIQ\.

Experiments on around 120,000 header columns from seven benchmarks, together with a diagnostic audit of theSemTab 2024 Metadata\-to\-KG track, show that the framework supports large\-scale metadata\-only semantic table interpretation, while also providing useful benchmark\-diagnostic evidence for KG\-oriented evaluation\. This positions the framework as a practical contribution to metadata\-driven semantic annotation, quality\-aware tabular preparation, and trustworthy knowledge\-graph integration\. More broadly, the framework also reflects robustness concerns that remain central in recent SemTab editions, particularly under noisy, ambiguous, and incomplete tabular metadata, while also opening opportunities for multilingual and LLM\-assisted extensions in future work\.

## Declaration on Generative AI

During the preparation of this work, the authors used ChatGPT/GPT5 \(OpenAI\) in order to: Grammar and spelling check, Paraphrase and reword, Improve writing style, and Formatting assistance\. Further, the authors used ChatGPT/GPT5 \(OpenAI\) to assist with the development, debugging, and explanation of code used in the research workflow\. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content\.

## References