Query2box: Reasoning over KnowledgeGraphs in Vector Space using Box Embeddings
Table 6: Number of training, validation, and test queries generated for different query structures.
['[BOLD] Queries  [BOLD] Dataset', '[BOLD] Training 1p', '[BOLD] Training others', '[BOLD] Validation 1p', '[BOLD] Validation others', '[BOLD] Test 1p', '[BOLD] Test others']
We consider 9 kinds of diverse query structures shown and named in Fig. We use 5 query structures for training and then evaluate on all the 9 query structures. Given a query q, let ⟦q⟧train, ⟦q⟧val, and ⟦q⟧test denote a set of answer entities obtained by running subgraph matching of q on Gtrain, Gvalid, and Gtest, respectively. At the training time, we use ⟦q⟧train as positive examples for the query and other random entities as negative examples. However, at the test/validation time we proceed differently. Note that we focus on answering queries where generalization performance is crucial and at least one edge needs to be imputed in order to answer the queries. Thus, rather than evaluating a given query on the full validation (or test) set ⟦q⟧val (⟦q⟧test) of answers, we validate the method only on answers that include missing relations. Given how we constructed , we have ⟦q⟧train⊆⟦q⟧% val⊆⟦q⟧test and thus we evaluate the method on ⟦q⟧val∖⟦q⟧% train to tune hyper-parameters and then report results identifying answer entities in ⟦q⟧test∖⟦q⟧% val. This means we always evaluate on queries/entities that were not part of the training set and the method has not seen them before. Furthermore, for these queries, traditional graph traversal techniques would not be able to find the answers (due to missing relations).