KG2Tables: A Domain-Specific Tabular Data Generator to Evaluate Semantic Table Interpretation Systems

SemTab 2019 [30] introduced a new collection of benchmarks created using an automated data generator. The data generator takes a KG with a SPARQL endpoint as input and first performs profiling to identify classes, properties, and their characteristics. It then uses the profiling output to generate tables where: a) each table contains a set of entities of a particular class type (e.g., person), b) the first column in each table contains an identifier label (e.g., person name), c) other columns in each table contain property values (e.g., age or place of birth), and d) errors and variations are introduced in each cell value to make the annotation task more challenging. Each generated table comes with ground truth annotations for CEA (mapping each label to the KG entity), CTA (mapping each column to the associated class), and CPA (mapping the first column and every other column to the property used to populate the column contents). The SemTab 2019 generator retrieves only direct properties for each class without considering the subclass hierarchy in the KG. The primary mechanism for data generation in the generator is randomly selecting property sets and running SPARQL queries to find those that produce complete tables with no null values.

In the following, we discuss the most common benchmarks that are used for evaluating STI systems with an overview of their limitations. We provide comparison tables for such benchmarks, including our newly generated ones in Table 2 and Table 3 (see Section 5).

Limaye [34] is one of the earliest benchmarks developed for STI tasks. It aims to annotate web tables using the YAGO KG. The dataset is divided into four subsets according to the data source, the labeling method, and application scenarios. Three subsets are manually labeled, while the fourth one is automatically generated. Altogether, it constructs the final benchmark with 428 annotated tables. Annotation errors were reported for the automatically labeled subset [36], which were corrected by Bhagavatula et al. [18] in 2015. Later on, in 2017, Efthymiou et al. [24] adapted the disambiguation links to the DBpedia KG.

T2Dv2 [33] is the recent edition of the T2D [40] gold standard where annotation errors are fixed. It is widely used by STI systems like Limaye et al. [34] and others. Up to 2019, T2Dv2 along with Limaye were the main benchmarks used by STI systems. T2Dv2 covers the tasks of row-to-instance (RA in our context), attribute-to-property (maps to our definition of CPA), and table-to-class (TD following our definition), for 779 tables that are derived from WebTables [19] where the target KG is DBpedia. In addition, T2Dv2 provides extensive metadata, such as the context of the table and whether the table has a header.

ToughTables (2T) [21] is a set of 180 tables that are annotated from Wikidata and DBpedia. The first use of 2T was during SemTab 2020 fourth round. It focuses on the ambiguity among entity mentions in a way that makes it hard to disambiguate by a human expert. The authors did not rely on the automatic generation of the dataset only but also provided manual curation of such annotation to avoid false positives while evaluating a matching algorithm. It contains real tables that reflect a knowledge gap between the target KG and an input table. Misspellings are frequent and intense, which is useful for testing the weight of lexical features an algorithm could use. In addition, a large number of rows is used to evaluate the system’s performance.

GitTables [28] is a subset of the original dataset [27] that was introduced in SemTab 2021. It is a collection of 1,101 tables crawled from GitHub. They are annotated with DBpedia and schema.org for the CTA task. GitTables poses a special case of CTA where the target annotation match is not only a KG class but also a KG property. However, we analyzed the provided CTA targets; we found GitTables has a sparse table structure leading to empty or almost empty columns, making the CTA task very challenging.

SemTab 2019-2020 [30, 31] are the first and second benchmarks that were introduced by SemTab challenge in 2019 and 2020, respectively. Both are large-scale datasets automatically generated (AG) from DBpedia and Wikidata, consisting of $15k$ and $131k$ tables, respectively. The common data issues in both benchmarks are misspellings and ambiguity among table rows. These benchmarks also focus on testing the ability of a system to scale.

HardTables 2021-2022 [22, 1] are the benchmarks that were introduced by SemTab’s third and fourth editions in 2021 and 2022. They also focus on misspellings and ambiguities. Each consists of $9k$ tables generated using an improved version of the data generator introduced in 2019 [30] that creates more realistic-looking tables. Tables that are correctly annotated by baseline methods are removed to create a harder dataset.

WikidataTables [14] is the benchmark that was published during SemTab’s fifth edition in 2023. This dataset is also generated by an improved version of the 2019 data generator and consists of $10k$ tables. However, it is generated using a configuration that resulted in a large number of very small tables with a high level of ambiguity for entity columns. This was done by selecting labels that can refer to more than one entity in Wikidata.

