eyeling 1.26.6 → 1.27.0

package/examples/rdf-message-cold-chain-recall.n3

@@ -0,0 +1,229 @@
+# =================================
+# RDF Message Cold Chain Recall
+# =================================
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-message-cold-chain-recall.n3 examples/input/rdf-message-cold-chain-recall.trig
+#
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
+# This example is meant to be operationally obvious: a cold-chain shipment has
+# many historical telemetry messages, a checkpoint says which prefix was already
+# processed, and the new tail contains inconsistent evidence about whether a
+# medicine batch stayed below its temperature limit.  The repair keeps the
+# calibrated logger reading before materializing a recall/quarantine decision.
+
+@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-cold-chain-recall#>.
+@prefix eymsg: <https://eyereasoner.github.io/eyeling/vocab/message#>.
+@prefix ldes: <https://w3id.org/ldes#>.
+@prefix tree: <https://w3id.org/tree#>.
+@prefix list: <http://www.w3.org/2000/10/swap/list#>.
+@prefix log: <http://www.w3.org/2000/10/swap/log#>.
+@prefix math: <http://www.w3.org/2000/10/swap/math#>.
+@prefix string: <http://www.w3.org/2000/10/swap/string#>.
+
+# Parser replay gives us an ordered RDF Message stream.  Keep this visible in
+# the derived data so the report can say how many messages were processed.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:envelope ?Envelope.
+  ?Envelope a eymsg:MessageEnvelope;
+    eymsg:offset ?Offset.
+} => {
+  ?Envelope :messageOffset ?Offset;
+    :messageBoundaryExplicit true.
+}.
+
+# Message 1 carries stream metadata and the consumer checkpoint.  Everything up
+# to sequence 42 was already materialized by a previous synchronization run.
+{
+  ?Envelope eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :telemetryStream a ldes:EventStream;
+      ldes:timestampPath :observedAt;
+      ldes:sequencePath :sequence;
+      tree:view :telemetryPage;
+      :lastCommittedSequence ?Bookmark;
+      :currentWindowFromSequence ?WindowStart;
+      :temperatureLimitTenthC ?Limit;
+      :temperatureLimitLabel ?LimitLabel;
+      :repairPolicy :preferCalibratedLogger.
+    :quarantineDecision :decisionText ?DecisionText.
+  }.
+} => {
+  :telemetryStream a ldes:EventStream;
+    ldes:timestampPath :observedAt;
+    ldes:sequencePath :sequence;
+    tree:view :telemetryPage;
+    :lastCommittedSequence ?Bookmark;
+    :currentWindowFromSequence ?WindowStart;
+    :temperatureLimitTenthC ?Limit;
+    :temperatureLimitLabel ?LimitLabel;
+    :repairPolicy :preferCalibratedLogger.
+  :quarantineDecision :decisionText ?DecisionText.
+}.
+
+# Each RDF Message payload contributes one LDES telemetry member.  The payloads
+# stay scoped to their message graphs; the reasoner lifts only the fields needed
+# for incremental classification, repair, and reporting.
+{
+  ?Envelope eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :telemetryStream tree:member ?Member.
+    ?Member a :ColdChainObservation;
+      :sequence ?Sequence;
+      :observedAt ?ObservedAt;
+      :batch ?Batch;
+      :temperatureTenthC ?Temperature;
+      :temperatureLabel ?TemperatureLabel;
+      :priority ?Priority;
+      :source ?Source.
+  }.
+} => {
+  ?Member :ldesMember true;
+    :envelope ?Envelope;
+    :sequence ?Sequence;
+    :observedAt ?ObservedAt;
+    :batch ?Batch;
+    :temperatureTenthC ?Temperature;
+    :temperatureLabel ?TemperatureLabel;
+    :priority ?Priority;
+    :source ?Source.
+  ?Envelope :emitsLDESMember ?Member.
+}.
+
+
+# Carry optional calibration metadata when a telemetry member has it.  Most
+# sensors do not; the calibrated logger in the noisy tail does.
+{
+  ?Envelope eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    ?Member :calibrationClass ?CalibrationClass.
+  }.
+} => {
+  ?Member :calibrationClass ?CalibrationClass.
+}.
+
+# The checkpoint separates the large committed prefix from the new tail.
+{
+  :telemetryStream :lastCommittedSequence ?Bookmark.
+  ?Member :ldesMember true;
+    :sequence ?Sequence.
+  ?Sequence math:notGreaterThan ?Bookmark.
+} => {
+  ?Member :alreadyCommitted true.
+}.
+
+{
+  :telemetryStream :lastCommittedSequence ?Bookmark.
+  ?Member :ldesMember true;
+    :sequence ?Sequence.
+  ?Sequence math:greaterThan ?Bookmark.
+} => {
+  ?Member :newlyEmitted true.
+}.
+
+{
+  :telemetryStream :currentWindowFromSequence ?WindowStart.
+  ?Member :newlyEmitted true;
+    :sequence ?Sequence.
+  ?Sequence math:notLessThan ?WindowStart.
+} => {
+  :currentColdChainWindow :contains ?Member.
+  ?Member :inCurrentColdChainWindow true.
+}.
+
+# The raw tail is inconsistent for batchA: some new telemetry says the batch is
+# still within range, while another message says it crossed the cold-chain limit.
+{
+  :telemetryStream :temperatureLimitTenthC ?Limit.
+  :currentColdChainWindow :contains ?InRangeMember, ?ExcursionMember.
+  ?InRangeMember :batch ?Batch;
+    :temperatureTenthC ?InRangeTemperature.
+  ?ExcursionMember :batch ?Batch;
+    :temperatureTenthC ?ExcursionTemperature.
+  ?InRangeTemperature math:notGreaterThan ?Limit.
+  ?ExcursionTemperature math:greaterThan ?Limit.
+  ?InRangeMember log:notEqualTo ?ExcursionMember.
+} => {
+  :currentColdChainWindow :rawConflict :batchBothInRangeAndInExcursion;
+    :inconsistentBatch ?Batch.
+}.
+
+# Preferred repair: calibrated cold-chain logger evidence wins for recall
+# decisions.  In this example it says batchA exceeded the temperature limit.
+{
+  :telemetryStream :temperatureLimitTenthC ?Limit.
+  :currentColdChainWindow :rawConflict :batchBothInRangeAndInExcursion;
+    :contains ?PreferredMember.
+  ?PreferredMember :batch ?Batch;
+    :temperatureTenthC ?PreferredTemperature;
+    :temperatureLabel ?PreferredTemperatureLabel;
+    :priority ?PreferredPriority;
+    :source ?PreferredSource;
+    :sequence ?PreferredSequence;
+    :calibrationClass :calibratedLogger.
+  ?PreferredTemperature math:greaterThan ?Limit.
+} => {
+  :currentColdChainWindow :preferredRepair :calibratedLoggerWins;
+    :repairedBatch ?Batch;
+    :preferredEvidence ?PreferredMember;
+    :preferredSource ?PreferredSource;
+    :preferredSequence ?PreferredSequence;
+    :preferredPriority ?PreferredPriority;
+    :repairedTemperatureTenthC ?PreferredTemperature;
+    :repairedTemperatureLabel ?PreferredTemperatureLabel;
+    :materializedDecision :quarantineDecision.
+}.
+
+# Count the whole stream and the incremental tail.  The interesting point is
+# that the input is large enough to make streaming useful, while the repair is
+# local to the new messages after the checkpoint.
+{
+  ( ?Member { ?Member :ldesMember true. } ?AllMembers ) log:collectAllIn _:coldChainCounts.
+  ?AllMembers list:length ?AllCount.
+  ( ?Member { ?Member :alreadyCommitted true. } ?CommittedMembers ) log:collectAllIn _:coldChainCounts.
+  ?CommittedMembers list:length ?CommittedCount.
+  ( ?Member { ?Member :newlyEmitted true. } ?NewMembers ) log:collectAllIn _:coldChainCounts.
+  ?NewMembers list:length ?NewCount.
+  ( ?Member { ?Member :inCurrentColdChainWindow true. } ?WindowMembers ) log:collectAllIn _:coldChainCounts.
+  ?WindowMembers list:length ?WindowCount.
+} => {
+  :incrementalColdChainRun :totalTelemetryMembers ?AllCount;
+    :alreadyCommittedMembers ?CommittedCount;
+    :newlyEmittedMembers ?NewCount;
+    :windowMemberCount ?WindowCount.
+}.
+
+# Emit one compact report when replay, checkpointing, conflict detection, repair,
+# and final materialization are all present.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:orderedEnvelopes ?Envelopes.
+  ?Envelopes list:length ?EnvelopeCount.
+  :telemetryStream :lastCommittedSequence ?Bookmark;
+    :temperatureLimitTenthC ?Limit;
+    :temperatureLimitLabel ?LimitLabel.
+  :incrementalColdChainRun :totalTelemetryMembers ?AllCount;
+    :alreadyCommittedMembers ?CommittedCount;
+    :newlyEmittedMembers ?NewCount;
+    :windowMemberCount ?WindowCount.
+  :currentColdChainWindow :rawConflict :batchBothInRangeAndInExcursion;
+    :inconsistentBatch :batchA;
+    :preferredRepair :calibratedLoggerWins;
+    :preferredSource ?PreferredSource;
+    :preferredSequence ?PreferredSequence;
+    :preferredPriority ?PreferredPriority;
+    :repairedTemperatureLabel ?PreferredTemperatureLabel;
+    :materializedDecision :quarantineDecision.
+  :quarantineDecision :decisionText ?DecisionText.
+  ("# rdf-message-cold-chain-recall\n\n## Source files\n\n- [N3 rules](../rdf-message-cold-chain-recall.n3)\n- [Input RDF Message Log](../input/rdf-message-cold-chain-recall.trig)\n- [Story deck](../deck/rdf-message-cold-chain-recall.md)\n\n## Answer\nCold-chain recall reasoning accepted: %d RDF Message envelopes contained %d append-only telemetry members. The consumer checkpoint was sequence %d, so %d committed history members were skipped and only %d newly emitted members entered the repair window. The tail window has %d members and says batchA is both within range and over the %s limit. The repair keeps the calibrated logger evidence at sequence %d from %s with priority %d, resolves the repaired temperature to %s, and materializes the decision: %s.\n\n## Explanation\nThis is the streaming shape that matters operationally. A cold-chain consumer can replay a long RDF Message Log, use LDES sequence metadata to resume after its checkpoint, and inspect only the new tail. The raw tail is contradictory, so the rules do not materialize from the flattened data. They first choose the calibrated logger reading, then derive the quarantine decision from that repaired state." ?EnvelopeCount ?AllCount ?Bookmark ?CommittedCount ?NewCount ?WindowCount ?LimitLabel ?PreferredSequence ?PreferredSource ?PreferredPriority ?PreferredTemperatureLabel ?DecisionText) string:format ?Block.
+} => {
+  :rdfMessageColdChainRecallExample log:outputString ?Block.
+  :rdfMessageColdChainRecallExample :demonstrates :RDFMessageLogReplay, :LDESMemberStream, :CheckpointedSynchronization, :IncrementalColdChainReasoning, :TelemetryConflictRepair, :QuarantineMaterialization.
+}.

