Tab2KG: Semantic table interpretation with lightweight semantic profiles

4.1.Domain profiles

For creating a domain profile, we make use of a domain knowledge graph G that contains representative values for the data type relations in the target domain. A domain profile Π(GO)={(rD,π(rD))|rD∈ROD} of a domain ontology GO=(NO,ROC∪ROD) is a set of data type relation profiles π(rD) derived from G, where a data type relation profile is a set of features of the literals covered by this data type relation in G’s data graph GD.

In brief, the profile of a data type relation rD is a feature vector containing a set of statistics, computed using all literals corresponding to rD. A description of the features of the literal relations follows in Section 4.3.

To create a profile for the data type relation rD=(c,pd,d), we utilize all literals l∈GD, such that: (e,pd,l)∈RD, (e,rdf:type,c)∈RD, and dt(l)=d.

In our running example, in Fig. 4, the data type relation (sosa:Sensor rdfs:label xsd:string) in the domain ontology corresponds to the literal relation (:Sensor3 rdfs:label “S3”) in the data graph. Therefore, we use “S3” as one of the literals to create the data type relation profile.

4.2.Data table profiles

To facilitate semantic interpretation of a data table, we create a data table profile.

A data table profile is a set of column profiles, each representing a specific data table column. More formally, the profile of a data table T consists of a column profile π(cn),n∈{1,…,N} for each table column cn∈T as defined in Definition 4.

A column profile is defined as follows:

We create column profiles using literal values contained in the table columns.

Column profiles and data type relation profiles are created analogously and contain the same features, presented in Section 4.3.

4.3.Profile features

Motivated by the RDF profile characteristics defined by Ellefi et al. [15], we include data types, as well as completeness and statistical features described in the following into the profiles in Tab2KG. The selection is motivated by the expected feature effectiveness for semantic table interpretation, i.e., matching the domain and data table profiles. We demonstrate in our evaluation that these features can facilitate an effective matching in several application domains. This feature set can be extended to include relevant domains-specific characteristics.

To derive numerical features, we transform literals into numbers. The features of textual data type relations are computed based on the textual value lengths. Temporal values are transformed into timestamps. For spatial values, we consider the line string length or the polygon area, respectively.

4.4.Profile-based semantic table interpretation

Following the definition of domain profiles, their features and representation, we can now refine Definition 5. Instead of requiring a data graph G, profile-based semantic table interpretation solely requires a domain profile Π(GO).

The domain profile is typically built from a domain knowledge graph G. As soon as the domain profile is created, the data graph of G is not required anymore for profile-based semantic table interpretation.

4.5.Semantic profile representation

Domain and data table profiles can be represented as semantic profiles in RDF, as an extension of the Data Catalog Vocabulary (DCAT)77 and the SEAS Statistics ontology.88

Within the DCAT vocabulary, a data catalog (dcat:DataCatalog) consists of datasets (dcat:Dataset), where a dataset is a collection of data, published or curated by a single agent. In the context of Tab2KG, both the domain knowledge graph and the data tables can be represented using dcat:Dataset. We extend the descriptions of datasets in a Tab2KG data catalog to include semantic profiles. For example, we introduce an Attribute class representing the data table columns and data type relations. We make the definitions of this vocabulary available online.99

Figure 6 provides an overview of the classes involved in representing semantic profiles. A dcat:Dataset in a Tab2KG data catalog includes several attributes. In the case of a data table profile, these attributes are the columns. In the case of a domain profile, these attributes are the data type relations. These attributes are assigned the profile features, as presented in Section 4.3:

Fig. 6.

Classes and properties used for describing a semantic profile. ⇾ marks owl:subClassOf relations. Dashed arrows indicate the existence of further classes which are not included in this excerpt. The two feature types (data types and numeric features) are grouped by different colors.

In the case of domain profiles, the existing mapping to the domain ontology can be modeled by connecting attributes to their corresponding classes, and data type properties [17].

Note that such semantic profiles do not only enable profile-based semantic table interpretation but can also be used to provide lightweight dataset visualizations, e.g., through box plots (quartiles) or as histograms.

4.6.Running example: Weather data catalog

An excerpt of an example data catalog for our running example from the weather observation domain introduced in Section 2 is shown in Fig. 7. The data catalog identified as WeatherCatalog includes two data tables (RainData and AirData). Here, the AirData data table has two columns, one of them with a column profile feature denoting the maximum value of the observation end time.

With Tab2KG, we can directly utilize this catalog for profile-based semantic table interpretation. Both example data tables can be interpreted through their data table profiles when a domain profile of the weather observation domain is provided.

