Ossie-Fact-Based Modelling Viewer: independent .NET viewer and two-way FBM/ORM converter — feedback and collaborators welcome

[FactEngineCommunity]

Hello Ossie community,

I have built Ossie-FBM, an independent .NET viewer and experimental two-way converter between Apache Ossie (incubating) and Fact-Based Modelling/Object-Role Modeling (FBM/ORM).

For readers unfamiliar with Fact-Based Modelling, Ossie’s ontology representation maps closely to fact-based conceptual models, including Fact Types with ordered Roles, natural-language readings, constraints and derivations.

I am publishing it through FactEngineCommunity as an implementation experience—not as an official Apache Ossie application—and would welcome feedback and collaborators.

Repository: FactEngineCommunity/Ossie-FBM

What is Ossie-FBM?

Ossie-FBM is a Windows desktop application and .NET library for exploring how Ossie models map to a fact-oriented conceptual model.

It currently supports:

• parsing and serialising Ossie YAML;
• tree-based inspection of Ossie ontology and semantic-model documents;
• searchable YAML source and generated-YAML views;
• importing Fact-Based Model (.fbm) files;
• converting FBM/ORM models into Ossie ontology YAML;
• converting Ossie ontology YAML into an FBM model;
• side-by-side inspection of the Ossie structure, YAML and resulting FBM model;
• worked examples based on Ossie’s flights.yaml, TPC-DS and a Cinema Bookings model.

Why I built it

The aim is to test semantic interoperability through a concrete implementation.

Ossie’s ontology representation has useful correspondences with established FBM/ORM constructs, including:

• EntityType and ValueType (relationships become Fact Types);
• inheritance through extends;
• relationships and ordered roles (Fact Types);
• natural-language readings through verbalizes;
• reference schemes through identify_by;
• common uniqueness patterns through multiplicity;
• derivations through derived_by; and
• conceptual-to-physical mappings through ontology_mappings.

The preservation of natural-language readings is particularly valuable. It allows an exchanged model to remain understandable to subject-matter experts rather than only to YAML-aware software.

Ossie’s explicit mapping between conceptual elements and physical datasets is another notable strength. It provides a practical bridge between conceptual modelling and deployable semantic models.

What implementation has exposed

Building a working converter has also revealed several useful interoperability questions.

Objectified Fact Types

In FBM/ORM, a Fact Type may itself be treated as an Entity Type and participate in other Fact Types. This is commonly called an Objectified/Nested Fact Type.

For example, the ternary Fact Type:

Part is in Bin in Warehouse

might be reified/objectified as StockedItem, which can then participate in additional relationships.

The converter can recognise this structure in an FBM model, but I have not yet found a lossless Ossie representation that explicitly preserves:

• the Fact Type being objectified;
• its ordered roles; and
• the relationship between those roles and the objectifying Entity Type.
• verbalizations/Fact Type Readings for the Objectified Fact Type, which would otherwise be an (Objectifying) Entity Type in Ossie

I have documented a candidate representation (TBA in a future Issue) and would particularly value guidance from the ontology and specification contributors.

Implementation findings: What we learned implementing Ossie

Constraint semantics

Common single-role uniqueness and preferred identifiers map reasonably well. Value Constraints, and richer constraint families—including, mandatory participation, subset, equality, exclusion, ring and frequency constraints—need further investigation.

Ossie’s requires expressions are flexible, but a converter may not always be able to reconstruct the author’s intended conceptual constraint family from an expression alone.
A parser for Ossie 'requires' constraints is being developed.

We would be interested to hear whether other implementers have encountered similar objectification or constraint-reconstruction issues, and whether named, machine-recognisable constraint semantics would be useful alongside expressions. Shared parser examples—covering different programming languages or grammar tools—could also be valuable.

Current status

This is an experimental interoperability implementation.

Current limitations include:

• conversion does not yet cover every type of constraint in either modelling approach;
• objectified Fact Types cannot yet round-trip without candidate extension syntax;
• automated conversion-level round-trip tests are still being expanded; and
• the WinForms application currently depends on a separately licensed FactEngine binary for .fbm support.

The original Ossie-FBM source and documentation are Apache-2.0 licensed. The bundled FactEngine dependency permits non-commercial use and redistribution under its accompanying licence, so the complete application is not an Apache-2.0-only distribution. The repository documents this distinction explicitly.

Feedback and collaboration

I would welcome help with:

• reviewing the FBM/ORM ↔ Ossie mappings;
• testing additional Ossie examples;
• identifying semantics lost during round-trip conversion;
• designing a representation for Objectified Fact Types (as Objectifying Entity Types with Fact Type Readings);
• defining portable constraint semantics;
• adding conversion and interoperability tests;
• improving the .NET model and viewer; and
• contributing small models that expose useful edge cases.

In particular, I would appreciate the community’s views on:

1. Is there already an intended Ossie representation for objectified or nested Fact Types?
2. Should recognised constraint families be recoverable independently of their executable expressions?
3. Which models would make the most useful interoperability test corpus?

Where the implementation uncovers a genuine specification or documentation gap, I would be happy to contribute focused examples, tests, documentation or schema proposals upstream.

Thank you—and congratulations to everyone building Apache Ossie. Developing against the format has been a valuable way to understand both its strengths and the remaining interoperability questions.

---

Project status: Independent FactEngineCommunity implementation
Repository: FactEngineCommunity/Ossie-FBM
Upstream: apache/ossie
Implementation findings: What we learned implementing Ossie
Licence information: Licence

Apache Ossie is an effort undergoing incubation at The Apache Software Foundation. Ossie-FBM is not an official Apache Ossie project and is not endorsed by the Apache Software Foundation.