Supervised Typing of Big Graphs using Semantic Embeddings

TL;DR

This paper introduces a supervised method for creating semantic type embeddings in large-scale graphs, enabling efficient type recommendation, clustering, and ontology alignment without manual feature engineering.

Contribution

It presents a scalable, feature-agnostic algorithm for generating type embeddings that works on big graphs and integrates seamlessly with existing entity embeddings.

Findings

Outperforms non-parametric baselines in type recommendation

Achieves 15x speedup and near-constant memory on large DBpedia data

Successfully clusters millions of instances into ontology types

Abstract

We propose a supervised algorithm for generating type embeddings in the same semantic vector space as a given set of entity embeddings. The algorithm is agnostic to the derivation of the underlying entity embeddings. It does not require any manual feature engineering, generalizes well to hundreds of types and achieves near-linear scaling on Big Graphs containing many millions of triples and instances by virtue of an incremental execution. We demonstrate the utility of the embeddings on a type recommendation task, outperforming a non-parametric feature-agnostic baseline while achieving 15x speedup and near-constant memory usage on a full partition of DBpedia. Using state-of-the-art visualization, we illustrate the agreement of our extensionally derived DBpedia type embeddings with the manually curated domain ontology. Finally, we use the embeddings to probabilistically cluster about 4 million DBpedia instances into 415 types in the DBpedia ontology.

Figures

Tables

Table 1. Table 1. Details of ground-truth datasets. The five datasets together comprise a partition of all (extensional) type assertion statements available for DBpedia.

Data-set	Num. triples	Num. unique instances	Num. unique types	Size on disk (bytes)
D-1	792,835	792,626	410	113,015,667
D-2	793,500	793,326	412	113,124,417
D-3	793,268	793,065	409	113,104,646
D-4	793,720	793,500	410	113,168,488
D-5	792,865	792,646	410	113,031,346

Table 2. Table 2. Top 3 type recommendations for the embedding method and 10NN for five entities from the 100-sample dataset (Experiment 2)

Entity	Embedding Method Rec.	10NN Rec.
Shenyang_J-13	Aircraft, Weapon, Rocket	Aircraft, Weapon, Photographer
Amtkeli_ River	River, BodyOfWater, Lake	River, Dam, Mountain
Melody_ Calling	Album, Single, Band	Album, Single, PublicTransitSystem
Esau_ (judge_royal)	Monarch, Loyalty, Noble	Noble, Journalist, AdministrativeRegion
Angus_ Deayton	Comedian, ComedyGroup, RadioProgram	Person, Actor, TelevisionShow

Equations

$${\overrightarrow{t}}_{new}={\overrightarrow{t}}_{old}+\frac{1}{|T(s)|}\overrightarrow{s}$$

Full text

Semantic Embeddings; Type recommendation; DBpedia

††copyright: rightsretained††journalyear: 2017††copyright: acmcopyright††conference: SBD’17; May 19, 2017; Chicago, IL, USA††price: 15.00††doi: http://dx.doi.org/10.1145/3066911.3066918††isbn: 978-1-4503-4987-1/17/05††ccs: Information systems Data mining††ccs: Computing methodologies Artificial intelligence††ccs: Computing methodologies Natural language processing

In recent years, the distributional semantics paradigm has been used to great effect in natural language processing (NLP) for embedding words in vector spaces (Turian et al., 2010). The distributional hypothesis (also known as Firth’s axiom) states that the meaning of a word is determined by its context (Sahlgren, 2008). Algorithms like word2vec use neural networks on large corpora of text to embed words in semantic vector spaces such that contextually similar words are close to each other in the vector space (Mikolov et al., 2013). Simple arithmetic operations on such embeddings have yielded semantically consistent results (e.g. $King-Man+Woman=Queen$).

