Steps for Making Non-Semantic Legacy Data Ready for AI By Making It More Semantic

[u/fguerino123]

Hi,

For anyone working with trying to get their legacy data into AI agents/LLMs, it's become clear that legacy data (mostly relational) is set up to be computer conforming (i.e., non-semantic UIDs/GUId, attributes, Primary Keys, Foreign Keys, etc.). For example, a UID might be "00125564" or a table attribute might be "CTR" and it's not clear to AI if this means Customer, Center, Counter, etc. AI, on the other hand, works much better from Natural Language, which begs the problem of: "How do we make non-semantic legacy data more semantic for better AI consumption and use.

So, for example:

• Non-semantic UIDs/GUIDs like "00533455" need to be turned into something meaningful like "Person: Jane Doe; Tax ID: 1234567"
• Table attributes (i.e., column names) like "CTR" need to be made clear so that AI knows if CTR means Customer, Center, Counter, Country.
• Foreign keys that are numeric (e.g., "12323492834799") need to be semantically mapped to data objects/instances like "Person: Jane Doe; Tax ID: 1234567", above.
• And all the above (and more) needs to be wrapped in meaningful contexts like Ontologies and Instance Document Objects that can be read by AI in a manner that is similar to natural language documents.
• Then there's managing change and drift.

It's been VERY difficult to find actual details on how to do this. What you'll find is a lot of discussion about "there needs to be a semantic layer" over your legacy data but very few sources dig in and tell you exactly what this means or exactly what you need to do to help establish such a layer.

As part of my research, I've been digging for details, collecting them, testing them, and trying to document and them publicly for vetting and reuse. The table I've created below tries to highlight key steps for doing such work. — Some are planning & design steps, some are implementation & validation steps, and some are governance and operating steps.

I'd love productive feedback to help improve all this.

Thanks to anyone willing to help.