package/examples/rdf-message-flow.n3

@@ -6,6 +6,9 @@
 #
 #   eyeling -r examples/rdf-message-flow.n3 examples/input/rdf-message-flow.trig
 #
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
 # Motivation
 # ----------
 # The RDF Messages draft describes an RDF Message as an RDF dataset interpreted

package/examples/rdf-message-ldes-incremental.n3

@@ -0,0 +1,231 @@
+# =====================================
+# RDF Message LDES Incremental Repair
+# =====================================
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-message-ldes-incremental.n3 examples/input/rdf-message-ldes-incremental.trig
+#
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
+# This example combines two streaming ideas:
+#
+# - RDF Messages give parser-level message boundaries for a potentially long
+#   stream.  Eyeling replays those boundaries as eymsg: envelopes and keeps each
+#   payload graph separate.
+# - LDES describes an append-only stream of members with a timestamp/sequence
+#   order.  The rules below model an incremental consumer that has already
+#   committed sequence 34, so it only reasons over the new tail of the log.
+#
+# The input intentionally contains forty LDES members.  Only the six members
+# after the checkpoint are part of the current incremental repair window.  That
+# tail contains a concrete inconsistency: the same door is both open and closed.
+# The repair keeps the highest-priority assertion before materializing the
+# operational action.
+
+@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-ldes-incremental#>.
+@prefix eymsg: <https://eyereasoner.github.io/eyeling/vocab/message#>.
+@prefix ldes: <https://w3id.org/ldes#>.
+@prefix tree: <https://w3id.org/tree#>.
+@prefix list: <http://www.w3.org/2000/10/swap/list#>.
+@prefix log: <http://www.w3.org/2000/10/swap/log#>.
+@prefix math: <http://www.w3.org/2000/10/swap/math#>.
+@prefix string: <http://www.w3.org/2000/10/swap/string#>.
+
+# Eyeling's RDF-message replay gives us a static, ordered view of a message log.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:envelope ?Envelope.
+  ?Envelope a eymsg:MessageEnvelope;
+    eymsg:offset ?Offset.
+} => {
+  ?Envelope :messageOffset ?Offset;
+    :messageBoundaryExplicit true.
+}.
+
+# Message 1 carries LDES context and the incremental consumer state.  The LDES
+# bookmark is the key point: everything up to sequence 34 was already committed
+# by the previous synchronization run.
+{
+  ?Envelope eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :doorStream a ldes:EventStream;
+      ldes:timestampPath :observedAt;
+      ldes:sequencePath :sequence;
+      tree:view :doorStreamPage;
+      :lastCommittedSequence ?Bookmark;
+      :currentWindowFromSequence ?WindowStart;
+      :windowSize ?WindowSize;
+      :repairPolicy :preferHigherPriority.
+    :open :stateText ?OpenStateText;
+      :actionText ?OpenAction.
+    :closed :stateText ?ClosedStateText;
+      :actionText ?ClosedAction.
+  }.
+} => {
+  :doorStream a ldes:EventStream;
+    ldes:timestampPath :observedAt;
+    ldes:sequencePath :sequence;
+    tree:view :doorStreamPage;
+    :lastCommittedSequence ?Bookmark;
+    :currentWindowFromSequence ?WindowStart;
+    :windowSize ?WindowSize;
+    :repairPolicy :preferHigherPriority.
+  :open :stateText ?OpenStateText;
+    :actionText ?OpenAction.
+  :closed :stateText ?ClosedStateText;
+    :actionText ?ClosedAction.
+}.
+
+# Each non-configuration RDF Message payload contributes one LDES member.  The
+# rules lift just the metadata needed by the incremental reasoner; the payloads
+# themselves stay scoped to their message graphs.
+{
+  ?Envelope eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :doorStream tree:member ?Member.
+    ?Member a :DoorObservation;
+      :sequence ?Sequence;
+      :observedAt ?ObservedAt;
+      :door ?Door;
+      :doorState ?State;
+      :priority ?Priority;
+      :source ?Source.
+  }.
+} => {
+  ?Member :ldesMember true;
+    :envelope ?Envelope;
+    :sequence ?Sequence;
+    :observedAt ?ObservedAt;
+    :door ?Door;
+    :doorState ?State;
+    :priority ?Priority;
+    :source ?Source.
+  ?Envelope :emitsLDESMember ?Member.
+}.
+
+# The LDES checkpoint lets an incremental consumer skip the large, already
+# committed history.
+{
+  :doorStream :lastCommittedSequence ?Bookmark.
+  ?Member :ldesMember true;
+    :sequence ?Sequence.
+  ?Sequence math:notGreaterThan ?Bookmark.
+} => {
+  ?Member :alreadyCommitted true.
+}.
+
+{
+  :doorStream :lastCommittedSequence ?Bookmark.
+  ?Member :ldesMember true;
+    :sequence ?Sequence.
+  ?Sequence math:greaterThan ?Bookmark.
+} => {
+  ?Member :newlyEmitted true.
+}.
+
+# The current incremental repair window is the new tail after the checkpoint.
+{
+  :doorStream :currentWindowFromSequence ?WindowStart.
+  ?Member :newlyEmitted true;
+    :sequence ?Sequence.
+  ?Sequence math:notLessThan ?WindowStart.
+} => {
+  :currentLDESWindow :contains ?Member.
+  ?Member :inCurrentLDESWindow true.
+}.
+
+# Raw tail materialization is inconsistent: the same door is open and closed in
+# the new LDES members.
+{
+  :currentLDESWindow :contains ?OpenMember, ?ClosedMember.
+  ?OpenMember :door ?Door;
+    :doorState :open.
+  ?ClosedMember :door ?Door;
+    :doorState :closed.
+  ?OpenMember log:notEqualTo ?ClosedMember.
+} => {
+  :currentLDESWindow :rawConflict :doorOpenAndClosed;
+    :inconsistentDoor ?Door.
+}.
+
+# Preferred repair: keep the higher-priority assertion when the current tail
+# contains conflicting LDES members for the same door.
+{
+  :currentLDESWindow :contains ?PreferredMember, ?RejectedMember;
+    :rawConflict :doorOpenAndClosed.
+  ?PreferredMember :doorState ?PreferredState;
+    :priority ?PreferredPriority;
+    :source ?PreferredSource;
+    :sequence ?PreferredSequence.
+  ?RejectedMember :doorState ?RejectedState;
+    :priority ?RejectedPriority.
+  ?PreferredState log:notEqualTo ?RejectedState.
+  ?PreferredPriority math:greaterThan ?RejectedPriority.
+} => {
+  :currentLDESWindow :preferredRepairState ?PreferredState;
+    :preferredEvidence ?PreferredMember;
+    :preferredSource ?PreferredSource;
+    :preferredSequence ?PreferredSequence;
+    :preferredPriority ?PreferredPriority;
+    :rejectsLowerPriority ?RejectedMember;
+    :repairsInconsistency :doorOpenAndClosed;
+    :resolvedDoorState ?PreferredState.
+}.
+
+# Materialize from the repaired state, not from the inconsistent raw window.
+{
+  :currentLDESWindow :preferredRepairState ?State.
+  ?State :actionText ?ActionText.
+} => {
+  :currentLDESWindow :materializedActionText ?ActionText.
+}.
+
+# Count the stream and the incremental tail.  These counts are useful in the
+# report because they show that the example input has lots of historical data,
+# but the reasoning focus is the tail after the LDES bookmark.
+{
+  ( ?Member { ?Member :ldesMember true. } ?AllMembers ) log:collectAllIn _:ldesCounts.
+  ?AllMembers list:length ?AllCount.
+  ( ?Member { ?Member :alreadyCommitted true. } ?CommittedMembers ) log:collectAllIn _:ldesCounts.
+  ?CommittedMembers list:length ?CommittedCount.
+  ( ?Member { ?Member :newlyEmitted true. } ?NewMembers ) log:collectAllIn _:ldesCounts.
+  ?NewMembers list:length ?NewCount.
+  ( ?Member { ?Member :inCurrentLDESWindow true. } ?WindowMembers ) log:collectAllIn _:ldesCounts.
+  ?WindowMembers list:length ?WindowCount.
+} => {
+  :incrementalRun :totalLDESMembers ?AllCount;
+    :alreadyCommittedMembers ?CommittedCount;
+    :newlyEmittedMembers ?NewCount;
+    :windowMemberCount ?WindowCount.
+}.
+
+# Emit a compact human-readable result only once the parser replay, LDES
+# checkpoint, count aggregation, inconsistency repair, and final materialization
+# are all present.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:orderedEnvelopes ?Envelopes.
+  ?Envelopes list:length ?EnvelopeCount.
+  :doorStream :lastCommittedSequence ?Bookmark;
+    :windowSize ?WindowSize.
+  :incrementalRun :totalLDESMembers ?AllCount;
+    :alreadyCommittedMembers ?CommittedCount;
+    :newlyEmittedMembers ?NewCount;
+    :windowMemberCount ?WindowCount.
+  :currentLDESWindow :rawConflict :doorOpenAndClosed;
+    :inconsistentDoor :doorA;
+    :preferredSource ?PreferredSource;
+    :preferredSequence ?PreferredSequence;
+    :preferredPriority ?PreferredPriority;
+    :resolvedDoorState ?State;
+    :materializedActionText ?ActionText.
+  ?State :stateText ?StateText.
+  ("# rdf-message-ldes-incremental\n\n## Source files\n\n- [N3 rules](../rdf-message-ldes-incremental.n3)\n- [Input RDF Message Log](../input/rdf-message-ldes-incremental.trig)\n- [Story deck](../deck/rdf-message-ldes-incremental.md)\n\n## Answer\nIncremental LDES reasoning accepted: %d RDF Message envelopes contained %d append-only LDES members. The consumer checkpoint was sequence %d, so %d committed history members were skipped and only %d newly emitted members entered the repair window. The tail window has %d members, contains a raw open/closed inconsistency for doorA, repairs it by keeping the priority-%d member at sequence %d from %s, resolves the door state to %s, and materializes the action: %s.\n\n## Explanation\nThe input is deliberately larger than the reasoning task: it serializes many LDES members as RDF Messages, but the LDES sequence bookmark tells the consumer which prefix was already materialized. Eyeling's -r mode replays the RDF Message Log into ordered eymsg: envelopes; the rules inspect each payload with log:includes, classify old versus new members from the LDES sequence path, and run the inconsistency repair only over the new tail. This mirrors an incremental streaming pipeline: append-only publication, resumable synchronization, small repair window, and monotonic output after the noisy tail is fixed." ?EnvelopeCount ?AllCount ?Bookmark ?CommittedCount ?NewCount ?WindowCount ?PreferredPriority ?PreferredSequence ?PreferredSource ?StateText ?ActionText) string:format ?Block.
+} => {
+  :rdfMessageLDESIncrementalExample log:outputString ?Block.
+  :rdfMessageLDESIncrementalExample :demonstrates :RDFMessageLogReplay, :LDESMemberStream, :CheckpointedSynchronization, :IncrementalReasoning, :TailWindowRepair, :RawDoorInconsistency, :PreferredRepair.
+}.

