Data Model Lifting
Decades of agreement are encoded in your data models — in a form no reasoner can use. VIStology lifts fielded data models into reasoning-ready OWL ontologies automatically, so the lift re-runs on every revision of the source instead of rotting as a one-off port. The documented proof: NATO’s JC3IEDM.
The Challenge: Decades of Agreement, in a Form No Reasoner Can Use
Organizations encode their hardest-won agreements in data models. JC3IEDM — the Joint Command, Control and Consultation Information Exchange Data Model — is the NATO Multilateral Interoperability Programme’s standard for exchanging command-and-control information between coalition systems, maintained as a relational model in the ERwin data-modeling tool; by the time of this work it was increasingly used not just for exchange but as the basis for the data models underlying C2 systems themselves. VIStology wanted it in OWL, as the foundation for ontology-based reasoning applications that establish situation awareness — reasoning a relational schema cannot support directly.
Translating by hand is the obvious answer, and VIStology had already tried it: a prior effort manually translated a subset of JC3IEDM’s predecessor, C2IEDM, into OWL — sufficient for one over-the-horizon targeting application, and no further. The complete model is another matter entirely; in the paper’s own words, the task “was clearly in need of automation.” What follows is what that automation did — and, just as deliberately, what it did not claim.
Case Study: Lifting a NATO Data Model into OWL
The clearest demonstration of automated lifting is a lift of a fielded standard. In work presented at the 12th International Command and Control Research and Technology Symposium, VIStology translated JC3IEDM — the NATO Multilateral Interoperability Programme's standard for exchanging command-and-control information between coalition systems — into a reasoning-ready OWL ontology, automatically.
Too large — and too alive — to translate by hand
JC3IEDM carries decades of coalition agreement: 289 entities, 396 relationships between them, 1,729 attributes, and nearly 7,000 value codes, maintained as a relational ERwin data model and revised on a regular — the paper says "aggressive" — schedule. A manual translation at that scale would be obsolete before it was finished. VIStology built an automated pipeline instead: roughly 470 lines of XSLT that read the model's XML definition and emit the complete OWL ontology on demand.
Semantics preserved, plumbing stripped
The pipeline translates the logical model — entities to classes, attributes to datatype and object properties, relationships to object properties with cardinality constraints and inverses, code lists to enumeration classes — while deliberately filtering out the physical database plumbing of keys, indexes, and replication fields. Where a lossy shortcut would have collapsed distinctions the source model insists on, the pipeline refuses it: preserving semantic content took precedence over convenience.
Verified, repeatable, general
The generated ontology was machine-checked for consistency and passed with no detected errors or warnings. Because the pass is automated, it re-runs against every revision of the source model — the lift survives the standard's release cycle instead of rotting alongside it. And because the pipeline works from ERwin's standard XML export, the same strategy, and much of the same code, lifts any ERwin data model into OWL.
What the Automated Pass Preserves
The mapping decisions are where a lift succeeds or fails, and this pipeline’s were made in one direction: keep the meaning, keep the readability, drop only the database plumbing.
The documentation travels with the model
Every entity’s English-text definition is carried into the generated ontology as an annotation, so the classes stay as readable to a human as the source model was. Subclass structure is recovered even where the source encodes it only indirectly: subclasses that exist in JC3IEDM purely as category-code values — with no attributes or relationships of their own — are minted as OWL classes in their own right, under the entity that owns the code. Attribute datatypes map onto standard XSD types, and attributes that range over a code list become object properties whose range is an enumeration class built from the very XSD file the model’s maintainers already ship — one named individual per code value, each keeping its English-text meaning as an annotation.
Names a person can still read
JC3IEDM reuses relationship names like “has” across many entity pairs, so unique identifiers had to be generated — and the pipeline refuses the easy answer of long mechanical concatenations. Class names are abbreviated systematically, disambiguation is applied only where a clash actually occurs, and the one abbreviation collision in the entire model was caught and resolved explicitly. Because the generated ontology is consistency-checked on every regeneration, a future clash cannot slip through silently. Inverse relationships are declared as such, and the source model’s cardinality codes are carried into OWL as cardinality restrictions and functional-property declarations rather than being dropped.
What this result is — and is not
The claims stop where the paper stops. The consistency check reported above — run over the full five-file output: entities, attributes, relations, codes, and a top-level file importing them — is the only validation in the paper; no reasoning benchmark was run. The authors are candid that the full ontology “would likely be a challenge to the processing capabilities of most RDF/OWL reasoners,” and planned subset-import mechanisms for real reasoning tasks. And much of the model’s meaning lives in its English-text definitions, which the lift carries as annotations but does not formalize — the paper calls extending the formal semantics beyond the automated pass “perhaps the most significant open problem,” and it is exactly where expert ontology engineering earns its place on top of automation. This is 2007 work against the MIP model of its day: a capability proof for automated model lifting, not a claim about the current NATO baseline.
A Different Lift for a Different Job
VIStology has built more than one lifter, and honesty requires keeping them apart. The work on this page lifts a data model: a purpose-built XSLT transform over the ERwin XML export of a relational model, in the coalition command-and-control domain — reusable, per the paper, across other ERwin data models “using a similar strategy (and in many cases, the code),” but not schema-agnostic. The Test & Evaluation practice lifts instance documents: on Data Integration for T&E, xVISor’s generic, schema-agnostic lifter builds a TBox from an XSD and an ABox from vendor XML telemetry-configuration documents. Different domain, different machinery, different decade — neither result is evidence for the other, and each page states its own.
Proof Points
JC3IEDM: ERwin to OWL, Automatically
A ~470-line XSLT pipeline lifted NATO's JC3IEDM — 289 entities, 396 relationships, 1,729 attributes, nearly 7,000 value codes — into an OWL ontology that passed consistency checking with zero detected errors. Presented at the 12th ICCRTS, the pipeline re-runs on every model revision and generalizes to any ERwin data model.
Selected Publications
On the Automated Generation of an OWL Ontology Based on the Joint C3 Information Exchange Data Model
12th International Command and Control Research and Technology Symposium
View PublicationRelated
Lift the Model You Already Maintain
If your organization’s hard-won agreements live in a data model no reasoner can use, we can help you lift it into an ontology automatically — and keep the lift current with every revision of the source.
Get in Touch