BioTables [37] is a dataset that is used during SemTab 2021. It is derived from the biomedical domain and consists of 110 tables. Its unique characteristic is that it contains columns with very long descriptions from Wikidata.

BiodivTab [12, 13] is a biodiversity-specific benchmark manually annotated using Wikidata and DBpedia concepts. It consists of $50$ tables that are derived from real and augmented tables. BiodivTab featured new challenges besides the common ambiguity issue and spelling mistakes, like the nested entities in a single cell and the synecdoche; biodiversity scientists might use a city name instead of a target river or an ecosystem name. For example, we found an occurrence for Kentucky (city) to represent Kentucky River (river).

We retrieved both instances and subclasses for each level using a recursive method for each concept. For example, at the first level, for each concept in the input domain, we identified three folds: direct instances, subclasses, and instances of subclasses. For each fold, we applied two kinds of table generation methods to construct horizontal relational tables: a description-based method and properties-based methods.

The generation of this table type, entity table is more straightforward in development than in horizontal relation tables. For each child in the retrieved children per concept, we have listed its properties and have applied the general filtering function, i.e., excluding labels and IDs. Afterwards, we have saved such a child to a CSV file with an entity orientation, where an entity table should have at least two properties. Additionally, we added a common description of the parent category to all its belongings. The added long text provides an entity table with more lexical context.

The supported STI tasks for entity tables are (i) TD links the entire table to a KG entity. (ii) RA annotates a row to a single property. (iii) CEA maps a single cell that has a property value to an instance.

The objective of this task is to obtain the final output of the benchmark, and it contains two steps. Raw table headers containing either the term ‘description’ or the original properties names. I.e., in properties-based generation methods, table columns represent children’s properties. We have anonymized these values by changing them to col1, col2, etc. Another indirect manipulation is renaming the header to another value. This technique requires manual effort. For example, a column with header ‘country of origin’ would be renamed to ‘originated’. Another possibility for header manipulation is to abbreviate it. For example, the same example is changed to ‘C. of Origin’ or ‘CoO’. For this task, we can also leverage a Large Language Model (LLM), e.g., GPT-4 [38] to suggest realistic abbreviated labels for a given column header.

During the raw table generation phase, we embedded the solution of STI tasks in the table itself except for CTA. For example, the original table name is the solution of TD. In addition, we created an extra column with the ground truth of the RA task. In this step, we create the final format of the benchmark. We create final tables, their solutions ‘Ground truth data (gt)’, and targets, i.e., indicate what to solve for each task. Targets are given to STI systems in case the gt data is hidden. They are used to guide these systems on what to annotate without providing the actual solutions or annotations to them. During the gt creation, we extracted solutions from the raw tables and created separate files that list the gt data with an indication of the target file, column, row, or cell. From this gt, we create the targets for the required tasks by dropping its solution column. For the CTA task, we collected cells’ annotations for columns and queried the KG for their semantic types. We collected all types with at least 50% support of the column cells. To enable a partially correct solution for CTA, we queried the ancestors and descendants for the collected types using the same technique introduced in SemTab 2020 [31]. For the CEA task, since some cells are created using multiple properties, we kept a ground truth for each individual if it exists.

We selected the Food, Biodiversity, and Biomedical domains as examples to generate domain-specific STI benchmarks. However, KG2Tables is not limited to these domains since it accepts any given domain concepts. We set the maximum levels of depth to 10 of the KG2Tables for the first two domains while we set it to 5 for the biomedical domain. These experiments yielded three huge datasets: tFoodL, tBiodivL, and tBiomedL.

The target KG contains different tree sizes based on the selected domain concepts. For instance, the biomedical domain contains general concepts, e.g., entity (wd:Q35120) contains millions of instances. Thus, tree pruning is needed.

Figure 6 depicts the tree we leveraged to construct tFood. It also highlights the effective depth that is included during the creation of the corresponding benchmark. tFood and tFoodL are created with 2 and 8 levels of the tree, respectively. This also indicates that constructed benchmarks contain all related data (instances and subclasses) by convergence before reaching the maximum level of depth without any tree pruning applied.

