N-ary Facts and Nominalization in FCO-IM vs RDF and RDF-star

Most data-modeling debates quietly assume a shape before they start. Once you commit to the triple — subject, predicate, object — you have already decided that every fact in the world is binary, and everything that isn't will be bent until it fits. FCO-IM (Fully Communication-Oriented Information Modeling) makes the opposite commitment. It starts from the sentences people actually utter about their domain, and human sentences are stubbornly N-ary. A model built on that footing carries facts of any arity as first-class citizens, and lets whole facts become the subject matter of other facts through nominalization. This short piece walks through why that matters, using one running example, and lines it up against RDF and RDF-star.

A layered model, grounded in communication

FCO-IM is layered, and the layering is the point.

At the bottom sits the concrete layer of fact expressions: real, verbalized sentences supplied by domain experts. Nothing is invented here; the analyst collects communication as it occurs.

Above that is the information grammar, abstracted from those sentences. A fact type is a predicate with a fixed set of roles (predicators). An object type is a class of things that play roles, and a label type connects objects to the names by which we denote them. A fact tuple is a single instance of a fact type — one filled-in sentence.

On top sit the fact constraints: uniqueness, totality (mandatory roles), and set-comparison constraints (subset, equality, exclusion) that range over roles and combinations of roles.

The crucial property is that arity is never fixed at two. A fact type has as many roles as the sentence has open positions — three, five, seven — and constraints are stated over whatever combination of those roles the business rule actually concerns.

N-ary facts, natively

Take one sentence from a clinical domain:

On 2026-03-14, physician Vialli prescribed 500 mg of Amoxicillin to patient Marco, three times daily, for 7 days.

That is a single, atomic unit of communication with seven roles: date, physician, dose, drug, patient, frequency, duration. In FCO-IM it is one fact type, verbalized directly from the sentence:

Prescription: On <Date>, physician <Physician> prescribed <Dose> of <Medicine> to patient <Patient>, <Interval>, for <Duration>.

No role is privileged. There is no "subject" that the other six hang off — the drug, the patient, and the physician are peers in the same predicate. And constraints attach to exactly the right combination of roles.

The N-ary fact and the rules about it live in the same layer, in the same vocabulary. The Fact Expression depicting the full nested information grammar shows the full weight of the information communicated: 

Nominalization: a fact that becomes an object

Now suppose the pharmacy needs to talk about that prescription:

Pharmacist Rossi dispensed the above prescription on 2026-03-15.

Here the entire seven-role fact has to appear as a single participant in a new fact. FCO-IM handles this by nominalization (also called objectification): the Prescription fact type is objectified into an object type whose instances are its fact tuples. That object then plays a role in another N-ary fact, exactly like any other object:

Dispension: Pharmacist <Pharmacist> dispensed prescription <Prescription> on <Date>.

The <Prescription> role is filled by a nominalized fact. This is what "facts can be substituted into other facts" means in practice: a whole sentence is packaged as a thing and dropped into another sentence, without flattening it, without losing its identity, and without losing the constraints that governed it. You can nominalize a nominalization, stack facts about facts about facts, and every level remains N-ary and constrainable.

RDF: everything is binary, so nothing is whole

RDF has exactly one construction: the binary triple subject predicate object. Our seven-role prescription cannot be stated as one thing. You reify it — invent an anchoring resource and scatter the fact across seven triples:

_:presc a :Prescription ; :date "2026-03-14" ; :physician :Vialli ; :dose "500mg" ; :drug :Amoxicillin ; :patient :Marco ; :frequency "3x daily" ; :duration "7 days" .

Three things have quietly gone wrong. First, the fact's identity is an artifact: _:presc is a blank node that exists only because the graph could not hold an N-ary shape. Second, the atomic fact is now a pattern, not an object — "the prescription" is whatever set of triples happen to share that node, and nothing in RDF guarantees they stay together or complete. Third, the constraints are homeless. RDF itself expresses none; the "same drug, same day, same patient" rule has to move out to SHACL or OWL, and a uniqueness rule over a combination of three properties is awkward even there, because those languages also think one property at a time.

