Your SQL tables, answering as a knowledge graph.Without moving a single row.
Virtuoso gives every row in any ODBC- or JDBC-accessible DBMS its own hyperlink, which works as a cross-platform super-key. You can then ask the same data questions in SQL, in SPARQL, or in both at once, and an OPAL agent can answer them in plain English. Nothing on this page is a screenshot: every example runs against live servers as you read. The showcases use Microsoft SQL Server, PostgreSQL, Databricks and native Virtuoso SQL tables as examples, plus a Snowflake-style warehouse estate.
Works with the databases, files and web sources you already have
One Data Space. Four ways in.
Some questions want SQL. Some want a graph. Some are easier to browse than to type, and some are best asked in a sentence. Virtuoso answers all four from the same data, on the same server.
RDF Views
Any ODBC or JDBC database, seen as a graph. Nothing is exported.
- 01SQL over XMLA, against the tables themselves
- 02SPASQL: SPARQL inside a SQL
FROM - 03SPARQL over the same rows, now with IRIs
Sponger
Give it a web page. Get back a graph.
- 01Pages, feeds, repos and posts in, RDF out
- 02Each source URL names its own graph
- 03Entities extracted and linked to DBpedia
Faceted Browse
See what is in the data before you write a query.
- 01Start from text or a class
- 02Pivot along a relationship
- 03Every view is a shareable link
OPAL Agents
Ask in English. A query does the work.
- 01Agents call predefined query functions
- 02Answers come from live SQL and SPARQL
- 03Embed the same widget on any page
Three steps from any ODBC or JDBC database to a knowledge graph
Attach
Connect Virtuoso to any DBMS it can reach over ODBC or JDBC; the showcases use Microsoft SQL Server, PostgreSQL and Databricks alongside native Virtuoso SQL tables as examples. The tables appear inside Virtuoso, for example "sqlserver"."northwind"."customers", and the data stays where it is.
Map
An RDF View gives each row a hyperlink of its own, such as …/customers/CustomerID/ALFKI#this, and turns each foreign key into a link you can follow. That hyperlink is a super-key that works on any platform able to follow a link.
Query or ask
Use SQL, SPASQL or SPARQL, browse by facets, or put the question to an OPAL agent. Every IRI also opens a page that describes it.
Your schema becomes an ontology. Shared ontologies make it travel.
When Virtuoso generates an RDF View, it also generates the ontology that describes it: a class for every table, a typed property for every column, a link for every foreign key. Align those classes with shared ontologies such as FOAF, schema.org or DBpedia, and one question in a shared vocabulary reaches every database at once.
8 tables, 8 classes, 94 properties
The Northwind tables in Virtuoso became eight classes, each labelled with the table it came from, with properties typed from the SQL columns. SQL Server's Northwind gets the same treatment: nine classes.
See the generated classes → AlignedMapped to the ontologies everyone shares
Generated classes are declared subclasses of shared ones: customers of foaf:Organization, employees of foaf:Person, movies of dbo:Film, campaigns of schema:Action.
One question, two different sources
Asked for people in FOAF terms, the server returns 18 from CSV files and 9 from Virtuoso SQL tables, because both generated classes are aligned with foaf:Person. No mapping code; just the ontology.
Three facts worth knowing before you choose
Nothing is copied
Each SPARQL query here is translated into SQL and run against the source tables at that moment. When a row changes in the source database, the next answer changes with it. There is no export to schedule and no copy to drift.
See it on Northwind →Every row's hyperlink is a cross-platform super-key
Each customer, order and product gets a hyperlink that opens a page describing it. Unlike a primary key, it keeps its meaning outside its own database, so rows in two different databases, or a row and a web page, can be joined by reference instead of by file transfer.
See sponged entity links →Answers come from queries, not from a stored copy
An OPAL agent builds its answer from a query you can inspect. When a number looks wrong, you can see exactly where it came from.
Talk to an agent →Your data stays where it lives. So do the rules.
Access is decided by attribute-based (ABAC) ACLs on the server, not by the page. On the demo instance anyone may run SPARQL; SQL, SPASQL and fresh sponging need a sign-in. Identity can come from WebID-TLS, OAuth or OpenID Connect through the Virtuoso Authentication Layer.
The questions people ask first
Run your first query. Most answer in under a second.
Most Northwind queries on this page answer in under a second. Run one, then ask an OPAL agent the same question in plain English and compare the two.
The same tables, asked three ways
Each tab is a data source exposed through a Virtuoso RDF View (any DBMS reachable over ODBC or JDBC qualifies); the showcases use native Virtuoso SQL tables, Microsoft SQL Server, PostgreSQL and Databricks as examples, plus a synthetic Snowflake-style warehouse estate and CSV files, all on demo.openlinksw.com. SPARQL runs right here, and you can edit any query before you run it. SQL and SPASQL open in the SPASQL Query Builder, which sends them to Virtuoso over XMLA.
Pick a database, then a language
Point it at a web page. Get back a graph.
The Sponger is Virtuoso's Linked Data middleware. Its cartridges read a web resource (an HTML page, an RSS feed, a GitHub repository, an X profile), produce RDF, and store it in a named graph whose IRI is the source URL. On URIBurner, a query names that graph with FROM <url> and adds DEFINE get:soft "replace" to fetch or refresh it.
DEFINE get:soft "replace" and opens URIBurner's authenticated endpoint.Five live examples from two sources
Try it on a page of your own
Enter a URL. You get a description page, a Data Twingler-style type profile you can run now (it returns rows if URIBurner already holds that graph), and the authenticated refresh query.
See what is in a dataset before you write a query
Pick a demo dataset. The page runs the standard explore query against that dataset's named graph only: one row per entity type, with a sample entity and a count. Each type then opens in the SPARQL Faceted Browser, a single-page app in the style of Virtuoso's FCT service, whose links were built with the sparql-faceted-browser skill's link builder.
Run the explore query on one dataset
Open this dataset in the faceted browser
One link per entity type in the selected dataset, plus a pivot and an entity description where the dataset has them.
An assistant that answers from live queries
OPAL connects LLMs to databases, knowledge graphs, filesystems and APIs. An agent is a set of instructions plus a list of query functions. The model picks a function, Virtuoso runs a predefined SQL, SPARQL or SPASQL query, and the answer is built from what comes back. Because the agent and the data are only loosely coupled, you can change the model or the Data Space without rewriting the agent.
How a question becomes an answer
After the OPAL widget architecture diagram.
Agents published on URIBurner
Read live from URIBurner's A2A Agent Card. Agents with a “Chat here” button can be used in the chat panel on this page.
Ask about the data on this site
How the chat connects. The panel uses the same OPAL widget, key and settings as virtuoso.openlinksw.com: its auth.js client carries the public widget key that virtuoso.openlinksw.com (Virtuoso Support Agent) or uda.openlinksw.com (ODBC & JDBC Support Agent) uses for that agent, so there is nothing to sign in to.
The same widget as virtuoso.openlinksw.com
The chat panel on this page is driven by the OPAL widget scripts served from virtuoso.openlinksw.com. This is the initialisation that site uses:
module picks the agent configuration and functions lists the query functions it may call. The panel here swaps module when you choose a different agent. A site of your own should register its own key at URIBurner's OAuth applications page rather than reuse this one.Other ways to reach the same agents
MCP
The same functions, exposed as Model Context Protocol tools.
https://linkeddata.uriburner.com/chat/mcp/messages
https://linkeddata.uriburner.com/chat/mcp/sse
A shared OPAL session from the Northwind Sales Performance Dashboard post: open the Northwind chat transcript.
Ontologies generated from your SQL schema, then reused with shared ones
An RDF View is two things: the mapping that turns rows into entities, and an ontology that describes them. Virtuoso generates both from the database schema, on the fly, for any ODBC- or JDBC-accessible DBMS. Every class and property gets its own IRI, so the ontology is itself linked data you can query, describe and extend.
What gets generated
becomes a class
Demo.demo.Products becomes …/schemas/Northwind/Products, labelled with its source table.
becomes a typed property
UnitPrice becomes an owl:DatatypeProperty with domain Products and range xsd:numeric.
becomes a link
Products → Categories becomes the owl:ObjectProperty has_categories, so joins become paths you follow.
connects it to shared ontologies
One rdfs:subClassOf or owl:equivalentClass statement ties a generated class to FOAF, schema.org or DBpedia.
See it on the live server
Each query below runs against demo.openlinksw.com. The first three read the generated ontologies; the last three show them aligned with, and answering in, shared vocabularies.
Generate one for your own database
Attach and generate
Link the tables over ODBC or JDBC, then generate the RDF View. Virtuoso writes the ontology (TBox), the instance mapping (ABox) and the rewrite rules that make each IRI resolve.
Align
State how your classes relate to shared ones (rdfs:subClassOf, owl:equivalentClass, owl:equivalentProperty), in a few triples kept beside the generated ontology.
Query in any vocabulary
Ask in your own terms or in the shared ones. Apply the alignment in the query, as the last example does, or let Virtuoso's inference rules do it.
Agent skills that automate these steps: virtuoso-support-agent (RDF View generation) and linked-data-skills (RDF Views from database objects).
Where every example comes from
Queries, graph IRIs and links were taken from these posts and checked against the live endpoints.