Computed and entailed values

Semogram has two distinct forms of inference. An inferred binding computes an output using a supported CEL expression over named bound inputs. Ontology entailment applies a bounded named-term relation profile to an ontology query when explicitly enabled. Neither is an unrestricted OWL reasoner or an automatic AI prediction.

You need a Semogram account with access to the workspace and a project in it. Definition and binding changes, query publication, execution and assertion review require their respective permissions. External reads and writes also require the selected plugin installation's credentials and access.

Computed example: is this order open?

Use the complete operations model, with Order, status and isOpen terms under https://example.com/operations#. An Active root binding supplies orders; an Active property binding supplies string status. For a live Postgres fixture, entity 1 has status open and entity 2 has status delivered. The source endpoint uses Postgres read with database connection credentials on the installation.

Create an Active Inferred Property binding for https://example.com/operations#isOpen, selecting the same compiled package/version and a compatible source endpoint, expected values One. Configure:

Bind https://example.com/operations#isOpen as a computed property using the status term and CEL status == "open". Select the real compiled package/version and compatible endpoint. Check dependency bindings and cycles; show validation before saving.

{
  "inputs": {
    "status": "https://example.com/operations#status"
  },
  "expression": {
    "language": "cel",
    "body": "status == \"open\""
  }
}

Add is_open: { term_ref: "https://example.com/operations#isOpen" } to the complete Order query output mapping and declare a boolean output. Validate, save and publish that revision. Expect true for the open order and false for the delivered order. Missing inputs and conflicting scalar inputs need handling in the definition; do not invent a value from an unrelated row.

Input aliases must be valid identifiers and reference nonempty terms. Dependencies must resolve; cycles fail. Supported function packs are checked rather than downloaded arbitrarily. Restriction/masking on input terms propagates to derived outputs.

Ontology entailment profile

Set target.inference: rdfs-owl-relations-v1 in a complete query with an explicit ontology package ID when named-term entailment is wanted. This profile supports subclass/subproperty propagation, equivalent classes/properties, inverse relationships, domain/range class membership and named symmetric/transitive relationships.

For example, if DeliveredOrder is a named subclass of Order, stored DeliveredOrder membership can contribute to an Order read under that profile. These are model-declared relation rules, not generated business judgments. Anonymous class expressions are outside the profile; bounded fact expansion applies. Inspect the resulting bindings, source snapshots and diagnostics.

Do not enable inference merely to conceal a missing source binding. A computed binding still needs data for its dependencies, and an entailed query still needs accessible source facts.