Package ai.chatur.cortex.core.ingest

Class IngestService

java.lang.Object
ai.chatur.cortex.core.ingest.IngestService
public class IngestService extends Object
Validates incoming RDF assertions and stages them on a new branch pending review.

Incoming assertions are linted against the ontology, validated against SHACL shapes together with the approved assertions, trimmed of triples already approved, and staged on a branch — a named graph within the assertions dataset. Every branch carries a provenance activity recording the ingestion, built by the ProvenanceRecorder. Reviewing, editing, and resolving a branch once it is staged are the jobs of core.branch's services, not this one.

  • Constructor Details

    • IngestService

      public IngestService(org.apache.jena.query.Dataset assertions, LintService lintService, ProvenanceRecorder provenanceRecorder)
      Creates the service.
      Parameters:
      assertions - the dataset holding the approved assertions and the staged branches
      lintService - the lint check and SHACL validation incoming assertions must pass
      provenanceRecorder - builds the provenance activity recorded when a branch is staged

  • Method Details

    • ingest

      public ai.chatur.cortex.IngestResult ingest(String ttl)
      Lints and validates the given assertions and stages them on a new branch.

      Assertions that cannot be parsed, fail the lint check against the ontology, or do not conform to the shapes are not staged; the problem is reported in the result instead. The shapes are validated against the union of the approved assertions and the incoming ones, so incoming assertions may rely on already approved statements to conform.

      Incoming triples already present among the approved assertions are trimmed before staging, so a branch only ever carries novel statements. If every triple is already approved, nothing is staged and the result carries no branch. The staged branch also carries a provenance activity recording when the ingestion was staged.

      The SHACL validation, the novelty diff, and the staging write all happen inside one write transaction on the assertions dataset, so a concurrent approve landing between the validation and the write can no longer make either stale: TDB2 serializes writers, so this ingestion either sees the approval's result in full (and validates and diffs against it) or runs entirely before it. Parsing the incoming Turtle happens first, outside the transaction, since it depends on nothing from the dataset.

      Parameters:
      ttl - RDF assertions in Turtle syntax
      Returns:
      the outcome, carrying either the name of the created branch — null if every triple was already approved — or the errors