Demo 1 · Results-aware SPARQL embeddings

An embedding should place two queries close together when they return the same answers, even if they are written differently.

1 Same look, different answers

a

SELECT ?p WHERE { ?p a dbo:Actor ;
       dbo:birthPlace dbr:Paris }

136 answers

b

SELECT ?p WHERE { ?p a dbo:Actor ;
       dbo:deathPlace dbr:Paris }

94 answers · one predicate changed

c

SELECT ?p WHERE { ?p a dbo:Actor ;
       dbo:birthPlace ?c .
  FILTER(?c = dbr:Paris) }

136 answers · same meaning, other form

Compared with (a)	(b)	(c)
Token similarity	0.92	0.77
Answer overlap J	0.19	1.00

Sketch for intuition (as in the paper's Figure 1, panels 2 and 3). Real measurements follow below.

2 Real embeddings of SQuARE test queries

Every dot is one test query, placed by t-SNE. Dots with the same colour return (nearly) the same answers (the largest groups are coloured, the rest are grey). Pick a space for each side.

Encoder maps are added by demo/scripts/build_embeddings.py --model <encoder> from the trained checkpoints. "Answer overlap (target)" is the layout the training aims for, computed from the complete answer labels.

3 How the embeddings are trained

1 · Execute once

Run each logged query once, offline, and cache its answer set.

2 · Label by answer overlap

J = |A ∩ B| / |A ∪ B|. Pairs with J ≥ 0.8 are positives, J ≤ 0.1 negatives.

3 · Contrastive fine-tuning

InfoNCE pulls positives together and pushes execution-verified hard negatives apart.

At query time

Only the query text goes in. No execution needed.

Next: Demo 2 · what this changes for retrieval and caching →