arXiv CSopen access

Clean Me If You Can: A Large Collection of Real-World Addresses for Data Cleaning Benchmarking

Clean Me If You Can: A Large Collection of Real-World Addresses for Data Cleaning Benchmarking [Experiment, Analysis & Benchmark] Fatemeh Ahmadi1 , Tobias Bernhard1 , Mohamed Abdelmaksoud1 , Luca Zecchini1 , Tilmann Rabl2 , Ziawasch Abedjan1 1 BIFOLD & TU Berlin, 2 Hasso Plattner Institute, Potsdam

{f.ahmadi,mohamed,luca.zecchini,abedjan}@tu-berlin.de,[email protected],[email protected]

arXiv:2606.31983v1 [cs.DB] 30 Jun 2026

ABSTRACT There has been extensive research on automating and scaling data cleaning, i.e., the detection and correction of erroneous values in tabular data. Yet, existing approaches often perform well only within controlled environments. One of the major bottlenecks in data cleaning research is the lack of real-world datasets. In this paper, we address this gap by providing a large, dirty dataset with postal entries and their corresponding ground truth. We discuss the design decisions and challenges for obtaining the dataset. We demonstrate the limitations of existing cleaning approaches when faced with our proposed datasets and derive guidelines for future research. PVLDB Reference Format: Fatemeh Ahmadi, Tobias Bernhard, Mohamed Abdelmaksoud, Luca Zecchini, Tilmann Rabl, Ziawasch Abedjan. Clean Me If You Can: A Large Collection of Real-World Addresses for Data Cleaning Benchmarking. PVLDB, 20(1): XXX-XXX, 2026. doi:XX.XX/XXX.XX PVLDB Artifact Availability: The source code, data, and other artifacts have been made available at https://github.com/D2IP-TUB/Clean-Me-If-You-Can.

1

INTRODUCTION

Ensuring high-quality data is a cumbersome process that requires numerous exhaustive human cycles [26]. Data cleaning research aims to automate this task, proposing a large number of rulebased [32], learning-based [23], and, more recently, LLM-driven [39] approaches. Although individual papers often report improved results, industrial adoption remains a challenge. This is partially due to the fact that many approaches are not scalable, or they target specific error types and distributions that do not reflect the complexity of the real world [16]. One impeding factor to data cleaning research is the absence of real-world benchmark datasets to guide the research progress. For evaluating a cleaning algorithm, two versions of a dataset are necessary: the so-called dirty version, which requires cleaning, and the ground truth, which contains all records in the desired cleaned format. Generally, there are three possible approaches to obtain This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing [email protected]. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 20, No. 1 ISSN 2150-8097. doi:XX.XX/XXX.XX

such benchmark datasets: (i) a supposedly clean dataset is dirtied using error generators [4, 16], (ii) a dirty dataset is manually curated to obtain the corresponding ground truth [3], or (iii) the ground truth does not exist and the success of a downstream task, such as inference accuracy, is used as a proxy for cleanliness [19, 25, 34]. Each of these approaches is generally viable but has specific limitations. Error generators are useful for benchmarking algorithm behavior in controlled environments, but they often rely on randomness or explicit patterns, in contrast to latent patterns that manifest in the real world. Tabular errors result from systematic flaws in data collection, such as human typos, flawed extractors, outdated values, etc. In contrast, when building a benchmark from naturally dirty data, the central challenge is constructing ground truth at scale. This is either feasible for small-scale datasets or for very obvious errors that can be cleaned with very simple heuristics. Finally, using downstream task performance circumvents the need for obtaining ground truth. However, downstream proxy scores are not always guiding towards a clean version of a dataset, as proxy scores such as downstream inference accuracy might even improve through artificial noise [25]. To address the lack of realistic large-scale benchmark datasets, we put our efforts into providing researchers and practitioners with a real-world dataset that can be used for benchmarking data cleaning solutions. Cleaning postal information has been a primary use case in data quality assessment, as companies try to retain curated information about (prospective) customers [35], suppliers, and partners [11]. The famous case of the 6.8 billion pieces of mail that could not be delivered as addressed [38] further underpins the importance of data quality in such a context. Despite this relevance, a real-world benchmark address dataset has so far been missing. Prior research was conducted on either proprietary address datasets or a rather limited restaurant dataset [3]. In this paper, we present a dataset that contains real addresses of organizations across the world with real-world data quality problems. To obtain this dataset, we exploited the Web Data Commons (WDC) corpus [8] and used Web services to collect postal information on public entities. The resulting dataset contains up to 9,317,886 records, which exhibit data quality issues that stem from language inconsistencies, inaccuracies, obsolescence, and extraction limitations [2]. We also provide further variations of the dataset that differ in terms of geographical scope, type of entities, and cleanliness. We show that a rather low-dimensional real-world dataset is already challenging for state-of-the-art research prototypes, opening avenues for further research in error detection and correction. In summary, we make the following contributions.

(1) We present a real-world benchmark dataset for scalable data cleaning that contains real errors. We also provide the corresponding ground truth derived from geocoding services. We share our process for obtaining this benchmark dataset. The process is fully reproducible and our dataset and extraction code are available online. (2) We conduct an extensive evaluation that highlights the limitations of existing approaches for both error detection and correction. None of the evaluated data cleaning approaches can reliably clean the dataset or even its slices. Learning-based approaches generally achieve strong effectiveness, but they also expose clear scalability limitations. (3) We identify and discuss future directions for data cleaning research, supported by empirical evidence from our benchmark and evaluation. In particular, our results show the need for approaches that can benefit from corrections beyond the input dataset, balance classic rule-based, learning-based, and LLMdriven strategies, and scale not only with respect to the number of rows and columns, but also across different error rates and error distributions.

2

Data Cleaning for Machine Learning. Data cleaning can be an operator within a data science pipeline [33]. Thus, one can measure the effectiveness of cleaning using downstream model performance as a proxy. Karlaš et al. proposed CPClean [17], a data cleaning framework built on top of machine learning pipelines, and evaluated the impact of cleaning in the context of k-nearest neighbor classifiers. Abdelaal et al. proposed REIN [1], a benchmark framework that enables data cleaning evaluation for downstream machine learning tasks, such as regression, classification, and clustering. While using downstream accuracy is viable in some scenarios, it does not serve for general-purpose data cleaning assessment. Indeed, it can be misleading, as the downstream performance optimum often differs from the performance on the actual ground truth data [25]. With our benchmark dataset, we expand existing test cases in two directions: we provide a very large real-world dataset with ground truth and we curate smaller subsets for specific analysis tasks. Our dataset is significantly larger than existing academic datasets, showcasing the limitations of current cleaning methods.

3

ADDRESS DATASET

In this section, we iterate through the requirements we expect a benchmark dataset for data cleaning to meet and introduce the design of the targeted schema.

RELATED WORK

Benchmark datasets for data cleaning appear in three adjacent lines of research.

3.1 Data Cleaning Research. Most real-world benchmark datasets have been established on-the-fly while proposing novel data cleaning techniques. This is the case for datasets like Hospital [9], Flights [20], Rayyan [29], or Beers [14]. In 2015, Abedjan et al. [3] conducted an evaluation of state-of-the-art error detection techniques from that time. To focus on real-world errors, the authors mostly relied on proprietary datasets. Ni et al. extended the evaluation to data repair [27]. Overall, most of the existing datasets are either small or contain errors that are easy to identify and fix. For example, Flights contains duplicate records acquired from different sources and presents a strong correlation between the source of a record and its quality. Thus, errors can be easily detected and corrected using records from higher-quality sources.

Dataset Requirements

The main goal of this benchmark dataset is to support data cleaning research. We therefore identify several requirements that the final benchmark should fulfill. (1) Relevant domain. The dataset should belong to a common domain for data cleaning and the errors should closely mirror those present in real-world data. (2) Content variations. The dataset should capture a diverse set of data relationships at row and column levels. Thus, it should exhibit redundancy and conflicting records, different data types, as well as both related and independent attributes. (3) Error diversity. The data should encompass various error types, such as missing values, inconsistent formatting, contradictory data, misspellings, or nonsensical values. Some errors should be easy to fix without additional context, while others might require consideration of attribute relationships and external knowledge. (4) Ground truth labels. We are interested in how well a system can detect and correct errors. With the ground truth data for each record it is possible to determine which values are erroneous and what the correct value should be, enabling the calculation of metrics such as precision and recall. (5) Provenance. The dataset should track the origin of each record. This enables transparent inspection of benchmark construction and allows future users to verify, reproduce, or extend the dataset.

Error Generators. Several benchmarking papers provided error generation tools for datasets. BART [4] represents one of the earliest efforts to systematically generate data errors for benchmarking data cleaning systems, enabling controlled injection of diverse error types into clean databases. It remains widely used for constructing synthetic benchmarks [1]. JENGA [33] is a framework that includes a data corruption module to study the impact of data quality issues on downstream machine learning tasks. GouDa [31] is a data generation tool that creates datasets with specific error types without requiring an initial clean table. More recently, Jung et al. [16] argued that errors in real-world data often depend on the data itself, whereas many existing benchmarks inject errors independently of the underlying data. They proposed a latent-factor model that captures dependencies between data values and error occurrences through shared latent variables. While these frameworks facilitate controlled evaluations, they still produce synthetic errors with a set of predefined types rather than naturally occurring ones, limiting their ability to reflect the full diversity of real-world data issues.

3.2

Domain: Postal Addresses

