SQL to a semantic graph environment

ArcXA SQL Consulting (ASC): Proposes connecting a relational database environment (SQL) to a semantic graph environment (Triple Store Architecture(ICL)) is an excellent way to bridge the gap between rigid data structures and intelligent, context-aware data governance.

Equitus.ai’s ArcXA SQL Consulting (ASC) can structure this journey, starting from On-boarding and moving all the way through to Testing.

SQL to Subject-Predicate-Object (SPO) triples mapping, flat, siloed tables turn into a dynamic Knowledge Graphs.

1. SPO now powers three critical  graph capabilities simultaneously.
2. NLP-to-SQL semantic grounding (so AI agents don't hallucinate column names), end-to-end data lineage tracing.
3. MCP-callable data assets- Context Layer Generation is the value extraction phase. 

_________________________________________________

1. The On-boarding Phase: Mapping & Materialization

ArcXA systems onboard / ingest the existing SQL schema and translates it into a semantic context layer without disrupting current operations.

• Step 1: Schema Discovery & Ontology Alignment

  • ASC scans the enterprise SQL metadata (Data Dictionaries, Foreign Keys, Primary Keys).

  • An Ontology (the graph schema) is defined. For example, a SQL table called Customers becomes a Subject class (ex:Customer), a column like Email becomes a Predicate (ex:hasEmail), and the cell value becomes the Object.

• Step 2: Mapping Rule Creation

  • Using standards like R2RML (RDB to RDF Mapping Language), ASC creates the declarative rules that govern how SQL rows are transformed into SPO triples.

• Step 3: Initial Graph Materialization

• Data is either converted into physical triples (RDF) and loaded into the Triple Store, or a virtual graph layer (Ontop / OBDA) is established to query the SQL database in real-time using SPARQL.

2. The Context & Governance Layer: Active Metadata

Triple Store doesn't just hold data; it holds context  giving enterprise migration and integration projects get their safety net.

• Lineage Tracking: Because every data point is an SPO triple, you can attach governance metadata to the predicate. You don't just know what the data is; you know its source, classification (e.g., PII), and transformation history.

• Policy Enforcement: Business rules are written as semantic constraints (using SHACL - Shapes Constraint Language). If a SQL integration violates a business rule, the context layer flags it immediately.

3. The Testing Phase: Validating the Semantic Bridge

Testing a hybrid SQL-Triple Store architecture requires validating data integrity, semantic accuracy, and performance across both paradigms.

A. Schema & Structural Testing

• How: Validate that the R2RML mapping rules haven't broken down.

• Execution: Ensure that every Primary Key-Foreign Key relationship in the SQL database correctly resolves to a valid Object Property (relationship) in the Triple Store. If Orders.CustomerID links to Customers.ID, the graph must show ex:Order123 ex:placedBy ex:Customer456.

B. Semantic Consistency Testing (Reasoning Validation)

• How: Use the Triple Store's inference engine to catch data anomalies that SQL constraints might miss.

• Execution: Run a semantic reasoner (like Pellet or HermiT) over the graph. If the ontology states that a Manager must be an Employee, but a SQL integration migration mistakenly populates a manager record without an employee ID, the reasoner will flag a logical contradiction.

C. Data Integrity & Completeness (Reconciliation Testing)

• How: Ensure no data was lost in translation from the relational database to the graph.

• Execution: ASC utilizes a "Dual-Query" testing framework. A test script executes a standard SQL query and an equivalent SPARQL query simultaneously, comparing the result sets to guarantee 100% data parity.

Test Type	SQL Target	Triple Store (SPO) Target	Expected Outcome
Row vs. Triple Count	SELECT COUNT(*)...	SELECT (COUNT(?s)...	Exact match of data volume based on mapping ratio.
Data Type Validation	VARCHAR, INT, DATETIME	xsd:string, xsd:integer, xsd:dateTime	Strict adherence to XML Schema Datatypes in the graph.
Constraint Testing	Check Constraints, Nullability	SHACL Shapes Validation	Graph alerts on any data violating enterprise governance boundaries.

_________________________________________________________________________

Sources — IBM i/DB2, RDBMS, cloud lakehouses, and files/APIs are the raw inputs. ArcXA connects to all of them without requiring a pre-cleaned data model.

Ingest — Schema discovery parses DDL and resolves legacy field aliases (so CUST_REC_NO becomes customer.account_id). ETL/profiling scores quality and flags nulls/outliers. Lineage capture timestamps and traces every column back to its origin.

Core — The SPO triple store is the semantic grounding layer — it holds Subject→Predicate→Object relationships that make NLP SQL non-hallucinatory. The KGNN infers relationships across entities and makes query results explainable. MRA + IST modules score migration complexity and sizing.

Governance — Before any query result leaves the platform, ICAM gates it by identity and clearance, IIS enforces data classification and compliance policy (CMMC/FISMA), and the audit log writes an immutable provenance record.

Expose — Three SQL interfaces emerge from governance: the NLP→SQL engine (SPO-resolved natural language to SQL), the MCP Connector (a /schema-context endpoint LLM agents call before generating SQL), and direct JDBC/ODBC/REST for engineers.

Consumers — Business users, AI agents (Claude, GPT-4o), and engineers/BI tools each hit the appropriate interface — all governed, all traceable, all semantically grounded by the same triple store underneath.

The dashed lineage feedback arrow on the right shows that query results write back into the core graph — every query improves the semantic map over time.

5 Phases of ArcXA:

Phase 1 — Onboarding begins with three parallel intake tracks: a Migration Readiness Assessment (MRA) that captures the client's current state, schema discovery that crawls source databases (DB2, SQL Server, legacy flat files, RPG/CL artifacts), and an institutional sizing tool that scopes volume and complexity. These converge into a signed project charter that governs the engagement.

Phase 2 — SQL to SPO Mapping is ASC's core differentiator. Every SQL construct gets translated into the triple store:

• Tables and named entities → Subjects
• Joins, foreign keys, and transforms → Predicates (the governed relationships)
• Column values, attributes, and references → Objects (semantic context)

SQL - Triple Store - Subject - Predicate - Object -  where "dumb SQL" becomes an intelligent, queryable knowledge graph.

Phase 3 — Context Layer Generation is the value extraction phase. The SPO graph now powers three critical capabilities simultaneously: NLP-to-SQL semantic grounding (so AI agents don't hallucinate column names), end-to-end data lineage tracing, and MCP-callable data assets that tools like IBM Bob can consume natively.

Phase 4 — Governance Layer wraps the context layer in enterprise controls: ICAM/RBAC access enforcement, policy rules tied to standards (CMMC, FedRAMP, FISMA), a full audit trail, and live quality scoring via ArcXA's triple key scoring engine.

Phase 5 — Testing runs three gate checks before any migration, integration, or development deliverable goes live: SQL round-trip accuracy (do SPO-mapped queries return correct results?), context fidelity (do NLP queries resolve to the right semantic nodes?), and governance sign-off (does the audit trail satisfy compliance requirements?).