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

¹

1 Introduction↩︎

Ensuring high-quality data is a cumbersome process that requires numerous exhaustive human cycles [1]. Data cleaning research aims to automate this task, proposing a large number of rule-based [2], learning-based [3], and, more recently, LLM-driven [4] 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 [5].

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 such benchmark datasets: (i) a supposedly clean dataset is dirtied using error generators [5], [6], (ii) a dirty dataset is manually curated to obtain the corresponding ground truth [7], 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 [8]–[10].

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 [8].

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 [11], suppliers, and partners [12]. The famous case of the 6.8 billion pieces of mail that could not be delivered as addressed [13] 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 [7].

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 [14] 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 [15]. 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 LLM-driven strategies, and scale not only with respect to the number of rows and columns, but also across different error rates and error distributions.

2 Related Work↩︎

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

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 [16], Flights [17], Rayyan [18], or Beers [19]. In 2015, Abedjan et al. [7] 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 [20]. 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.

Error Generators↩︎

Several benchmarking papers provided error generation tools for datasets. BART [6] 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 [21]. JENGA [22] is a framework that includes a data corruption module to study the impact of data quality issues on downstream machine learning tasks. GouDa [23] is a data generation tool that creates datasets with specific error types without requiring an initial clean table. More recently, Jung et al. [5] 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.

Data Cleaning for Machine Learning↩︎

Data cleaning can be an operator within a data science pipeline [22]. Thus, one can measure the effectiveness of cleaning using downstream model performance as a proxy. Karlaš et al.proposed CPClean [24], 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 [21], 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 [8].

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.

3.1 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.

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 [7]. While prevalent, address information is often challenging, as formats do not follow a single, universally adopted standard.

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 [14]. 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.

1. Download WDC N-Quads. The WDC project extracts structured data from Common Crawl² and publishes pre-extracted RDF statements in N-Quads format [14]. We downloaded all class-specific Schema.org subsets³ that contain PostalAddress annotations⁴, covering types of points of interest (POIs) such as Library, Hotel, and Hospital, as well as the html-mf-adr subset from the Microformats source⁵.
   \(\quad\rightarrow\;\) 12.9B N-Quads from 22 Schema.org subsets
   \(\quad\rightarrow\;\) 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.
   \(\quad\rightarrow\;\) 247.9M dirty records from schema:PostalAddress entities
   \(\quad\rightarrow\;\) 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.
   \(\quad\rightarrow\;\) 219.9M dirty records from schema:PostalAddress entities
   \(\quad\rightarrow\;\) 8.5M dirty records from vcard:Address entities

4. Retrieve reference addresses. We searched for corresponding reference addresses using a geocoding service. After matching and validation, we treat these reference addresses as ground-truth records. The matching and validation procedure is discussed in detail in Section 4.2.
   \(\quad\rightarrow\) 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.
   \(\quad\rightarrow\;\) 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.
   \(\quad\rightarrow\;\) 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.

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 [14]. We used the WDC release for December 2024, the most recent at the time of data collection.

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 [lst:nquads95example]. 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 [lst:nquads95example], _:b1 is the address node, and _:b0 is the LocalBusiness entity whose address is _:b1. Listing [lst:extracted95record] shows a simplified extracted address with selected fields.

_:b0  rdf:type           schema:LocalBusiness    <example.de/page> .
_:b0  schema:name        "NAME"                  <example.de/page> .
_:b0  schema:address     _:b1                    <example.de/page> .
_:b1  rdf:type           schema:PostalAddress    <example.de/page> .
_:b1  schema:streetAddress     "STREET"          <example.de/page> .
_:b1  schema:addressLocality   "CITY"            <example.de/page> .

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

html-mf-adr Microformats subset. WDC also provides a format-specific 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 [lst:vcard95nquads]. 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.

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.

_:b0  rdf:type                vcard:Address     <example.com/page> .
_:b0  vcard:street-address    "STREET"          <example.com/page> .
_:b0  vcard:locality          "CITY"            <example.com/page> .
_:b0  vcard:country-name      "COUNTRY"         <example.com/page> .

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.1 Geocoding Service Selection↩︎

Generating ground truth at this scale requires a geocoding service with broad geographic coverage, 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 Maps⁶, a dataset of approximately 446M addresses stored as GeoParquet files on S3, which can be queried offline via DuckDB; (ii) OpenAddresses⁷, a collection of roughly one billion addresses distributed as GeoJSON files, also queryable via DuckDB; and (iii) Nominatim⁸, 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 API⁹, 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.

4.2.2 Geocoding Service Querying↩︎

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

For each dirty record, we queried the Nominatim API through its /search endpoint to retrieve the corresponding representation in the OSM database. The query template, which exploits the structured information provided by the PostalAddress schema, is shown in Listing [fig:nominatim95search]. 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 libpostal¹⁰, 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.

Similarly, OSM stores both the country name and its ISO 3166-1 alpha-2 code¹¹, 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 [25], was then used as the tie-breaking criterion in case multiple (non)preferred fields were present at the same time.

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 ratio¹² 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 country-based lists of recognized localities, e.g., Gemeinden in Germany¹³ or places/subdivisions in the US¹⁴, 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.

