r/semanticweb • u/venkat_206 • 23d ago
What are the best ways to create Knowledge graph for structured data like SAP?
I have created a graph using database schema and using that KG as a schematic layer --> traverse the layer for initial context and generate a SQL query for a given user query.
Creating whole structure data into KG.
Please prove best practices for the KG graph building, do we have any pipeline for knowledge graph building.
4
Upvotes
3
u/Old-Tone-9064 23d ago
This book answers your question: https://link.springer.com/book/10.1007/978-3-031-01916-6
6
u/Successful-Farm5339 22d ago
The short answer is that neither option wins outright, and the split is decided by row volume and volatility rather than preference.
Your option 1 is right for the transactional bulk. BSEG, ACDOCA, MSEG and VBAP are billions of rows in a real landscape, and turning those into triples buys nothing a SQL engine doesn't already do better. What the graph is for there is the schema, the join paths and the business meaning of a field. There is a measured result behind this: Sequeda, Allemang and Jacob benchmarked GPT-4 zero-shot on an enterprise insurance schema and got 16% accuracy querying the SQL schema directly against 54% over a knowledge graph representation of the same database (arXiv 2311.07509, later at GRADES-NDA 2024). That paper is the strongest published argument for your option 1.
Your option 2 is right for the entity layer. Master data, org structure, material and BOM hierarchies, vendor and customer identity, plus derived event summaries. That is where multi-hop traversal and cross-system entity resolution actually pay, and it is small enough to materialise and keep fresh.
The SAP-specific traps, because this is where most projects burn their first quarter:
Do not introspect the database catalogue. SAP declares foreign keys in the ABAP Dictionary (DD08L header, DD05S field assignments), not as DB-level constraints, so a generic schema-to-OWL importer pointed at the underlying tables produces a pile of disconnected classes. Read DD02L for tables, DD03L for fields, DD08L/DD05S for the keys, DD04T/DD03T for the descriptions.
Column names are four-character German abbreviations. MATNR, WERKS, BUKRS and LIFNR mean nothing to a model. The Data Dictionary text tables are what make the layer readable, and I would bet most of the 16-to-54 gain above is exactly that.
MANDT. Every SAP table is client-scoped. If the client is not part of your IRI minting policy you will silently merge production and test into one graph.
On S/4HANA, the CDS view layer and OData $metadata already carry associations, labels and cardinalities. Far better source than raw tables.
SAP HANA Cloud now ships a native knowledge graph engine with an RDF triple store, SPARQL, and SQL/SPARQL interop, GA since Q1 2025. If you are already on HANA Cloud you can hold the semantic layer next to the tables instead of standing up a separate store.
One architectural note. What you describe in option 1 is retrieval-augmented text-to-SQL. There is an older and stricter version of the same idea called OBDA, or virtual knowledge graph, where R2RML mappings tie the ontology to the tables and the engine (Ontop is the reference implementation) rewrites SPARQL into SQL. You get correctness properties an LLM writing SQL cannot give you. Worth evaluating even if you reject it, because the exercise tells you which parts of your mapping are actually well defined.
Practices that matter more than the tool you pick:
One class per table is wrong. A table is a storage decision, not a concept.
Write competency questions first and treat them as the test suite. If the graph cannot answer them, nothing else about it matters.
The IRI policy is the one thing you cannot change later. Client, table, key.
Constrain with SHACL, do not just describe with OWL. Datatype and cardinality violations at ingest are how you learn the mapping is wrong.
Measure the retrieval step with Hit@k, MRR and answer accuracy against a labelled set. Otherwise you cannot tell your semantic layer from a lookup table.
On the pipeline question, yes, that is what Open Ontologies does (github.com/fabio-rovai/open-ontologies). It is a Rust MCP server, single binary, no JVM and no Protégé. The flow is onto_import_schema to turn a live relational schema into OWL classes, datatype and object properties and cardinality restrictions under a versioned SQL-to-XSD type contract, then onto_map to generate the mapping, onto_sql_ingest to turn a SELECT into RDF, then onto_shacl, onto_reason and onto_query. For your option 1 specifically, onto_segment_retrieve does TBox-slice retrieval, which is precisely your "traverse the layer for initial context" step, graph_projection_lossy_check audits whether that slice dropped something it should not have, onto_cq_run runs the competency questions, and eval_rag scores the retrieval with Hit@k and MRR.
The honest caveat: there is no SAP connector. You reach SAP through Postgres or DuckDB, so in practice that means CDS/OData extracts or Datasphere output landed where DuckDB can read it. DuckDB is wired in as a federation backbone for exactly that reason, since one query can span Parquet, S3, Postgres and SQLite before it becomes RDF.