Fig. 7.

Running example: excerpt of a weather data catalog containing two data tables and an exemplified column profile feature denoting the maximum end time value (ObservationEndTimeMax).

5.1.Approach overview

Figure 8 provides an overview of our proposed Tab2KG approach to semantic table interpretation, where a data graph GDT is created from a data table T. To facilitate the interpretation, Tab2KG utilizes background knowledge that includes a domain ontology GO and a domain profile. The domain profile is generated in a pre-processing step from a domain knowledge graph G.

In brief, the Tab2KG pipeline consists of the following steps:

In the following, we describe these steps in more detail.

Fig. 8.

An overview of semantic table interpretation with Tab2KG. Input is a data table T and a domain knowledge graph G. The output is a data graph GDT that represents the content of T as a data graph.

5.2.Domain profile creation

The profile-based semantic table interpretation in Tab2KG requires the availability of a domain profile. This profile can be inferred from a domain knowledge graph G as described in Section 4.1. The domain profile is created by computing the feature values given the literal relations in the domain knowledge graph. This profile can be used as a lightweight domain representation. The domain profile can be created in a pre-processing step and become available as part of a data catalog as described in Section 4.5. The domain profile does not contain any entities or literals from the domain knowledge graph G.

5.3.Data table profile creation

From the input data table T, we create a data table profile by computing the profile features based on the column values as described in Section 4.2.

5.4.Column mapping

With the help of the domain profile and the data table profile, we create column mappings.

For example, we can create a mapping from column c2 of the data table illustrated in Fig. 1 to the data type relation (time:Interval – time:hasBegin – xsd:time) in the ontology illustrated in Fig. 2.

For the column mapping, we utilize a domain-independent column mapping function. Given a column profile π(cn) and a data type relation profile π(rD), this mapping function returns a similarity score.

The column mapping function is trained in a pre-processing step. It learns from positive pairs of columns and data type relations that should be mapped (similarity: 1.0) and negative pairs that should not (similarity: 0.0). After training, the function predicts the similarity of previously unseen pairs.

The architecture of the column mapping function is shown in Fig. 9. The column profile π(cn) and the data type relation profile π(rD) are taken as an input and normalized jointly. Then, their similarity is computed by a Siamese network that encodes both normalized profiles using the same weights and then predicts the similarity score based on the difference between the two profile encodings. As in [30], we use Rectified Linear Units for the hidden layers and a Sigmoid output layer. By using the Sigmoid output layer, the column mapping function learned by our Siamese network returns a similarity score in the range [0,1].

Fig. 9.

Architecture of the mapping function to predict the similarity between a column cn and a data type relation rD.

Within the Tab2KG pipeline shown in Fig. 8, the column mapping function is utilized to create a set of candidate column mappings Mcn for each column cn in the data table T. In this step, we only consider mappings between columns and data type relations of the same data type (numeric, textual, temporal, spatial or Boolean).

The use of a Siamese network follows the idea used for one-shot learning for image classification [30]. Here, the task is not only to classify images into known classes (e.g., many images showing tigers) but also to generalize towards new classes (e.g., new images showing lions). That means, the underlying classifier needs to acquire features which enable the model to successfully generalize. This is done by inducing a metric that represents the domain-independent similarity between two input feature vectors (e.g., between an unknown image and a single image showing a lion).

As we cannot train a classifier on known classes (in contrast to domain-specific approaches such as Sherlock [23] and ColNet [8]), we are in a one-shot learning setting as well: We may learn how to map column profiles to known data type relations. But when facing a new domain, our classifier needs to generalize towards unseen data type relations. In Tab2KG, the similarity between a column and a data type relation is predicted based on the experience of the similarity of other profiles learned earlier.

The column profile and the data type relation profile are normalized jointly, i.e., the features are normalized in a range between 0.0 and 1.0 concerning the sum of the values in both profiles. This pairwise normalization is to ensure that the normalization happens within the same range, and this range covers all the values in both sources. If both profiles were normalized in isolation, different maximum values would be both normalized to 1.0 such that the values from different profiles were not comparable.

5.5.Data graph creation

Given a set of candidate column mappings Mcn with similarity scores for each column cn in the input data table T, we now map each table column to a data type relation in a greedy manner. First, we take the column mapping with the highest similarity score. Then, we remove all candidate column mappings with the particular column or data type relation. These two steps are repeated until all columns are mapped to a data type relation.

From the chosen column mappings set, we create the data graph GDT that contains all data type relations resulting from the chosen mapping. GDT needs to adhere to the following four conditions:

5.6.Creation of training instances for column mapping