8pt

4.3 Ethical Concerns↩︎

In alignment with prior work that analyzed the Common Crawl archives [26], 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 library¹⁵ 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 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, 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 \(\rightarrow\) country_code¹⁶), two (e.g., postcode, locality \(\rightarrow\) country), or three attributes on the left-hand side (e.g., house_number, road, postcode \(\rightarrow\) 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.

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 [27], [28]. In our analysis, we focus on library and shopping-center, which cover all identified error types.

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.

• 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 double-counting 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:

Clean \(\to\) Missing \(\to\) Parsing \(\to\) Capitalization \(\to\) Special Chars \(\to\) Name Reformat \(\to\) Language \(\to\) Abbreviation \(\to\) Token Subset \(\to\) Typo \(\to\) Word Substitution \(\to\) 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-distance-based 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 \(\leftrightarrow\) München, Café \(\leftrightarrow\) Café. Equality with the ground truth is restored after an appropriate decoding step.

4. Capitalization – The two values are identical under Unicode case folding [29], e.g., ATLANTA \(\leftrightarrow\) Atlanta, 10a \(\leftrightarrow\) 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 \(\leftrightarrow\) Notre Dame Street, U.S.A. \(\leftrightarrow\) 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 ordering in the original strings, e.g., Howson Branch, Austin Public Library \(\leftrightarrow\) Austin Public Library – Howson Branch, South 37th Avenue \(\leftrightarrow\) 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 \(\leftrightarrow\) Österreich, Athens \(\leftrightarrow\) \(A\theta\acute{\eta}\nu\alpha\). 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 [30], e.g., Ave \(\leftrightarrow\) Avenue, Bachmannstr. \(\leftrightarrow\) Bachmannstraße.

9. Token Subset – One token multiset is a strict subset of the other, e.g., New York \(\subset\) New York City, Finavia \(\subset\) 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 [25], [31], e.g., Theater \(\leftrightarrow\) Theatre, Marriott \(\leftrightarrow\) Mariot.

11. Word Substitution – Exactly one token differs between the two multisets while at least one token is shared, e.g., VA Clinic \(\leftrightarrow\) 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 \(\leftrightarrow\) Highway 76, administrative reassignments, e.g., Strathroy \(\leftrightarrow\) 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. [32] 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 [7].

4pt

5.2.2 Error Category Distributions↩︎

We now report the ratios of the defined error types for the full dataset and its slices.

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.

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.

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 ski-resort, often referenced from multiple countries. Focusing on the 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.%).

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, learning-based, 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. RAID-configured SSDs were used for storage.

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, de-slice, 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 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.

Rule-based Approaches↩︎

 [2] is a scalable rule-based system that generates repairs in linear time. We used the implementation provided by the authors¹⁷. As input, Horizon requires a set of FDs: we extracted them from the clean version of each sample using TANE [33], relying on a third-party Python implementation¹⁸.

 [34] 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 implementation¹⁹ 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.

Learning-based Approaches↩︎

 [35] is an error correction system that combines integrity constraints, external data sources, and statistical profiles in a unified factor graph model to infer the most likely repairs for detected errors. We used the original implementation²⁰ and provided it with the same FDs used for Horizon and UniClean.

 [36] and Baran [3] 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 implementation²¹. As recommended by the authors, we ran each experiment with 20 labeled tuples per task to train the corresponding models.

 [37] is a data imputation method based on deep learning. We used the official implementation²² 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.

LLM-driven Approaches↩︎

 [38] 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 implementation²³ 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.

6.3 Effectiveness Experiments↩︎

We evaluate the effectiveness of all baselines for both error detection and correction across different error rates, country slices, and POI-based 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.

6.3.1.1 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 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.

6.3.1.2 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’sperform 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’swith 42% and DataWig with 18%.

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’sis 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.

3pt

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.

Table 4 reports the overall precision, recall, and F1-score for detection and correction on both slices. Table ¿tbl:tab:poi-err-type-res? 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 ¿tbl:tab:poi-err-type-res? 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’sperforms better on textual and semantic transformations, including Abbreviation, Language, Special Characters, and Word Substitution. This complements the previous results: learning-based and rule-based 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 Efficiency and Scalability Experiments↩︎

To evaluate efficiency and scalability of the different data cleaning systems, we measure runtime and peak memory usage. Table ¿tbl:tab:runtime95memory? 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.

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 quick-response 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 memory-intensive. Its memory consumption increases from about 1.8 GB on the smallest setting to more than 86 GB on the subset with 100\(k\) 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. UniClean shows the highest memory footprint. Its peak memory already exceeds 127 GB on 100\(k\) 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 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.

6.5.0.1 (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.

6.5.0.2 (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 needed to infer the correct value becomes less reliable. Future research should therefore consider including augmentation strategies to balance out the error rates.

6.5.0.3 (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 LLM-based solutions. However, we have to acknowledge that existing systems already combine rules, supervision, and agents [3], [4], [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.

6.5.0.4 (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.

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.

7 Conclusions↩︎

In this paper, we present the first large-scale dirty address dataset with ground truth. The dirty version of the dataset contains real-world 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.

References↩︎