Expand Bar: Efficient RDF Graph Exploration

• Expand Bar is a formal mechanism in eLinda that partitions RDF nodes based on semantic labels using subclass, property, or object expansions.
• It employs rigorous, set-theoretic definitions and SPARQL-expressible algorithms to facilitate efficient visual exploration of large linked data sets.
• Optimizations like incremental evaluation, caching, and specialized SQL indexes ensure sub-second response times even on datasets with hundreds of millions of triples.

The Expand Bar operation is a formal interactive mechanism in the eLinda system for visual exploration of linked data, specifically large RDF graphs. At each step, the user selects a "bar" representing a set of nodes and a semantic label, and the system expands this bar to a new bar chart along one of several supported axes (e.g., subclass, property, or object type). This operation is rigorously defined, algorithmically characterized, and engineered for low-latency usability even on very large datasets (Mishali et al., 2017).

1. Formal Structure and Definition

Each bar in eLinda is defined as a triple $B = \langle S, \lambda, t \rangle$, with $S \subseteq U(G)$ (a set of subject URIs from RDF graph $G$), $\lambda\in U(G)$ (the bar's label), and $t \in \{\text{class}, \text{property}\}$ (indicating semantic type). The Expand Bar functor $\eta$ operates on $B$ to produce a new bar chart, i.e., a partition of $S$ by new labels and types. Supported expansion kinds are:

• Subclass expansion (only when $t = \text{class}$): Computes the distribution over direct subclasses of $\lambda$ present among $S$.
• Property expansion (only when $t = \text{class}$): Partitions $S$ by outgoing RDF properties used.
• Object expansion (only when $t = \text{property}$): Partitions according to the $rdf:type$ of objects connected by $\lambda$ from $S$.

Each expansion has precise set-theoretic and SPARQL-expressible semantics, accompanied by explicit histogram formulas.

2. Algorithmic Expansions and LaTeX Formulations

The three core expansion algorithms are specified as follows:

2.1 Subclass Expansion ($\eta_\mathrm{sub}$):

Given $B = \langle S, \lambda, \text{class} \rangle$:

• Compute

$$\text{labels}(C) = \{\tau \in U(G) : (\tau, \text{rdfs:subClassOf}, \lambda) \in G\}$$

• For each $\tau$,

$$S_\tau = \{ s \in S : (s, \text{rdf:type}, \tau) \in G \}$$

• Output histogram:

$$H_{\mathrm{sub}}(S;\lambda) = \left\{ \left(\tau, \left| \left\{ s \in S \mid (s,\mathrm{rdf:type},\tau)\in G \ \wedge\ (\tau,\mathrm{rdfs:subClassOf},\lambda)\in G \right\}\right| \right) \right\}$$

2.2 Property Expansion ($\eta_\mathrm{prop}$):

Given $B = \langle S, \lambda, \text{class} \rangle$:

• Compute

$$\text{labels}(P) = \{ p \in U(G) : \exists s\in S, o\ ((s,p,o)\in G) \}$$

• For each $p$,

$S_p = \{ s\in S : \exists o\ ((s,p,o)\in G) \}$

• Output histogram:

$$H_{\mathrm{prop}}(S) = \left\{ \left(p, |\{ s\in S : \exists o\, (s,p,o)\in G\}| \right) \right\}$$

2.3 Object Expansion ($\eta_\mathrm{obj}$):

Given $B = \langle S, p, \text{property} \rangle$:

• Compute

$$\text{labels}(O) = \{ \tau \in U(G) : \exists s\in S,o\ ((s,p,o)\in G \wedge (o,\text{rdf:type},\tau)\in G ) \}$$

• For each $\tau$,

$$S_\tau = \{ o \in U(G) : \exists s\in S, (s,p,o)\in G, (o, \text{rdf:type}, \tau)\in G \}$$

• Output histogram:

$$H_{\mathrm{obj}}(S;p) = \left\{ \left( \tau, |\{ o : \exists s\in S, (s,p,o)\in G \wedge (o, \mathrm{rdf:type}, \tau)\in G \}| \right) \right\}$$

3. Indexing, Caching, and Performance

For scalability, eLinda implements a three-pronged strategy to guarantee sub-second interactive latency:

• Incremental Evaluation: For operations that may require full graph scans (e.g., initial expansion), SPARQL GROUP BY queries are paginated with LIMIT/OFFSET. Partial aggregates are merged by the frontend, enabling immediate UI feedback.
• Heavy-Query Store (HVS): Any expansion query exceeding a latency threshold (e.g., 1s) is stored in a local key–value cache keyed by query hash, enabling $O(1)$ lookup for subsequent identical expansions. The cache is invalidated on mirror graph updates.
• Decomposer with Specialized Indexes: Frequently-used charts are supported by SQL summary tables (triple_sp, triple_po) with B-tree indexes. This eliminates global joins and provides $O(\mathrm{distinct\ labels} \cdot \log|G| +$chart size$)$ complexity for expansions, yielding near-interactive performance on graphs with $|G|$ in the hundreds of millions.

A performance summary table:

Technique	Complexity	Typical Latency
SPARQL GROUP BY	$O(|G|)$	Minutes
Incremental (N rows)	$O(N)$	Sub-second (per page)
HVS cache	$O(1)$	$\sim$50 ms
Decomposer+indexes	$O(D \log|G| + R)$	1–2 seconds

with $D$ = distinct labels, $R$ = chart size (Mishali et al., 2017).

4. Worked Example

Consider the RDF graph $G$ given by 5 triples:

1. $<$John$>$ rdf:type Person ; birthPlace $<$Vienna$>$ ; influencedBy $<$Plato$>$
2. $<$Jane$>$ rdf:type Person ; birthPlace $<$Berlin$>$ ; influencedBy $<$Socrates$>$
3. $<$Beethoven$>$ rdf:type Person ; birthPlace $<$Bonn$>$ ; influencedBy $<$Mozart$>$
4. $<$IBM$>$ rdf:type Company.
5. $<$MonaLisa$>$ rdf:type Artwork ; creator $<$DaVinci$>$

• Step 1 – Subclass Expansion: Expanding $$\langle S_0, \mathrm{owl{:}Thing}, \text{class} \rangle$$ with $S_0$ all subjects yields the chart $$\{ (\text{Person}, 3), (\text{Company}, 1), (\text{Artwork}, 1) \}$$.
• Step 2 – Select Person bar: Yields $S_1 = \{$John, Jane, Beethoven$\}$.
• Step 3 – Property Expansion: For $S_1$, both "birthPlace" and "influencedBy" yield counts of 3 each.
• Step 4 – Select influencedBy bar: Yields objects $\{$Plato, Socrates, Mozart$\}$.
• Step 5 – Object Expansion: If $(\text{Plato},\text{rdf:type},\text{Philosopher})$, $$(\text{Socrates},\text{rdf:type},\text{Philosopher})$$, $(\text{Mozart},\text{rdf:type},\text{Composer})$ are in $G$, the histogram is $\{$(Philosopher,2), (Composer,1)$\}$.

This example illustrates the exact semantics, data flow, and resulting partitions/labels for each expansion type (Mishali et al., 2017).

5. Implementation Optimizations and Remote Access

• Front-end merging of paged counts permits responsive visualization as aggregates load.
• Key–Value queries for heavy expansions accelerate repeated analytics over static datasets (useful for user sessions with repeated navigation patterns).
• SQL summary tables (TripleSP, TriplePO) dramatically reduce join sizes, leveraging index locality for scalability.
• SPARQL compatibility mode is retained for deployment on third-party endpoints, with expected higher response times due to lack of index optimizations.

When running against remote triple stores, only incremental and paged strategies are possible, but the system still delivers fast initial overviews suitable for large-scale knowledge-graph exploration (Mishali et al., 2017).

6. Significance and Application Scenarios

The Expand Bar paradigm is foundational for interactive semantic exploration of RDF graphs. It supports:

• Schema inference: Identifying class, property, and object type distributions visually across arbitrary URI sets.
• Semantic faceted browsing: Chaining expansions to drill down by ontology, relation type, or attribute.
• Data quality and curation: Rapid detection of coverage, missing types, or anomalous property usage.
• Knowledge discovery in large graphs: Scalably navigating tens or hundreds of millions of triples with sub-second feedback.

The explicit formalization of expansion operations, their efficient implementation, and the decoupling of navigation from SPARQL-specific limitations distinguish eLinda's Expand Bar approach among linked-data explorers (Mishali et al., 2017).