Worked examples

These seven queries are the retrieval patterns Atlas runs in production. Every query on this page has a counterpart at docs/examples/keystone/<name>.rq that is executed in CI against the staging graph. When the ontology changes, a query that goes stale fails the build before this page ships — so what you read here is what runs.

✓

Parameters

Variables prefixed with $ are string substitutions — your client replaces them before sending to the endpoint. The typed Go and Python clients do this automatically; raw SPARQL over HTTP requires you to substitute them yourself.

1 — Find callers of a deprecated BAPI

The single most common question on a conversion program: who in my own code is still calling this deprecated BAPI? Atlas resolves the BAPI to its canonical graph node, finds the deprecation notice, then walks every custom artifact (Z… / Y…) that references the BAPI and whose provenance traces back to the system you are asking about.

find-callers-of-deprecated-bapi.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?callerName ?callerType ?deprecation ?deprecationDoc ?section
WHERE {
  # the deprecated BAPI, looked up by name
  ?bapi a atlas:BAPI ;
        atlas:artifactName $bapi .

  # the deprecation notice pointing at it
  ?deprecation a atlas:Deprecation ;
               atlas:guidesFrom ?bapi ;
               atlas:citesDocument ?deprecationDoc .

  # callers: any custom artifact that references the BAPI
  ?caller atlas:belongsToModule ?module ;
          atlas:artifactName ?callerName ;
          a ?callerType .
  FILTER (strstarts(?callerName, "Z") || strstarts(?callerName, "Y"))

  # where the caller was sourced
  ?caller atlas:supportedByStatement ?section .
  ?section atlas:sourceURL ?srcURL .
  FILTER (contains(str(?srcURL), $system))
}
ORDER BY ?callerName

Used by the atlas si scan subcommand and the Studio’s “affected objects” panel. Raw file: find-callers-of-deprecated-bapi.rq.

Run simulated query· With $bapi = "BAPI_PO_CREATE1", $system = "my-prod" against the staging graph.

2 — Resolve one entity across four source names

Four sources call BAPI_PO_CREATE1 four different things. Atlas’s entity-resolver collapses them to a single canonical node; this query lists every source document that contributed, with its topic type and fetch timestamp. Reviewers run this when a plan’s evidence feels light — it shows which source Atlas actually trusted.

resolve-entity-across-sources.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?canonical ?sourceURL ?topicType ?label ?fetchedAt
WHERE {
  ?canonical atlas:artifactName $artifactName .

  ?doc a atlas:Document ;
       atlas:references ?canonical ;
       atlas:sourceURL ?sourceURL ;
       atlas:fetchedAt ?fetchedAt ;
       atlas:topicType ?topicType .

  ?doc atlas:hasSection ?section .
  ?section rdfs:label ?label .
}
ORDER BY DESC(?fetchedAt)

Used by atlas evidence --node <artifact> and the Studio’s entity drawer. Raw file: resolve-entity-across-sources.rq.

Run simulated query· With $artifactName = "BAPI_PO_CREATE1". Four sources named the same canonical artifact; Atlas collapsed them to one node.

3 — Walk a plan’s dependency graph

Atlas’s plan graph is a set of atlas:PlanStep nodes linked by atlas:dependsOnStep and atlas:involvesArtifact. This query returns them in deterministic order with the artifact each step operates on — the exact shape the Studio renders in the pipeline view.

walk-plan-dependencies.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>

SELECT ?step ?order ?artifact ?artifactName ?dependsOn
WHERE {
  $plan atlas:hasStep ?step .
  ?step atlas:stepOrder ?order ;
        atlas:involvesArtifact ?artifact .
  ?artifact atlas:artifactName ?artifactName .

  OPTIONAL {
    ?step atlas:dependsOnStep ?dependsOn .
  }
}
ORDER BY ?order

Used by the atlas plan show subcommand and every plan-visualization panel. Raw file: walk-plan-dependencies.rq.

Run simulated query· With $plan = task_7f3a. The three-node dependency graph for "list top customers by net sales".

4 — Compute effective stability tier

A plan’s effective contract is the MIN of every binding it pulls in. This query traverses a CDS view’s transitive associations and returns the lowest sap:ReleaseContract it touches. If any binding lands on C1, the whole plan is effectively C1 — Atlas surfaces that on the plan node so the upgrade exposure is visible before transport.

effective-stability-tier.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>
PREFIX sap:   <https://atlas.naburis.cloud/ontology/sap#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?view ?effectiveTier (MIN(?tierValue) AS ?effectiveTierValue)
WHERE {
  # Map a C0/C1/C2 string to a comparable integer.
  VALUES (?tierCode ?tierValue) {
    ("C2" 2) ("C1" 1) ("C0" 0)
  }

  ?root a sap:CDSView ;
        rdfs:label $viewName .

  # Traverse dependencies via sap:hasAssociation → sap:targetsView,
  # transitively via a SPARQL 1.1 property path.
  ?root (sap:hasAssociation/sap:targetsView)* ?view .

  ?view sap:hasReleaseContract ?contract .
  ?contract sap:hasReleaseState ?tierCode .
}
GROUP BY ?view ?effectiveTier
ORDER BY ?effectiveTierValue
LIMIT 1