For our benchmark dataset, we choose the domain of postal information. Postal address data is prevalent in a wide range of real-world applications, such as e-commerce or logistics. It is one of the most common types of data that is subject to cleaning [3]. While prevalent, address information is often challenging, as formats do not follow a single, universally adopted standard. 2

(4) Retrieve reference addresses. We searched for corresponding reference addresses using a geocoding service. After matching and validation, we treat these reference addresses as groundtruth records. The matching and validation procedure is discussed in detail in Section 4.2. → 29.7M pairs of dirty and ground-truth records (5) Align the schema for dirty and ground-truth records. We mapped the attributes of dirty and ground-truth records to a common schema and excluded pairs in which the ground-truth record contained imprecise or incomplete information. We also removed exact duplicates, i.e., records that appeared multiple times in the exact same format on the same Web page. → full-unnamed address dataset: 9,317,886 dirty records with the corresponding ground truth (without names) (6) Filter out entity mismatches. We ensured that the name referred to the same real-world entity in both the dirty record and the corresponding ground truth. → full-named address dataset: 4,338,109 dirty records with the corresponding ground truth (with names). We further refined the full-named dataset into several variations. A detailed overview of all datasets and their key properties is provided in Table 2. Next, we describe each step in the dataset generation process in further detail.

As a result, the address structure can vary considerably depending on local postal conventions and cultural differences. For instance, the house number typically precedes the street name in US addresses (e.g., 17 Main Street) and follows it in German addresses (e.g., Hauptstraße 17). Addresses commonly include abbreviations, and even punctuation is often used inconsistently, separating address components through commas, whitespaces, or dashes. Further, address styles can be heavily location-specific. For example, the old town of Mannheim in Germany employs a distinctive addressing scheme using block-level identifiers and house numbers, while other districts of Mannheim adhere to the conventional German format based on street name and house number. Finally, postal data often exhibit missing values: while fields such as street or locality are integral to an address, other fields such as region or country are frequently missing.

4

DATASET CREATION

Choosing the postal domain for benchmarking also has practical advantages, as the data and ground truth are generally accessible and understandable by any data engineer. Yet, as we will describe in this section, the scalable extraction and annotation of addresses requires a careful process for searching and postprocessing. A rich source for arbitrarily created datasets that are operational is the Web. Thus, one could extract visible addresses in regular Web dumps, such as the Web Data Commons (WDC) corpus [8]. At the same time, there are several commercial services that provide clean address records. The process can be divided in six major steps that are introduced below and detailed and justified in the following subsections.

4.1

Dirty Data Collection

To obtain addresses in their dirty version, we used structured data pre-extracted from Common Crawl snapshots and publicly released as RDF N-Quads by the WDC project [8]. We used the WDC release for December 2024, the most recent at the time of data collection.

(1) Download WDC N-Quads. The WDC project extracts structured data from Common Crawl1 and publishes pre-extracted RDF statements in N-Quads format [8]. We downloaded all class-specific Schema.org subsets2 that contain PostalAddress annotations3 , covering types of points of interest (POIs) such as Library, Hotel, and Hospital, as well as the html-mf-adr subset from the Microformats source4 . → 12.9B N-Quads from 22 Schema.org subsets → 41M N-Quads from the html-mf-adr subset (2) Extract address information. We parsed the downloaded N-Quads to identify address entities and reconstruct them as dataset records. We extracted schema:PostalAddress entities from the class-specific Schema.org subsets and vcard:Address entities from the html-mf-adr subset. After collecting its fields, each extracted address entity is represented as one dirty record, as it may contain errors. → 247.9M dirty records from schema:PostalAddress entities → 11.8M dirty records from vcard:Address entities (3) Filter out unverifiable addresses. We discarded dirty records that provided neither street name, nor locality, nor postal code, as their information was insufficient for geocoding validation. → 219.9M dirty records from schema:PostalAddress entities → 8.5M dirty records from vcard:Address entities

4.1.1 Address Extraction. We extracted records containing address information from two complementary WDC sources: Schema.org and Microformats. Class-specific Schema.org subsets. WDC extracts Schema.org annotations from Web pages and publishes them in class-specific subsets according to the annotated entity type, such as Library, Hotel, and Hospital. We downloaded all 22 subsets that contain entities with schema:PostalAddress annotations, comprising 12.9B RDF statements in N-Quads format. In this format, each line encodes a single (subject, predicate, object, graph IRI) tuple, where graph IRI represents the source page URL. Each address is therefore distributed across multiple lines, one per field, as shown in Listing 1. For each node typed as schema:PostalAddress, we extracted its address fields, including streetAddress, postalCode, addressLocality, addressRegion, and addressCountry. We then searched for an entity whose schema:address property pointed to that address node. From this entity, we extracted its schema:name property. In Listing 1, _:b1 is the address node, and _:b0 is the LocalBusiness entity whose address is _:b1. Listing 2 shows a simplified extracted address with selected fields. html-mf-adr Microformats subset. WDC also provides a formatspecific dump for the html-mf-adr microformat, where address fields are encoded as HTML class names and extracted into the W3C vCard vocabulary, as shown in Listing 3. This subset covers 41M RDF statements in N-Quads format across nine shards. We remapped vCard predicates to Schema.org field names to ensure a uniform structure across both sources.

1 https://commoncrawl.org 2 https://webdatacommons.org/structureddata/2024-12/stats/schema_org_subsets.

html 3 https://schema.org/PostalAddress 4 https://webdatacommons.org/structureddata/2024-12/stats/stats.html 3

_:b0 _:b0 _:b0 _:b1 _:b1 _:b1

rdf:type schema:LocalBusiness schema:name "NAME" schema:address _:b1 rdf:type schema:PostalAddress schema:streetAddress "STREET" schema:addressLocality "CITY"

<example.de/page> . <example.de/page> . <example.de/page> . <example.de/page> . <example.de/page> . <example.de/page> .

https://nominatim.openstreetmap.org/search .... ?amenity=extracted.name .... &street=extracted.streetAddress .... &city=extracted.addressLocality .... &postalcode=extracted.postalCode .... &state=extracted.addressRegion .... &country=extracted.addressCountry .... &format=geojson .... &limit=1 .... &addressdetails=1 .... &extratags=1

Listing 1: N-Quads example from the LocalBusiness Schema.org subset. The address node (_:b1) is linked to its parent entity (_:b0) via schema:address.

Listing 4: The parameters used to query each dirty address through the Nominatim API.

{ "address": { "streetAddress": "STREET", "addressLocality": "CITY", }, "name": "NAME", "graph_iri": "https://example.de/page"

reliable address-level matches, and sufficient throughput for hundreds of millions of queries. We therefore considered both proprietary geocoding services and open alternatives. Proprietary services such as Google Places, HERE, and Geocode.xyz provide geocoding APIs, but their use at scale is constrained by a combination of licensing costs, rate limits, and regional coverage restrictions. Some services are optimized for specific countries or regions, while others become impractical for 228.4M queries under their public rate limits or pricing models. We also considered three open alternatives: (i) Overture Maps5 , a dataset of approximately 446M addresses stored as GeoParquet files on S3, which can be queried offline via DuckDB; (ii) OpenAddresses6 , a collection of roughly one billion addresses distributed as GeoJSON files, also queryable via DuckDB; and (iii) Nominatim7 , the geocoding front-end of OpenStreetMap (OSM), which is available as a public RESTful API and can also be self-hosted to support high-throughput querying. To assess their suitability for generating ground truth at scale, we compared them on a stratified sample of 1k dirty addresses to preserve the original distribution of countries and points of interests (POIs). For each service, we queried the sampled addresses and scored the returned matches based on fuzzy string similarity across house number, street name, postal code, and locality. Nominatim was able to match with high confidence 96.5% of the dirty addresses. We further verified a random sample of 1k addresses against the Google Address Validation API8 , finding 99.1% agreement between the two sources. The two alternatives showed substantial coverage gaps: Overture Maps and OpenAddresses covered only 39 and 19 countries, matching 10.8% and 33.4% of the dirty addresses, respectively. Both significantly struggled with regions outside Europe. The strong performance of Nominatim can be mainly attributed to two factors. First, OSM maintains rich POI data, such as hotels, restaurants, and public amenities, that align well with the entities in our dataset. Second, the structured search endpoint provided by Nominatim accepts individual address fields, which reduces ambiguity compared to free text. Based on these findings, we selected Nominatim as the geocoding service for ground truth generation, and we deployed a self-hosted instance capable of handling several hundred requests per second.

}

Listing 2: Address extracted from the example in Listing 1.

_:b0 _:b0 _:b0 _:b0

rdf:type vcard:street-address vcard:locality vcard:country-name

vcard:Address "STREET" "CITY" "COUNTRY"

<example.com/page> . <example.com/page> . <example.com/page> . <example.com/page> .

Listing 3: N-Quads example from the html-mf-adr subset, using the W3C vCard vocabulary. Unlike Schema.org, no parent entity is linked, so the place name is unavailable.

This extraction phase yielded 247.9M schema:PostalAddress entities from the Schema.org subsets and 11.8M vCard:Address entities from the html-mf-adr subset. After collecting its fields, we represent each extracted address entity as one dirty record. 4.1.2 Address Filtering. To focus validation on records with sufficient spatial evidence, we retained only dirty records containing at least one core address signal: streetAddress, addressLocality, or postalCode. This filtering step removes records whose address information is too sparse to be meaningfully validated, while preserving the vast majority of usable records. After filtering, 219.9M dirty records remain from the Schema.org subsets (88.7% retention rate) and 8.5M from the html-mf-adr subset (71.9% retention rate). Together, they form a combined pool of 228.4M dirty records.