Figure 7 and Figure 8 illustrate the tree to construct both tBiodiv and tBiomed. We applied a tree-pruning technique for both benchmarks by setting the maximum number of instances/subclasses to 100. tBiomed did not converge where the maximum depth is reached even after applying tree pruning. This is due to the huge number of instances retrieved, e.g., ‘protein (Q8054)’ contains 1,002,653 instances in Wikidata as of the time of writing in November 2023. So, to construct a biomedical-specific benchmark, we set the maximum depth to 5 levels instead of 10 to yield into tBiomedL.

Table 1 summarizes the current state of the three experiments. tFoodL is 3x times larger than tFood by leveraging more tree levels instead of two, as in tFood. tFoodL contains all the data of the internal hierarchy of eight levels without any tree pruning. The last two levels (9 and 10) yielded no results We set the tree pruning threshold to 100 for both biodiversity and biomedical benchmarks. This threshold will limit the maximum number of instances/subclasses to be retrieved. The former, tBiodivL produced more than $220k$ tables leveraging nine levels of the tree, where the last level produced no results. The latter, shown in tBiomed, failed to converge when we set the maximum level to 10; thus, we reduced the maximum depth into five levels, yielding more than $860k$ tables leveraging five levels of the tree. We constructed relatively smaller-sized benchmarks for both domains using only two levels: tBiodiv and tBiomed. However, tBiodiv is still large, 122 GB in size. Both dataset folds, validation and test, are available online, but the test fold currently has no ground truth data. We plan to publish it as well by the end of 2024. We published a sample online for those datasets that were too large (as a proof of concept). This sample contains 1% of the resultant benchmark data.

Table 2 describes the existing benchmarks in terms of their domain, original data source, and target KG. Our generated benchmarks are the only domain-specific datasets that are derived from a given KG (Wikidata in this case). Table 3 shows the statistics of the state-of-the-art benchmarks compared to the horizontal tables from our generated datasets. It shows their number of tables, average rows, columns, and their coverage for STI tasks. From this table, our generated benchmarks are the only benchmarks that cover all STI tasks. In addition, they are large-scale domain-specific datasets compared to BioTables and BiodivTab. E.g., tBiomedL contains more than $500k$ tables, to the best of our knowledge, this is the largest benchmark for STI tasks. This enriches the community with large-scale benchmarks that cover the entire set of STI. In addition, KG2Tables facilitates the construction of new domain-specific tabular data benchmarks since it is independent of the domain of interest and easily adapted to different underlying KGs.

In this section, we demonstrate randomly generated tables by KG2Tables in the three domains we have experimented with to explore whether the generated tables adhere to a specific domain. Figure 12 represents a randomly tFood generated table. It contains encoding issues, e.g., in row 42, that should be solved first before systems can annotate such a table. This table groups a set of drinks (wd:Q40050). Figure 13 and Figure 14 depict random examples from tBiodiv, and tBiomed datasets, respectively. Both tables are much smaller regarding row number compared to the tFood example. The former represents a set of tidal rivers (wd:Q1074069). The latter demonstrates a set of taxons (wd:Q16521). Given the solutions of TD task as shown above, the three examples demonstrate domain specificity for each experimental domain.

In the following, we give a statistical overview of the tFood benchmark and an evaluation of well-known STI systems participating in the 2022 and 2023 editions of SemTab and beyond.

Resources should be easily accessible to allow replication and reuse. We follow the FAIR guidelines to publish our contributions [44]. We released KG2Tables [10]¹³¹³13https://github.com/fusion-jena/KG2Tables and datasets (tFood(L) [8, 9], tBiodiv(L) [4, 5], tBiomed(L) [6, 7]) in such a way that researchers in the community can benefit from them. To reach a broader audience the tFood benchmark was integrated within the SemTab 2023 edition¹⁴¹⁴14https://sem-tab-challenge.github.io/2023/. We plan to include the other datasets within SemTab 2024. Our code and datasets are released under MIT and Creative Commons Attribution 4.0 International (CC BY 4.0), respectively.

We plan to maintain the published artifacts from this paper by uploading newer versions of the dataset to the same Zenodo repositories. We expect changes for such datasets in case of bug fixes, ground truth data modifications, targets, etc. Regarding the code, we plan to apply the same methodology of monitoring updates; we will release new code versions and upload them to Zenodo as well, while the most recent version of the code is found under our GitHub repository. In addition, we will publish a ‘change log’ that describes the changes that have been applied to a specific dataset or in the code.