Used by gate G-112 (binding to a P_ view) and the tier-propagation diagram. Raw file: effective-stability-tier.rq.

Run simulated query· With $viewName = "ZC_TopCustomersBySales". The worst-case tier anywhere in the binding tree.

5 — List everything superseded in a named release

Release-window planning: which artifacts SAP superseded in S/4HANA 2023? The guidance family carries migration paths; this query joins them to the target version scope and returns pairs of old-name / new-name with the citation that backs each pair.

superseded-in-release.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>

SELECT ?oldName ?newName ?priority ?citation
WHERE {
  ?path a atlas:MigrationPath ;
        atlas:guidesFrom ?old ;
        atlas:guidesTo   ?new ;
        atlas:priority   ?priority ;
        atlas:citesDocument ?citation .

  ?old atlas:artifactName ?oldName ;
       atlas:hasVersionScope ?scope .
  ?new atlas:artifactName ?newName ;
       atlas:hasVersionScope ?newScope .

  ?newScope atlas:validForRelease ?release .
  ?release  atlas:artifactName $release .
}
ORDER BY ?priority ?oldName

Used by the release-coverage dashboards in the Studio and the atlas sources status refresh summary. Raw file: superseded-in-release.rq.

Run simulated query· With $release = "2023". Five of the 1,412 supersessions the Simplification Item Catalog records for S/4HANA 2023.

6 — Find released replacements for a custom Z-view

When Atlas proposes a conversion, it needs candidate released views whose fields overlap with the custom view’s signature. This query ranks candidates by the number of shared fields with the same role (key / measure / currency / dimension), restricted to C2 contracts and the A_ / I_ naming pattern.

released-replacements-for-custom-view.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>
PREFIX sap:   <https://atlas.naburis.cloud/ontology/sap#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?candidate ?candidateLabel ?contract (COUNT(DISTINCT ?sharedField) AS ?overlap)
WHERE {
  ?custom a sap:CDSView ;
          rdfs:label $customView ;
          sap:hasField ?customField .
  ?customField sap:fieldRole ?role ;
               rdfs:label ?fieldName .

  ?candidate a sap:CDSView ;
             rdfs:label ?candidateLabel ;
             sap:hasField ?sharedField ;
             sap:hasReleaseContract ?contractNode .
  ?contractNode sap:hasReleaseState "C2" ;
                rdfs:label ?contract .
  ?sharedField sap:fieldRole ?role ;
               rdfs:label ?fieldName .

  FILTER (?candidate != ?custom)
  FILTER (strstarts(?candidateLabel, "A_") || strstarts(?candidateLabel, "I_"))
}
GROUP BY ?candidate ?candidateLabel ?contract
HAVING (COUNT(DISTINCT ?sharedField) >= 3)
ORDER BY DESC(?overlap)
LIMIT 5

Used by atlas bind suggest <view-name> — the command that drives G-112 resolution. Raw file: released-replacements-for-custom-view.rq.

Run simulated query· With $customView = "ZI_CustomerCustom". Three candidates whose field signatures overlap with the Z-view.

7 — Export a plan’s full evidence trail

This is the query behind atlas evidence --format jsonld. It CONSTRUCTs a JSON-LD graph of every claim in the plan’s transitive closure — plan steps, artifacts, gate results, overrides — with the atlas:supportedByStatement chain that ties each one to a source document, hash, and timestamp. The output is what your auditor will read.

evidence-trail-export.rq

PREFIX atlas: <https://atlas.naburis.cloud/ontology#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

CONSTRUCT {
  ?claim ?p ?o ;
         atlas:supportedByStatement ?section .
  ?section atlas:sourceURL ?url ;
           atlas:contentHash ?hash ;
           atlas:fetchedAt ?ts ;
           rdfs:label ?label .
}
WHERE {
  $plan (atlas:hasStep|atlas:involvesArtifact|^atlas:generatedFrom)+ ?claim .
  ?claim ?p ?o ;
         atlas:supportedByStatement ?section .

  ?section atlas:sourceURL ?url ;
           atlas:contentHash ?hash ;
           atlas:fetchedAt ?ts ;
           rdfs:label ?label .
}

Used by the governance export pipeline and every atlas evidence invocation. Raw file: evidence-trail-export.rq.

Run simulated query· Truncated JSON-LD response for task_7f3a — every claim, every supporting document section, fully dereferenceable.

Running an example

The examples are not end-user queries — they document the retrieval shapes the Atlas services exercise internally. End-user surfaces against the graph are the natural-language Investigate view (POST /api/atlas/resolve) and the hand-traversal Graph Explorer (POST /api/atlas/traverse); both wrap these same shapes. Internal service callers use the typed internal/keystone client.