RDF-star: reification embedded, but still binary at the core

RDF-star (now folding into RDF 1.2 as triple terms) improves the ergonomics of statements about statements. A triple can be quoted and used as the subject or object of another triple:

<< :Marco :wasPrescribed :Amoxicillin >> :by :Vialli ; :dose "500mg" ; :on "2026-03-14" ; :frequency "3x daily" ; :duration "7 days" .

For provenance and annotation — "this statement was asserted by X, valid on date Y" — this is genuinely better than classic reification, and the quoted-versus-asserted distinction (a triple term can be referenced without being claimed true) is a real expressive gain.

But look at what the N-ary fact was forced to become. Some single binary triple — here :Marco :wasPrescribed :Amoxicillin — had to be nominated as the base, and the other five roles were demoted to annotations hanging off it. That choice is arbitrary: why is (Marco, Amoxicillin) the core rather than (Vialli, Amoxicillin) or (Marco, Vialli)? A genuinely N-ary fact has no natural binary heart, so any RDF-star encoding smuggles in an asymmetry the domain never had. RDF-star embeds reification into the syntax, which is elegant, but it does not raise the arity. The base is still two slots; everything past the second is metadata by convention. And, like plain RDF, it adds no constraint language of its own.

Contrast this with FCO-IM nominalization. RDF-star lets a binary triple be a term. FCO-IM lets an N-ary fact type be an object type — one that plays full roles in further N-ary facts and carries its own uniqueness and totality constraints. One is quoting a statement; the other is promoting a fact to a first-class, symmetric, constrainable participant.

Side by side

Generation runs downhill

None of this makes RDF the enemy — and with a tool like CaseTalk, generating RDF from an FCO-IM model is easy, precisely because the model has already broken every expression down to a smaller grain. By the time you have an information grammar, each N-ary fact type is fully resolved into its roles, and each role already knows its object type and its label type. The finer, binary structure that RDF wants is not something you have to reverse-engineer; it is sitting there explicitly in the grammar.

So the mapping is mechanical. Each role of a fact type becomes a predicate. Each N-ary fact tuple becomes an anchoring resource carrying one binary triple per role — and because the fact type can be nominalized, that anchor gets a real, meaningful identity (a proper URI) instead of an anonymous blank node. The label types tell the generator exactly where literals belong and where object references belong, so there is no guessing about datatypes or IRIs. And because the fact constraints are captured in the same model, the uniqueness and totality rules can be emitted as SHACL shapes alongside the triples, rather than being hand-written after the fact.

The direction is what matters. Going from N-ary facts down to binary triples is a lossless projection: the source model holds strictly more information than the target, so the transform is deterministic and automatable. Going the other way — reconstructing which scattered triples were once a single seven-role fact, and what its arity and constraints were — is guesswork. FCO-IM sits upstream of RDF, relational schemas, and JSON alike; each of those is a generated view. You author once, in the language your domain experts actually speak, and let the tool project it into whatever binary substrate a given system needs.

Why it matters

The difference is not cosmetic. Because FCO-IM begins with communication rather than with a storage primitive, arity is dictated by the sentence, not by the serialization. A seven-role fact stays one fact; a rule about three of its roles stays one rule; and when you need to talk about the fact as a whole, nominalization hands you the whole thing, intact, to drop into the next sentence. RDF and RDF-star can encode all of this — they are, after all, general graph substrates — but they encode it by decomposition, and decomposition is exactly where fact identity, role symmetry, and combined-role constraints leak away. Triples are a fine transport. They are a lossy model of a world that talks in N-ary sentences.

If your data genuinely is binary — links between two resources, annotated occasionally with provenance — RDF-star is a clean, capable tool. But the moment your domain experts say a sentence with three or more open slots, and then start saying sentences about that sentence, you are modeling N-ary facts and nominalizations whether you admit it or not. FCO-IM's advantage is simply that it admits it from the first line.