Skip to content
Follow yggy on LinkedInFollow @yggy_tech on X

Entities & triples

Graph data becomes misleading when a value is attached to the wrong record. A number, date, currency, or unit does not decide its own place. Its meaning does: it can describe an entity, or it can qualify one exact statement.

yggy stores entities as nodes and triples as graph statements. It also stores literal properties on entities and qualifiers on triples. This page helps you choose the right one.

An entity is a thing described by your documents, for example a person, organization, product, place, or concept.

An entity has a label and a type. It can also have aliases, a description, an external identifier, and links to its incoming and outgoing triples.

Examples:

  • Tesla with type organization
  • Alice Chen with type person
  • Q4 report with type document

Entity resolution tries to reuse an existing entity when the same thing appears again. Review can still be necessary when names are ambiguous.

A triple is one relationship in this form:

(subject, predicate, object)

Examples:

  • (Tesla, headquartered_in, Austin)
  • (Alice Chen, employed_by, Acme)
  • (Project Atlas, supersedes, Project Titan)

A triple can link to one or more source documents. It can also store a note, status, confidence, validity dates, extraction method, and source text. These fields are optional, so do not assume that every triple has all of them.

A literal property, also called a data property, stores a typed value about one entity without creating another entity. Use it when the value describes that entity regardless of the particular relationship you are reading.

  • (Inspection INSP-9, sample_size, 30)
  • (Service case CASE-001, occurred_at, "2026-07-29T08:30:00Z")
  • (Product P-17, description, "Replacement pump")

Dates, identifiers, numbers, Boolean values, and descriptive text can use literal properties when the ontology defines their meaning. Each property must use an ontology term; a bare number or date has no shared graph meaning. sample_size is an organization-defined property in this example, so add it to your organization ontology before you map it. Source-specific fields without canonical semantics remain source attributes and stay linked to their source record.

A triple qualifier is metadata on one exact triple. It adds context that is only true for that statement, not for either entity in every situation.

For example, a price can have a currency and pricing basis:

(Tomatoes, has_purchase_price, Measurement "5.30")
[amount: 5.30, currency: EUR, unit: kg]

The measurement is the triple’s object. EUR and kg qualify this purchase-price statement. Storing them directly on Tomatoes would incorrectly imply that every fact about the product uses euro and kilograms. The same product can have a retail price in a different currency or a price per item.

yggy uses qualifiers for amount, currency, unit, the real-world validity period, location context, and extraction confidence. Source evidence and extraction details describe provenance in their own fields. All qualifiers are optional.

An inspection can be an entity and still be the object of a fact:

(Batch B-19, has_inspection, Inspection INSP-9)
(Inspection INSP-9, sample_size, 30)

The first triple says that the batch has an inspection. The second statement stores sample_size as a literal property of that inspection. The sample size is part of the inspection model, but it does not qualify the has_inspection connection itself.

Use a triple qualifier only when a value describes the connection. For example, the unit belongs on a concrete measurement or price statement, not on the inspection entity when the inspection can contain measurements in several units.

Before mapping a source field, ask these questions in order:

  1. Does the value describe one entity regardless of a specific relation? Use a literal property.
  2. Does the value make sense only with one subject-predicate-object statement? Use a triple qualifier.
  3. Does the field have no stable, shared meaning yet? Keep it as a source attribute.

The field name alone does not choose the model. For example, currency can be a literal property for an account’s default currency, or a qualifier for one price assertion.

See Ontology and OWL 2 for how the ontology defines entity relations and literal properties. Open the Graph modeling FAQ for more examples.

  • Graph shows entities as nodes and triples as edges.
  • Data Explorer provides paginated entity, triple, and document tables.
  • Document detail → Triples shows facts associated with one document.
  • Review contains merge suggestions and contradictions that need a decision.

The graph and document views provide different paths to the same records. Use the document view for source context and the graph view for relationships.