4.2

Ground Truth Generation

To generate the ground truth, we need to find a true representation for each address. This would normally require the definition of a desired target representation, followed by the manual verification of each dirty address. Unfortunately, the latter is not scalable. Alternatively, one can compare each dirty address with the corresponding representation in a trusted source. The challenge is ensuring that each address is correctly matched. Following this intuition, we resorted to a mixed approach, where we first tried to match each dirty address to its representation provided by a geocoding service, then applied manually crafted scripts to filter out inconsistencies.

4.2.2 Geocoding Service Querying. For each dirty record, we queried the Nominatim API through its /search endpoint to retrieve the 5 https://overturemaps.org 6 https://openaddresses.io

4.2.1 Geocoding Service Selection. Generating ground truth at this scale requires a geocoding service with broad geographic coverage,

7 https://github.com/osm-search/Nominatim 8 https://developers.google.com/maps/documentation/address-validation

4

Extracted Addresses (Before alignment)

Aligned Schema

OSM Addresses (Before alignment)

name

name

name

road

road

house_number

house_number

postcode

postcode

addressLocality

locality

city, town, village, borough neighborhood, hamlet, municipality

addressRegion

region

region, state county, province, state_district

country

country

country_code

country_code

Similarly, OSM stores both the country name and its ISO 3166-1 alpha-2 code10 , each in a dedicated field. In contrast, PostalAddress uses a single addressCountry attribute, which can contain either the country name or its code. We decided to keep both fields in the aligned schema and to move the addressCountry value to country_code if it matched with the required two-letter pattern. Finally, addressLocality and addressRegion attributes have many possible correspondences in OSM, listed in Figure 1. Each location returned by Nominatim can contain one or more of these fields, requiring a flexible approach to identify the most appropriate value for the ground truth. Specifically, we favored the city and town (region and state) fields, semantically closer to the concept of locality (region) in PostalAddress, considering the remaining ones only if none of them were present. The edit distance from the extracted value, computed using the well-known Damerau-Levenshtein metric [10], was then used as the tie-breaking criterion in case multiple (non)preferred fields were present at the same time.

streetAddress

postalCode

4.2.4 Ground Truth Filtering. After obtaining ground truth addresses from Nominatim, we applied a validation and normalization pipeline before constructing the benchmark dataset. First, we filtered out 183.8M addresses (about 80% of our queries) for which Nominatim did not return any matching location. To further ensure completeness, we removed addresses whose corresponding ground truth entries were missing values for at least one attribute, excluding name. Indeed, as name was missing in more than 42% of the remaining entries, removing them would have significantly reduced the size of the dataset. We opted therefore to create two versions of the dataset: (i) full-unnamed (9,317,886 addresses), obtained by retaining all remaining addresses, dropping the name attribute from both the extracted dirty dataset and the ground truth; (ii) full-named (4,338,109 addresses), obtained from the portion of addresses for which the name was present in the ground truth, after a further refinement step using name similarity as a heuristic to identify and remove inaccurate matches. We measured similarity through token set ratio11 due to its robustness to different word ordering and partial overlaps. A perfect threshold (100%) was chosen after string normalization (lowercasing and converting to a canonical Unicode form) to ensure that distinct co-located entities were not mistakenly aligned. In both dataset versions, duplicate addresses originating from the same source page and sharing identical attribute values in both the dirty dataset and the ground truth were removed. Finally, to further improve the consistency of the locality attribute in the ground truth, we used publicly available countrybased lists of recognized localities, e.g., Gemeinden in Germany12 or places/subdivisions in the US13 , to maintain the same level of granularity in the locality attribute. For each ground-truth entry, we checked the presence of a certified locality in that region from the list, allowing fuzzy matches based on containment or edit distance, and we updated the locality of that entry to the certified one in case it was reporting a different value.

addressCountry

Figure 1: Schema alignment between extracted addresses (dirty records) and OSM addresses (ground truth).

corresponding representation in the OSM database. The query template, which exploits the structured information provided by the PostalAddress schema, is shown in Listing 4. Based on the additional parameters, Nominatim returns the closest match in JSON format. The result is a JSON object that includes address details and additional information about the location, such as opening hours. Relevant fields for our use case are: (i) name, i.e., the name associated with the location; (ii) place_rank, an integer that reflects the granularity of the location (higher values correspond to more specific location types); (iii) address, a nested JSON object that includes the address details of the location. Unfortunately, the address details returned by Nominatim do not adhere to the PostalAddress schema. We therefore need to perform schema alignment by defining appropriate mappings and transformations. 4.2.3 Schema Alignment. Figure 1 provides an overview of the designed alignment between the PostalAddress schema and the address details returned by Nominatim. While name and postcode can be aligned directly, most fields require more refined strategies to handle structural differences. For instance, OSM uses two independent fields to store the street name and the house number, which are instead combined into a single streetAddress attribute in PostalAddress. To unify the two representations, we split streetAddress into road and house_number to keep a more modular representation of the address. We extracted the street name and house number from streetAddress using libpostal9 , a popular address parser. If libpostal could not identify one of the two components, the corresponding value was set to null in the dirty version of the dataset.

10 https://www.iso.org/iso-3166-country-codes.html 11 https://rapidfuzz.github.io/RapidFuzz/Usage/fuzz.html#token-set-ratio 12 https://public.opendatasoft.com/explore/assets/georef-germany-gemeinde/ 13 https://public.opendatasoft.com/explore/assets/georef-united-states-of-america-

place/ and https://public.opendatasoft.com/explore/assets/georef-united-states-ofamerica-county-subdivision/

9 https://github.com/openvenues/libpostal

5

Table 1: Number of distinct values for each attribute in the ground truth of the full-named and full-unnamed datasets. Dataset version full-named full-unnamed

_id

name

house_number

road

postcode

locality

region

country

country_code

graph_iri

4,338,109 9,317,886

357,323 —

30,417 74,539

157,530 412,231

90,819 152,099

39,810 61,579

1,263 1,461

128 135

127 135

2,911,740 6,240,792

we can count 427,885 and 1,457,806 distinct records in the ground truth of the full-named and full-unnamed versions, respectively. In the full-named version, multiple named entities can be located at the same address. On average, each distinct address hosts 1.03 distinct entities, with a maximum of 51 co-located entities. Functional Dependencies. Our dataset presents multiple functional dependencies (FDs), which can serve to detect errors and generate repairs in rule-based tools. The full-named version contains 14 FDs for country and 10 for country_code, involving one (e.g., country → country_code15 ), two (e.g., postcode, locality → country), or three attributes on the left-hand side (e.g., house_number, road, postcode → country). Country-based subsets may contain additional dependencies. For example, in German addresses region can be functionally determined by postcode and locality. The full lists of FDs for the representative dataset variations described in the paper are publicly available in our GitHub repository.

Figure 2: Country distribution in the full-named dataset.

4.3

Ethical Concerns

In alignment with prior work that analyzed the Common Crawl archives [36], we refrained from including any explicit personally identifiable information (PII), such as SSNs, emails, phone numbers, and banking information. After extraction, we also used the underlying PII detection library14 to identify unintentionally captured PII. No PII was detected. The entities whose addresses we collected represent businesses and publicly known offices. Furthermore, we semi-automatically audited the entries to identify facilities, further confirming that the addresses do not belong to individuals. The data from Common Crawl is used under its Terms of Use. In accordance with the Open Database Licence (ODbL) 1.0 of OpenStreetMap, our ground truth dataset remains under ODbL in line with the share-alike requirements.

5

5.1

Dataset Slices

For a finer-grained analysis, we readily sampled and made available multiple subsets of the full-named dataset based on specific dimensions, such as the country and the type of point of interest (POI), to use them in our experimental evaluation. Country-based Slices. We first considered the geographic dimension, producing dedicated subsets for the two most represented countries (US and Germany). As shown in Figure 2, the two slices (denoted as us-slice and de-slice) are composed of 2,267,895 and 374,533 addresses, respectively. POI-based Slices. We also created slices for 22 different types of POI, reflecting class-specific Schema.org subsets identified by WDC. This way, researchers can further explore specific cleaning strategies by augmenting certain entities with their type-specific properties [21, 22]. In our analysis, we focus on library and shoppingcenter, which cover all identified error types.

DATASET STATISTICS

In this section, we report statistical insights from our analysis of the dataset in its different variations, i.e., full-named and full-unnamed. As shown in Table 1, the schema of the generated dataset reflects the attributes defined in the schema alignment step (Section 4.2.3): house_number, road, postcode, locality, region, country, and country_code. The name attribute is present only in the full-named version. Further, a unique identifier (_id) is assigned to every record in the whole collection to serve as its identifier. We also track the source page URL as an attribute (graph_iri) for each record. Geographic Distribution. Although country-level coverage is uneven, the dataset is geographically diverse, with addresses spanning 128 countries worldwide. Figure 2 shows the geographic distribution of addresses in the full-named version. If needed, one can readily sample a balanced subset over x countries that remains larger than many existing cleaning datasets. Cardinalities. Table 1 reports the number of distinct values per attribute in the ground truth of the full-named and full-unnamed versions. With the only exception of the identifier, no attribute is unique. At the record level, filtering out _id and graph_iri attributes,

5.2

Error Statistics

