THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Make the dataset boundary part of the answer, not an invisible server choice
A SPARQL result is produced from a query and an RDF dataset. If the dataset boundary, default graph construction, named-graph mappings, endpoint state or entailment regime is missing, another reader may be unable to reproduce what the rows meant. This guide turns named graphs from a syntax feature into a disciplined way to preserve scope, provenance context and query evidence.
This guide belongs to the Information subject guide, the Gold Standard of Education, and the How X Works learning library. Choose a reading route, work the examples, then use the transfer checks to test whether the method survives a changed context.
Choose a reading route
Build the foundations · chapters 1–2
Apply the core method · chapters 3–5
Test evidence and alternatives · chapters 6–7
Handle limits and disagreement · chapters 8–9
Transfer and govern · chapters 10
The whole problem at a glance
| Layer | Question | Evidence to retain |
|---|---|---|
| Query text | Which variables, graph patterns and modifiers were evaluated? | Exact query plus prefixes and parameters |
| RDF dataset | What was the default graph and which named graphs were available? | Dataset description and graph-name mapping |
| Endpoint state | Which version, time and inference configuration supplied the data? | Snapshot, release, timestamp and service metadata |
| Result | How was output encoded, ordered and interpreted? | Result bytes, media type, row count and validation notes |
The same query can lawfully return different results against a different dataset, snapshot, inference regime or implementation configuration.
CHAPTER 1 OF 10 · Build the foundations
1. Begin with the RDF dataset, not the endpoint URL
Core idea. SPARQL evaluates graph patterns against an RDF dataset containing one default graph and zero or more named graphs. An endpoint URL locates a service, but the service can construct that dataset from files, databases, access rules or a changing federation. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Write a dataset contract before querying: identify the default graph, every named graph, graph-name policy, snapshot or release, entailment regime and access context. Treat an undocumented service default as an unknown input. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A school endpoint exposes two named graphs for two published terms. The analyst records both graph IRIs and the release date instead of writing only the endpoint URL. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A local file is loaded into a desktop tool. The same discipline applies because the tool may place it in the default graph, a generated named graph or both. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. SPARQL specifications define abstract datasets and query semantics, while products vary in loading, union defaults, virtual graphs and permissions. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. The endpoint is the dataset. It is a route to a service that can expose different datasets over time or to different users. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Write the dataset boundary in one sentence and verify it by querying the available graph names and known sentinel triples.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Distinguish the default graph from named graphs
Core idea. A default graph is the active graph for ordinary basic graph patterns. Named graphs are selected with GRAPH. The default graph is not necessarily the union of all named graphs and may be empty, separately loaded or constructed by the service. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Test an unqualified pattern and the same pattern under GRAPH ?g. Compare counts and examples, then document whether the default graph duplicates, merges or excludes named-graph content. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A query for ?student ex:enrolled true returns no rows in the empty default graph, while GRAPH ?source returns rows from two named graphs. The empty answer is correct for that dataset. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. Another endpoint enables a union default graph. The unqualified query now returns merged rows but loses which named graph contributed each statement unless graph context is requested. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Triples duplicated across named graphs can collapse in a set-like default graph while solution multiplicities depend on the query pattern. Service-specific union construction needs explicit tests. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. GRAPH is merely a folder filter. It changes the active graph used by the pattern and carries formal query semantics, not just storage navigation. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Create three sentinel triples—default-only, named-only and duplicated—and record the results of qualified and unqualified patterns.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Use FROM and FROM NAMED as dataset clauses
Core idea. FROM identifies graphs used to construct the query default graph, while FROM NAMED identifies graphs available by name. These clauses define a query dataset when supported; they do not simply add decorative provenance labels. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. List each dataset clause, record redirect and retrieval evidence for remote graphs, and check how the implementation handles duplicates, failures and graph-name assignment. Prefer controlled local snapshots for consequential work. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. FROM
Changed-context transfer. A remote FROM IRI changes between runs. The query text remains fixed but the retrieved graph differs, so the result is not reproducible without a version or captured input. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Services may restrict remote graph loading for security or performance. Dataset clauses can be ignored or rejected under local policy and must not be assumed portable. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. FROM NAMED automatically records provenance. It selects a named graph; it does not assert who created it or how its contents were derived. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Run a small dataset-clause query, capture service warnings and prove which graph bytes or version identifiers were actually used.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Carry graph identity through the result
Core idea. GRAPH
Method. Include the graph variable in SELECT, GROUP BY and evidence exports when graph identity affects interpretation. Avoid projecting it away before resolving disagreement or duplication. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. Two named graphs report different values for the same indicator. Returning ?g shows both claims rather than merging them into one apparent fact. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. The graph name is a release identifier rather than an organisation. The report resolves its metadata before displaying a human-readable source. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. A graph IRI can be chosen arbitrarily and may not dereference. Its evidential force comes from governed mapping, provenance and integrity checks. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. One graph name means one trusted source. A graph can aggregate several sources, and a source can publish several graphs. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Trace one result row from ?g to graph metadata, publisher evidence, version and the exact supporting triple.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Model provenance rather than reading it into graph names
Core idea. Named graphs provide containers and identifiers inside a dataset. Provenance requires explicit statements about entities, activities, agents, derivations, generation times and responsibility, often expressed with PROV-O or another documented model. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Maintain a provenance catalogue keyed by graph IRI or immutable release identifier. Separate graph creation, data collection, transformation, publication and endpoint loading as distinct events. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. Graph ex:cleaned-2026 is linked to a transformation activity that used ex:raw-2026, a script version and a validation report. The graph name alone made none of those claims. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. An auditor publishes a second provenance account for the same graph. Multiple accounts can coexist and should be scoped rather than forced into a single story. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Provenance can be incomplete, disputed or sensitive. Publishing lineage does not automatically grant access to personal or confidential records. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. A URI that contains a date is complete provenance. A date-like label is not a machine-checkable account of actors, inputs and transformations. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Choose one graph and require evidence for generation, attribution, derivation, time, integrity and access conditions without inferring them from its spelling.
- Return to chapter contents
Worked two-source dataset example
| Step | Dataset choice | Resulting meaning |
|---|---|---|
| Load | Graph ex:school-a and graph ex:school-b are named separately | Source boundaries remain addressable |
| Default graph | Leave it empty | Unqualified patterns do not silently merge sources |
| GRAPH variable | GRAPH ?g { ?s ex:score ?score } | Each solution carries its source graph name |
| Filter | Apply the same threshold inside the graph pattern | Scores are selected without losing source context |
| Report | Return ?g, ?s and ?score | The result can be traced to the declared graph |
A graph name identifies a graph within the dataset; it does not by itself prove who asserted the triples, when they were valid or whether the source is trustworthy.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Preserve query text, parameters and service context
Core idea. A reproducible record includes exact SPARQL text, prefixes, base IRI, parameters, HTTP method, dataset definition, endpoint version, authentication scope, timeout and result media type. Human-readable prose cannot replace these executable details. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Store the query as a file, normalize only for display, calculate a checksum, capture request and response metadata, and document any client-side substitution. Keep secrets out of the published record. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A dashboard substitutes a date into a query template. The evidence bundle saves the template, the resolved query and the date value, revealing what the service actually evaluated. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A query sent with POST returns the same semantics as GET, but a proxy cache or URL-length limit changes operational behaviour. Protocol evidence explains the difference. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Credentials can alter graph visibility, and services can enforce quotas or timeouts. Exact reproduction may be impossible without an equivalent access context. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. Copying the visible query from a dashboard is enough. Hidden filters, parameters and dataset settings can materially change the request. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Replay the saved request in a clean client and compare status, headers, result schema, row count and a deterministic result digest.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Snapshot mutable data and record time semantics
Core idea. A live graph can change while a query remains identical. Reproducibility therefore needs an immutable release, time-versioned graph, transaction snapshot or retained evidence package that identifies the state evaluated. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Use publisher release identifiers where available; otherwise capture authorised exports with timestamps, checksums and retrieval provenance. State whether time refers to event, record validity, publication or retrieval. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A public endpoint updates nightly. The analysis stores the monthly release graph and its checksum, so another reader can repeat the query even after the endpoint advances. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. For a privacy-sensitive database, the organisation cannot publish rows. It retains a controlled snapshot, query record and aggregate verification path for authorised audit. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Snapshots can preserve errors and personal data. Retention, access and deletion obligations must be designed alongside reproducibility. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. A timestamp proves the dataset can be reconstructed. It records a time but not necessarily the content or version that existed then. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Request the same historical state through the documented method and confirm its graph inventory and checksums match the evidence record.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Handle inference, federation and service extensions
Core idea. Entailment regimes, SERVICE federation, virtual graphs and extensions can add rows not explicitly present in stored graphs. Their rules, remote dependencies and failure modes belong to the reproducibility boundary. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Declare the inference regime, ontology versions, rule settings and federated endpoints. Capture subquery inputs or durable releases when lawful, and specify whether partial SERVICE failures are permitted. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A local graph states a class hierarchy and a query returns inferred instances. Replaying without the ontology or entailment regime produces fewer rows even though stored triples match. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A federated query joins two endpoints. One remote endpoint times out, and SERVICE SILENT permits a partial result; the evidence record must not present it as complete. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Remote endpoints can change, disappear or reveal different data by region and access. Federation multiplies provenance and privacy obligations. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. SPARQL results always correspond only to explicit triples. Inference and service behaviour can extend the evaluated information space. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Disable inference and federation in a test run, compare results, and attribute every additional row to a recorded rule or remote source.
- Return to chapter contents
Reproducibility failure map
| Failure | Visible symptom | Repair |
|---|---|---|
| Hidden union default graph | Unqualified results combine several sources | Declare default-graph construction and include graph identity |
| Mutable endpoint | Same query changes next week | Use a versioned release, snapshot or time-qualified evidence bundle |
| Missing entailment regime | Inferred rows appear only on one service | Record vocabulary, rules and materialisation or query rewriting |
| Unstable ordering | Rows arrive in a different sequence | Use ORDER BY when order is meaningful and preserve the comparator assumptions |
A changed result may be correct for a changed dataset. Reproducibility begins by distinguishing data drift from query, service and presentation differences.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Compare result sets without mistaking order for meaning
Core idea. SPARQL solution sequences are unordered unless ORDER BY applies. Result comparison must account for variable bindings, datatypes, language tags, blank nodes, duplicates, projection and ordering choices. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Canonicalise the result representation for the intended comparison, sort only when order is semantically irrelevant, and record duplicate handling. Use ORDER BY with explicit keys when presentation order matters. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. Two services return the same ten bindings in different row order. Set comparison shows semantic agreement, while byte comparison of CSV files does not. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A query uses LIMIT without ORDER BY. Different valid evaluation orders select different subsets, so reproducibility requires a stable ordering condition or a different claim. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Collations, timezone handling, numeric promotion and extension functions can vary. Cross-engine validation needs carefully chosen test cases. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. CSV files that differ are proof the query disagreed. Encoding, line endings, row order and lexical forms may differ while bindings agree. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Compare parsed bindings, multiplicities and datatypes first; then separately compare the intended order and serialization bytes.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Publish a bounded query evidence bundle
Core idea. A useful bundle lets another reader discover the inputs, rerun the query where authorised, inspect the result and understand limits without exposing protected data. It connects dataset, query, provenance and result as separate evidence objects. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Package the query, dataset manifest, graph inventory, versions, provenance links, endpoint context, result, checksums, licence, access notes and a plain-language claim. Add review dates and correction links. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A research report deposits a query file, manifest of named graphs, release identifiers, PROV-O record, CSV result and README explaining that the result applies to the September snapshot. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A school analysis cannot share student data, so it publishes the aggregate query logic and metadata while an authorised auditor can access the protected snapshot. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. An evidence bundle supports checking within its scope; it cannot guarantee source truth, lawful reuse or future availability. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. Reproducible means everything must be public. Reproducibility can use controlled access when privacy and law require it, provided the verification route is genuine. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Give the bundle to an independent reader and ask them to identify the dataset, rerun conditions, supported claim, missing evidence and correction route.
- Return to chapter contents
Build a SPARQL dataset evidence worksheet
State the decision, unit of analysis, time horizon and affected people before collecting evidence. Separate observations from interpretations and interpretations from recommendations. Record data provenance, missingness and incentives that could distort reporting.
For every important claim, add a rival explanation and one observation that would favour it. Give uncertainty a visible place instead of hiding it inside a single score. Assign an owner and review date to assumptions that may change.
Run the worksheet with someone who did not design the analysis. Ask them to reconstruct the conclusion and identify where judgement entered. Revise any step that depends on private intuition or undefined terminology.
Finish with an action table: act now, monitor, investigate or stop. Link each action to evidence and a reversal condition so the method supports learning rather than defending the first answer.
Design a changed-context transfer check
Rewrite the case with a different scale, institution and distribution of power while preserving the underlying structure. Predict which parts of the method should remain stable and which require new evidence.
Remove one convenient data source and add one conflicting stakeholder account. Re-run the reasoning. If the answer changes, explain whether the change reflects better evidence, a different value choice or an unstable method.
Switch the time horizon. A decision that looks efficient this week may weaken resilience over years, while a long-run benefit may impose an unacceptable immediate burden. Report both rather than averaging them away.
Ask a reviewer to produce a counterexample. A transfer check passes when the method reveals why the new case differs, not when it mechanically produces the same conclusion.
Audit the reasoning and the record
Preserve source versions, transformations, thresholds, exclusions and decision notes. A final chart without its lineage cannot be independently checked and may conceal silent changes.
Trace one favourable and one unfavourable case from raw evidence to recommendation. Confirm that identical rules were applied and that exceptions were authorised, explained and reviewable.
Interview affected users about how the process works in practice. Formal policy may differ from operational reality, especially when time pressure, inaccessible interfaces or asymmetric power limit challenge.
Publish a proportionate account of method, limits, ownership and remedy. Protect sensitive data while ensuring that confidentiality is not used to block legitimate scrutiny.
Turn findings into accountable action
Assign every recommendation to a named role with authority, resources and a deadline. Distinguish mitigation from remedy: reducing future risk does not repair harm already caused.
Choose leading indicators that reveal drift early and outcome indicators that show whether people actually benefited. Disaggregate results where averages can hide concentrated burden.
Create an escalation rule for new evidence, missed thresholds and recurring complaints. Independent review should be available when the original decision maker has an incentive to defend the system.
Close the loop by publishing what changed, what did not and why. Re-open the analysis after material changes instead of treating one successful review as permanent certification.
Questions readers ask
Is a named graph automatically a provenance record?
- No. It provides a graph name and boundary; provenance needs explicit, supported statements about origin and processing.
Is the default graph always the union of named graphs?
- No. It may be empty, separately supplied or implementation-defined unless the dataset contract states otherwise.
Why can LIMIT change results?
- Without a stable ORDER BY, different valid solution orders can select different subsets.
Can a live endpoint make a query reproducible?
- Only if the evaluated state can be identified or preserved through releases, snapshots, transactions or equivalent evidence.
Does GRAPH ?g prove who asserted a triple?
- No. It identifies the named graph in the dataset; attribution and authority require further metadata and evidence.
Must protected data be published?
- No. Controlled snapshots and authorised verification can preserve legitimate reproducibility while respecting privacy and law.
Practise, verify and continue
Create two small named graphs that disagree about one value. Query them with GRAPH ?g, repeat through a union default graph, then package the query, graph inventory, result, checksums and provenance notes. Ask another person to explain exactly which claim each result supports.
Move the method from linked open data to a knowledge graph, policy dashboard or research repository. Preserve explicit scope, versions, provenance, access conditions and result comparison while changing the platform.
Related eduKate reading
PROV-O entities, activities, agents and derivations
PROV-AQ discovery and provenance access
RDF dataset canonicalisation and verifiable graphs
Data citation, versioned queries and reproducible subsets
Trusty URIs and immutable nanopublications
Authoritative sources and scope
W3C, SPARQL 1.1 Query Language
W3C, SPARQL 1.1 Protocol
W3C, RDF 1.1 Concepts and Abstract Syntax
W3C Note, RDF 1.1: On Semantics of RDF Datasets
W3C, PROV-O: The PROV Ontology
This article explains the W3C abstract model and practical evidence design; it does not certify a particular triplestore, endpoint or dataset. Implementations differ in loading, default-graph construction, inference, federation, authentication, extensions, limits and result serialization. The worked examples are original teaching cases. Production use should test the exact engine and version, preserve authorised data states, minimise personal information, respect licences and access controls, and distinguish reproducibility from truth. A query can be perfectly replayed against incomplete, biased or unlawful data. Reports should therefore state the supported claim, dataset boundary, time, provenance, uncertainty, access conditions and correction route.