Agentic Features
This page shows what your AI agent can do once it is connected. Each capability works in any MCP client.
The exchanges below come from a real agent session that starts with nothing but the following testdata.csv — seeded with a few deliberate data-quality traps (blank cells, a disallowed status) — and ends with a validated, queryable graph. The agent replies are condensed and the prompts lightly copyedited, but the files, tool calls, and results are the real ones — recreate the CSV in a workspace to follow along:
sensor_id,machine_id,machine_name,sensor_type,status,service_id,service_name,is_machine_critical
S1,M42,Packaging Machine 42,Temperature,Error,SVC-1,Packaging Line,true
S2,M42,Packaging Machine 42,Vibration,OK,SVC-1,Packaging Line,true
S3,,Unknown Machine,Pressure,Warning,SVC-1,Packaging Line,true
S4,M17,Filling Machine 17,Temperature,Broken,SVC-2,Filling Line,false
S5,M17,Filling Machine 17,Vibration,,SVC-2,Filling Line,false
S6,M99,Inspection Machine 99,Camera,Error,,Quality Control,true
Model ontologies with real vocabularies
Your agent can discover matching vocabularies from Linked Open Vocabularies, look up real term definitions, and write syntax-checked Turtle that reuses them — for a new ontology or an existing one.
I want to create a small ontology for machines, sensors, and services. Sensors are part of machines, sensors have a status, and machines can be critical for services. Start with a minimal model and explain your assumptions. Use testdata.csv to get an idea of the data.
vocabulary_lookup ×3 — schema, sosa, ssn
The sosa lookup returns the W3C sensor vocabulary's terms:
Terms for prefix "sosa":
http://www.w3.org/ns/sosa/FeatureOfInterest
http://www.w3.org/ns/sosa/ObservableProperty
http://www.w3.org/ns/sosa/Observation
http://www.w3.org/ns/sosa/Platform
http://www.w3.org/ns/sosa/Sensor
...
http://www.w3.org/ns/sosa/hosts
http://www.w3.org/ns/sosa/isHostedBy
...
I looked up the W3C sensor vocabularies (sosa, ssn) in the vocabulary store and reused them instead of inventing terms: sensors are sosa:Sensor directly, and machines subclass sosa:Platform — which gives us sosa:isHostedBy for the sensor-to-machine relation for free. The model is in ontology.ttl:
ex:Machine a owl:Class ;
rdfs:label "Machine" ;
rdfs:subClassOf sosa:Platform .
ex:StatusOK a ex:SensorStatus ; rdfs:label "OK" .
ex:StatusError a ex:SensorStatus ; rdfs:label "Error" .
ex:StatusWarning a ex:SensorStatus ; rdfs:label "Warning" .
ex:StatusBroken a ex:SensorStatus ; rdfs:label "Broken" .
ex:hasStatus a owl:ObjectProperty ;
rdfs:label "has status" ;
rdfs:domain sosa:Sensor ;
rdfs:range ex:SensorStatus .
Two verification queries against the new file confirm every class, property, and status individual parses and resolves. Key design decisions: sensor statuses are named individuals rather than string literals, so they can be validated and queried cleanly; and a sensor without a machine (like S3 in the data) stays valid, because the hosting relation is optional.
Build data pipelines & run ingestion (ETL)
Your agent can build a complete pipeline from raw data to RDF: it inspects a CSV, JSON, or XML source (field names and sample rows), writes the YARRRML mapping including transform functions, validates it, and generates the triples with the built-in RML engine.
For the test data, create a YARRRML mapping, execute it, and show me the generated RDF.
I inspected the source first:
yarrrml_inspect_source
CSV columns in testdata.csv:
| Field | Sample values |
|---|---|
| sensor_id | S1, S2, S3 |
| machine_id | M42, M42, M17 |
| machine_name | Packaging Machine 42, Packaging Machine 42, Unknown Machine |
| sensor_type | Temperature, Vibration, Pressure |
| status | Error, OK, Warning |
| service_id | SVC-1, SVC-1, SVC-1 |
| service_name | Packaging Line, Packaging Line, Packaging Line |
| is_machine_critical | true, true, true |
Then I wrote one mapping rule per entity — sensors, machines, services — so IRIs repeated across rows deduplicate naturally:
mappings:
sensor:
sources:
- csv-source
subjects: "ex:sensor/$(sensor_id)"
predicateobjects:
- [rdf:type, sosa:Sensor~iri]
- [ex:sensorType, "$(sensor_type)"]
- [sosa:isHostedBy, "ex:machine/$(machine_id)~iri"]
- [ex:hasStatus, "http://example.org/factory/Status$(status)~iri"]
The mapping validated cleanly, and a single run generated the complete graph in instances.ttl — all six sensors, three machines, and two services, with repeated IRIs deduplicated:
<http://example.org/factory/sensor/S1> a sosa:Sensor ;
ex:hasStatus ex:StatusError ;
ex:sensorType "Temperature" ;
sosa:isHostedBy <http://example.org/factory/machine/M42> .
Blank cells in the source produce no triples — no sosa:isHostedBy for S3, no ex:hasStatus for S5 — rather than invented or half-formed data.
Generated output files are written into the workspace — keep it under source control.
Validate & repair RDF data
Your agent can write SHACL shapes for your data, run validations, read the resulting report, fix violations directly in your files, and re-validate until the data conforms. It also sees the same live diagnostics the editor shows in the Problems panel.
Create SHACL shapes to validate that every sensor belongs to exactly one machine and has exactly one status from OK, Warning, or Error. Then validate the generated RDF.
I wrote shapes.ttl with two property shapes on sosa:Sensor — the second one restricts the allowed statuses with sh:in, which deliberately excludes Broken:
sh:property [
sh:path ex:hasStatus ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:in ( ex:StatusOK ex:StatusWarning ex:StatusError ) ;
sh:message "Sensor must have exactly one status: OK, Warning, or Error." ;
] .
shacl_validation
[ a sh:ValidationReport;
sh:conforms false;
sh:result [ a sh:ValidationResult;
sh:focusNode http://example.org/factory/sensor/S3;
sh:resultMessage "Sensor must belong to exactly one machine.";
sh:resultPath http://www.w3.org/ns/sosa/isHostedBy;
sh:resultSeverity sh:Violation;
sh:sourceConstraintComponent sh:MinCountConstraintComponent;
sh:sourceShape []
], [ a sh:ValidationResult;
sh:focusNode http://example.org/factory/sensor/S4;
sh:resultMessage "Sensor must have exactly one status: OK, Warning, or Error.";
sh:resultPath http://example.org/factory/hasStatus;
sh:resultSeverity sh:Violation;
sh:sourceConstraintComponent sh:InConstraintComponent;
sh:sourceShape _:b1;
sh:value http://example.org/factory/StatusBroken
], [ a sh:ValidationResult;
sh:focusNode http://example.org/factory/sensor/S5;
sh:resultMessage "Sensor must have exactly one status: OK, Warning, or Error.";
sh:resultPath http://example.org/factory/hasStatus;
sh:resultSeverity sh:Violation;
sh:sourceConstraintComponent sh:MinCountConstraintComponent;
sh:sourceShape _:b1
]
].
Validation catches the three problems seeded into the test data:
| Sensor | Caught by | Problem in the source |
|---|---|---|
| S3 | sosa:isHostedBy — sh:minCount 1 | no machine in the source row |
| S4 | ex:hasStatus — sh:in | StatusBroken is not an allowed status |
| S5 | ex:hasStatus — sh:minCount 1 | no status in the source row |
S1, S2, and S6 conform. Each finding points at an exact fix: fill in the two blank cells upstream, and either correct S4's status or add Broken to the sh:in list if it's a legitimate state — then the whole file conforms.
Repairing violations writes to your workspace files — see Agentic AI Security for the confinement rules.
Query your graph and endpoints
Your agent can write and execute SPARQL against local RDF files or your configured SPARQL endpoints and return the results as a readable table. Protected endpoints are addressed by opaque ids — stored credentials are never exposed to the agent.
Write and execute a SPARQL query that returns all services affected by machines that have at least one sensor with status Error.
sparql_query
PREFIX ex: <http://example.org/factory/>
PREFIX sosa: <http://www.w3.org/ns/sosa/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT DISTINCT ?serviceLabel ?service WHERE {
?sensor ex:hasStatus ex:StatusError ;
sosa:isHostedBy ?machine .
?machine ex:servedBy ?service .
?service rdfs:label ?serviceLabel .
}
| serviceLabel | service |
|---|---|
| Packaging Line | http://example.org/factory/service/SVC-1 |
Packaging Line is the only service reachable from an Error sensor through a complete sensor → machine → service chain. The join excludes S6's machine (M99) because its source row has no service link.
Reason across the pipeline
Because the agent built the ontology, the mapping, and the shapes itself, it can also explain how they relate — including when a change belongs in one layer and deliberately not in the others.
Please improve the ontology so it can distinguish between raw sensor status and calculated machine health.
I introduced ex:MachineHealth as a separate class with its own individuals — HealthOK, HealthDegraded, HealthCritical, and HealthUnknown for machines whose sensors have missing data (like S5) — plus an ex:hasHealth property on machines, annotated as derived, not directly observed. The value set and naming scheme deliberately differ from the raw ex:SensorStatus, so the two can't be mixed up accidentally. How health is computed from sensor statuses stays application logic — a SPARQL CONSTRUCT or a SHACL rule — not ontology structure.
Explain why you did not adapt SHACL and YARRRML.
Neither needed to change, and the reason is the same in both cases: ex:MachineHealth is a calculated value, not a raw data field.
YARRRML maps columns from the CSV to RDF triples — there is no machine_health column, because health isn't something the sensor hardware reports. There is nothing to map. SHACL validates the data graph as it is — no ex:hasHealth triples exist yet, so requiring them would make every machine fail validation. The shapes validate what the pipeline produces, not what a downstream computation will derive.
| Layer | What it handles | Tool |
|---|---|---|
| Raw sensor data | ex:hasStatus on sensors, sourced from the CSV | YARRRML + SHACL |
| Derived machine state | ex:hasHealth on machines, computed from statuses | a later SPARQL CONSTRUCT or SHACL rule |
Built-in syntax guides
Before writing or repairing files, your agent can pull concise Turtle, SHACL, SPARQL, and YARRRML reference guides from the server on demand. In the session above, the agent consulted the matching guide before writing each artifact — Turtle before the ontology, YARRRML before the mapping, SHACL before the shapes, SPARQL before the query — which is why every artifact in the session was valid on the first attempt.