package/examples/rdf-message-microgrid.n3

@@ -6,6 +6,9 @@
 #
 #   eyeling -r examples/rdf-message-microgrid.n3 examples/input/rdf-message-microgrid.trig
 #
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
 # A clinic is running as an islanded microgrid after a storm. Several small
 # systems send RDF data: one message describes life-safety loads, another
 # describes battery and solar status, another describes flexible demand that may

package/examples/rdf-message-window-repair.n3

@@ -0,0 +1,166 @@
+# =========================
+# RDF Message Window Repair
+# =========================
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-message-window-repair.n3 examples/input/rdf-message-window-repair.trig
+#
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
+# This example is inspired by incremental, inconsistency-resilient reasoning over
+# sliding ABox streams.  The input is a true RDF Message Log: each MESSAGE
+# boundary is parsed by Eyeling into an eymsg: envelope with one payload graph per
+# non-empty message.
+#
+# The rules below keep the message boundaries visible, select two overlapping
+# three-message windows, detect that the current window says the same fire door
+# is both open and closed, and repair the inconsistency by keeping the
+# higher-priority safety-controller assertion for the final materialization.
+
+@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-window-repair#>.
+@prefix eymsg: <https://eyereasoner.github.io/eyeling/vocab/message#>.
+@prefix math: <http://www.w3.org/2000/10/swap/math#>.
+@prefix list: <http://www.w3.org/2000/10/swap/list#>.
+@prefix log: <http://www.w3.org/2000/10/swap/log#>.
+@prefix string: <http://www.w3.org/2000/10/swap/string#>.
+
+# Eyeling's parser-level replay gives a static view of the message log: an
+# ordered list, explicit offsets, and next-envelope links.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:envelope ?Message.
+  ?Message a eymsg:MessageEnvelope;
+    eymsg:offset ?Offset.
+} => {
+  ?Message :boundaryExplicit true.
+  ?Message :offset ?Offset.
+}.
+
+# The first payload carries stream policy, like a fixed TBox/configuration that
+# is not itself part of the changing ABox window.
+{
+  ?Message eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :doorA :windowSize ?WindowSize;
+      :repairPolicy :preferHigherPriority.
+    :open :actionText ?OpenAction;
+      :stateText ?OpenStateText.
+    :closed :actionText ?ClosedAction;
+      :stateText ?ClosedStateText.
+  }.
+} => {
+  :doorA :windowSize ?WindowSize;
+    :repairPolicy :preferHigherPriority.
+  :open :actionText ?OpenAction;
+    :stateText ?OpenStateText.
+  :closed :actionText ?ClosedAction;
+    :stateText ?ClosedStateText.
+}.
+
+# With five messages, message 1 is configuration and messages 2-5 are ABox
+# assertions.  The previous and current sliding windows overlap on messages 3
+# and 4; message 2 expires and message 5 enters.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:firstEnvelope ?M1.
+  ?M1 eymsg:nextEnvelope ?M2.
+  ?M2 eymsg:nextEnvelope ?M3.
+  ?M3 eymsg:nextEnvelope ?M4.
+  ?M4 eymsg:nextEnvelope ?M5.
+} => {
+  :previousWindow :contains ?M2, ?M3, ?M4.
+  :currentWindow :contains ?M3, ?M4, ?M5.
+  :windowSlide :expired ?M2;
+    :retained ?M3, ?M4;
+    :entered ?M5.
+}.
+
+# Inspect each message payload inside its own replayed RDF Message graph, then
+# lift only the ABox assertion metadata needed for window reasoning.
+{
+  ?Window :contains ?Message.
+  ?Message eymsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    ?Reading :about :doorA;
+      :doorState ?State;
+      :priority ?Priority;
+      :source ?Source.
+  }.
+} => {
+  ?Message :windowAssertion ?Reading;
+    :doorState ?State;
+    :priority ?Priority;
+    :source ?Source.
+  ?Window :hasDoorState ?State.
+}.
+
+# The current graph-level window is inconsistent: after raw materialization it
+# says the same door is both open and closed.
+{
+  :currentWindow :contains ?OpenMessage, ?ClosedMessage.
+  ?OpenMessage :doorState :open.
+  ?ClosedMessage :doorState :closed.
+} => {
+  :currentWindow :rawConflict :doorOpenAndClosed;
+    :inconsistentDoor :doorA.
+}.
+
+# Preferred repair: if a current-window assertion has higher priority than a
+# conflicting current-window assertion, keep the higher-priority assertion as the
+# one used by materialization.
+{
+  :currentWindow :contains ?PreferredMessage, ?RejectedMessage;
+    :rawConflict :doorOpenAndClosed.
+  ?PreferredMessage :doorState ?PreferredState;
+    :priority ?PreferredPriority;
+    :source ?PreferredSource.
+  ?RejectedMessage :doorState ?RejectedState;
+    :priority ?RejectedPriority.
+  ?PreferredState log:notEqualTo ?RejectedState.
+  ?PreferredPriority math:greaterThan ?RejectedPriority.
+} => {
+  :currentWindow :preferredRepairState ?PreferredState;
+    :preferredEvidence ?PreferredMessage;
+    :preferredSource ?PreferredSource;
+    :rejectsLowerPriority ?RejectedMessage;
+    :repairsInconsistency :doorOpenAndClosed;
+    :resolvedDoorState ?PreferredState.
+}.
+
+# Materialize the final operational conclusion from the repaired state rather
+# than from the inconsistent raw window.
+{
+  :currentWindow :preferredRepairState ?State.
+  ?State :actionText ?ActionText.
+} => {
+  :currentWindow :materializedActionText ?ActionText.
+}.
+
+# Emit a report only when the parser replay, sliding-window bookkeeping, raw
+# conflict, preferred repair, and final materialization were all derived.
+{
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:orderedEnvelopes ?Messages.
+  ?Messages list:length ?Count.
+  :doorA :windowSize ?WindowSize.
+  :previousWindow :contains ?PreviousOnly.
+  :windowSlide :expired ?PreviousOnly;
+    :retained ?Overlap1, ?Overlap2;
+    :entered ?Entered.
+  :currentWindow :rawConflict :doorOpenAndClosed;
+    :inconsistentDoor :doorA;
+    :preferredEvidence ?PreferredMessage;
+    :preferredSource ?PreferredSource;
+    :resolvedDoorState ?State;
+    :materializedActionText ?ActionText.
+  ?State :stateText ?StateText.
+  ?PreferredMessage :priority ?PreferredPriority.
+  ("# rdf-message-window-repair\n\n## Source files\n\n- [N3 rules](../rdf-message-window-repair.n3)\n- [Input RDF Message Log](../input/rdf-message-window-repair.trig)\n- [Story deck](../deck/rdf-message-window-repair.md)\n\n## Answer\nSliding-window RDF Message repair accepted: %d parser-replayed messages produced two overlapping %d-message ABox windows. The current window retained two envelopes from the previous window, expired one old door reading, and added one new safety-controller reading. Its raw graph-level materialization was inconsistent because doorA was both open and closed. The preferred repair kept the priority-%d assertion from %s, resolved the door state to %s, and materialized the action: %s.\n\n## Explanation\nThe RDF Message Log uses VERSION \\\"1.2-messages\\\" and MESSAGE delimiters. Eyeling parses those boundaries into eymsg: envelopes and payload graphs; the rules inspect each payload with log:includes rather than merging message bodies by hand. The example mirrors a sliding-window stream-reasoning pattern: when the window advances, overlapping message evidence is retained, an expired assertion leaves the window, an entering assertion can change the materialization, and a preferred repair fixes a noisy open/closed contradiction before the final action is produced." ?Count ?WindowSize ?PreferredPriority ?PreferredSource ?StateText ?ActionText) string:format ?Block.
+} => {
+  :rdfMessageWindowRepairExample log:outputString ?Block.
+  :rdfMessageWindowRepairExample :demonstrates :RDFMessageLogReplay, :SlidingWindow, :OverlappingWindows, :ABoxStream, :RawDoorInconsistency, :PreferredRepair, :IncrementalMaterialization.
+}.

package/examples/rdf-messages.n3

@@ -6,6 +6,9 @@
 #
 #   eyeling -r examples/rdf-messages.n3 examples/input/rdf-messages.trig
 #
+# See the handbook section on RDF Message Log replay under -r:
+#   https://eyereasoner.github.io/eyeling/HANDBOOK#rdf-message-log-replay-under--r
+#
 # Motivation
 # ----------
 # The RDF Messages draft defines an RDF Message as an RDF dataset interpreted