Recent work has extended such neural embedding techniques, traditionally introduced only for natural language word sequences, to alternate kinds of data, including entities in large knowledge graphs like DBpedia (Riesen and Bunke, 2010; Ristoski and Paulheim, 2016). The basic approach is to convert an instance-rich knowledge graph into sets of sequences of graph nodes by performing random walks or using graph kernels (Lösch et al., 2012). NLP algorithms like word2vec are applied on the sequences to embed entities, just like words in natural language sentences (Ristoski and Paulheim, 2016).

In the Semantic Web, the domain of discourse is typically expressed by a manually curated ontology. A basic element of an ontology is a type, also called a class. Type assertion statements relate entities (i.e. instances) in a knowledge base (KB) to the domain ontology, which can then be used to infer more facts about entities.

Given the crucial role played by types in mediating between domain ontologies and instance-rich KBs, a natural question is whether types can be embedded in the same semantic vector space as entities, and whether data-driven type embeddings can be used to reason about, and visualize, ontologies. For example, one could use these embeddings to ask whether the data adequately capture ontological semantics (Section 3.3), and to recommend types for new entities in the knowledge base (Section 3.2). Unfortunately, type embeddings are difficult to directly derive from graphs because big knowledge graphs are sparse in type assertion statements compared to the number of unique instances and facts. In DBpedia, for example there are over 17 million (non-type) triples, and almost 4 million unique entities; the number of type assertion statements is also about 4 million, meaning that there is usually only one type assertion per entity. In many cases, the type assertions can be trivial (e.g. owl#Thing). Another problem is that types are typically asserted as objects, not subjects, in the KB; hence, a random walk cannot be initiated from a type node.

We propose a scalable proof-of-concept solution to the problem of deriving type embeddings from entity embeddings in big graphs. A visual intuition behind the method is provided in Figure 1. Given a set of pre-generated entity embeddings, and a sparse collection of type assertion triples, we are able to robustly generate embeddings for a set of types (e.g. Fruit, Building). We use these embeddings for a variety of tasks, most notably probabilistic type recommendation (e.g. recommending types such as Fruit and Plant for a new entity like Grape), intensional semantics visualization, and probabilistic type clustering over large graphs (Section 3). Specific empirical highlights are noted below. To the best of our knowledge, this is the first work that presents a feature-agnostic supervised typing of Big Graphs.

Empirical Highlights: Preliminary empirical results on a partition of DBpedia show that our algorithm achieved run-time speedups by more than a factor of 15 on the type recommendation task compared to non-parametric nearest-neighbors baselines, with superior recall on two relevance criteria. Visualizations of the type embeddings using the DBpedia ontology as a ground-truth show that they are in good agreement with the intensional semantics expressed by the ontology. The scalability of the model enabled us to probabilistically cluster almost 4 million DBpedia instances into 415 types on a serial machine in under 50 hours.

1. Related Work

Semantic vector space embeddings have witnessed much research in recent years, with neural word embedding algorithms (e.g. word2vec (Mikolov et al., 2013) and glove (Pennington et al., 2014)) achieving state-of-the-art performance on a number of NLP tasks (e.g. dependency parsing) (Chen and Manning, 2014). The success of word embedding approaches has led to a renewed interest in graph-based communities for embedding graphs. A famous example is DeepWalk, which applies word embedding techniques on random walk sequences on a graph to embed nodes in the graph to vectors (Perozzi et al., 2014). In the Semantic Web, variants of this strategy were recently applied to DBpedia and Wikidata, and the embedded entities were used in several important problems, include content-based recommendation and node classification (Ristoski and Paulheim, 2016),(Rosati et al., 2016). Some other influential examples of such knowledge graph embeddings (KGEs), which is an active area of research, include (but are not limited to) (Lin et al., 2015), (Wang et al., 2014), (Bordes et al., 2013), (Guo et al., 2015). An important aspect of this research is automatic knowledge base construction and completion (AKBC), to which this work is related (Wang et al., 2015), (Groth et al., 2016). A major difference is that, because of an additional layer of semantic abstraction (types vs. entities), we can afford to infer types without incrementally training the model such as in (Li et al., 2016) or any other details of how the entity embeddings were derived. We also do not rely on natural language context of any kind (Erp and Vossen, 2016).

In this paper, we do not seek to develop a new learning algorithm for graph (including knowledge graph) or word embeddings; instead, the goal is to use an existing publicly available set of graph entity embeddings to extensionally model types. To the best of our knowledge, this is the first paper to derive the embedding of schema-level elements (like types) directly using the embeddings of instance-level elements like entities. Because our method does not make underlying assumptions about the entity embeddings, it is general and can be applied to any set of entity embeddings.

The type recommendation problem to which we apply the type models is closely connected to the type prediction problem studied in prior work, a good example being Typifier (Ma et al., 2013). Unlike Typifier, which is not embedding-based and relies on manually devised features (e.g. data and pseudo-schema features (Ma et al., 2013)), our approach is feature-agnostic. Other examples of feature-centric type recommenders are the systems in (Melo et al., 2016), (Paulheim and Bizer, 2013). Due to the difficulty in automating feature construction, feature-agnostic systems are still quite rare; for example, in the Semantic Web, only a recent work achieved competitive performance at scale for feature-agnostic node classification (Ristoski and Paulheim, 2016). Furthermore, because embeddings are a very general framework, we use the embeddings not just for type embeddings but also visualization and online clustering, which cannot be handled by the other (special-purpose) type recommenders.

2. Approach

2.1. Framework

We lay the groundwork for this section by formally defining a typed knowledge base (t-KB) and related terminology below:

Definition. Given a set $\mathcal{I}$ of Internationalized Resource Identifiers (IRIs), a set $\mathcal{B}$ of blank nodes and a set $\mathcal{L}$ of literals, a typed RDF Knowledge Base $\mathcal{T}$ is a set of RDF triples (i.e. $\subseteq\{\mathcal{I}\cup\mathcal{B}\}\times\mathcal{I}\times\{\mathcal{I}\cup\mathcal{B}\cup\mathcal{L}\}$) such that $\forall(s,p,o)\in\mathcal{T}\rightarrow\exists t\in\mathcal{I},(s,:type,t)\in\mathcal{T}$, where $:type\in\mathcal{I}$ is a special type property (e.g. rdf:type).

We denote $(s,:type,t)$ as a type assertion statement, an arbitrary element $s$ from the entity set $S=\{s|(s,p,o)\in\mathcal{T}\}$ as an entity, and the set $T(s)=\{t|(s,:type,t)\in\mathcal{T}\}$ as its set of asserted types111At present, we take an extensional (or instance-driven) view of a type by identifying it by its referents (the set of explicitly declared instances) of an entity $s$. We investigate an empirical relaxation of this condition in Section 3.. Similar to the entity set $S$, we denote $T=\bigcup_{s\in S}T(s)$ as the type set of knowledge base $\mathcal{T}$. Finally, we denote a type-only KB (t-KB) $\mathcal{T}^{\prime}$ as the subset of the typed knowledge base $\mathcal{T}$ that contains exactly the type assertions in $\mathcal{T}$. Although each entity $s$ is represented by an IRI per the RDF data model, an alternate representation is as an embedding in a real-valued $d$-dimensional space:

Definition (entity embedding). A $d$-dimensional entity embedding representation of an entity $s$ is a mapping from $s$ to a real-valued vector $\overrightarrow{s}$ that is constrained to lie on the unit-radius hypersphere in $d$-dimensional space.

The constraint in the definition above ($\Sigma_{i}\overrightarrow{s}[i]^{2}=1$) ensures that the entity embedding is l2-normalized, which simplifies distance calculations considerably by equating cosine similarity between the two vectors with a dot product.

Concerning the actual learning of entity embeddings, we noted in Section 1 that recent work has successfully managed to learn embeddings (in spaces with only a few hundred dimensions) on large datasets like DBpedia by applying neural embedding algorithms like word2vec on graph node sequences (Ristoski and Paulheim, 2016). Typically, such embeddings do not include types. A practical reason is that, in big knowledge graphs like DBpedia, the graphs $\mathcal{T}^{\prime}$ and $\mathcal{T}-\mathcal{T}^{\prime}$ are released as separate files (we provide links in Section 3), and entity embeddings are only trained over the latter. A more serious reason, pointed out in the introduction, is sparsity of assertions and the observation that $T\cap S$ is typically empty.

To address problems of sparsity and robustness, we attempt to embed types into the same vector space as entities (thereby leveraging the enormous context of entities). Formally, we define a type embedding below.

Definition (type embedding). Given an entity set $S$ and a type $t$, a $d$-dimensional type embedding representation of $t$ is a mapping from $t$ to a real-valued vector $\overrightarrow{t}$ that is constrained to lie on the unit-radius hypersphere in $d$-dimensional space.

Intuitively, a ‘good’ type embedding should have two elements: (1) be close in the vector space to entities that have that type. In Figure 1 (b), for example, Fruit is much closer to Apple than it is to Times_Square; (2) be closer to ‘related’ types than to types that are unrelated. In Figure 1 (b), Building, City and Place are all closer to one another than to either Fruit or Plant.

Clearly, the two elements above are related as they strongly rely on the data and on the context in which types are asserted or co-appear with entities that share context. In the next section, we explore how such robust embeddings can be scalably generated.

2.2. Generating Type Embeddings

We propose a type embedding algorithm that is lightweight both in terms of run-time and memory. Algorithm 1 provides the pseudocode for our solution. Before describing the pseudocode, we describe the intuition as follows.

Algorithm 1 relies on two assumptions: first, a type is ultimately described by its entities. This means that, all things the same, a type should be close to as many entities having that type as possible. Second, a type should give more preference to entities that describe it exclusively. For example, suppose an entity $s_{1}$ has more than ten (explicitly declared) type assertions $\{t_{1},t_{2}\ldots t_{10}\}$ while entity $s_{2}$ only has two type assertions $\{t_{1},t_{2}\}$. Algorithm 1 is set up so that $s_{2}$ will contribute more to the derivation of $t_{1}$ and $t_{2}$ embeddings than $s_{1}$.

To operationalize these assumptions, while still being simple and scalable, Algorithm 1 computes a weighted average of entity embeddings to derive a type embedding. Specifically, in a first pass over a type-only KB $\mathcal{T}^{\prime}$, the algorithm computes the number of types $|T(s)|$ asserted by entity $s$. For each new type encountered, the algorithm initializes a zero vector for the type, in the same $d$-dimensional space as the entity embeddings. Even with millions of entities, this information can be stored in memory at little cost.

The second pass of the algorithm is incremental. For each triple $(s,:type,t)$, we update a type vector $\overrightarrow{t}$ (initialized to $\overrightarrow{0}$) using the equation:

[TABLE]

In the notation of the algorithm, $T_{S}[s]=T(s)$. Line 9 in Algorithm 1 shows a simple way of obtaining the final type embedding $\overrightarrow{t}$ by normalizing the ‘final’ mean vector $\overrightarrow{t}_{new}$ so that it lies on the unit-radius ($d$-dimensional) hypersphere. Normalizing ensures that the type embedding obeys the same constraints as the original entity embeddings and conforms to the type embedding definition earlier stated. A second reason for normalizing is that the computation of the cosine similarity between any vectors (whether type or entity) on the $d$-dimensional hypersphere reduces to the computation of the dot product between the vectors. The next section covers two applications of such computations.

2.3. Applications

Type Recommendation. Given the type embeddings generated in the previous section, we can recommend types (with scores) for an untyped entity $s$ by computing the dot product between the embedding $\overrightarrow{s}$ of the entity and each of the $|T|$ type embeddings derived in Algorithm 1, and normalizing over the $|T|$ results (if a valid probability distribution is desired). The probability distribution can also be used to rank a set of types with the highest-ranked type being the most relevant suggestion for the entity. Other than ‘completing’ knowledge bases with many untyped entities, such rankings can also assist in tasks like semantic search.

Online Clustering. In contrast with other update-based machine learning algorithms like Stochastic Gradient Descent, we note that data can be discarded once seen, making Algorithm 1 amenable to streaming settings. For example, we were able to probabilistically cluster the full set of DBpedia instances (yielding a $>$100 GB results file) in less than 2 days in a single-threaded computing environment.

3. Preliminary Experiments

The goal of this section is to illustrate the promise of the approach through some preliminary results. In Section 4, we discuss future directions based on the preliminary results.

3.1. Preliminaries

Datasets: We construct five evaluation datasets by performing random stratified partitioning on the full set of DBpedia triples. We used the publicly available type-only KB222Accessed at http://downloads.dbpedia.org/2015-10/core-i18n/en/instance_types_en.ttl.bz2 for our experiments from the October 2015 release of the English-language DBpedia. This file contains all the type assertions obtained only from the mapping-based extractions, without transitive closure using the ontology. Details of the five ground-truth datasets are provided in Table 1. Across the full five-dataset partition, there are 3,963,983 unique instances and 415 unique types. The five datasets are roughly uniform in their representation of the overall dataset, and not subject to splitting or dataset bias, owing to random stratified partitioning.

In Section 3.3, we also compare our type embeddings to the DBpedia domain ontology333Downloaded from http://downloads.dbpedia.org/2015-10/dbpedia_2015-10.nt.

Entity Embeddings: The algorithms presented in this paper assume that a set of entity embeddings has already been generated. Recently, (Ristoski and Paulheim, 2016) publicly made available 500-dimensional embeddings for DBpedia entities by using the word2vec algorithm on graph node sequences444Accessed at http://data.dws.informatik.uni-mannheim.de/rdf2vec/models/DBpedia. The word2vec model was trained using skip-gram, and was found to perform well on a range of node classification tasks555The authors also released Wikidata embeddings, which did not do as well on node classification and were noisier (and much larger) than the DBpedia embeddings. For this reason, we do not consider the Wikidata embeddings in this paper.. Rather than generate our own entity embeddings (which could potentially cause bias by overfitting to the type modeling task), we used those previously generated embeddings for all experiments in this paper.

Implementation: All experiments in this paper were run on a serial iMac with a 4 GHz Intel core i7 processor and 32 GB RAM. All code was written in the Python programming language. We used the gensim package666https://pypi.python.org/pypi/gensim for accessing, manipulating and computing similarity on the entity embeddings.

3.2. Probabilistic Type Recommendation

In this experiment, we evaluate Algorithm 1 on the probabilistic type recommendation task. The input to the recommendation system is an entity, and the output must be a set of scored (or ranked) types that are topically relevant to the entity. The issue of relevance, by its nature, is subjective; we present a methodology for evaluating subjective relevance shortly.

Baseline: We employ baselines based on weighted $k$ Nearest Neighbors (kNN). The kNN algorithm is a strong baseline with some excellent theoretical properties: for example, even the 1NN algorithm is known to guarantee an error rate that is at most twice the Bayes error rate777This is the minimum possible error for a particular distribution of data. in a given feature space and for a given distance function in the space. Because the entity embeddings are given, the kNN baseline, just like the embedding method, is feature-agnostic; to the best of our knowledge, it is the only baseline that has this property and is not super-linear. We consider three versions with $k$ set to 1, 5 and 10 respectively.

Baseline Complexity: Compared to the embedding method, kNN has high time and memory complexity since it is non-parametric and requires storing all the (training) entities in memory. In contrast, after computing the type embeddings, the embedding method has to store $|T|$ vectors, one for each type. In terms of run-time, a full pass is required over the training dataset for each new test entity, regardless of the value of $k$. We explore the empirical consequence of this in our results.

**Experiment 1: **We perform five experiments, where in each experiment, four partitions (from Table 1) are used as the training set, and 5000 entities are randomly sampled from the remaining partition and used as the test set. We were forced to constrain the test set to 5000 for this initial experiment because of baseline complexity.

This experiment adopts an extremely strict definition of relevance: namely, the only relevant types are the ones that are explicitly asserted for the entity in the test partition. Thus, even a super-type (of the true asserted type) would be marked as ‘irrelevant’ if not explicitly asserted itself, since we do not consider transitive closures in the type-only KB. Although a strict measure, it provides a reasonable first benchmark, as it conforms to extensional semantics.

We evaluate performance using the Recall@k888$k$ in Recall@k should not be confused with $k$ in kNN. measure from Information Retrieval. Recall@k computes, for each rank $k$ in a ranked list of types, the ratio of true positives to the sum of true positives and false negatives. For each one of the five experimental runs, we compute a single Recall@k measure (for each $k$) by averaging the Recall@k over all 5000 entities. Finally, we compute the average across the experimental runs, and plot the results in Figure 2 (a). We also plotted individual plots for all five experimental runs, which turned out to be qualitatively very similar to Figure 2 (a). We omit those figures and a per-run analysis herein due to space constraints.

**Analysis: **Figure 2 (a) shows that, even with the strict definition of relevance, although the embedding method starts out with low recall at the highest ranks, it converges with the other methods fairly quickly (between ranks 3-13). Figure 2 (b) shows that the baselines return very few non-zero recommendations per entity (fewer than 1.5) and the returned number is sub-linear in k: in this respect, the baselines perform ‘hard’ type predictions rather than graded recommendations. In contrast, the embedding method returns a more nuanced probability distribution over the 415 types (per entity), and is more apt for recommendations, as we show in the next experiment.

**Experiment 2: ** Although Experiment 1 is appropriate for determining the extensional types of an entity, it takes an overly strict reflection of relevance. Considering the number of triples and unique instances in Table 1, there was usually only one extensional type asserted in the knowledge base. For a better judgment of relevance, we randomly sampled 100 instances from D-1 and pruned the ranked type lists for 10NN (clearly the best performing method in Figure 2 (a)) and the embedding method to 10. Because the number of returned types for 10NN was often fewer than 10, we randomly ‘padded’ the rest of the list with DBpedia types, and manually counted the number of topically relevant recommendations in each (10-element) list999The annotations were performed externally, not by the authors.. This allows us to compute a single-point Recall@10 score over the 100 sampled entities. Note that the random padding can only help, not hurt, the Recall@10 score of the baseline. We also asked the annotator to do a side-by-side comparison of the two lists (for each of the 100 entities) and mark the list that is more topically useful overall. The annotator was not given the details of the two ranking algorithms; also, all annotations were conducted within a single short time-span.

Analysis: The single-point Recall@10 was 0.4712 for the embedding method (averaged across the 100 manually annotated samples) and 0.1423 for the 10NN with standard deviations of 0.2593 and 0.0805 respectively. Some representative results for both 10NN and the embedding method are presented in Table 2. The table presents some intuitive evidence that types recommended by the embedding method are more topically relevant than the types recommended by 10NN. The annotator found the embedding method to be topically more useful for 99 of the 100 entities, with 10NN more useful on only a single entity.

Run-times: Concerning the empirical run-times, all baseline methods required about 1 hour to process 5000 test instances for the 4-partition training set while the embedding method only required 4 minutes. If the training set is fixed, all methods were found to exhibit linear dependence on the size of the test set. This illustrates why we were forced to sample 5000 test instances (per experimental run) for evaluating kNN, since predicting types on only one of the full five partitions in Table 1 would take about 150 hours, which is untenable, even if only strict type predictions (i.e. assertions) are of interest.

3.3. Visualizing the Extensional Model

Note that our methods never relied on the DBpedia ontology when deriving embeddings and generative model parameters. However, an interesting experiment is to use the intensional semantics of types (e.g. sub-class relationships in the ontology) to visualize the embeddings derived from extensional assertions (the mapping-based type assertion extractions). We perform two visualization experiments using the unsupervised t-SNE algorithm (Maaten and Hinton, 2008), a state-of-the-art tool for visualizing high-dimensional points on a 2-D plot.

Visualization 1: We apply t-SNE on a matrix containing the type embedding vectors of all direct sub-types of five sampled types from the DBpedia ontology, namely Animal, Politican, MusicalWork, Building and Plant. The t-SNE algorithm takes the matrix as input and returns another matrix with the same number of rows but only 2 columns. We plot these points (rows) in Figure 3 (a), by assigning labels (i.e. colors) to points101010Because t-SNE is unsupervised, it never accessed the labels during the clustering. based on their super-type. The results show five well-separated clusters, with each cluster representing a super-type. In this case, the extensional model is in excellent agreement with the intensional model. Moreover, the clusters also demonstrate other interesting aspects not captured intensionally: e.g. Building, Politician and MusicalWork (artificial constructs) are much closer to each other, than they are to Animal and Plant (natural constructs), which form a separate ‘super’ cluster.

Visualization 2: We re-run the experiment but over sub-type embeddings of the types SportsTeam, SportsLeague, Company, Organisation and EducationalInstitution. Note that this set is much more topically coherent than the earlier set. The 2D visualization is illustrated in Figure 3 (b); the topical coherence (there are now two clusters rather than five) is well-reflected in the figure. The two purple ‘outliers’ on the left cluster are the embeddings for SportsTeam and SportsLeague, which are themselves sub-types of Organisation.

3.4. Online Type Clustering of DBpedia

The results of Experiment 2 in Section 3.2 illustrated that there are many types in the DBpedia ontology that are clearly related to an entity of interest, even if they are not super-types (or even sub-types) of the entity’s type. Given an entity, we ideally want to assign a probability to each type. Such a clustering has much potential, including topic modeling of entities and fuzzy reasoning. To achieve a full fuzzy clustering over DBpedia, we used the union of all five datasets in Table 1 to compute our type embeddings, and then executed the fuzzy clustering algorithm over all DBpedia entities in the union of all five datasets. The algorithm scaled near-linearly and was able to finish executing over almost 4 million entities and 415 clusters (types) in about 50 hours, collecting over 100 GB of data. We will make this data available on a public server in the near future. Overall, the results (using the extensional type assertions as ground-truth) were found to be highly correlated to the results in Figure 2 (a). We are currently in the process of conducting detailed probabilistic analyses on this data, and are also clustering Wikidata embeddings, a much larger dataset than DBpedia.

4. Conclusion

In this paper, we developed a framework for deriving type embeddings in the same space as a given set of entity embeddings. We devised a scalable data-driven algorithm for inferring the type embeddings, and applied the algorithm to a probabilistic type recommendation task on five DBpedia partitions. Compared to a kNN baseline, the algorithm yields better results on various relevance criteria, and is significantly faster. Visualizations also show that clusters over the type embeddings are intensionally consistent.

Future Work. There are many avenues for future work that we have already started exploring. First, we are using the methods in this paper to embed entire ontologies (collections of types and properties) into vector spaces, to enable a combination of distributional and ontological semantic reasoning. Second, we are exploring more applications of embedded types, such as an enhanced version of semantic search, and semantically guided information extraction from structured data. Last, but not least, we are conducting broader empirical studies e.g. on datasets other than DBpedia and using knowledge graph embeddings other than the DeepWalk-based RDF2Vec to test the robustness of our type embedding approach to such variations. We are also testing the hypothesis that deriving type embeddings from entity embeddings yields higher quality typing than treating types as part of a knowledge graph and jointly deriving entity and type embeddings. We are also looking to carry out a broader user study than the preliminary study in Experiment 2.