Event Report

STIDS 2026 brought the ontology community back into the room.

With approximately 150 registered attendees across in-person and remote participation, STIDS 2026 showed that semantic technology is no longer a niche academic concern. It is becoming central to AI, defense, intelligence, standards, and data interoperability.

STIDS 2026 made one thing clear: the future of AI depends on more than larger models and larger datasets. It depends on better representations, better governance, and better conceptual clarity.

Highlights​

• Strong participation from government, industry, and academic researchers.
• Serious discussion of ontology engineering as infrastructure for AI.
• Increased attention to knowledge graphs, semantic interoperability, and data quality.
• Productive overlap with KGOIDS and related defense and intelligence communities.
• Renewed interest in NCOR as a hub for ontology best practices.

What comes next​

NCOR will continue building the infrastructure around ontology education, certification, best practices, and community coordination. STIDS 2026 was not just an event. It was a signal that this field is entering a new phase.

Most organizations think they have an interoperability problem.

They have too many systems. Too many dashboards. Too many databases. Too many teams using different words for similar things and the same words for different things. So they buy a platform, build APIs, export data, create pipelines, and declare victory when the data finally moves from one place to another.

But moving data is not the same as preserving meaning.

A spreadsheet can be exported. A JSON object can be passed through an API. A table can be replicated from one system to another. None of that guarantees that the receiving system understands what the data means.

Take something as ordinary as location.

In one system, location might mean where an object was observed. In another, where it is assigned. In another, its last known position. In another, its expected destination. In another, a region associated with responsibility, ownership, service coverage, or responsibility.

The field name is the same. The meaning is not.

The hidden cost of local meaning​

Organizations do not usually lose control of their data because the data disappears. They lose control because meaning becomes trapped inside local assumptions, application logic, undocumented workflows, transformation scripts, and platform-specific models.

Semantic debt is what happens when teams keep solving meaning problems locally instead of explicitly. One team writes a transformation script. Another adds a convention to a data dictionary. Another embeds an assumption in a workflow. Another creates a dashboard filter that only the original analyst understands.

Each move is understandable and each may solve an immediate problem.

But eventually the organization is no longer managing shared meaning.

That means asking whether identifiers are preserved, whether definitions survive, whether relationships remain explicit, whether constraints are still testable, whether provenance remains attached, and whether the reasoning behind results can still be explained.

Semantic loss rarely announces itself​

Semantic loss rarely looks like system failure.

There is usually no flashing red warning. No broken dashboard. No dramatic outage. In fact, semantic loss often appears in systems that look perfectly functional.

The records are there. The charts render. The filters work. The workflow completes. Users can search, click, export, and report.

But something important has been flattened.

A hierarchy may be gone. A relationship may have been turned into a label. A constraint may have been replaced by a convention. A definition may have been copied into documentation but detached from the model that made it computable. An inference that once followed from the data may no longer be recoverable.

This is semantic loss: the loss of explicit meaning when information is transformed from one system, format, platform, or model into another.

It is easy to underestimate because many transformations preserve the visible surface of the data. A system may still display “customer,” “asset,” “supplier,” “patient,” “facility,” “claim,” “device,” or “event.”

But the displayed label is not the full meaning.

If those answers disappear, the data has become less meaningful even if it remains accessible.

Accessibility is not intelligibility​

Modern organizations are increasingly dependent on AI, analytics, automation, and knowledge graphs. These systems are flush with data; they need better-governed meaning.

AI systems, in particular, are often asked to operate across messy organizational boundaries. They summarize, classify, recommend, retrieve, predict, and explain. But if the underlying semantic structure is weak, the AI system inherits that weakness.

The solution is not to force every operational system into the same technology stack. Organizations need relational databases, document stores, property graphs, APIs, data lakes, workflow tools, application platforms, search indexes, and user interfaces. Different tools do different jobs.

But organizations also need an authoritative semantic layer: a place where the meaning of important terms, relationships, identifiers, constraints, and assumptions is represented in a transparent and governable way.

That semantic layer should be open, inspectable, testable, and portable. It should not live only inside one vendor’s platform or one team’s undocumented conventions.

From pipelines to architecture​

Data integration gets data from one place to another.

Semantic integration preserves what the data means when it gets there.

That is the difference between a pipeline and an architecture.

A pipeline can move content. An architecture preserves context.

A pipeline can connect systems. An architecture governs the meanings those systems depend on.

A pipeline can make data available. An architecture makes data trustworthy.

Organizations that care about AI, analytics, knowledge graphs, automation, and long-term interoperability need to ask harder questions than whether data can be moved.