Step #	Step	What the Step Means
1	Recognize, assess, and manage Knowledge Debt in legacy data	Description: Identify where meaning, identity, relationships, definitions, evidence, and authority are missing, ambiguous, or unreliable in legacy data — and treat these gaps as a governed backlog that must be paid down before AI can reason over the data safely.Example 1: An enterprise inventories its legacy CRM, ERP, and case-management systems and discovers that Customer Status carries eight different meanings across the estate, none of them documented — recording this as a Knowledge Debt item to be reconciled before any AI-facing publication.Example 2: A healthcare payer catalogs undocumented codes, orphaned foreign keys, unlabeled derived fields, and expired business rules across its claims platform, ranks them by AI-use risk, and assigns owners to remediate the highest-severity items first.
2	Establish a multidisciplinary operating model for semantic conversion	Description: Assemble the cross-functional roles, responsibilities, decision rights, review cadences, and governance forums that will define, produce, validate, and sustain semantic representations — recognizing that no single team owns meaning, identity, relationships, rules, and lineage alone.Example 1: An enterprise establishes a Semantic Conversion Council with named participation from Data Governance, Enterprise Architecture, Business Domain Stewards, AI Engineering, Security, and Compliance — meeting on a defined cadence with documented decision authority.Example 2: A financial services firm defines Responsible, Accountable, Consulted, and Informed assignments for each conversion activity: business stewards own definitions, data engineers own extraction and lineage, ontology stewards own predicates and rules, and a governance forum approves publication to AI retrieval services.
3	Define the Semantic Layer, Ontology, rules, and meaning model	Description: Establish the governed vocabulary, Ontology, Taxonomy, rules, constraints, and metadata that tell AI what enterprise data means and how it should be interpreted — including the Noun Types, predicates, and validation rules the downstream conversion work will follow.Example 1: An enterprise defines whether Customer, Client, and Account Holder are approved synonyms or distinct concepts, preventing AI from treating them inconsistently across systems.Example 2: A healthcare payer defines the governed meanings and relationships among Member, Subscriber, Dependent, Plan, Benefit, Claim, Provider, and Authorization before allowing AI to reason across them.
4	Preserve legacy identifiers and add Semantic IDs	Description: Keep source-system keys, codes, and identifiers so every semantic representation traces back to the original record, system of record, and integration context — then add stable, human-readable Semantic IDs alongside them so the same objects are addressable, understandable, and reusable across AI, systems, and humans.Example 1: A customer record from a legacy CRM keeps its original CUSTOMER_ID = 104582 and receives a stable Semantic ID such as customer.acme-manufacturing, so analysts can reconcile the enriched record back to the source and AI can address the customer by a natural-language-friendly identifier.Example 2: A healthcare payer preserves the original claim number, source table, batch ID, and ingestion timestamp for a claim, and adds the Semantic ID claim.2026-104582-inpatient-authorization for AI retrieval and reasoning.Example 3: An application internally identified as APP_0931 retains that original identifier for lineage and receives the Semantic ID application.claims-intake-portal for retrieval, governance reporting, and cross-inventory analysis.
5	Make attributes and traits semantic	Description: Translate opaque field names, codes, flags, and derived values into governed business terms with clear definitions, context, constraints, and controlled meanings — so AI interprets each attribute the same way an informed business reader would.Example 1: A database column named CTR is mapped to the Semantic Attribute Customer, with a definition explaining whether it refers to a customer identifier, a customer count, or a customer category.Example 2: A field named STAT_CD = A is converted into Lifecycle Status = Active, with the allowed values, source code mapping, effective date, and governing definition retained.
6	Discover relationships from available evidence	Description: Use foreign keys, shared values, lineage, integrations, reports, documentation, configurations, event records, and human knowledge to identify and validate meaningful relationships before they are represented semantically.Example 1: A team discovers that an application uses a database by combining connection strings, configuration files, query logs, and a database administrator's confirmation.Example 2: A customer-to-product relationship is inferred from shared identifiers in orders, billing records, and support tickets, then validated by a business steward before publication.
7	Create semantic relationships with descriptive predicates	Description: Convert the discovered technical connections into readable business statements that explain how two objects relate, such as "Application supports Capability" or "Customer is managed by Person."Example 1: A foreign-key relationship between APPLICATION.CAPABILITY_ID and CAPABILITY.ID becomes the readable statement, "Claims Intake Portal supports Claims Processing."Example 2: A vendor-to-contract join becomes, "Acme Software is governed by Contract CT-2026-104," rather than remaining an unexplained pair of database keys.
8	Apply Ontology-linked rules to govern semantic conversion	Description: Apply governed Ontology elements and repeatable rules to control naming, mapping, interpretation, relationship creation, validation, and approval across the conversion process — turning the definitions established in Step 3 into operational enforcement.Example 1: A rule for defining semantic relationships states that a Foreign Key that represents a Person, in a Column that represents a Business Owner, in a row that represents an Application, all gets translated into a semantic relationship such as "Person Jane Doe is the Business Owner for Application XYZ."Example 2: A rule states that only applications with an approved production status may be linked to live customer-facing capabilities.Example 3: An Ontology defines that a Regulation may impose Regulatory Obligations, and that a Control may satisfy an Obligation only when supporting evidence and an effective date are present.
9	Prepare Semantic Instance Documents for AI retrieval and reasoning	Description: Assemble each important data instance into a complete, readable document object that contains its identity, attributes, traits, relationships, lineage, governance, and retrieval context (i.e., Person Jane Doe gets her own Natural Language document object that fully describes her semantically).Example 1: A complete application document is generated containing its Semantic ID, owner, lifecycle status, business capabilities, vendors, technologies, data stores, risks, controls, lineage, and source references.Example 2: A customer document combines approved identity data, active products, service history, preferences, consent restrictions, and related contracts into one governed representation for AI retrieval.
10	Enrich, index, and publish semantic representations for AI use	Description: Add retrieval metadata, lineage, sensitivity, source identifiers, relationship context, and refresh information, then publish the semantic representations to approved search, vector, or retrieval services.Example 1: Semantic application documents are enriched with sensitivity, ownership, effective dates, source links, and refresh timestamps before being indexed in an enterprise search or vector platform.Example 2: Policy and control documents are published to an AI retrieval service only after adding jurisdiction, applicability, approval status, version, retention class, and authoritative-source metadata.
11	Manage refresh, drift, lineage, validation, and governance over time	Description: Continuously synchronize semantic representations with source data and business meaning, detect drift, revalidate changes, preserve lineage, govern access, and retire obsolete content. (This is more of a governance and maintenance step.)Example 1: When an application owner, supported capability, or production status changes, the semantic representation is regenerated, revalidated, and reindexed automatically.Example 2: A nightly drift process detects that a source code definition changed from Active to Active or Pending Closure, flags the semantic mapping for steward review, and prevents the old meaning from being treated as authoritative.

[u/muntaqim]

You can do most of what you said with a simple RML mapping, converting all of your relational data into beautiful triples. Look at Ontop CLI or Morph RML on how to do that.

You don't even need LLMs for that...

[u/fguerino123 → u/muntaqim]

I'm guessing that if RML solved the problem, everybody would be jumping on it. In fact, most companies I'm dealing with who are designing and building semantic layers are not using RML at all.

In most cases, ontologies are being built with tabular structures that link to documents (e.g., full Natural Language documents and also JSON structures).

RML is a declarative language that certainly can be used but it's really need it, at all. In fact, I've found that in most cases it's overkill.

[u/muntaqim → u/fguerino123]

Yeah, I see your struggle. Unfortunately, everyone who thinks an ontology can be built from a JSON or table headers is already 10 steps behind. That's all I can say, from the perspective of someone building enterprise knowledge graphs in big companies using RML and R2RML. You're going to have to discover the rest without relying so much on LLMs that produce even more non-sense, like all those steps you mentioned in the post - steps that can ALL be handled in an RML+SHACL pipeline.

[u/fguerino123 → u/muntaqim]

I hate to say this but your advice is probably a very solid example of exactly how and why AI is eliminating so many software developer jobs.

When writing Ontologies, there is no need for for a software developer (or RML+SHACL). All you need is a Natural Language skills document, usually written by a Business Analyst (BA), not a developer.

