@base . @prefix : . @prefix rdf: . @prefix rdfs: . @prefix owl: . @prefix xsd: . @prefix schema: . @prefix dcterms: . @prefix foaf: . @prefix skos: . @prefix prov: . # ── Named Graph Declaration ────────────────────────────────────────────────── a schema:Dataset ; rdfs:label "SPARQL Cluster Resilience Knowledge Graph" ; dcterms:source ; schema:dateCreated "2026-05-22"^^xsd:date ; prov:wasGeneratedBy ; schema:description "Knowledge graph derived from the OpenLink Community post on writing SPARQL queries resilient to execution-plan variations across RDF cluster subscriber nodes." . # ── Custom Ontology — Classes ──────────────────────────────────────────────── :QueryPractice a owl:Class ; rdfs:label "Query Practice" ; rdfs:comment "A specific SPARQL query-writing discipline that improves resilience to optimizer execution-plan variations across cluster nodes." . :OptimiserConcept a owl:Class ; rdfs:label "Optimiser Concept" ; rdfs:comment "A concept related to cost-based query-optimiser behavior in Virtuoso or similar SPARQL/SQL engines." . :AntiPattern a owl:Class ; rdfs:label "Anti-Pattern" ; rdfs:comment "A SPARQL query-writing pattern that leads to unpredictable or suboptimal optimizer behavior." . # ── Custom Ontology — Properties ───────────────────────────────────────────── :hasPractice a owl:ObjectProperty ; rdfs:label "has practice" ; rdfs:domain schema:TechArticle ; rdfs:range :QueryPractice . :avoidsIssue a owl:ObjectProperty ; rdfs:label "avoids issue" ; rdfs:domain :QueryPractice ; rdfs:range :OptimiserConcept . :hasAntiPattern a owl:ObjectProperty ; rdfs:label "has anti-pattern" ; rdfs:domain :QueryPractice ; rdfs:range :AntiPattern . # ── Source Article ──────────────────────────────────────────────────────────── a schema:TechArticle ; schema:name "General Guidance on Writing SPARQL Queries Resilient to multiple RDF Cluster Subscriber Node Query Optimiser Execution Plan Variations across nodes" ; schema:description "Explains why SPARQL execution plans diverge across RDF cluster nodes and provides six proven practices for writing queries that produce consistent, predictable plans regardless of per-node statistical variation." ; schema:author ; schema:publisher ; schema:datePublished "2026-05-22"^^xsd:date ; schema:about , :VirtuosoUniversalServer ; schema:keywords "sparql", "virtuoso", "query optimization", "rdf cluster", "knowledgegraph", "howto" ; schema:url ; schema:inLanguage "en" ; schema:hasPart :FAQ_WhyPlansDiffer, :FAQ_NotUniqueToVirtuoso, :FAQ_WhenVALUESvsFilter, :FAQ_BindAvoidance, :FAQ_FilterExists, :FAQ_GraphScopeWhen, :FAQ_OrderMatters, :FAQ_SparqlToSQL ; dcterms:hasPart :Query_EntityTypeSummary, :Query_ListPractices, :Query_FAQPairs, :Query_GlossaryTerms ; :hasPractice :Practice_RangeFilter, :Practice_VALUES, :Practice_ProjectionTrim, :Practice_SelectiveFirst, :Practice_GraphScope, :Practice_FilterProximity . # ── Organizations ───────────────────────────────────────────────────────────── a schema:Organization, foaf:Organization ; schema:name "OpenLink Software" ; schema:url ; rdfs:label "OpenLink Software" ; owl:sameAs . a schema:Organization ; schema:name "OpenLink Software Community" ; schema:url ; rdfs:label "OpenLink Software Community" . # ── Software ────────────────────────────────────────────────────────────────── :VirtuosoUniversalServer a schema:SoftwareApplication ; schema:name "Virtuoso Universal Server" ; schema:description "OpenLink Software's multi-model data server supporting SPARQL, SQL, RDF, and linked data, used as the substrate for the RDF cluster described in this article." ; schema:url ; rdfs:label "Virtuoso Universal Server" ; owl:sameAs . # ── Optimiser Concepts ──────────────────────────────────────────────────────── :CostBasedOptimiser a :OptimiserConcept ; rdfs:label "Cost-Based Query Optimiser" ; schema:name "Cost-Based Query Optimiser" ; schema:description "Selects the execution plan with the lowest estimated cost by evaluating alternative join orders and access strategies against runtime statistical models. The root cause of plan divergence when node statistics differ." . :StatisticalDivergence a :OptimiserConcept ; rdfs:label "Statistical Divergence" ; schema:name "Statistical Divergence" ; schema:description "Each cluster node independently samples data distribution at different times and under different load, building a slightly different statistical model even when the underlying RDF data is identical across nodes." . :PlanVariation a :OptimiserConcept ; rdfs:label "Execution Plan Variation" ; schema:name "Execution Plan Variation" ; schema:description "The same SPARQL query receives different execution plans on different cluster nodes due to divergent statistical models, causing orders-of-magnitude performance differences across nodes." . :FullTableScan a :OptimiserConcept ; rdfs:label "Full Table Scan" ; schema:name "Full Table Scan" ; schema:description "An access strategy that reads every row in the quad table. Triggered when a filter or join cannot leverage an index — commonly caused by computed filter variables derived through BIND or function calls." . :IntermediateResultInflation a :OptimiserConcept ; rdfs:label "Intermediate Result Inflation" ; schema:name "Intermediate Result Inflation" ; schema:description "The multiplicative growth of intermediate result sets when high-cardinality predicates are joined without selectivity constraints or when FILTER clauses are placed far from their binding patterns." . # ── Anti-Patterns ───────────────────────────────────────────────────────────── :AntiPattern_ComputedFilter a :AntiPattern ; rdfs:label "BIND-then-FILTER Anti-Pattern" ; schema:name "BIND-then-FILTER Anti-Pattern" ; schema:description "Deriving a filter variable through BIND or a function (e.g., BIND(YEAR(?date) AS ?year) then FILTER(?year = 2024)) creates a computed column with no index, forcing a full quad-table scan." . :AntiPattern_FilterIn a :AntiPattern ; rdfs:label "FILTER IN Anti-Pattern" ; schema:name "FILTER IN Anti-Pattern" ; schema:description "Using FILTER(?var IN (val1, val2)) evaluates as a runtime expression after the join rather than anchoring the plan to known constants before joining." . :AntiPattern_UnusedJoins a :AntiPattern ; rdfs:label "Unused Triple Pattern Joins" ; schema:name "Unused Triple Pattern Joins" ; schema:description "Including triple patterns whose variables are absent from the SELECT clause forces joins the engine must execute. High-cardinality predicates can multiply intermediate result sizes by millions of rows." . :AntiPattern_NonSelectiveFirst a :AntiPattern ; rdfs:label "Low-Selectivity Lead Pattern" ; schema:name "Low-Selectivity Lead Pattern" ; schema:description "Beginning the WHERE clause with a high-cardinality triple pattern gives the optimiser a large starting set. When statistics are uncertain this amplifies plan divergence across nodes." . :AntiPattern_NoGraphScope a :AntiPattern ; rdfs:label "Cross-Graph Pattern" ; schema:name "Cross-Graph Pattern" ; schema:description "Omitting GRAPH blocks forces the optimiser to search across all named graphs, increasing the search space and preventing partition-level pruning." . :AntiPattern_DistantFilters a :AntiPattern ; rdfs:label "Distant Filter Placement" ; schema:name "Distant Filter Placement" ; schema:description "Placing FILTER clauses far from the triple patterns that bind their variables causes the engine to accumulate large intermediate result sets before pruning." . # ── Query Practices (HowToSteps) ────────────────────────────────────────────── :Practice_RangeFilter a :QueryPractice, schema:HowToStep ; rdfs:label "Use direct range filters on indexed predicates" ; schema:name "Use direct range filters on indexed predicates" ; schema:text "Apply range conditions directly to date or value predicates using FILTER(?date >= '2024-01-01'^^xsd:date && ?date < '2025-01-01'^^xsd:date) rather than computing a derived variable through BIND or functions. Direct range conditions enable index seeks and eliminate scan dependency on per-node optimizer statistics." ; schema:position 1 ; :avoidsIssue :FullTableScan ; :hasAntiPattern :AntiPattern_ComputedFilter . :Practice_VALUES a :QueryPractice, schema:HowToStep ; rdfs:label "Use VALUES instead of FILTER IN for constant equality matching" ; schema:name "Use VALUES instead of FILTER IN for constant equality matching" ; schema:text "Replace FILTER(?var IN (ex:typeA, ex:typeB)) with VALUES ?var { ex:typeA ex:typeB }. The VALUES clause binds variables to known constants before the join executes, giving the optimiser a definite starting point and enabling index lookups directly on the supplied constants." ; schema:position 2 ; :avoidsIssue :CostBasedOptimiser ; :hasAntiPattern :AntiPattern_FilterIn . :Practice_ProjectionTrim a :QueryPractice, schema:HowToStep ; rdfs:label "Only join what you need in the projection" ; schema:name "Only join what you need in the projection" ; schema:text "Remove triple patterns whose variables are absent from the SELECT clause. Every triple pattern is a join the engine must execute regardless of projection. For existence checks on large predicates use FILTER EXISTS { ... } rather than an open join, to confirm presence without retrieving or joining values." ; schema:position 3 ; :avoidsIssue :IntermediateResultInflation ; :hasAntiPattern :AntiPattern_UnusedJoins . :Practice_SelectiveFirst a :QueryPractice, schema:HowToStep ; rdfs:label "Place the most selective triple pattern first" ; schema:name "Place the most selective triple pattern first" ; schema:text "Lead the WHERE clause with the triple pattern that binds the fewest results — typically a specific typed node or a narrow date/value range filter. Virtuoso uses triple-pattern ordering as a hint when statistics are ambiguous, so a selective lead pattern reduces the intermediate result size that subsequent joins must process." ; schema:position 4 ; :avoidsIssue :StatisticalDivergence ; :hasAntiPattern :AntiPattern_NonSelectiveFirst . :Practice_GraphScope a :QueryPractice, schema:HowToStep ; rdfs:label "Use GRAPH to scope joins to named graphs" ; schema:name "Use GRAPH to scope joins to named graphs" ; schema:text "Wrap triple patterns in GRAPH ?g { ... } blocks to constrain the search space to the relevant named-graph partition and prevent cross-graph scans. This is particularly effective in datasets partitioned by document, notice, or entity graph, where each record lives in its own named graph." ; schema:position 5 ; :avoidsIssue :PlanVariation ; :hasAntiPattern :AntiPattern_NoGraphScope . :Practice_FilterProximity a :QueryPractice, schema:HowToStep ; rdfs:label "Keep filters adjacent to their binding triple patterns" ; schema:name "Keep filters adjacent to their binding triple patterns" ; schema:text "Place each FILTER immediately after the last triple pattern that binds all variables referenced in it. This allows the engine to prune rows as early as possible in the join sequence rather than accumulating large intermediate result sets before filtering." ; schema:position 6 ; :avoidsIssue :IntermediateResultInflation ; :hasAntiPattern :AntiPattern_DistantFilters . # ── FAQ Pairs ───────────────────────────────────────────────────────────────── :FAQ_WhyPlansDiffer a schema:Question ; rdfs:label "Why do query execution plans differ across cluster nodes?" ; schema:name "Why do query execution plans differ across cluster nodes?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "Each node independently samples its data distribution through random sampling at different times and under different load conditions. Even when the underlying RDF data is logically identical, each node builds a slightly different statistical model. When the cost-based optimiser applies these divergent statistics to the same query, it may select a different — and sometimes dramatically slower — execution plan on some nodes." ] . :FAQ_NotUniqueToVirtuoso a schema:Question ; rdfs:label "Is execution-plan variation unique to Virtuoso?" ; schema:name "Is execution-plan variation unique to Virtuoso?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "No. All cost-based query optimisers share this characteristic. However it is particularly pronounced in RDF/SPARQL engines because the entire dataset is stored in a single quad table with a small number of indexes. The optimiser relies more heavily on statistical estimates of S/P/O/G value distributions to make planning decisions, compared to relational engines that have richer structural metadata to guide planning." ] . :FAQ_WhenVALUESvsFilter a schema:Question ; rdfs:label "When should I use VALUES instead of FILTER IN?" ; schema:name "When should I use VALUES instead of FILTER IN?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "Use VALUES whenever you are matching a variable against a known, finite set of constants. VALUES binds variables to the constants before the join executes, so the optimiser can plan index lookups on each constant. FILTER IN is evaluated as a runtime expression after the join, meaning the optimiser cannot anchor the plan to known cardinalities before executing." ] . :FAQ_BindAvoidance a schema:Question ; rdfs:label "Why should I avoid BIND when filtering dates or values?" ; schema:name "Why should I avoid BIND when filtering dates or values?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "BIND creates a derived variable (for example, ?year from YEAR(?date)) that has no index. The optimiser must perform a full quad-table scan to populate the derived column before the FILTER can prune it. A direct range filter on the underlying predicate, such as FILTER(?date >= '2024-01-01'^^xsd:date), allows the engine to use an index seek and dramatically reduces the number of rows examined." ] . :FAQ_FilterExists a schema:Question ; rdfs:label "How do I confirm existence without inflating intermediate results?" ; schema:name "How do I confirm existence without inflating intermediate results?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "Use FILTER EXISTS { ... } rather than an open triple-pattern join. An open join adds every matching value as a column in the intermediate result set, potentially multiplying result sizes by millions of rows for high-cardinality predicates such as financial values or participation links. FILTER EXISTS confirms presence without retrieving or joining the values." ] . :FAQ_GraphScopeWhen a schema:Question ; rdfs:label "When is GRAPH scoping most beneficial?" ; schema:name "When is GRAPH scoping most beneficial?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "GRAPH scoping is most beneficial in datasets partitioned by document, notice, or entity graph — for example, public procurement datasets where each tender or contract lives in its own named graph. Wrapping triple patterns in GRAPH ?g { ... } constrains the search space to the relevant partition and prevents cross-graph scans across the full quad store." ] . :FAQ_OrderMatters a schema:Question ; rdfs:label "Does triple pattern ordering always affect performance?" ; schema:name "Does triple pattern ordering always affect performance?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "It matters most when optimizer statistics are uncertain or divergent across cluster nodes. Leading with a highly selective pattern — one that binds very few results — gives the optimiser a small, definite starting set for subsequent joins. When statistics are accurate the optimiser may reorder patterns itself, but providing a selective lead pattern acts as a reliable fallback hint when statistics diverge." ] . :FAQ_SparqlToSQL a schema:Question ; rdfs:label "Why does Virtuoso translate SPARQL to SQL before executing?" ; schema:name "Why does Virtuoso translate SPARQL to SQL before executing?" ; schema:acceptedAnswer [ a schema:Answer ; schema:text "Virtuoso stores RDF as rows in a relational quad table (subject, predicate, object, graph) and executes queries through its mature SQL engine. Translating SPARQL to SQL allows Virtuoso to apply decades of relational optimization techniques — index selection, join reordering, statistics-based cost estimation — to RDF data access. The downside is that the SQL optimiser inherits its statistical sensitivity, which manifests as plan variation in cluster deployments." ] . # ── Glossary Terms ──────────────────────────────────────────────────────────── :Term_SPARQL a skos:Concept ; rdfs:label "SPARQL" ; skos:prefLabel "SPARQL" ; skos:definition "SPARQL Protocol and RDF Query Language — the W3C standard query language for RDF knowledge graphs, analogous to SQL for relational databases." ; owl:sameAs . :Term_RDFCluster a skos:Concept ; rdfs:label "RDF Cluster" ; skos:prefLabel "RDF Cluster" ; skos:definition "A distributed deployment of an RDF triplestore across multiple subscriber nodes, each holding a replica of the data and independently handling queries and statistics collection." . :Term_QueryOptimiser a skos:Concept ; rdfs:label "Query Optimiser" ; skos:prefLabel "Query Optimiser" ; skos:definition "The database engine component responsible for selecting the most efficient execution plan for a given query, based on available indexes and statistical cost estimates." . :Term_CostBasedPlanning a skos:Concept ; rdfs:label "Cost-Based Planning" ; skos:prefLabel "Cost-Based Planning" ; skos:definition "A strategy where the database engine enumerates multiple candidate execution plans, estimates the computational cost of each, and selects the cheapest based on statistical metadata about data distribution." . :Term_ExecutionPlan a skos:Concept ; rdfs:label "Execution Plan" ; skos:prefLabel "Execution Plan" ; skos:definition "The specific sequence of operations (index seeks, joins, filters, sorts) that the database engine performs to satisfy a query. Different cluster nodes may choose different plans for the same query." . :Term_TriplePattern a skos:Concept ; rdfs:label "Triple Pattern" ; skos:prefLabel "Triple Pattern" ; skos:definition "The basic building block of a SPARQL WHERE clause — a pattern of subject, predicate, and object where any component may be a variable or a bound value." . :Term_Selectivity a skos:Concept ; rdfs:label "Selectivity" ; skos:prefLabel "Selectivity" ; skos:definition "The fraction of a dataset that a predicate, filter, or triple pattern matches. A highly selective pattern matches very few rows and is a good starting point for the join sequence." . :Term_NamedGraph a skos:Concept ; rdfs:label "Named Graph" ; skos:prefLabel "Named Graph" ; skos:definition "In RDF, a collection of triples identified by a URI. Named graphs enable data partitioning, provenance tracking, and scoped querying within a triplestore." . :Term_QuadStore a skos:Concept ; rdfs:label "Quad Store" ; skos:prefLabel "Quad Store" ; skos:definition "An RDF triplestore that extends each triple with a fourth component — the graph identifier — forming quads. In Virtuoso all quads are stored in a single relational table." . :Term_IndexSeek a skos:Concept ; rdfs:label "Index Seek" ; skos:prefLabel "Index Seek" ; skos:definition "A fast, targeted data-access strategy that locates rows by directly traversing an ordered index structure. Far faster than a full-table scan for selective conditions." . # ── SPARQL Queries (KG exploration) ────────────────────────────────────────── :Query_EntityTypeSummary a schema:SoftwareSourceCode ; schema:name "Entity Type Summary" ; schema:description "Overview of all entity types in the SPARQL Cluster Resilience knowledge graph with sample entities and counts." ; schema:programmingLanguage "SPARQL" ; schema:codeRepository ; schema:text """PREFIX rdf: PREFIX rdfs: SELECT ?type (SAMPLE(?s) AS ?sampleEntity) (SAMPLE(?label) AS ?sampleLabel) (COUNT(?s) AS ?entityCount) WHERE { GRAPH { ?s rdf:type ?type . OPTIONAL { ?s rdfs:label ?label } } } GROUP BY ?type ORDER BY DESC(?entityCount)""" . :Query_ListPractices a schema:SoftwareSourceCode ; schema:name "List All SPARQL Resilience Practices" ; schema:description "Retrieves all six SPARQL query-writing practices with their names, step positions, anti-patterns they replace, and optimiser issues they address." ; schema:programmingLanguage "SPARQL" ; schema:codeRepository ; schema:text """PREFIX rdf: PREFIX rdfs: PREFIX schema: PREFIX : SELECT ?practice ?name ?position ?avoids ?antiPattern WHERE { GRAPH { ?practice a :QueryPractice ; schema:name ?name ; schema:position ?position . OPTIONAL { ?practice :avoidsIssue ?issueNode . ?issueNode rdfs:label ?avoids } OPTIONAL { ?practice :hasAntiPattern ?apNode . ?apNode rdfs:label ?antiPattern } } } ORDER BY ?position""" . :Query_FAQPairs a schema:SoftwareSourceCode ; schema:name "Retrieve FAQ Question-Answer Pairs" ; schema:description "Lists all FAQ questions and their accepted answers from the knowledge graph." ; schema:programmingLanguage "SPARQL" ; schema:codeRepository ; schema:text """PREFIX rdf: PREFIX schema: SELECT ?question ?questionText ?answerText WHERE { GRAPH { ?question a schema:Question ; schema:name ?questionText ; schema:acceptedAnswer ?answer . ?answer schema:text ?answerText . } } ORDER BY ?questionText""" . :Query_GlossaryTerms a schema:SoftwareSourceCode ; schema:name "Explore Glossary Terms" ; schema:description "Retrieves all glossary concepts with their preferred labels and definitions." ; schema:programmingLanguage "SPARQL" ; schema:codeRepository ; schema:text """PREFIX skos: SELECT ?term ?label ?definition WHERE { GRAPH { ?term a skos:Concept ; skos:prefLabel ?label ; skos:definition ?definition . } } ORDER BY ?label""" .