Apache Ossie 0.2 Is Taking Shape and Coginiti Will Support It

The Apache Ossie (incubating) project, the new home of the Open Semantic Interchange effort, is beginning to take shape around its 0.2 specification.

Ossie began with a straightforward proposition: the semantic layer ecosystem needs a common interchange format. Organizations should not have to recreate their business semantics every time they change tools, add a platform, or introduce another consumer of their data.

That remains true. But the work underway for 0.2 suggests a broader ambition. Ossie is starting to define how semantic models are serialized, how they are structured, how the expressions inside them should behave, how they relate to ontologies, and eventually how consumers might query them consistently.

Coginiti intends to support that evolution directly.

When Apache Ossie 0.2 is released, Coginiti plans to release an open-source import/export converter for the 0.2 specification under the Apache 2.0 License.

With it, organizations will be able to move semantic definitions between Coginiti and the broader Ossie ecosystem without locking those definitions into a proprietary representation.

What is changing in Ossie 0.2?

The specification is still under development, and some details will change before release. What follows reflects the working drafts as of today. But several themes are already clear.

Semantic models become cleaner artifacts

The current 0.2 development specification moves toward one semantic model per document.

Earlier versions allowed semantic models to be wrapped inside a collection. The new structure makes the semantic model itself the document.

That sounds small, but it establishes a much cleaner unit of identity. A semantic model can now correspond naturally to an artifact in source control, a resource exposed by an API, a deployable object, or an independently versioned component. As semantic models move from BI configuration into managed enterprise infrastructure, that one-to-one mapping gets more useful.

Measures are moving closer to the data they describe

Another proposal under discussion is support for dataset-scoped metrics.

A measure like revenue often belongs naturally to the dataset it is derived from:

datasets:
  - name: orders
    metrics:
      - name: revenue
        expression: SUM(order_amount)

That can coexist with model-level metrics that span multiple datasets or compose lower-level measures.

Not every semantic definition operates at the same level. Some semantics belong to a particular relation. Others describe the business model as a whole. A useful semantic standard needs to represent both.

Expressions need semantics too

Portable metadata only goes so far if every implementation interprets the expressions inside it differently. The Ossie expression-language work addresses that problem through a portable, SQL-oriented expression language.

If two systems can both parse:

SUM(order_amount)

but disagree about identifier resolution, null semantics, aggregation behavior, or available functions, then they have exchanged syntax rather than meaning. Semantic interoperability requires agreement about evaluation as well as YAML keys.

Semantic models and ontologies are being separated

This may be the most conceptually important development. Ossie is defining semantic models, ontologies, and the mappings between them as distinct artifacts, with ontology mappings connecting them.

A semantic layer and an ontology solve related but different problems.

The semantic layer defines the analytical model used to consistently calculate and query business data: dimensions, measures, relationships, entities, metrics, and their execution semantics.

An ontology represents a broader conceptual model of the business: concepts, types, relationships, constraints, and other forms of knowledge.

The two can and should be connected, but they should not be confused. Ossie keeps them separate and links them with a mapping:

   Ontology
      ↑
      | mapping
      |
Semantic Model

This gives organizations a path from physical data, through analytical semantics, toward broader knowledge infrastructure without collapsing all three into a single abstraction.

From interchange format to semantic contract

Taken together, the 0.2 work goes beyond metadata portability. It starts to define a stack of layers:

Ontology
    ↑
Ontology mappings
    ↑
Semantic model
    ↑
Expression and evaluation semantics
    ↑
Relational data

There is also active work on query semantics and interfaces that could eventually let clients consume Ossie models through both relational SQL and higher-level semantic queries. Some of that work may not land in 0.2, but the direction is clear.

Ossie started with "How do I describe a semantic model?" It is now taking on a harder one: "What should a portable semantic model mean?" Any real semantic interoperability standard has to answer that second question.

Why Coginiti is supporting Ossie

We have argued for some time that enterprise semantics should not belong to a single BI tool, AI agent, or analytics platform. Metrics such as revenue, active customer, inventory position, or gross margin are organizational assets. They should be defined once, governed centrally, versioned, tested, and consumed wherever they are needed.

That is one of the core ideas behind Coginiti's Semantic Intelligence Platform. But a universal semantic layer cannot be universal if the only way into or out of it is a proprietary format.

That is why Coginiti joined the Open Semantic Interchange effort, and why we will support Apache Ossie 0.2 from release.

The converter will work in both directions:

Ossie 0.2
    ↓ import
Coginiti Semantic Model

Coginiti Semantic Model
    ↓ export
Ossie 0.2

We want it to be useful beyond Coginiti customers. Publishing it under the Apache 2.0 license as part of the Ossie project converters means other vendors, developers, and data teams can inspect it, extend it, embed it, or use it as a reference implementation when building their own Ossie integrations.

Open standards need running code

A semantic standard succeeds when organizations can take a model defined in one environment and move it somewhere else without starting over, when vendors can implement against a common contract rather than reverse engineering one another, and when semantic definitions become durable enterprise assets rather than configuration trapped inside whichever analytics tool happened to create them first.

Apache Ossie 0.2 looks like a real step toward that future, and Coginiti intends to help make it work.

If you want to follow the 0.2 work or contribute, start with the Apache Ossie project site and the 0.2 specification drafts. When the converter ships, you'll find it with other Ossie project converters.