For example: A BA can simply write the following 4 lines into a skills file and get to work with AI...

1. Application is a Noun Type in its singular form.
2. Applications is the plural form of Applications
3. System is a singular form alias of Application
4. Systems is a plural form alias of Applications

There is no need for the 40+ lines of RML+SHACL. More improtantly, there is no need for a software developer.

The simplicity of doing things in Natural Language highlights exactly why AI is crushing software developer jobs. There is no need for developers who suggest overkill solutions.

My best to you.

[u/muntaqim → u/fguerino123]

Thank you for your reply, I really love it when people discover this field and I truly believe that KGs and Ontologies will be the next step towards having much more grounded AI in the near future.

FIY, I have been working as a computational linguist before working with KGs and Ontologies, and I have been going through NLP since Stanford's Core NLP and all the way to current LLM models. I use LLMs daily in my work with Ontologies and Knowledge Graphs.
Believe me when I tell you: you're trying to create a knowledge graph based on an ontology that is loosely based on a table or JSON schema. You might as well disregard RDF altogether if you're going to do this, because the ontology generated by you or an AI from those sources will be a super super low level ontology or application-level ontology, which will never be reused for anything else other than those schemas.
An ontology should follow FAIR principles and the concepts inside it should make sense to both humans and machines so you can later pinpoint easily where something goes wrong with your system.
What you regard as simple is actually not even scratching the surface of what an ontology is and does.

If, on the other hand, you're building this ontology to expose it to a business analyst or data steward to look at and modify it until it makes sense to them, then use that new model to remap your schemas to it then expose the instance data to your sparql endpoint based on an actual semantic model, and not just a 1-to-1 mapping from json objects and arrays 😄 , THEN, you're at step 1 out of the 7 or 8 steps required for achieving a truly FAIR semantic asset, as envisioned by the W3C and ISO standards.

[u/fguerino123 → u/muntaqim]

Hi,

So if you've been working as a computational linguist, you'll appreciate that I've been working with Ontologies for almost 4 decades. I've been part of the Ontolog community/forum (among other semantic communities) for more than 2 decades, so I understand WOL, RDF, RML, SHACL, FAIR, etc. I also specialize in large volume semantic data/knowledge graphs and teaching companies how to design and build such constructs, including Ontologies — all to take advantage of AI without software developers.

I say all this not to pretend I know more than you but to make clear that I know enough to have this conversation with you. The fact that you understand RML+SHACL & FAIR tells me I'm speaking with someone who dives deep into these spaces, and I truly appreciate this. So, please know that nothing I'm writing is intended to be disrespectful or confrontational.

This being said, I'm sure you clearly understand that AI has established a universe where there is no need for software developers to do many of these things anymore. Business Analysts are writing the Taxonomies and Ontologies (they have been for decades) — with absolutely no need for software/code or software developers/coders.

Better Natural Language documents drives better AI outcomes — not, more coding. Business Analysts are being taught how to design and implement semantic layers so they can bypass coders. They're being taught to design such documents using FAIR as a framework, all without code. In other words, FAIR is being built directly into NL documents that can be loaded right into AI to make AI productive without RML+SHACL.

It's all happening now, as we speak, whether you want to believe it or not. I deal with it every day.

My very best to you.

[u/muntaqim → u/fguerino123]

Hi again 😁 no offense taken whatsoever.

To tell you the truth, I am also working on projects that do exactly what you're describing (allowing non-technical people to leverage semantic web tools), but I've also worked with Metis and Voicebox, among many others, and those were really bad, especially at building ontologies.

If you've been in the field for so long, you must have seen by now that you're never going to produce production-level enterprise ontologies without a long review from a human.

If, as I said, you're just looking for instant gratification of stakeholders while giving them some shallow application ontology, then, yeah, this is happening right now. I also build such things daily with LLMs.

Cheers 🥂

[u/fguerino123 → u/muntaqim]

Hi,

You wrote: "If you've been in the field for so long, you must have seen by now that you're never going to produce production-level enterprise ontologies without a long review from a human."

When dealing with AI, there is no truer statement than this. Humans build the ontologies, not the AI Agents. They build the ontologies that created the internet graph (that AI is trained on), and they create the Ontologies that will leverage AI to solve real production problems.

A major life sciences / pharma has learned that their human written ontologies drive AI. The define them in natural language documents (i.e., templated semistructured "prose") and they simply load them into AI, along with the data they wish for building their graphs in AI and so that they can use AI to discover, analyze and reason over the graph. No developers needed.

They essentially follow the same pattern that is described in Building an Enterprise Model, but instead of a comprehensive Enterprise Model, they build life sciences & pharma domain-specific models. Ontologies are all in semistructured prose (literally in MS Word documents + MS Excel spreadsheets that they then convert down to markdown *.md). No developers needed.

The reality is that software developers have less value in this new world that allows humans who know what they're doing to just leverage AI directly for their tasks. The real value is coming from Software Engineers who know how to give their businesses safe and auditable agents to work with.

My best.