To demonstrate the usefulness of our generated dataset, we analyze the characteristics of its errors. We report the overall error rate for the full-named and full-unnamed variants and the error rate for individual address fields. To capture not only frequency but also the nature of errors, we analyze the distribution of error types. In general, we compare the dirty value in each cell with the corresponding clean value from the ground truth. Cells that do not match exactly are counted as errors. • full-named – Across 4,338,109 addresses with eight fields, hence 34,704,872 cells in total, 51.1% of the cells are clean, i.e., they match the ground truth, while 48.9% contain errors.

15 Note that the rule country_code → country does not hold instead, due to an excep-

14 https://github.com/PovertyAction/PII_detection

tion, Northern Cyprus, which is associated with the same ISO code as Cyprus. 6

• full-unnamed – Across 9,317,886 addresses with seven fields, hence 65,225,202 cells in total, 47.3% of the cells are clean, while 52.7% contain errors. 5.2.1 Error Categories. To characterize the errors present in our dataset, we apply a hierarchical, rule-based classifier that assigns each cell to exactly one error category. Because a single cell can be subject to multiple errors simultaneously, e.g., a token reordering that also introduces a capitalization change, mutual exclusivity is enforced by a strict priority cascade: each rule is evaluated in the order listed below, and the first rule leading to a match with the ground truth determines the label. This design prevents doublecounting and makes the classification reproducible, ensuring that aggregate statistics are fully comparable across dataset slices. Before any rule is applied, both the dirty and clean value are normalized deterministically: zero-width and non-breaking space characters are removed or replaced with regular spaces, whitespace runs are collapsed, and Unicode NFC normalization is applied. This step is intentionally case- and punctuation-preserving so that purely cosmetic differences are absorbed into the Clean category rather than triggering downstream rules. The taxonomy comprises 12 mutually exclusive categories, applied in the following priority order:

Figure 3: Percentages of clean and erroneous cells (grouped by error type) per attribute in the full-named dataset. ordering in the original strings, e.g., Howson Branch, Austin Public Library ↔ Austin Public Library – Howson Branch, South 37th Avenue ↔ 37th Avenue South. (7) Language – The two values refer to the same entity but differ due to a language variation, such as a translation, an exonym, ´ or a romanisation, e.g., Austria ↔ Österreich, Athens ↔ 𝐴𝜃 𝜂𝜈𝛼. Resolving language variations before abbreviations prevents short tokens in a non-Latin script from being claimed by the abbreviation lookup, which operates on Latin-script expansions. (8) Abbreviation – The two values are equal after standardized address-form expansion via libpostal [5], e.g., Ave ↔ Avenue, Bachmannstr. ↔ Bachmannstraße. (9) Token Subset – One token multiset is a strict subset of the other, e.g., New York ⊂ New York City, Finavia ⊂ Finavia Oyj. Structural containment is a stronger indicator than a small edit distance: resolving such cases before typos prevents us from incorrectly labeling them as typographical errors. (10) Typo – The two normalized strings differ by at most two edit operations (substitution, insertion, deletion, or adjacent transposition) under the Damerau–Levenshtein distance [10, 18], e.g., Theater ↔ Theatre, Marriott ↔ Mariot. (11) Word Substitution – Exactly one token differs between the two multisets while at least one token is shared, e.g., VA Clinic ↔ Outpatient Clinic. This category captures factual inaccuracies, but also morphological variants, derivational forms, and near-synonyms that represent the same concept. (12) Miscellaneous – Any cell-level difference that does not satisfy any of the preceding rules is assigned this residual category. It subsumes cases such as cross-source conflicts, e.g., California ↔ Highway 76, administrative reassignments, e.g., Strathroy ↔ Adelaide Metcalfe, OCR-style corruptions, etc. Our categories build on prior work on error detection and taxonomies, but are more fine-granular and tailored to cell-level differences. Bhadauria et al. [6] provide a broader catalog of errors. Our taxonomy covers a subset observable through cell-wise address comparison and focuses on the cause of the error and not the type they belong to based on the algorithm that exposes them, such as rule violation or outliers [3].

Clean → Missing → Parsing → Capitalization → Special Chars → Name Reformat → Language → Abbreviation → Token Subset → Typo → Word Substitution → Miscellaneous We begin by separating exact matches and missing values, which can be identified without applying any transformation. Next come deterministic representation changes such as parsing issues, capitalization, punctuation, and name reformatting. These must be resolved early to avoid misclassifying them into broader, less precise categories such as typos. Language variations and abbreviations, which produce values that are lexically distinct but semantically equivalent, are evaluated before token-subset and edit-distancebased typo rules. Finally, typos, word substitutions, and miscellanea capture progressively less constrained differences, serving as a catch-all for cases not resolved by the earlier, more specific rules. Next, we explain each category in detail. (1) Clean – The normalized dirty value is identical to the normalized ground truth. No error is present. (2) Missing – The dirty value is empty after normalization. This error type is placed first, as applying any subsequent rule to an empty string would be meaningless. (3) Parsing – The dirty value contains an artifact resulting from an incorrectly identified character encoding, e.g., M%C3%BCnchen ↔ München, Caf&#233; ↔ Café. Equality with the ground truth is restored after an appropriate decoding step. (4) Capitalization – The two values are identical under Unicode case folding [37], e.g., ATLANTA ↔ Atlanta, 10a ↔ 10A. (5) Special Characters – The two values are identical under case folding after removing all Unicode punctuation, symbol, and whitespace characters from both, e.g., Notre-Dame Street ↔ Notre Dame Street, U.S.A. ↔ USA. This rule fires for differences that are entirely attributable to punctuation usage conventions. (6) Name Reformat – The multiset of accent-folded, lowercased word-level tokens is identical for both values, despite different

5.2.2 Error Category Distributions. We now report the ratios of the defined error types for the full dataset and its slices. 7

Table 2: Distribution of error types across dataset variations (percentages of total cells). Parsing is also reported as an absolute count due to its negligible overall frequency. Statistics for other POI-based slices are available on GitHub. Slice

Num-rows

Clean

Missing