Since KGs are dynamic and subject to frequent changes, we should point to a specific version or a KG dump for benchmark reproducibility and allow a fair assessment to STI systems that solve these benchmarks. Thus, we also upload specific dumps of KG, e.g., Wikidata, to Zenodo. For example, the early Wikidata dump of March 2024 [26] could be used to either reproduce the results of KG2Tables or to be used by STI systems to solve the generated benchmarks.

We relied on STI systems to directly solve our generated benchmarks, and we used their obtained scores as a metric to evaluate such benchmarks. However, after these experimentations, either in the early bird evaluation or in SemTab 2023 (see Section 5.5, we decided to investigate the quality of the generated tables as well.)

Since the generated benchmarks could reach up to 500K tables, inspecting the individual tables manually is impossible. Thus, to gain an overview of these benchmarks, we constructed smaller subsets using the most frequent semantic class, e.g., top CTA annotation for each of them, and re-ran the generator using a maximum depth level of two and maximum number of instances (tree pruning) is five. These subsets are summarized in Table 5 demonstrating the selected concept and validation test splits number of tables. We manually checked the validation split for each of these benchmarks, which is, in total, 30 tables with their corresponding ground truth annotations.

In this quality inspection experiment, we aim to evaluate these subsets concerning three dimensions of data quality: 1) Diversity of the generated data, e.g., does the generator manage to capture other related domain concepts, or does it stick to the provided domain concepts? Another aspect is comparing null annotations to the retrieved types, e.g., NILs. 2) Quality of annotations, i.e., if a required annotation is impossible to solve, it is wrongly labeled in the ground truth or too abstract and not that useful. Finally, 3) Quality of the table structure, e.g., if there are duplicate tables, rows, or columns. Table 6 summarizes these findings by showing the number of tables per subset that fulfills the abovementioned requirements.

To assess the generated topics’ diversity, we counted unique table types from the ground truth data of the TD task. While NILs represent the count of the null annotations versus the actual semantic types for CTA annotations. For this aspect, the generator found more related concepts using only two levels for both tBiomed and tFood subsets. For tBiodiv, the generator needs more levels to explore to include more diverse data. The NILs metric balances the number of null annotations and actual semantic types for the tBiomed subset. This is much better in the other two domains, where the dominant types are actual semantic classes.

To evaluate the quality of annotations, we counted the number of individual tables with wrong, abstract, or impossible annotated annotations in all STI tasks. To inspect the quality of the generated table structure, we also counted the number of individual tables that are duplicated or have duplicate columns, rows, or cells. In tBiomed and tFood subsets, we found a couple of tables listing a duplicate cell value (wd:Q16695773, ‘WikiProject’), which is considered too abstract. In tBiodiv subset, another table contains (wd:Q1239328, ‘national encyclopedia’) as a column type, CTA annotation, which is too abstract or not domain-relevant. Additionally, another table contains RA annotations for rows containing one cell value (short values, e.g., country names). Those should be removed from RA ground truth or converted to NIL. In tFood, RA annotations are also found for tables that contain only one column but with longer text, e.g., descriptions. We did not consider that as impossible to annotate as in tBiodiv since the text provides more context than short values. We extended the evaluation of the annotation quality by giving a closer look to RA and CTA ground truth data. We determined four more aspects: how many annotations belong to the general domain, a different domain, and the desired domain. In addition, we locate those that are impossible to be annotated by an STI system. Table 7 summarizes these findings for the three datasets. RA gt annotations for tBiomed and tBiomed have seven unique entities in total. In tBiomed, we found (wd:Q3, life) and treated as both domain-specific and general domain simultaneously. The rest are entities related to (wd:Q2996394, biological process) like (wd:Q11978 ,digestion). In tBiodiv, we found only one entity that is impossible to annotate since it does not have any label or description in Wikidata. The rest are entities related to (wd:Q16521, taxon) or (wd:Q7432, species). tFood has a total of 19 unique RA annotations; we found two impossible entities to annotate due to the lack of Wikidata labels. The rest are entities related to (wd:Q178, pasta), (wd:Q9266, salad), or (wd:Q746549, dish). CTA gt annotation for tBiomed and tBiodiv have three unique classes. The former has the WikiProject class, which we considered a general domain, and the latter contains a class related to Philosophy, which is a different domain from biodiversity. tFood has a total of 8 unique classes, three of which belong to the general domain like (wd:Q6256, country). The rest are subclasses of (wd:Q2095, food) or (wd:Q25403900, food ingredient).