For the computation of the column mapping function, we utilize a Siamese network trained once in a pre-processing step. This training process requires the extraction of positive and negative training instances. Following Definition 5 (see also Fig. 8), this step requires a set of (G, T, GDT) triples, where G is the domain knowledge graph, T is the data table and GDT is the resulting data graph. For each triple (G, T, GDT), each pair of data type relations in G and a column in T is a positive training instance. We select the remaining (data type relation, column) pairs from the same knowledge graph G as negative instances.

In the first step, we synthetically create a set of (G, T, GDT) triples for the model training, intending to have a large dataset of positive and negative examples derived from existing data tables and knowledge graphs. Such data, i.e., a diverse set of tables and their mapping definitions to different domain ontologies, is difficult to obtain, except for manually created, task-specific research datasets [39], which are not large enough for training deep neural networks and do not provide enough topical and structural diversity. Therefore, we utilize existing knowledge graphs to create training data.

Given a set of knowledge graphs, we create a new dataset of triples (G1, T, G2T). Each input knowledge graph G is disjunctly (i.e., without shared triples) split into two KGs: G1 and G2. As G1 and G2 do not overlap, it is ensured that the domain profile and the data table profiles used in training are not generated from the same values. G1 represents the domain knowledge graph, while G2 is transformed into a data table T. The transformation of G2 into T is based on a set of domain ontology templates. A template is a directed tree with up to k nodes, where k is a parameter. The nodes and edges of these trees are placeholders for classes and properties. A set of trees is transformed into domain ontologies by replacing these placeholders with the classes and properties of G2. From the knowledge graph G2, a data graph G2T is extracted and transformed into a data table T to create the triple (G1, T, G2T).

We aim to retrieve a set of heterogeneous data tables that represent the original knowledge graph characteristics. Therefore, the data table creation process incorporates several stochastic decisions in proportion to the knowledge graph statistics:

5.7.Running example: Data table creation

Fig. 10.

Creation of a data table T and a data graph G2T from a knowledge graph G2 and a domain ontology template τ. For brevity, we omit type relations.

For our running example introduced in Section 2, Fig. 10 illustrates the transformation of a knowledge graph G2 and a domain ontology template τ into a data table T. This transformation is performed after splitting the input knowledge graph G into G1 and G2, where G1 and G2 represent different portions of G (e.g., G1 contains a third observation of Sensor3). Consequently, the triple (G1, T, G2T) can be used as a training example where the feature weights to map T to G2T based on G1’s domain profile and T’s data table profile are learnt.

6.1.Data table pre-processing

Each data table interpreted in Tab2KG runs through three pre-processing steps:

7.1.Domain ontologies and vocabularies

In the real-world applications of Tab2KG, we require a domain ontology and a dataset that is modelled using this ontology to build the domain profile.

In our experiments, we aim to assess the performance of Tab2KG in different domains for mapping real-world tables. This evaluation requires annotated datasets which provide the tables and their ontology mappings. In the existing datasets such as SemTab [26], the tables are typically annotated using cross-domain ontologies such as DBpedia and schema.org. To facilitate evaluation, we extract domain ontologies from tables within specific domains. This extraction results in the domain-specific parts of the existing cross-domain ontologies.

For the ontology extraction, we use two approaches: a pairwise setting (P) that uses one table and a set-based setting (S) that uses a union of tables to represent a domain. These approaches are discussed in Section 7.3.

Statistics of the domain ontologies used in the evaluation and examples of their involved classes are presented in Table 1.

7.2.Datasets

The Siamese network training requires a dataset that spans multiple vocabularies and domains to ensure generalization. However, the domain ontologies shown in Table 1 are based on schema.org and the DBpedia ontology only. To feed and evaluate the Siamese network with data from a more diverse set of vocabularies, we created a new synthetic dataset automatically extracted from GitHub repositories dealing with knowledge graphs. The column mapping function trained on the train split of this dataset is expected to generalise to other domains and vocabularies represented in our datasets. Therefore, we use this mapping function for all datasets in the evaluation and do not train any dataset-specific column mapping functions.

7.3.Profile & test data generation

It is important to emphasize the difference in the evaluation setting compared to typical evaluation using the previously mentioned datasets such as ST: In the experiments conducted by [9,39,52], target general-purpose knowledge graphs such as DBpedia or Wikidata are given. Each data table in the test set is then mapped to the nodes in such a knowledge graph. In our evaluation setting, we assume that no data instances are given, i.e., an instance lookup is not possible.

