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.

Every few years, someone declares that open semantic standards are obsolete.

The argument usually sounds practical. The market has moved on. Developers prefer simpler formats. Operational platforms need speed and scale. Business users need dashboards, workflows, and applications, not formal models.

There is a grain of truth to this.

Operational platforms should not be judged only by whether they use a semantic standard as their native runtime architecture. Serious systems are layered. They combine SQL, JSON, APIs, graph stores, search indexes, workflow engines, code, and user interfaces.

No one should expect one standard to do every job.

But that does not mean open semantic standards are irrelevant. It means we need to understand what job they are supposed to do.

Open semantic standards give organizations a transparent, inspectable, machine-readable way to represent shared meaning.

Data platforms manage data. Semantic standards govern meaning.​

Organizations increasingly rely on ecosystems rather than single systems. Data moves across teams, vendors, departments, products, partners, analytic tools, and AI systems. If the meaning of the data is trapped in one platform’s internal model, the organization becomes dependent on that platform not only for execution but also for interpretation.

That is a deeper form of lock-in.

The issue is not whether a platform can export data. The issue is whether it can export meaning in a form that other tools and independent experts can inspect, test, validate, and reuse.

A CSV file can move rows.
A JSON document can move objects.
A Parquet file can move columns efficiently.
An API can expose endpoints.

But none of these, by themselves, guarantees preservation of meaning.

They may preserve the data while leaving behind the definitions, axioms, relationships, constraints, provenance, version history, and inference rules that made the data intelligible.

Do not confuse the platform with the semantic model​

A platform is not a strategy.

Platforms help organizations integrate data, build workflows, run analytics, create applications, manage access, automate processes, and deliver useful interfaces to real users.

But a platform should not be confused with the organization’s semantic model.

The semantic model is the organization’s account of what its important things mean. It defines the categories that matter, the relationships among them, the identifiers used to track them, the constraints that govern them, and the assumptions that make them usable.

A platform may implement parts of that model. It may visualize it, operationalize it, transform it, query it, or enrich it.

But the platform should not silently become the only place where meaning lives.

When that happens, the organization loses independence. Meaning becomes embedded in proprietary configuration, workflow logic, transformation code, application behavior, or undocumented platform conventions.

At first, this may look efficient. The platform team moves quickly. The demos are impressive. Users see integrated views and working applications.

But over time, the organization may discover that its most important semantic commitments are no longer easy to inspect, export, validate, or reconstruct outside the platform.

This is more subtle than data lock-in; it is semantic lock-in.

Open standards create leverage​

Open semantic standards give organizations a vendor-independent baseline for representing important meanings. They allow teams to define classes, relationships, identifiers, definitions, constraints, mappings, and versioned commitments in ways that are more transparent than platform-specific configuration.

The point is not that every application must run natively on RDF, OWL, SKOS, SHACL, SPARQL, or JSON-LD. The point is that organizations need a standards-backed semantic layer that can survive beyond any one product.

A mature architecture can use open semantic standards for governance, validation, mapping, enrichment, documentation, and exchange while allowing operational systems to use whatever internal representations are best for performance and usability.

Open standards let organizations ask better questions:

These questions become more important as organizations adopt AI. AI systems need context, structure, provenance, and constraints. Without them, they produce confident answers over unstable foundations.

Open semantic standards are not a silver bullet. They do not solve data quality, security, workflow, latency, or user experience by themselves.

But they provide something every serious organization needs: a way to keep meaning visible, portable, and governable.

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.