In this section, we evaluate the generated tables with their annotation concerning being a realistic dataset that is possible to annotate. First, we define the metrics we use to define a realistic dataset.

• $\mathrm{■}$

  M1: The analysis of the generated tables with their TD gt data should reflect various domain concepts and not stick to the given ones.

• $\mathrm{■}$

  M2: The analysis of the individual rows and columns with their mappings (RA and CTA) should reflect the selected domain (probably with some classes from the general domain as well) or cannot be mapped at all (NILs).

• $\mathrm{■}$

  M3: The ratio between the number of annotations and NILs should have a good balance.

• $\mathrm{■}$

  M4: The analysis of the gt data for STI tasks should have NILs for records that are impossible to annotate.

• $\mathrm{■}$

  M5: The generated tables should have no or limited duplicated rows and columns.

• $\mathrm{■}$

  M6: The generated tables should have realistic noise. For example, column names should be anonymized or renamed with meaningful headers.

Currently, we evaluate the generated benchmarks across these metrics. We could determine some of them based on the method we developed and others we assess using the manual inspection of the generated benchmark as we did in the Quality Inspection (Subsection 5.8).

For M1, manual inspection of the generated benchmarks is needed. We provided these numbers for the generated snippets of the three domains. Table 6 showed that the generated datasets contain more topics than the initial input domain-related concepts. Despite KG2Tables parsing the input domain concepts hierarchically, this ensures that all topics and classes belong to the same parent concept, and manual inspection could help identify the relational mistakes among these concepts in the source KG itself. For instance, if we leverage DBpedia as a source KG, at the time of writing, it contains a triple dbr:Species rdf:type dbo:MilitaryUnit.

For M2-M5, all of them need manual inspection as well. The Data Quality Inspection (see above) fulfills these metrics. For M2, Table 7) demonstrated the number of entities and classes that are related to the target domain versus the general or different domain. In the three domains, the desired target domain has the dominant mappings. For M3, M4, and M5, Table 6 showed that the generated benchmarks have a good balance between NILs and true annotations for all STI tasks. Where we detected duplicates only on the cell level. However, it is still a subject of enhancement, especially for those that are impossible to annotate records in both tBiodiv and tBiomed.

For M6, we can judge this metric from the method level. We currently anonymize column headers for all generated tables, such as Col1, Col2, … etc. We also suggest using LLMs to rename these columns, providing more context to the table. Alternatively, we could abbreviate the original column headers, which provides limited context. For table cells, we do not introduce any artificial noise to the original cell content. This is unlike existing AG general domain benchmarks (SemTab’19-23 and 2T) that have excessive artificial noise in the table content, making the generated table more artificial than realistic. These metrics and their evaluation in our generated benchmark from the method level or based on the sample evaluation demonstrate that we created realistic benchmarks for the three domains of interest using KG2Tables.

Table 8 demonstrates a summary of five categories of the comparison between KG2Tables to SemTab 2019 generator approach: General aspects, generated tables types, internal structure it uses, table refinement techniques, and supported STI tasks. At first, the SemTab 2019 approach requires an entire dump of a KG, which it analyzes during the profiling step; however, it can also work off of SPARQL as well. KG2Tables, it requires an input of a list of domain-related concepts and uses SPARQL queries only to interact with KG to retrieve scoped children via recursive calls as demonstrated in Section 4. Both SemTab 2019 and KG2Tables produced large-scale benchmarks, while the latter has the largest produced tBiodivL with around half a million tables. SemTab 2019 adheres to no domain since it can process an entire KG dump; however, our approach is bounded by the scope of the provided domain concepts as in the input file. Both generators are subject to generalization and support various KGs via slight modifications. This is possible in SemTab 2019 by having a KG dump of own choice or by re-writing SPARQL queries. In KG2Tables, we need to change the configuration of the SPARQL query endpoint and re-write the SPARQL queries themselves as well. Regarding the generated table types, SemTab 2019 generates only horizontal table types, but KG2Tables generates horizontal and entity table types. The internal data structure used by SemTab 2019 generator code is the direct classes with their properties only, i.e., ‘flat’ data structure compared to KG2Tables. In the case of KG2Tables, we process the entire data hierarchy using recursive calls as a ‘tree’. A flat structure is also covered by setting the depth level to one. Concerning table refinement, KG2Tables anonymizes table columns only. However, SemTab 2019 introduces artificial noise, i.e., spelling mistakes and column anonymization. Finally, SemTab 2019 supports the three basic STI tasks: CEA, CTA, and CPA only, but KG2Tables additionally supports RA, and TD.