Instead, a domain profile and a domain ontology are provided which are derived via the pairwise and the set-based setting. Figure 11 exemplifies these two approaches which are described in more detail in the following. While we consider pairs of data tables in the pairwise setting, we create a domain ontology based on a set of tables in the set-based setting.

Fig. 11.

Comparison of the pairwise (black) and the set-based setting (black and blue) for creating training and test instances. In the pairwise setting, one data table (TB) represents the domain knowledge of the other data table (TA). In the domain ontology approach, we first create a domain ontology from a set of data tables (TB and TD) and then interpret several data tables (TA and TC) against the domain ontology each. In this example, “running” and “idle” are comments (rdfs:comment) about specific sensors.

The set-based setting and the pairwise setting reflect different application scenarios of Tab2KG. The pairwise setting considers smaller domain ontologies, where the directly corresponding concepts are available in the ontology and a table. An example task for the pairwise setting is table augmentation, where a given table is populated with additional rows, columns or cell values [50]. The set-based setting reflects traditional semantic table interpretation and involves larger domain ontologies, with concepts potentially represented in several tables.

7.4.Baselines

We compare Tab2KG against the following three semantic table interpretation baselines:

8.1.Accuracy of the column mapping function

We train our Siamese network on the GitHub training dataset for 1,000 epochs, a batch rate of 100 and a learning rate of 0.0001, following Hsiao et al.’s approach for one-shot image classification [22]. We apply an early stopping criterion if the validation accuracy has not improved within 100 epochs. We use 256 dimensions for the hidden layer. 10% of the training dataset are used for validation. The feature vectors contain histograms with 10 buckets.

After training for all epochs on the synthetic training dataset, the Siamese network has an accuracy of 0.959 and a loss (binary cross-entropy) of 0.149 on the validation set. On the test set, it achieves an accuracy of 0.952, when treating scores of greater than 0.5 as candidates for column mapping.

We experimented with different train/test splits (90/10 and 80/20). We achieve a similar accuracy on the splits, namely 0.948 on the 80/20 and 0.952 on the 90/10 split. Whereas slight variations are expected, we do not observe any remarkable drop in performance if less training data is provided to the algorithm.

8.1.1.Hyperparameter tuning

To identify the best combination of hyperparameters, we performed a grid search over the number of hidden layers and their dimensions. The results with respect to the classification accuracy are shown in Table 3. Following these results, using one hidden layer is sufficient, and we set its dimension to 256.

Table 3

Grid search results (accuracy on the test set) over the number of hidden layers and their dimension. Higher accuracy values are marked darker

8.2.Semantic table interpretation results

Until now, we evaluated the accuracy of the column mapping function, i.e. Tab2KG’s ability to provide correct data type relation mappings. Now, we evaluate the entire semantic table interpretation process. While we expect a similar accuracy for data type relation mappings for the GitHub dataset, the results depend on the accuracy of class relations mappings and can vary across datasets. The evaluation in this section follows three steps: we measure accuracy (i) of the whole semantic table interpretation, (ii) of the column mapping and graph creation in isolation, and (iii) of the semantic table interpretation on different domains.

8.3.Error analysis

By inspection of the results, we have identified two typical sources of erroneous results in Tab2KG:

Overall, our evaluation results demonstrate that domain profiles in combination with one-shot learning adopted by Tab2KG are an effective method for semantic table interpretation. This method does not require any instance lookup and achieves the highest accuracy on several datasets compared to the baselines.

9.1.Limitations

We identified few limitations of Tab2KG, which can be attributed to the idea of using semantic lightweight dataset profiles, without requiring knowledge about particular data instances.

Fig. 12.

Cyclic class relation: did the London olympic games happen in 2012 or in 2016?

Fig. 13.

Class relations connecting the same classes: is Kamala Harris the president or the vice president of the US?

9.2.Lightweight semantic dataset profiles

Lightweight semantic profiles generated by Tab2KG can be utilized as a compact domain and dataset representation to complement and enrich existing dataset catalogs. Such profiles can be generated automatically from the existing datasets and described using the DCAT1717 and the SEAS1818 vocabularies to facilitate their reusability. We believe that lightweight semantic profiles presented in this article are an essential contribution that can benefit a wide range of semantic applications beyond semantic table interpretation.

Differences in value representations such as value formatting and data types, the representativeness of the domain profile, as well as the dataset characteristics (number of columns in the data table as well as the number of classes and relations in the domain ontology) are the decisive factors to perform semantic table interpretation without instance-lookup and with lightweight profiles.

The profiles of Tab2KG are extensible. For example, header values, language-specific information or value embeddings can be used as a source of additional profile features in future work.