Sensor and Tracking Intelligence with W3C Ontologies
How aerospace, defense and telecom teams use TrustGraph Ontology RAG and the W3C SSN/SOSA sensor ontology to turn intelligence reports into an auditable, explainable context graph.
Aerospace, defense and telecom organizations run on observations. Radar returns, transponder tracks, satellite passes, network telemetry and analyst reports all describe something, observed by something, at some time. The hard part is not collecting these observations. It is connecting them across documents and sources, consistently enough that a decision built on them can be audited and reproduced later.
This guide shows how TrustGraph does that with Ontology RAG and a W3C standard ontology. It follows the Ontology RAG tutorial in the TrustGraph documentation, which processes a fictional maritime tracking report, and explains what each step means for high-assurance teams.
The problem: observations without shared meaning
Intelligence and operations data arrives as prose: reports, logs, briefings and assessments written by different people, for different purposes. Two common approaches fall short when the stakes are high:
- Vector search over text chunks finds passages that look similar, but it does not know that a vessel, a sensor and an observation are different kinds of things, or how they relate.
- Schema-free graph extraction (GraphRAG) builds a graph, but the entity and relationship types it invents can vary from document to document, which makes the graph harder to query consistently and harder to defend in review.
What these teams need is extraction that conforms to an agreed, formally defined vocabulary, so every fact in the graph has a known type, every relationship has a known meaning, and every answer can be traced to its source.
The approach: Ontology RAG with SSN/SOSA
Ontology RAG uses an ontology, a formal schema of concepts and relationships, to guide knowledge extraction from unstructured text. The extracted knowledge is stored in a context graph that conforms to the ontology's types and relationships.
For sensor and tracking data, the natural choice is the W3C Semantic Sensor Network (SSN) ontology and its lightweight core, SOSA (Sensor, Observation, Sample, and Actuator). SOSA covers the essential concepts of sensing and observation; SSN extends it with richer detail. Because both are W3C standards, the graph you build is portable to any RDF- and OWL-compliant system rather than locked to one vendor's schema.
The same pattern applies across the sector:
| Domain | Typical sensors and sources | What the ontology makes explicit |
|---|---|---|
| Aerospace | Radar, telemetry, flight and maintenance reports | Which sensor observed which platform, when, with what result |
| Defense | ISR reports, tracking data, analyst assessments | Observations, the assets that produced them and the features of interest they describe |
| Telecom | Network probes, performance counters, incident reports | Which component was measured, by what, and what was observed |
Walkthrough: Operation PHANTOM CARGO
The tutorial uses a fictional maritime tracking intelligence report, Operation PHANTOM CARGO, together with the SSN/SOSA ontology. It runs entirely in the TrustGraph Workbench and takes about 15 minutes.
Before you start: deploy TrustGraph (for example with the Docker Compose installation guide), and be familiar with TrustGraph's core concepts and with ontologies in general.
1. Load the ontology
Download the SSN/SOSA ontology in Turtle format from the TrustGraph example data. In the Workbench, open Ontology Management from the Workflows page, choose Import OWL/Turtle…, and select the file.
The ontology editor then shows the ontology's classes, properties and datatypes, which you can explore and edit. TrustGraph stores ontologies in a JSON format that closely follows the OWL structure.
Bring your own ontology. You can draft a domain ontology with an LLM and save it as Turtle. Include an
rdfs:labeland a description on every element: the extraction pipeline relies on them.
2. Add the intelligence report
Download operation-phantom-cargo.md. On the Workflows page choose + Add Document, select the file, and give it a title (Operation PHANTOM CARGO), a short description and tags such as intelligence, maritime and shipping. Then choose Upload. PDF, plain text, Markdown and HTML are all supported.
3. Process it with the ontology flow
From the document's detail panel, choose Submit for Processing and follow the three-step wizard:
- Flow: select the ontology flow blueprint (the tutorial names the flow
onto-rag). You can also choose the LLM and adjust advanced parameters here. - Collection: select default.
- Confirm and submit.
The ontology flow produces an ontology-conformant knowledge graph and a Context Core. Unlike the default flow, it does not create a chunk store, because it does not run Document RAG.
4. Monitor extraction
Ingestion is observable. Grafana, bundled with the deployment, shows the pub/sub and knowledge-extraction backlogs, LLM latency, token throughput and rate-limit events. The sample report is small and clears quickly; large document sets can take minutes to hours. Rate-limit events are normal during a large backlog and indicate when to add LLM capacity or move to dedicated or self-hosted inference.
5. Inspect the context graph
Open Context Graph to see extracted nodes clustered around their ontology types; select a node to highlight its edges and see its details. Ontology Viewer shows each ontology type as a card with the instances extracted for it. This is the quickest way to check that the report's sensors, observations and platforms landed where the ontology says they should.
6. Ask a question, and see why it was answered that way
Open Graph RAG Query and ask:
What intelligence resources were used during the PHANTOM CARGO operation?
Explainability is built into this console. Alongside the answer, TrustGraph shows how it was produced:
- Grounding: the key concepts selected from the question
- Exploration: the graph nodes explored
- Focus: the core graph edges chosen as evidence, each traceable back to the source document
- Synthesis: the final answer, generated from that evidence
7. Explore the graph
Open Graph Explorer (with an optional 3D view) to navigate the graph directly, search by similarity, and expand a node's neighbours. Because extraction followed the ontology, expect a more consistent and more interconnected graph than schema-free extraction produces.
Why this matters for high-assurance teams
- Defined meaning. Every fact has a type from a published W3C standard, so analysts, systems and auditors agree on what a "sensor", an "observation" or a "platform" is.
- Traceable answers. The focus step ties each answer to specific graph edges and source documents, so a conclusion can be checked rather than trusted.
- Reproducibility. A consistent, ontology-conformant graph answers the same question the same way, which is what review boards and regulators expect.
- Portability and sovereignty. Standard ontologies and open source mean the knowledge stays yours, and the stack, including TrustGraph's own inference for open-weight models, can run entirely inside your environment.
This graph is also the foundation for governed action. Once the operating picture is ontology-grounded, TrustGraph's agent runtime can check each proposed agent action against that meaning, authority and evidence, then allow, pause or deny it before it executes. See What is determinism for AI? for how that works.
Trade-offs to plan for
Ontology RAG asks more of you up front than GraphRAG: you need an ontology, and extraction spends LLM tokens at ingest time. It is the right choice when a domain ontology already exists (as SSN/SOSA does for sensing), when answers draw on several documents, or when the work is specialist and high-stakes, as in intelligence and security. For simple keyword lookups over small data, Document RAG is enough; where defining an ontology is impractical, GraphRAG is a reasonable start.
Frequently asked questions
Why use the W3C SSN/SOSA ontology for sensor intelligence?
SSN and its lightweight core, SOSA, are W3C standards for describing sensors, observations, samples and actuators. Using a standard ontology means every extracted fact has a defined type and relationship, and the resulting graph stays portable to any RDF- and OWL-compliant system instead of being locked to one vendor's schema.
How is Ontology RAG different from GraphRAG?
GraphRAG extracts entities and relationships without a predefined schema. Ontology RAG guides extraction with an ontology, so the graph conforms to known types and relationships. The result is more precise and more consistently connected, at the cost of more setup and extraction tokens at ingest time.
Can analysts see why the system gave an answer?
Yes. Graph RAG queries in the TrustGraph Workbench expose explainability events (grounding, exploration, focus and synthesis), and the focus step traces the graph edges used in an answer back to the source documents.
Next steps
- Follow the full Ontology RAG tutorial, including the companion CLI guide for scripted workflows.
- Read What is OntologyRAG? for the concepts behind this approach.
- See Explainable AI with a Context Graph for more on traceable answers.