In this section, we discuss eleven aspects of KG2Tables with an illustration of its limitations, and we point out possible solutions for them.

The out-of-the-box usage of KG2Tables is the fastest use, i.e., Wikidata is source KG. A list of domain-related concepts is the only required step. Ideas on how to select domain concepts include but are not limited to, a data-driven approach where a domain analysis is required on the KG itself, as we did in tFood construction. Another approach is reusing existing semantic classes or types for a particular domain. We adopted this approach to create tBiomed and tBiomed. Last but not least, ask domain experts to suggest domain-related concepts. KG2Tables has no limit on the number of domain-related concepts, but a non-exhaustive list is guaranteed to generate benchmarks successfully.

A recommended step before generating a benchmark is a sanity quality inspection, i.e., a lightweight activity to gain an overview of the to-be-generated benchmark, which can be tested with one or two domain-related concepts. Mertices that are important to check are the quality of both annotations and generated tables. We demonstrate such activity in Section 5.8 with a list of useful metrics to assess the data quality. This step can influence the filters applied to generate the final tables and yield high-quality benchmarks.

A customized use is also supported beyond providing domain-related concepts to KG2Tables. We expose customized input to the generator via a configuration file¹⁶¹⁶16https://github.com/fusion-jena/KG2Tables/blob/main/config.py. For example, the value of the depth level and the maximum number of children per depth level are customizable. Changing these values allows exploring different data and nested concepts; if the maximum number of children is too large, KG2Tables might fail to generate the benchmark.

More advanced use of KG2Tables leverages other KGs, e.g., DBpedia or domain-specific ones. In addition to providing the target SPARQL query endpoint in the configuration file, more modifications are required to the current code version. For example, re-writing SPARQL queries that retrieve instances, subclasses, and their properties. These queries are embedded in the code itself¹⁷¹⁷17https://github.com/fusion-jena/KG2Tables/blob/main/inc/api_properties.py.

Based on the comparison with SemTab 2019 approach and the explained aspects of KG2Tables, we summarize its impact and challenges. On the one hand, KG2Tables solved the problem of finding or crafting an STI benchmark to assess domain-specific STI system. This is brought handily and quickly by providing a list of concepts of a domain of interest. The target audience for this tool will be researchers who aim to build trusted domain-specific STI systems. Other audiences from the industry could also use it to validate their commercial tools. From our experience, STI systems evaluation using only general domain benchmarks is insufficient if such systems are supposed to be domain-specific; a critical domain example is the biomedical domain. The manual construction of these domain-specific benchmarks, usually small in scale, costs an average of a year of development, e.g., BiodivTab [12, 13]. KG2Tables generated realistic datasets as we defined in Subsection 5.9. For example, the constructed benchmarks add no artificial noise to the cell content. In addition, KG2Tables relies purely on SPARQL queries to construct STI benchmarks, making it easily adapted to any other KG. It can also generate various benchmarks with different parameters, such as the maximum depth at which the approach can go deep. On the other hand, the current version of KG2Tables brought new challenges to the STI benchmarks creation. Generally, the output benchmarks from the KG2Tables approach are silver-standard, which is less in quality than those manually created or gold-standard. For example, the ambiguous rows we detected in a later stage of KG2Tables development. This requires a sort of systematic approach to ensure high-quality data. We explained a sample-based method to ensure data quality in Subsection 5.8 with quality metrics in Table 6 and Table 7. In addition, KG2Tables is sensitive to the domain representation in the source KG. If the target domain has limited entities and classes, then the resultant benchmark will lack a dense representation of such a domain. Moreover, KG2Tables is bounded by the selected resources of the hardware and the timeout errors from the SPARQL endpoint. Such scalability issues we experienced in the construction of tBiodivL.