Graph modeling FAQ
Graph queries only stay reliable when each value is attached to the thing it actually describes. These answers help you decide whether a source field belongs on an entity, a triple, or only its source record.
How do I choose between a literal property and a triple qualifier?
Section titled “How do I choose between a literal property and a triple qualifier?”Use a literal property when the value describes one entity. Use a triple qualifier when the value only makes sense for one exact statement.
For example, an inspection has a sample size:
(Inspection INSP-9, sample_size, 30)A purchase price has a currency and pricing basis:
(Tomatoes, has_purchase_price, Measurement "5.30") [amount: 5.30, currency: EUR, unit: kg]sample_size describes Inspection INSP-9. currency and unit describe
this one purchase-price statement. If you attached EUR to Tomatoes, a graph
query could wrongly treat every price for that product as euro. The measurement
is the triple’s object; the qualifiers explain that specific measurement.
Can an inspection be both an entity and part of a fact?
Section titled “Can an inspection be both an entity and part of a fact?”Yes. Model the inspection as an entity when it has its own details, then connect it to the batch:
(Batch B-19, has_inspection, Inspection INSP-9)(Inspection INSP-9, sample_size, 30)The first triple is the fact that connects the batch to the inspection. The
sample size remains a property of the inspection. It is not metadata on the
has_inspection relation. sample_size is an organization-defined data
property in this example, so define it in your organization ontology before you
map it.
Is currency always a triple qualifier?
Section titled “Is currency always a triple qualifier?”No. Field names do not determine the model.
Use a literal property when currency means an entity’s default currency. For
example, an organization can define default_currency as a data property:
(Account Acme GmbH, default_currency, EUR)Use a qualifier when it tells you how to interpret one price or measurement:
(Tomatoes, has_retail_price, Measurement "7.99") [amount: 7.99, currency: USD, unit: kg]Use the same rule for units, dates, times, and locations: attach the value to the entity or statement that it actually describes.
How do I place dates and times?
Section titled “How do I place dates and times?”Use a literal property when the date describes an entity or event:
(Machine M-001, installed_at, "2026-07-29")Use a triple qualifier when the date states when a relationship was true:
(Part P-4, part_of, Machine M-001) [valid_from: "2026-07-29"]The machine’s installation date describes the machine. The validity date describes the specific claim that the part belongs to that machine. Do not put firmware versions, numeric bounds, or applicability ranges in validity qualifiers; model them as domain facts instead.
Why not store every source column as a literal property?
Section titled “Why not store every source column as a literal property?”A source column can be local to one file or provider and have no stable meaning outside it. Promoting every column would make the shared ontology noisy and could make unrelated fields look equivalent.
For example, map opened_at to the canonical occurred_at property when it
means when a service case occurred. Keep archive_batch as a source attribute
when it only identifies a row in that source. You retain the original value
without making a claim that every project can interpret it the same way.
Read Entities & triples for the full decision check and Ontology and OWL 2 for the vocabulary rules.