Parsing (#)

Parsing (%)

Capitalization

Special Chars

Name Reformat

Language

Abbreviation

Token Subset

Typo

Word Subst.

Misc

full-named full-unnamed

4,338,109 9,317,886

51.1% 47.3%

23.7% 28.6%

8830 500

0.025% 0.001%

2.1% 1.7%

0.8% 0.8%

0.6% 0.3%

6.9% 6.4%

9.3% 9.5%

2.6% 1.8%

1.2% 1.3%

0.2% 0.4%

1.5% 1.9%

us-slice de-slice ru-slice

2,267,895 374,533 194,274

52.9% 53.5% 51.9%

20.1% 30.0% 29.6%

6940 91 0

0.038% 0.003% 0.000%

1.0% 1.9% 7.8%

0.5% 1.2% 0.3%

0.1% 0.3% 0.1%

7.0% 5.3% 2.2%

14.9% 1.2% 0.4%

2.2% 2.7% 0.7%

0.7% 0.3% 6.4%

0.0% 0.0% 0.2%

0.5% 3.6% 0.3%

5,370 3,478

51.7% 45.8%

27.3% 22.4%

10 13

0.023% 0.047%

2.8% 3.1%

0.4% 0.2%

0.6% 7.3%

2.0% 4.2%

5.8% 7.1%

1.6% 2.5%

1.1% 6.5%

0.0% 0.2%

6.6% 0.6%

library shopping-center

Full Dataset. Figure 3 summarizes the cell-wise comparison over all attributes between the extracted dataset and its ground truth for the full-named version. The full-unnamed version shows a very similar distribution. The largest drift between the dirty and clean version of the dataset is due to representation issues and missing values. Common issues include abbreviated or shortened forms of street and region names, partial or omitted locality fields, and inconsistent capitalization or punctuation. Textual attributes such as region and country are the most affected, often due to incomplete or shortened representations of organizations and administrative divisions. In contrast, structured fields, such as house_number, postcode, and locality, tend to be considerably cleaner, with most inconsistencies limited to minor formatting or typographic deviations. The country_code value is frequently missing, reflecting the common omission of standardized codes on Web sources.

two selected slices, library combines a high rate of missing values (27.3%) with the largest amount of miscellaneous errors across all slices (6.6%), while shopping-center exhibits the highest rate of name reformatting (7.3%) and the second-highest rate of typos (6.5%), together with a lower rate of clean cells (45.8% vs. 51.7%).

6

EXPERIMENTAL ANALYSIS

To demonstrate the utility of our benchmark dataset, we conducted an extensive set of experiments and evaluated the effectiveness and scalability of state-of-the-art data cleaning systems across different subsets. We selected representative systems for rule-based, learningbased, and LLM-driven approaches, and assessed their performance in terms of effectiveness, runtime, and memory usage. Setup. All dataset variations and source code for dataset extraction, ground truth generation, analysis, and experiments are publicly available on GitHub. The code is implemented in Python. Runtime experiments were executed on a server equipped with an AMD EPYC 7702P 64-core processor and 512 GB of RAM. RAIDconfigured SSDs were used for storage.

Country-based Slices. The distribution of error types in addresses from us-slice is very similar to the one in the full dataset, where US addresses represent more than the half of the entries. US addresses show a significantly higher rate of abbreviations, especially in the region attribute (74.6%), but also for road (25.3%) and country (19%). For instance, addresses inconsistently use abbreviations for street components, such as “W” for “West” or “Blvd.” for “Boulevard”. The abbreviation rate is much lower in de-slice, e.g., 9.2% for road or close to 0% for region and country, which shows instead a high rate of missing values for region (70.3%). Indeed, for free cities, such as Berlin and Hamburg, the region coincides with the city itself and is therefore omitted for practical reasons. Another distinguishing factor is the overall clean ratio for street names (61.8%). An interesting observation concerns the orthography of the word “street” (“Straße”) in German and Swiss addresses. While German addresses strictly adhere to the usage of “ß” instead of “ss” in the ground truth, Swiss addresses do the opposite. The correspondingly wrong usage can be observed in the dirty version of the dataset.

6.1

Datasets

To evaluate state-of-the-art cleaning systems across different scenarios, we created the samples summarized in Table 3. For effectiveness experiments, we used samples of 10k records of full-named, deslice, and ru-slice. The latter contains Russian addresses and was selected to assess how cleaning systems perform on a non-Latin address subset. Since US addresses already represent the majority in full-named, we exclude the results on us-slice for brevity. As the error rate in the original dataset is rather high (about 50% of the cells), we also generated samples at lower error rates by proportionally replacing erroneous cells with the corresponding ground truth values. For example, on a dataset with 100 cells among which 50 are marked as erroneous, hence presenting a 50% error rate, a 20% error rate would be obtained by randomly restoring 30 of the 50 erroneous cells to their ground truth values. We additionally report on two POI-based slices, library and shopping-center, which differ with regard to their error-type distributions, to assess system behavior on domain-specific data. For scalability experiments, we considered random full-named samples of 10k, 100k, 500k, and 1M records. All datasets have eight columns: we excluded _id and graph_iri from all experiments, as both are always clean. For the effectiveness experiments, we additionally filtered out records that were exact duplicates in their dirty version after the removal of the _id and graph_iri columns. This

POI-based Slices. In Table 2, we report the distribution of error types for the two POI-based slices (library and shopping-center) used in our experiments. Statistics for the other 20 slices are available on GitHub. Missing values are by far the most common error type across all slices, ranging from 16% to 49.1% of the cells, with the highest rates concentrated in sport-related slices. Abbreviations are dominating among representational inconsistencies (median 9.2%, up to 13.8%), while typos are rare in most slices (median 0.8%, up to 6.9%). The remaining categories vary substantially by POI type. Language variations range from 2% to 16.2% across slices, reaching the highest values in tourism-related slices, such as skiresort, often referenced from multiple countries. Focusing on the 8

Table 3: Overview of dataset samples used in the experiments. For the effectiveness experiments, records that were exact duplicates in their dirty version after the removal of the _id and graph_iri columns were filtered out before sampling. Dataset Error Rate Effectiveness Experiments full-named 0.05, 0.10, 0.20, 0.51 (original*) de-slice 0.05, 0.10, 0.20, 0.48 (original*) ru-slice 0.05, 0.10, 0.20, 0.65 (original*) library 0.64 (original*) shopping-center 0.64 (original*) Scalability Experiments full-named (All) 0.49 full-named (1M) 0.49 full-named (500𝑘 ) 0.49 full-named (100𝑘 ) 0.49 full-named (10𝑘 ) 0.49

#Rows

#Columns

10,000 10,000 10,000 1,656 802

8 8 8 8 8

4,338,109 1,000,000 500,000 100,000 10,000

8 8 8 8 8

a unified factor graph model to infer the most likely repairs for detected errors. We used the original implementation19 and provided it with the same FDs used for Horizon and UniClean. Raha [24] and Baran [23] are semi-supervised systems for error detection and correction, respectively. Both formulate detection and correction as classification tasks and learn data-specific patterns to identify and repair erroneous cells. All experiments were conducted using their official implementation20 . As recommended by the authors, we ran each experiment with 20 labeled tuples per task to train the corresponding models. DataWig [7] is a data imputation method based on deep learning. We used the official implementation21 and the SimpleImputer module for our experiments. We used 20 labeled tuples for training and validation. For each column, the imputer was trained to predict its values based on all remaining columns. We then used the calibrated probability scores provided by the imputer to filter predictions, setting the threshold to 0.5. Among the remaining predictions, those differing from the original values were considered as detected errors. For the correction task, we then used the trained models to predict repairs for all actual erroneous cells in the dataset.

determines the error rates marked as original* in Table 3, which are slightly different from those reported in Table 2.

6.2

Baselines

In our experiments, we considered several state-of-the-art data cleaning systems in representation of rule-based, learning-based, and LLM-driven approaches.

LLM-driven Approaches. Glock’s [13] recently used LLMs to detect and correct errors in personal contact information datasets, a use case with which our dataset closely aligns. The proposed approach prompts LLMs to process each record individually, providing table-level rules and descriptions to guide both detection and correction. We used the official implementation22 and adapted the prompts to fit our dataset, making the edited versions publicly available in our repository. Experiments were conducted using Gemini 2.5 Flash-Lite. In preliminary tests, we had observed very similar results between Gemini 2.5 Flash-Lite and GPT-5-mini. We opted for Gemini 2.5 Flash-Lite due to its faster response times.

Rule-based Approaches. Horizon [32] is a scalable rule-based system that generates repairs in linear time. We used the implementation provided by the authors16 . As input, Horizon requires a set of FDs: we extracted them from the clean version of each sample using TANE [15], relying on a third-party Python implementation17 . UniClean [12] is a system for building efficient data cleaning workflows. We classify it as rule-based because it requires predefined rules and constraints as input. We used the official implementation18 with its default configuration and the same set of FDs used for Horizon. In addition, we enabled pattern-based and missing-value cleaners, as UniClean supports multiple error types. For datasets where UniClean did not finish within the allocated time budget of 10 hours under its initial configuration, we reduced the workload by incrementally modifying three settings. First, we changed the sampling mode, choosing whether UniClean derives the repair plan from a quality-based coreset or from the full data directly. Second, we simplified the set of FDs by removing those with three or more attributes on the left-hand side. Third, we adjusted the block-size threshold single_max. When repairing a target attribute or attribute group, UniClean applies all rules jointly if the sampled block contains fewer than single_max rows; otherwise, it applies the rules one at a time. For each dataset we applied these changes incrementally in the presented order, stopping as soon as the run completed within the time budget. The final configuration used for each dataset is available in our repository.

6.3

Effectiveness Experiments

We evaluate the effectiveness of all baselines for both error detection and correction across different error rates, country slices, and POIbased slices. We ran each system three times and report the average. For holistic systems such as UniClean and Horizon, which do not explicitly output detected errors, we derive detection results from the repairs they perform: whenever a system changes a cell value, we count that cell as detected. 6.3.1 Cleaning Effectiveness w.r.t. Error Rate. Figure 4 illustrates the effectiveness of all baselines in both error detection and correction on samples from full-named, de-slice, and ru-slice. The x-axis represents the cell-level error rate, while the y-axis shows the F1-score. As expected, all systems perform better on de-slice and ru-slice: within the same country, patterns and rules for addresses are more homogeneous, which makes the data inherently easier to clean. Error Detection. Among detection baselines, Raha shows the strongest performance across all slices. The LLM-based approach by Glock et al. is the second strongest detector. On de-slice, it

Learning-based Approaches. HoloClean [30] is an error correction system that combines integrity constraints, external data sources, and statistical profiles in

19 https://github.com/HoloClean/holoclean 16 https://github.com/D2IP-TUB/Horizon

20 https://github.com/BigDaMa/raha

17 https://github.com/codocedo/tane

21 https://github.com/awslabs/datawig

18 https://github.com/qzkinhit/UniClean-bench-Result

22 https://github.com/Anna-Christina-Glock/pci-llm-toolkit

9

Table 4: Error detection and correction results across POI-based slices. Dataset

Error Detection System Raha Horizon DataWig HoloClean Glock’s UniClean Raha Horizon DataWig HoloClean Glock’s UniClean

library

shopping-center

F1-Score

de-slice - Detection 1 0.8 0.6 0.4 0.2 0

5% 20% 48% Error Rate

Precision 0.92 0.49 0.66 0.88 0.97 0.73 0.90 0.54 0.67 0.91 0.98 0.95

ru-slice - Detection 1 0.8 0.6 0.4 0.2 0

5% 20% 65% Error Rate Raha

DataWig

Recall 0.91 0.54 0.97 0.73 0.56 0.86 0.90 0.65 0.98 0.70 0.60 0.67

F1-Score 0.91 0.51 0.79 0.80 0.71 0.79 0.90 0.59 0.80 0.79 0.74 0.78

full - Detection 1 0.8 0.6 0.4 0.2 0

Error Correction System Baran Horizon DataWig HoloClean Glock’s UniClean Baran Horizon DataWig HoloClean Glock’s UniClean

de-slice - Correction

1 0.8 0.6 0.4 0.2 0 5% 20% 51% 5% 20% 48% Error Rate Error Rate Horizon Glock’s HoloClean

Precision 0.14 0.01 0.30 0.001 0.31 0.005 0.47 0.004 0.28 0.01 0.27 0.01

Recall 0.11 0.005 0.29 0.001 0.27 0.03 0.35 0.003 0.27 0.003 0.24 0.02

F1-Score 0.12 0.007 0.29 0.001 0.29 0.009 0.40 0.003 0.27 0.004 0.25 0.01

ru-slice - Correction 1 0.8 0.6 0.4 0.2 0

5% 20% 65% Error Rate UniClean

full - Correction 1 0.8 0.6 0.4 0.2 0

5% 20% 51% Error Rate

Baran

Figure 4: F1-score of different data cleaning systems for error detection and correction on subsets of de-slice, ru-slice, and full-named dataset variations at different error rates. reaches an F1-score of 0.77-0.82 and remains close to Raha across all error rates. DataWig, HoloClean, UniClean, and Horizon start from substantially lower F1-scores at small error rates, but their performance improves as the amount of errors increases. For example, on de-slice DataWig’s F1-score rises from 0.13 at a 5% error rate to 0.68 at 48%. This trend can be explained by class imbalance. At low error rates, erroneous cells are rare. Thus, even high-recall detectors may suffer from low precision, since many flagged cells are clean. As the error rate increases, the share of erroneous cells grows, precision improves, and the F1-score rises accordingly. This effect is less visible for Raha, which maintains competitive precision even at low error rates due to its semi-supervised strategy.

Baran’s strong performance shows the benefits of using signals within the dataset when enough clean context is available. Its performance drops for higher error rates, because the same internal signals become noisier as more cells are corrupted. Glock’s is more robust against increases in error rates because each record is processed independently and the method relies on knowledge acquired during pretraining rather than on evidence present in the dataset. DataWig also remains relatively stable, because we used a fixed training budget across all error rates. Rule-based approaches perform poorly in correction because their applicability is limited by the available dependencies and by the values present in the data. FDs do not cover all attributes. Thus, errors in attributes such as house_number, name, or postcode cannot be repaired, as they are not captured by any rule. Even when a rule applies, the system can only infer a correction if enough clean and consistent evidence exists elsewhere in the dataset. This assumption is often violated in our benchmark, which contains heterogeneous addresses from different countries, together with a high number of missing values, abbreviations, and noisy variants. These results show a limitation shared by many correction methods: they rely on the dataset itself to provide reliable correction evidence, hence their effectiveness decreases when the data is noisy, incomplete, or internally inconsistent.

Error Correction. To evaluate correction quality independently from detection, we provide the systems with the list of actual erroneous cells. In contrast to detection, which benefits from class imbalance at higher error rates, correction performance degrades as the error rate increases. Most correction systems rely on the assumption that the dataset contains enough clean and redundant evidence to infer the correct value. As the error rate increases, this evidence becomes less reliable, hence correction gets harder. Baran achieves the strongest average performance across all slices. On de-slice, Baran and Glock’s perform similarly, with average F1-scores of 69% and 68%, respectively. UniClean ranks third with 53%. A similar trend is registered on ru-slice, with Baran (45%) outperforming UniClean (39%) and Glock’s (37%). The lower scores registered on ru-slice compared to de-slice are mainly due to the fact that its columns generally present higher distinct value ratios, providing therefore less evidence to support correction. Finally, Baran reaches an average F1-score of 46% on full-named, followed by Glock’s with 42% and DataWig with 18%.

6.3.2 Cleaning Effectiveness on POI-based Slices and Different Error Types. We evaluate the systems on two POI-based slices: library (1,656 records, 13,248 cells) and shopping-center (802 records, 6,416 cells). These POIs were selected because they exhibit complementary error profiles and together cover the main error types identified in our benchmark, as shown in Table 2. 10

Table 5: Error detection (recall) and correction (F1-score) performance across error types. Dataset

Task

Method

Missing

Parsing

Capitalization

Special Chars

Name Reformat

Language

Abbreviation

Token Subset

Typo

Word Subst.

Miscellaneous

Raha Horizon DataWig HoloClean Glock’s UniClean

0.995 0.332 0.994 0.959 0.995 1.000

0.286 1.000 0.667 0.000 0.000 1.000

0.813 1.000 0.937 0.137 0.003 0.551

0.594 1.000 0.894 0.033 0.000 0.683

0.649 1.000 0.846 0.142 0.000 0.544

0.504 1.000 0.891 0.102 0.013 0.570

0.949 0.970 0.995 0.390 0.061 0.501

0.580 1.000 0.844 0.223 0.006 0.579

0.106 1.000 0.951 0.244 0.081 0.512

0.524 1.000 0.952 0.000 0.143 0.571

0.653 0.993 0.989 0.395 0.175 0.626

Baran Horizon Correction DataWig (F1-Score) HoloClean Glock’s UniClean

0.072 0.010 0.399 0.001 0.219 0.007

0.000 0.000 0.000 0.000 0.000 0.000

0.043 0.000 0.022 0.004 0.372 0.000

0.065 0.000 0.000 0.000 0.117 0.000

0.019 0.000 0.016 0.000 0.604 0.000

0.172 0.000 0.018 0.000 0.330 0.000

0.712 0.014 0.154 0.000 0.936 0.000

0.041 0.000 0.008 0.000 0.100 0.000

0.089 0.000 0.008 0.000 0.182 0.000

0.250 0.000 0.000 0.000 0.154 0.000

0.427 0.000 0.016 0.000 0.256 0.000

Raha Horizon DataWig HoloClean Glock’s UniClean

1.000 0.460 0.996 0.996 0.999 1.000

0.267 1.000 0.833 0.000 0.000 1.000

0.872 0.993 0.958 0.268 0.001 0.056

0.477 1.000 0.879 0.000 0.023 0.250

0.575 1.000 0.925 0.226 0.000 0.016

0.679 0.992 0.949 0.101 0.009 0.050

0.798 0.961 0.982 0.152 0.061 0.094

0.434 1.000 0.876 0.028 0.013 0.022

0.253 1.000 0.893 0.200 0.027 0.000

0.921 1.000 1.000 0.000 0.000 0.000

0.747 0.962 0.983 0.506 0.169 0.544

Baran Horizon Correction DataWig (F1-Score) HoloClean Glock’s UniClean

0.432 0.004 0.400 0.001 0.210 0.008

0.000 0.000 0.067 0.000 0.000 0.000

0.219 0.000 0.035 0.023 0.129 0.000

0.029 0.000 0.023 0.000 0.300 0.000

0.640 0.000 0.038 0.000 0.225 0.000

0.275 0.006 0.028 0.000 0.446 0.005

0.586 0.006 0.117 0.000 0.762 0.000

0.136 0.000 0.020 0.000 0.148 0.000

0.097 0.000 0.071 0.000 0.105 0.000

0.027 0.000 0.035 0.000 0.563 0.000

0.429 0.000 0.160 0.000 0.344 0.016

shopping-center

library

Detection (Recall)

Detection (Recall)

Table 4 reports the overall precision, recall, and F1-score for detection and correction on both slices. Table 5 further breaks down the results by error type. For detection, we report recall per error type, since the goal is to measure how many errors are successfully identified for each category. Type-wise precision is not meaningful in this context, because false positives correspond to clean cells and therefore cannot be assigned to a specific error category. For correction, we report F1-score, as a predicted repair is only counted as correct if it matches the ground-truth value. For several error types, Raha, UniClean, DataWig, and Horizon achieve high detection recall, yet the corresponding correction F1-scores remain low. For example, on library DataWig detects Abbreviation errors with a recall of 0.995, but reaches only a 0.154 F1-score in correcting them. Similarly, Horizon obtains near-perfect recall for several categories, but almost never produces successful repairs. Rule violations or distributional signals are often enough to identify suspicious cells, but not to infer the correct value. Table 5 shows that correction quality strongly depends on the error type. Baran performs best on Missing, Name Reformat, and Miscellaneous errors on shopping-center, where useful evidence can be derived from recurring patterns in the dataset. Glock’s performs better on textual and semantic transformations, including Abbreviation, Language, Special Characters, and Word Substitution. This complements the previous results: learning-based and rulebased methods are effective when clean and redundant evidence is available, whereas the LLM-based method is more robust for transformations that require lexical, linguistic, or world knowledge.

6.4

6.4.1 Runtime. Among all baselines, DataWig is the fastest. Its runtime can be due to the small training set, consisting of only 20 tuples. Both Raha and Baran were terminated before reaching 500k records: the former ran out of memory, while the latter exceeded the time limit. Although Horizon is usually fast, its runtime is sensitive to the number and interaction structure of the input FDs. Having to deal with 24 FDs at a 49% error rate, the run did not finish within 10 hours on the 500k-record dataset. UniClean’s runtime is non-monotonic. The execution on 100k records (3,118s) is faster than on 10k (13,455s) and 500k (7,613s). UniClean is configured with a set of rules and repairs violations by first partitioning inconsistent rows into blocks. Cost scales with block size, rule count, and iteration count, so runtime is driven by error distribution rather than the number of rows. Each sample presents a different error profile, determining the non-monotonic behavior mentioned above. Finally, Glock’s offloads computation to an external LLM API, avoiding local hardware limits, but one API call per record makes runtime and cost scale linearly, already requiring 8 hours to process 1M records and therefore exceeding the time limit on the full dataset with 4.3M records. Clearly, also monetary costs become significant on large datasets. For instance, just a single run on the full dataset would cost approximately $650. Note that Gemini 2.5 Flash-Lite is a rather fast model with a quickresponse API. We had significantly slower runtime in preliminary experiments using GPT-5-mini. 6.4.2 Memory Usage. Among the non-LLM approaches, DataWig is the most memory-efficient: it requires at most around 14 GB even on the full dataset. In contrast, Raha is substantially more memoryintensive. Its memory consumption increases from about 1.8 GB on the smallest setting to more than 86 GB on the subset with 100𝑘 records, after which it runs out of memory. This limits its applicability to larger datasets despite its strong detection effectiveness. HoloClean also shows increasing memory usage, reaching around 19 GB for error detection on the full dataset. However, in correction settings it times out before memory becomes the limiting factor.

Efficiency and Scalability Experiments

To evaluate efficiency and scalability of the different data cleaning systems, we measure runtime and peak memory usage. Table 6 shows the corresponding results. We executed all systems three times. The number of records ranges from 10k to the full dataset size. Executions exceeding a predefined 10-hour limit were terminated. 11

Table 6: Runtime (seconds) and peak memory usage (MB) of data cleaning systems across samples of increasing size. TO: timeout (runtime > 10 hours); OOM: out of memory.

needed to infer the correct value becomes less reliable. Future research should therefore consider including augmentation strategies to balance out the error rates.

Number of Records Task

System

10𝑘

100𝑘

500𝑘

1M

4.3M

Error Detection

Raha HoloClean Glock’s

122.7 8.5 101.8

12865.9 45.6 1092.9

OOM 219.8 10,379.46

OOM 445.9 12,927.58

OOM 1,965.0 TO

Error Correction

Baran HoloClean Glock’s

1,057.2 404.5 103.4

5,230.4 4,621.1 1,747.39

TO TO 8,945.61

TO TO 16,567.23

TO TO TO

Error Detection + Error Correction

DataWig Horizon UniClean

29.1 6,445.0 13,455

241.2 TO 3,118

1,186.4 TO 7,613

2,376.5 TO 11,357

10,230.1 TO 13,490

Error Detection

Raha HoloClean Glock’s

1795 306 257.69

86,734 711 1,030.13

OOM 2,459 4,562.0

OOM 4,663 8,954.88

OOM 18,979 TO

Error Correction

Baran HoloClean Glock’s

685.84 2,867 257.69

3021.3 33,843 1,030.13

TO TO 4,562.0

TO TO 8,954.88

TO TO TO

Error Detection + Error Correction

DataWig Horizon UniClean

1,138 1,700 8,229

2,002 2,088 127,662

3,723 TO 131,006

5,761 TO 324,948

14,576 TO 315,567

(3) Cleaning strategies. We observe a clear tendency where supervised approaches outperform the more rigid rule-based systems, even on the rather canonical data types that exist in postal datasets. Although rule-based approaches are generally faster, their effectiveness depends on the error rate, dataset homogeneity, and availability of rules. While both rule-based and learning-based approaches primarily exploit patterns and evidence contained in the available data, LLMs can draw on knowledge acquired during pretraining to detect and correct erroneous values. This would suggest that a promising direction is a staged combination of these strategies, by filtering with fast and coarse-granular rule-based techniques and passing on difficult cases to the more powerful supervised and LLMbased solutions. However, we have to acknowledge that existing systems already combine rules, supervision, and agents [23, 28, 39]. Thus, the way forward is to further refine and adjust how different approaches work together so that a quick fall-back on expensive agentic-based solutions can be avoided.

Runtime (seconds)

Peak Memory (MB)

(4) Scalability. Existing systems scale differently and are therefore not equally suitable for all settings. Beyond table size, efficiency is affected by the error rate, the number and complexity of rules, and the distribution of errors and values in the data. LLM-based solutions avoid some local hardware limitations, but introduce a different scalability bottleneck: their cost and runtime depend on record-level inference, model response time, and the available serving infrastructure. Consequently, they can quickly become impractical at larger scales. Future cleaning research would benefit from approaches that take the relevant metadata into consideration and recalibrate their detection and correction strategies.

UniClean shows the highest memory footprint. Its peak memory already exceeds 127 GB on 100𝑘 records and more than 300 GB on larger samples. Horizon, in comparison, remains relatively lightweight on the smaller samples, but it times out on larger ones. Finally, the LLM-based approach has low memory requirements because the main computation is delegated to the cloud model. Thus, the reported peak memory usage does not reflect the actual memory footprint of the model.

6.5

Limitations. While the dataset covers a very important domain and is large, it does not scale in the number of columns. Although current systems already struggle with the current dataset dimensions, it would be beneficial for future benchmarks to also scale horizontally. Further, the dataset is skewed towards US and Europe. Finally, the approach for obtaining ground truth is only one among many. Quality describes fitness for use. How addresses should be represented and used can differ depending on the use case. Our approach made sure that the data is correct and consistent with regard to one standard that was cross-confirmed with different validators.

Key Takeaways

Overall, our experiments show that even for address data, which is highly prevalent and does not require specialized domain expertise, existing cleaning systems remain insufficient for resolving data quality issues, prompting the need for further research on scalable and reliable data cleaning. Learning-based methods are strong detectors and can exploit regularities within the dataset when sufficient clean evidence is available. LLM-based approaches are more robust under heterogeneity and missingness, but come with scalability costs. Rule-based systems are effective only in settings with high redundancy, reliable dependencies, and broad rule coverage. In the following, we point out some more detailed takeaways.

7

CONCLUSIONS

In this paper, we present the first large-scale dirty address dataset with ground truth. The dirty version of the dataset contains realworld addresses. The collected addresses are dirty and inconsistent. The dataset contains a high variety of errors, enabling reasoning on different types and rates of errors. Using a geo-location service and additional manual postprocessing, we obtained a corresponding ground truth. For ease of use, we also provide country-based and POI-based slices of the dataset. With this dataset, we aim to support research in data cleaning. In fact, we also highlight that existing prototypes show significant limitations in handling our dataset. Beyond data cleaning, the dataset might also be interesting for use cases such as data transformation discovery or entity resolution.

(1) Data consistency. Systems generally perform better on the country-specific slices than on the full dataset, confirming that linguistic, structural, and formatting consistency facilitates both detection and correction. Thus, a clear development direction for general-purpose cleaning systems is the ability to identify such slices automatically for effective step-wise cleaning. (2) Error rates. Detection often improves as the error rate increases, because erroneous cells become less rare and class imbalance becomes less severe. Correction, however, typically becomes harder at higher error rates, since the clean and redundant evidence 12

REFERENCES

Social Networks. Proceedings of the VLDB Endowment (PVLDB) 10, 10 (2017), 1010–1021. https://doi.org/10.14778/3115404.3115407 [23] Mohammad Mahdavi and Ziawasch Abedjan. 2020. Baran: Effective Error Correction via a Unified Context Representation and Transfer Learning. Proceedings of the VLDB Endowment (PVLDB) 13, 11 (2020), 1948–1961. https: //doi.org/10.14778/3407790.3407801 [24] Mohammad Mahdavi, Ziawasch Abedjan, Raul Castro Fernandez, Samuel Madden, Mourad Ouzzani, Michael Stonebraker, and Nan Tang. 2019. Raha: A Configuration-Free Error Detection System. In Proceedings of the ACM International Conference on Management of Data (SIGMOD). 865–882. https: //doi.org/10.1145/3299869.3324956 [25] Sedir Mohammed, Lukas Budach, Moritz Feuerpfeil, Nina Ihde, Andrea Nathansen, Nele Sina Noack, Hendrik Patzlaff, Felix Naumann, and Hazar Harmouch. 2025. The effects of data quality on machine learning performance on tabular data. Information Systems 132, Article 102549 (2025), 18 pages. https://doi.org/10.1016/j.is.2025.102549 [26] Sedir Mohammed, Lisa Ehrlinger, Hazar Harmouch, Felix Naumann, and Divesh Srivastava. 2025. The Five Facets of Data Quality Assessment. ACM SIGMOD Record 54, 2 (2025), 18–27. https://doi.org/10.1145/3749116.3749120 [27] Wei Ni, Xiaoye Miao, Xiangyu Zhao, Yangyang Wu, Shuwei Liang, and Jianwei Yin. 2024. Automatic Data Repair: Are We Ready to Deploy? Proceedings of the VLDB Endowment (PVLDB) 17, 10 (2024), 2617–2630. https://doi.org/10.14778/ 3675034.3675051 [28] Wei Ni, Kaihang Zhang, Xiaoye Miao, Xiangyu Zhao, Yangyang Wu, Yaoshu Wang, and Jianwei Yin. 2025. ZeroED: Hybrid Zero-Shot Error Detection Through Large Language Model Reasoning. In 41st IEEE International Conference on Data Engineering, ICDE 2025, Hong Kong, May 19-23, 2025. IEEE, 3126–3139. https: //doi.org/10.1109/ICDE65448.2025.00234 [29] Mourad Ouzzani, Hossam Hammady, Zbys Fedorowicz, and Ahmed Elmagarmid. 2016. Rayyan—a web and mobile app for systematic reviews. Systematic Reviews 5, Article 210 (2016), 10 pages. https://doi.org/10.1186/s13643-016-0384-4 [30] Theodoros Rekatsinas, Xu Chu, Ihab F. Ilyas, and Christopher Ré. 2017. HoloClean: Holistic Data Repairs with Probabilistic Inference. Proceedings of the VLDB Endowment (PVLDB) 10, 11 (2017), 1190–1201. https://doi.org/10.14778/ 3137628.3137631 [31] Valerie Restat, Gerrit Boerner, André Conrad, and Uta Störl. 2022. GouDa Generation of universal Data Sets: Improving Analysis and Evaluation of Data Preparation Pipelines. In Proceedings of the Workshop on Data Management for End-To-End Machine Learning (DEEM). Article 2, 6 pages. https://doi.org/10. 1145/3533028.3533311 [32] El Kindi Rezig, Mourad Ouzzani, Walid G. Aref, Ahmed K. Elmagarmid, Ahmed R. Mahmood, and Michael Stonebraker. 2021. Horizon: Scalable Dependency-driven Data Cleaning. Proceedings of the VLDB Endowment (PVLDB) 14, 11 (2021), 2546– 2554. https://doi.org/10.14778/3476249.3476301 [33] Sebastian Schelter, Tammo Rukat, and Felix Biessmann. 2021. JENGA - A Framework to Study the Impact of Data Errors on the Predictions of Machine Learning Models. In Proceedings of the International Conference on Extending Database Technology (EDBT). 529–534. https://doi.org/10.5441/002/edbt.2021.63 [34] Shafaq Siddiqi, Roman Kern, and Matthias Boehm. 2023. SAGA: A Scalable Framework for Optimizing Data Cleaning Pipelines for Machine Learning Applications. Proceedings of the ACM on Management of Data (PACMMOD) 1, 3, Article 218 (2023), 26 pages. https://doi.org/10.1145/3617338 [35] Jasmin Singh and Heiko Gebauer. 2024. Clean Customer Master Data for Customer Analytics: A Neglected Element of Data Monetization. Digital 4, 4 (2024), 1020–1038. https://doi.org/10.3390/digital4040051 [36] Nishant Subramani, Sasha Luccioni, Jesse Dodge, and Margaret Mitchell. 2023. Detecting Personal Information in Training Corpora: an Analysis. In Proceedings of the Workshop on Trustworthy Natural Language Processing (TrustNLP). 208–220. https://doi.org/10.18653/v1/2023.trustnlp-1.18 [37] The Unicode Consortium. 2024. The Unicode Standard, Version 15.1. https: //www.unicode.org/versions/Unicode15.1.0/. [38] United States Postal Service. 2014. Undeliverable as Addressed Mail. https: //www.uspsoig.gov/reports/audit-reports/undeliverable-addressed-mail. [39] Yangyang Wu, Chen Yang, Mengying Zhu, Xiaoye Miao, Wei Ni, Meng Xi, Xinkui Zhao, and Jianwei Yin. 2025. A Zero-Training Error Correction System with Large Language Models. In Proceedings of the IEEE International Conference on Data Engineering (ICDE). 2949–2962. https://doi.org/10.1109/ICDE65448.2025.00221

[1] Mohamed Abdelaal, Christian Hammacher, and Harald Schöning. 2023. REIN: A Comprehensive Benchmark Framework for Data Cleaning Methods in ML Pipelines. In Proceedings of the International Conference on Extending Database Technology (EDBT). 499–511. https://doi.org/10.48786/edbt.2023.43 [2] Ziawasch Abedjan, Cuneyt G. Akcora, Mourad Ouzzani, Paolo Papotti, and Michael Stonebraker. 2015. Temporal Rules Discovery for Web Data Cleaning. Proceedings of the VLDB Endowment (PVLDB) 9, 4 (2015), 336–347. https://doi. org/10.14778/2856318.2856328 [3] Ziawasch Abedjan, Xu Chu, Dong Deng, Raul Castro Fernandez, Ihab F. Ilyas, Mourad Ouzzani, Paolo Papotti, Michael Stonebraker, and Nan Tang. 2016. Detecting Data Errors: Where are we and what needs to be done? Proceedings of the VLDB Endowment (PVLDB) 9, 12 (2016), 993–1004. https://doi.org/10.14778/ 2994509.2994518 [4] Patricia C. Arocena, Boris Glavic, Giansalvatore Mecca, Renée J. Miller, Paolo Papotti, and Donatello Santoro. 2015. Messing Up with BART: Error Generation for Evaluating Data-Cleaning Algorithms. Proceedings of the VLDB Endowment (PVLDB) 9, 2 (2015), 36–47. https://doi.org/10.14778/2850578.2850579 [5] Christopher Barrington-Leigh and Adam Millard-Ball. 2017. The World’s UserGenerated Road Map Is More Than 80% Complete. PLOS ONE 12, 8 (2017), e0180698. https://doi.org/10.1371/journal.pone.0180698 [6] Divya Bhadauria, Hazar Harmouch, Felix Naumann, Divesh Srivastava, and Lisa Ehrlinger. 2026. A Catalog of Data Errors. CoRR abs/2604.09277 (2026). https://doi.org/10.48550/ARXIV.2604.09277 arXiv:2604.09277 [7] Felix Bießmann, Tammo Rukat, Philipp Schmidt, Prathik Naidu, Sebastian Schelter, Andrey Taptunov, Dustin Lange, and David Salinas. 2019. DataWig: Missing Value Imputation for Tables. Journal of Machine Learning Research (JMLR) 20, Article 175 (2019), 6 pages. https://jmlr.org/papers/v20/18-753.html [8] Alexander Brinkmann, Anna Primpeli, and Christian Bizer. 2023. The Web Data Commons Schema.org Data Set Series. In Companion Proceedings of the ACM Web Conference 2023, WWW 2023, Austin, TX, USA, 30 April 2023 - 4 May 2023, Ying Ding, Jie Tang, Juan F. Sequeda, Lora Aroyo, Carlos Castillo, and Geert-Jan Houben (Eds.). ACM, 136–139. https://doi.org/10.1145/3543873.3587331 [9] Xu Chu, Ihab F. Ilyas, and Paolo Papotti. 2013. Holistic Data Cleaning: Putting Violations Into Context. In Proceedings of the IEEE International Conference on Data Engineering (ICDE). 458–469. https://doi.org/10.1109/ICDE.2013.6544847 [10] Fred Damerau. 1964. A Technique for Computer Detection and Correction of Spelling Errors. Communications of the ACM (CACM) 7, 3 (1964), 171–176. https://doi.org/10.1145/363958.363994 [11] Edith Desiree de Leeuw. 1992. Data Quality in Mail, Telephone and Face to Face Surveys. https://eric.ed.gov/?id=ED374136 [12] Xiaoou Ding, Zekai Qian, Hongzhi Wang, Siying Chen, Yafeng Tang, Hongbin Su, Huan Hu, and Chen Wang. 2025. UniClean: A Scalable Data Cleaning Solution for Mixed Errors based on Unified Cleaners and Optimized Cleaning Workflow. Proceedings of the VLDB Endowment (PVLDB) 18, 11 (2025), 4117–4130. https://doi.org/10.14778/3749646.3749681 [13] Anna-Christina Glock, Christine Dominka-Kiss, Philipp Korom, and Lisa Ehrlinger. 2025. Detecting and Cleaning Errors in Personal Contact Information with Large Language Models. Proceedings of the VLDB Endowment (PVLDB) (2025). [14] Jean-Nicholas Hould. 2017. Craft Beers Dataset. https://www.kaggle.com/ nickhould/craft-cans. Version 1. [15] Ykä Huhtala, Juha Kärkkäinen, Pasi Porkka, and Hannu Toivonen. 1999. TANE: An Efficient Algorithm for Discovering Functional and Approximate Dependencies. Comput. J. 42, 2 (1999), 100–111. https://doi.org/10.1093/COMJNL/42.2.100 [16] Philipp Jung, Sebastian Jäger, Nicholas Chandler, and Felix Biessmann. 2025. Towards Realistic Error Models for Tabular Data. ACM J. Data Inf. Qual. 17, 4 (2025), 28:1–28:27. https://doi.org/10.1145/3774914 [17] Bojan Karlas, Peng Li, Renzhi Wu, Nezihe Merve Gürel, Xu Chu, Wentao Wu, and Ce Zhang. 2020. Nearest Neighbor Classifiers over Incomplete Information: From Certain Answers to Certain Predictions. Proceedings of the VLDB Endowment (PVLDB) 14, 3 (2020), 255–267. https://doi.org/10.14778/3430915.3430917 [18] Vladimir I. Levenshtein. 1966. Binary Codes Capable of Correcting Deletions, Insertions, and Reversals. Soviet Physics Doklady 10, 8 (1966), 707–710. [19] Peng Li, Xi Rao, Jennifer Blase, Yue Zhang, Xu Chu, and Ce Zhang. 2021. CleanML: A Study for Evaluating the Impact of Data Cleaning on ML Classification Tasks. In Proceedings of the IEEE International Conference on Data Engineering (ICDE). https://doi.org/10.1109/ICDE51399.2021.00009 [20] Xian Li, Xin Luna Dong, Kenneth Lyons, Weiyi Meng, and Divesh Srivastava. 2012. Truth Finding on the Deep Web: Is the Problem Solved? Proceedings of the VLDB Endowment (PVLDB) 6, 2 (2012), 97–108. https://doi.org/10.14778/2535568. 2448943 [21] Yi Li and Gao Cong. 2025. GeoBloom: Revisiting Lightweight Models for Geographic Information Retrieval. Proceedings of the VLDB Endowment (PVLDB) 18, 5 (2025), 1348–1361. https://doi.org/10.14778/3718057.3718064 [22] Yiding Liu, Tuan-Anh Nguyen Pham, Gao Cong, and Quan Yuan. 2017. An Experimental Evaluation of Point-of-interest Recommendation in Location-based 13

Related documents

• TrajectoryDB: A New Database for Agent Trajectories#673620
• Preserving contextual information in cultural heritage metadata through multidimensional knowledge graphs#673621
• X-DigCheck: Co-Evolving Application Profiles and Knowledge Graphs, Demonstrated on the RTI Documentation of Rupe Magna#673622
• Open Tabular Insight Extraction: Where Do We Stand, and Where Should We Go?#673623
• Protocol effects on feature-based hardware-Trojan detection across Trust-Hub families#673624