eyeling 1.24.25 → 1.24.26

package/README.md

@@ -3,6 +3,8 @@
 [![npm version](https://img.shields.io/npm/v/eyeling.svg)](https://www.npmjs.com/package/eyeling)
 [![DOI](https://img.shields.io/badge/DOI-10.5281%2Fzenodo.19068086-blue.svg)](https://doi.org/10.5281/zenodo.19068086)
 
+![Eyeling](eyeling.png)
+
 A compact [Notation3 (N3)](https://notation3.org/) reasoner in **JavaScript**.
 
 ## Quick start

package/dist/browser/eyeling.browser.js

@@ -1699,7 +1699,7 @@ function __pushBuiltinDeltaLimited(out, delta, maxResults) {
 
 function __collectListLikeTermsFromTerm(t, out, seen) {
   if (t instanceof ListTerm || t instanceof OpenListTerm) {
-    const k = termFastKey ? termFastKey(t) : null;
+    const k = termFastKey(t);
     if (k === null || !seen.has(k)) {
       if (k !== null) seen.add(k);
       out.push(t);
@@ -11498,6 +11498,20 @@ class Parser {
     if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'a') {
       this.next();
       pred = internIri(RDF_NS + 'type');
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'has') {
+      // N3 syntactic sugar is also valid in predicate-object lists,
+      // including blank node property lists: [ has :p :o ] means _:b :p :o.
+      this.next();
+      pred = this.parseTerm();
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'is') {
+      // N3 syntactic sugar: [ is :p of :s ] means :s :p _:b.
+      this.next();
+      pred = this.parseTerm();
+      if (!(this.peek().typ === 'Ident' && (this.peek().value || '') === 'of')) {
+        this.fail(`Expected 'of' after 'is <expr>', got ${this.peek().toString()}`);
+      }
+      this.next();
+      invert = true;
     } else if (this.peek().typ === 'OpPredInvert') {
       this.next();
       pred = this.parseTerm();

package/examples/input/rdf-message-flow.trig

@@ -1,5 +1,29 @@
+# ==============================
+# RDF Message Flow input sidecar
+# ==============================
+#
+# This file is the data half of the runnable example:
+#
+#   eyeling -r examples/rdf-message-flow.n3 examples/input/rdf-message-flow.trig
+#
+# It is intentionally plain TriG rather than a parser-level RDF Message Log with
+# VERSION "1.2-messages" and MESSAGE delimiters. The RDF Messages draft says an
+# RDF Message is an RDF dataset interpreted atomically, that a stream is an
+# ordered sequence of such messages, and that messages in a stream should not be
+# combined by default. To demonstrate those ideas in Eyeling today, the default
+# graph below contains example-local envelope records (:m001 ... :m005) and each
+# non-empty message payload is placed in its own named graph (in:payload001 ...
+# in:payload005).
+#
+# The envelope IRIs are not identifiers for RDF Messages defined by the spec;
+# they are application-level records used by the flow-control rules. The named
+# payload graphs are the datasets/messages being interpreted atomically. The
+# third envelope is an empty heartbeat, which is valid because RDF Messages may
+# be empty. Blank node labels are kept unique because this sidecar is ordinary
+# TriG; a true RDF Message Log parser would reset blank-node scope per MESSAGE.
+
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-flow#> .
-@prefix msg: <https://example.org/msg#> .
+@prefix flow: <https://eyereasoner.github.io/eyeling/examples/rdf-message-flow/vocab#> .
 @prefix prov: <http://www.w3.org/ns/prov#> .
 @prefix sosa: <http://www.w3.org/ns/sosa/> .
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@@ -10,77 +34,87 @@
 @prefix see: <https://example.org/see#> .
 @prefix in: <https://example.org/see/input#> .
 
-# Formal Eyeling input evidence in RDF 1.2 TriG.
-# The generated runner reads this TriG evidence directly.
-
-:temperatureFlow a msg:MessageStream .
-:temperatureFlow msg:orderedMessages (:m001 :m002 :m003 :m004 :m005) .
-:temperatureFlow msg:message :m001 .
-:temperatureFlow msg:message :m002 .
-:temperatureFlow msg:message :m003 .
-:temperatureFlow msg:message :m004 .
-:temperatureFlow msg:message :m005 .
+:temperatureFlow a flow:RDFMessageStream .
+:temperatureFlow flow:orderedEnvelopes (:m001 :m002 :m003 :m004 :m005) .
+:temperatureFlow flow:envelope :m001 .
+:temperatureFlow flow:envelope :m002 .
+:temperatureFlow flow:envelope :m003 .
+:temperatureFlow flow:envelope :m004 .
+:temperatureFlow flow:envelope :m005 .
+:temperatureFlow :producer :thermometerA .
+:temperatureFlow :consumer :flowProcessor .
 :temperatureFlow :pipeline (:ingest :validate :interpret :route :sink) .
 :temperatureFlow :highThreshold 26 .
+
+:thermometerA a flow:StreamProducer .
+:flowProcessor a flow:StreamConsumer .
+:archiveSink a flow:StreamConsumer .
+:alertSink a flow:StreamConsumer .
+:heartbeatSink a flow:StreamConsumer .
+
+:m001 a flow:MessageEnvelope .
 :m001 :atStage :ingest .
-:m001 a msg:RDFMessage .
-:m001 msg:offset 1 .
-:m001 msg:nextMessage :m002 .
-:m001 prov:generatedAtTime "2026-05-12T18:20:00Z" .
-:m001 msg:payloadKind :observation .
-:m001 msg:expectedResult 21 .
-:m001 msg:payload in:formula1 .
-:m002 a msg:RDFMessage .
-:m002 msg:offset 2 .
-:m002 msg:nextMessage :m003 .
-:m002 prov:generatedAtTime "2026-05-12T18:21:00Z" .
-:m002 msg:payloadKind :observation .
-:m002 msg:expectedResult 22 .
-:m002 msg:payload in:formula2 .
-:m003 a msg:RDFMessage .
-:m003 msg:offset 3 .
-:m003 msg:nextMessage :m004 .
-:m003 prov:generatedAtTime "2026-05-12T18:22:00Z" .
-:m003 msg:payloadKind :heartbeat .
-:m004 a msg:RDFMessage .
-:m004 msg:offset 4 .
-:m004 msg:nextMessage :m005 .
-:m004 prov:generatedAtTime "2026-05-12T18:23:00Z" .
-:m004 msg:payloadKind :observation .
-:m004 msg:expectedResult 28 .
-:m004 msg:payload in:formula3 .
-:m005 a msg:RDFMessage .
-:m005 msg:offset 5 .
-:m005 prov:generatedAtTime "2026-05-12T18:24:00Z" .
-:m005 msg:payloadKind :observation .
-:m005 msg:expectedResult 29 .
-:m005 msg:payload in:formula4 .
+:m001 flow:offset 1 .
+:m001 flow:nextEnvelope :m002 .
+:m001 prov:generatedAtTime "2026-05-12T18:20:00Z"^^xsd:dateTime .
+:m001 flow:payloadKind :observation .
+:m001 flow:expectedResult 21 .
+:m001 flow:payloadGraph in:payload001 .
+
+:m002 a flow:MessageEnvelope .
+:m002 flow:offset 2 .
+:m002 flow:nextEnvelope :m003 .
+:m002 prov:generatedAtTime "2026-05-12T18:21:00Z"^^xsd:dateTime .
+:m002 flow:payloadKind :observation .
+:m002 flow:expectedResult 22 .
+:m002 flow:payloadGraph in:payload002 .
+
+:m003 a flow:MessageEnvelope .
+:m003 flow:offset 3 .
+:m003 flow:nextEnvelope :m004 .
+:m003 prov:generatedAtTime "2026-05-12T18:22:00Z"^^xsd:dateTime .
+:m003 flow:payloadKind :heartbeat .
+
+:m004 a flow:MessageEnvelope .
+:m004 flow:offset 4 .
+:m004 flow:nextEnvelope :m005 .
+:m004 prov:generatedAtTime "2026-05-12T18:23:00Z"^^xsd:dateTime .
+:m004 flow:payloadKind :observation .
+:m004 flow:expectedResult 28 .
+:m004 flow:payloadGraph in:payload004 .
+
+:m005 a flow:MessageEnvelope .
+:m005 flow:offset 5 .
+:m005 prov:generatedAtTime "2026-05-12T18:24:00Z"^^xsd:dateTime .
+:m005 flow:payloadKind :observation .
+:m005 flow:expectedResult 29 .
+:m005 flow:payloadGraph in:payload005 .
 
-in:formula1 {
+in:payload001 {
   _:m001b0 a sosa:Observation .
   _:m001b0 sosa:madeBySensor :thermometerA .
-  _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z" .
+  _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z"^^xsd:dateTime .
   _:m001b0 sosa:hasSimpleResult 21 .
 }
 
-in:formula2 {
+in:payload002 {
   _:m002b0 a sosa:Observation .
   _:m002b0 sosa:madeBySensor :thermometerA .
-  _:m002b0 sosa:resultTime "2026-05-12T18:21:00Z" .
+  _:m002b0 sosa:resultTime "2026-05-12T18:21:00Z"^^xsd:dateTime .
   _:m002b0 sosa:hasSimpleResult 22 .
 }
 
-in:formula3 {
+in:payload004 {
   _:m004b0 a sosa:Observation .
   _:m004b0 sosa:madeBySensor :thermometerA .
-  _:m004b0 sosa:resultTime "2026-05-12T18:23:00Z" .
+  _:m004b0 sosa:resultTime "2026-05-12T18:23:00Z"^^xsd:dateTime .
   _:m004b0 sosa:hasSimpleResult 28 .
 }
 
-in:formula4 {
+in:payload005 {
   _:m005b0 a sosa:Observation .
   _:m005b0 sosa:madeBySensor :thermometerA .
-  _:m005b0 sosa:resultTime "2026-05-12T18:24:00Z" .
+  _:m005b0 sosa:resultTime "2026-05-12T18:24:00Z"^^xsd:dateTime .
   _:m005b0 sosa:hasSimpleResult 29 .
 }
 
@@ -88,13 +122,7 @@ in:metadata {
   in:run a see:InputDataset .
   in:run see:name "rdf_message_flow" .
   in:run see:title "RDF Message Flow" .
-  in:run see:sourceFile "examples/n3/rdf_message_flow.n3" .
-  in:run see:sourceSHA256 "e4e534c8ac3c2aa276e7158cca8d3146531879033f73685c302b486be2ab0099" .
-  in:run see:description "A companion to rdf_messages.n3. This example focuses on a live stream where\nRDF Messages continuously flow through a small processing pipeline. The next\nmessage is released only after the current message reaches the sink, so the\nstream behaves as an ordered, replayable flow rather than a single merged RDF\ngraph." .
+  in:run see:sourceFile "examples/rdf-message-flow.n3" .
+  in:run see:description "A single Eyeling example split across an N3 rule file and a TriG input sidecar. It models an ordered RDF Message Stream using application-level envelopes and named payload graphs so that each payload can be interpreted atomically without merging all message contents into one graph." .
   in:run see:compiler "Eyeling RDF/TriG input sidecar" .
-  in:run see:inputFacts 42 .
-  in:run see:compiledRules 9 .
-  in:run see:compiledBackwardRules 0 .
-  in:run see:compiledFuses 0 .
-  in:run see:compiledQueries 1 .
 }

package/examples/input/rdf-message-microgrid.trig

@@ -0,0 +1,89 @@
+# ===================================
+# RDF Message Microgrid input sidecar
+# ===================================
+#
+# This file is the data half of the runnable example:
+#
+#   eyeling -r examples/rdf-message-microgrid.n3 examples/input/rdf-message-microgrid.trig
+#
+# The scene is a clinic operating as an islanded microgrid after a storm. The
+# data arrives as a replayable stream of atomic messages: life-safety loads,
+# power status, flexible demand, and an empty heartbeat. The default graph holds
+# application-local envelope facts, while each non-empty message payload is kept
+# in a named graph.
+#
+# The envelope IRIs are not RDF Message identifiers defined by the specification;
+# they are local replay records for this example. The named graphs are the
+# datasets/messages interpreted atomically by the N3 rules.
+
+@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-microgrid#> .
+@prefix rmsg: <https://eyereasoner.github.io/eyeling/examples/rdf-message-microgrid/vocab#> .
+@prefix prov: <http://www.w3.org/ns/prov#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+@prefix see: <https://example.org/see#> .
+@prefix in: <https://example.org/see/input#> .
+
+:stormClinicLog a rmsg:MessageLog .
+:stormClinicLog rmsg:orderedMessages (:m001 :m002 :m003 :m004) .
+:stormClinicLog rmsg:message :m001 .
+:stormClinicLog rmsg:message :m002 .
+:stormClinicLog rmsg:message :m003 .
+:stormClinicLog rmsg:message :m004 .
+:stormClinicLog rmsg:retentionPolicy "storm replay archive" .
+
+:m001 a rmsg:MessageEnvelope .
+:m001 rmsg:offset 1 .
+:m001 prov:generatedAtTime "2026-05-15T19:00:00Z"^^xsd:dateTime .
+:m001 rmsg:payloadKind :lifeSafetyLoads .
+:m001 rmsg:payloadGraph in:lifeSafetyPayload .
+
+:m002 a rmsg:MessageEnvelope .
+:m002 rmsg:offset 2 .
+:m002 prov:generatedAtTime "2026-05-15T19:01:00Z"^^xsd:dateTime .
+:m002 rmsg:payloadKind :powerStatus .
+:m002 rmsg:payloadGraph in:powerPayload .
+
+:m003 a rmsg:MessageEnvelope .
+:m003 rmsg:offset 3 .
+:m003 prov:generatedAtTime "2026-05-15T19:02:00Z"^^xsd:dateTime .
+:m003 rmsg:payloadKind :flexibleDemand .
+:m003 rmsg:payloadGraph in:flexPayload .
+
+:m004 a rmsg:MessageEnvelope .
+:m004 rmsg:offset 4 .
+:m004 prov:generatedAtTime "2026-05-15T19:03:00Z"^^xsd:dateTime .
+:m004 rmsg:payloadKind :heartbeat .
+
+in:lifeSafetyPayload {
+  :oxygenConcentrator a :LifeSafetyLoad .
+  :oxygenConcentrator :requiresWatts 500 .
+  :oxygenConcentrator :serves :respiratoryCareRoom .
+
+  :vaccineFridge a :ColdChainLoad .
+  :vaccineFridge :requiresWatts 120 .
+  :vaccineFridge :serves :vaccineColdChain .
+}
+
+in:powerPayload {
+  :batteryBank a :PowerReserve .
+  :batteryBank :availableWatts 650 .
+  :batteryBank :state :islanded .
+
+  :solarForecast a :NearTermForecast .
+  :solarForecast :expectedWatts 150 .
+}
+
+in:flexPayload {
+  :evChargers a :FlexibleLoad .
+  :evChargers :shedWatts 600 .
+  :evChargers :serves :staffVehicles .
+}
+
+in:metadata {
+  in:run a see:InputDataset .
+  in:run see:name "rdf_message_microgrid" .
+  in:run see:title "RDF Message Microgrid" .
+  in:run see:sourceFile "examples/rdf-message-microgrid.n3" .
+  in:run see:description "A storm clinic microgrid example using application-local RDF Message envelopes and named payload graphs so a reasoner can make a bounded, explainable load-shedding decision." .
+  in:run see:compiler "Eyeling RDF/TriG input sidecar" .
+}

package/examples/input/rdf-messages.trig

@@ -1,5 +1,32 @@
+# ==========================
+# RDF Messages input sidecar
+# ==========================
+#
+# This file is the data half of the runnable example:
+#
+#   eyeling -r examples/rdf-messages.n3 examples/input/rdf-messages.trig
+#
+# It is intentionally plain TriG rather than a parser-level RDF Message Log with
+# VERSION "1.2-messages" and MESSAGE delimiters. The RDF Messages draft says an
+# RDF Message is an RDF dataset interpreted atomically, that a message stream is
+# an ordered sequence of such messages, that messages are not combined by
+# default, and that blank-node labels are scoped to the message.
+#
+# To demonstrate those ideas in Eyeling today, the default graph contains
+# application-local envelope records (:m001 ... :m003) plus replay order and
+# offsets. Each non-empty message payload is placed in its own named graph
+# (in:payload001 and in:payload003). The second envelope is an empty heartbeat,
+# which is valid because RDF Messages may be empty.
+#
+# The envelope IRIs are not message identifiers defined by the spec; they are
+# application-level records used by the rules. The named payload graphs are the
+# datasets/messages being interpreted atomically. The rmsg:localBlankLabel values
+# show that the same source-local label "_:b0" can recur in different messages;
+# the concrete TriG blank nodes themselves are unique because this sidecar is
+# ordinary TriG rather than an RDF Message Log parser resetting blank-node scope.
+
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-messages#> .
-@prefix msg: <https://w3c-cg.github.io/rsp/spec/messages#> .
+@prefix rmsg: <https://eyereasoner.github.io/eyeling/examples/rdf-messages/vocab#> .
 @prefix prov: <http://www.w3.org/ns/prov#> .
 @prefix sosa: <http://www.w3.org/ns/sosa/> .
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@@ -10,46 +37,46 @@
 @prefix see: <https://example.org/see#> .
 @prefix in: <https://example.org/see/input#> .
 
-# Formal Eyeling input evidence in RDF 1.2 TriG.
-# The generated runner reads this TriG evidence directly.
+:temperatureLog a rmsg:MessageLog .
+:temperatureLog rmsg:orderedMessages (:m001 :m002 :m003) .
+:temperatureLog rmsg:message :m001 .
+:temperatureLog rmsg:message :m002 .
+:temperatureLog rmsg:message :m003 .
+:temperatureLog rmsg:profile :generatedAtTimeProfile .
+:temperatureLog rmsg:retentionPolicy "replayable archive" .
+
+:m001 a rmsg:MessageEnvelope .
+:m001 rmsg:offset 1 .
+:m001 prov:generatedAtTime "2026-05-12T18:20:00Z"^^xsd:dateTime .
+:m001 rmsg:payloadKind :observation .
+:m001 rmsg:localBlankLabel "_:b0" .
+:m001 rmsg:expectedResult 22 .
+:m001 rmsg:payloadGraph in:payload001 .
+
+:m002 a rmsg:MessageEnvelope .
+:m002 rmsg:offset 2 .
+:m002 prov:generatedAtTime "2026-05-12T18:22:00Z"^^xsd:dateTime .
+:m002 rmsg:payloadKind :heartbeat .
 
-:temperatureLog a msg:MessageLog .
-:temperatureLog msg:orderedMessages (:m001 :m002 :m003) .
-:temperatureLog msg:message :m001 .
-:temperatureLog msg:message :m002 .
-:temperatureLog msg:message :m003 .
-:temperatureLog msg:profile :generatedAtTimeProfile .
-:temperatureLog msg:retentionPolicy "replayable archive" .
-:m001 a msg:RDFMessage .
-:m001 msg:offset 1 .
-:m001 prov:generatedAtTime "2026-05-12T18:20:00Z" .
-:m001 msg:payloadKind :observation .
-:m001 msg:localBlankLabel "_:b0" .
-:m001 msg:expectedResult 22 .
-:m001 msg:payload in:formula1 .
-:m002 a msg:RDFMessage .
-:m002 msg:offset 2 .
-:m002 prov:generatedAtTime "2026-05-12T18:22:00Z" .
-:m002 msg:payloadKind :heartbeat .
-:m003 a msg:RDFMessage .
-:m003 msg:offset 3 .
-:m003 prov:generatedAtTime "2026-05-12T18:25:00Z" .
-:m003 msg:payloadKind :observation .
-:m003 msg:localBlankLabel "_:b0" .
-:m003 msg:expectedResult 23 .
-:m003 msg:payload in:formula2 .
+:m003 a rmsg:MessageEnvelope .
+:m003 rmsg:offset 3 .
+:m003 prov:generatedAtTime "2026-05-12T18:25:00Z"^^xsd:dateTime .
+:m003 rmsg:payloadKind :observation .
+:m003 rmsg:localBlankLabel "_:b0" .
+:m003 rmsg:expectedResult 23 .
+:m003 rmsg:payloadGraph in:payload003 .
 
-in:formula1 {
+in:payload001 {
   _:m001b0 a sosa:Observation .
   _:m001b0 sosa:madeBySensor :thermometerA .
-  _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z" .
+  _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z"^^xsd:dateTime .
   _:m001b0 sosa:hasSimpleResult 22 .
 }
 
-in:formula2 {
+in:payload003 {
   _:m003b0 a sosa:Observation .
   _:m003b0 sosa:madeBySensor :thermometerA .
-  _:m003b0 sosa:resultTime "2026-05-12T18:25:00Z" .
+  _:m003b0 sosa:resultTime "2026-05-12T18:25:00Z"^^xsd:dateTime .
   _:m003b0 sosa:hasSimpleResult 23 .
 }
 
@@ -57,13 +84,7 @@ in:metadata {
   in:run a see:InputDataset .
   in:run see:name "rdf_messages" .
   in:run see:title "RDF Messages" .
-  in:run see:sourceFile "examples/n3/rdf_messages.n3" .
-  in:run see:sourceSHA256 "2ea8b414b92e65531cf384000955ca47811d5b7c779a8d2c9fb007515e745f32" .
-  in:run see:description "This Eyeling example models the main idea from\nhttps://pietercolpaert.be/papers/eswc2026-rdf-messages/:\na message stream/log is not just one freely mergeable RDF graph. It is an\nordered sequence of RDF Datasets that are interpreted atomically, one message\nat a time. The middle message is deliberately empty to model a heartbeat, and\nthe local blank-node label \"_:b0\" is deliberately reused by two messages to\nshow message-scoped blank nodes." .
+  in:run see:sourceFile "examples/rdf-messages.n3" .
+  in:run see:description "A single Eyeling example split across an N3 rule file and a TriG input sidecar. It models a replayable RDF Message Log with application-level envelopes and named payload graphs so that each payload can be interpreted atomically without merging all message contents into one graph." .
   in:run see:compiler "Eyeling RDF/TriG input sidecar" .
-  in:run see:inputFacts 25 .
-  in:run see:compiledRules 6 .
-  in:run see:compiledBackwardRules 0 .
-  in:run see:compiledFuses 0 .
-  in:run see:compiledQueries 1 .
 }

package/examples/output/rdf-message-flow.md

@@ -6,7 +6,7 @@
 - [Input TriG](../input/rdf-message-flow.trig)  
 
 ## Answer  
-Continuous RDF Message flow accepted: 5 ordered messages moved through the ingest → validate → interpret → route → sink pipeline. The threshold was 26, so results 21 and 22 were archived, the heartbeat kept the stream alive, and results 28 and 29 were emitted as alerts.  
+Continuous RDF Message flow accepted: 5 ordered message envelopes moved through the ingest → validate → interpret → route → sink pipeline. The threshold was 26, so results 21 and 22 were archived, the heartbeat kept the stream alive, and results 28 and 29 were emitted as alerts.  
 
 ## Explanation  
-The N3 source starts only :m001 at ingress. Each message must reach :sink before the continuous-flow rule releases its msg:nextMessage. Observation payloads are inspected with log:includes inside each message formula, while the empty heartbeat uses the same envelope and routing stages without a payload. This models messages flowing through a live stream while preserving message boundaries.  
+The input is a single runnable example split across an N3 rule file and a TriG sidecar. The TriG file uses example-local envelope facts for stream order and processing state, while each named payload graph is treated as an atomic RDF Message dataset. Only :m001 starts at ingress; each envelope must reach :sink before the continuous-flow rule releases its flow:nextEnvelope. Observation payloads are inspected with log:includes inside their own payload formula, and the empty heartbeat advances without a payload graph. This keeps message boundaries visible to the reasoner instead of merging all payload triples into one global graph.  

package/examples/output/rdf-message-microgrid.md

@@ -0,0 +1,14 @@
+# rdf-message-microgrid  
+
+## Source files  
+
+- [N3 rules](../rdf-message-microgrid.n3)  
+- [Input TriG](../input/rdf-message-microgrid.trig)  
+
+## Answer  
+Storm clinic microgrid accepted: 4 RDF Message envelopes were replayed atomically. Critical care needs 620 W, current battery plus solar gives 800 W, and deferring the EV chargers frees 600 W, so the protected budget is 1400 W. The reasoned action is to keep the oxygen concentrator and vaccine fridge online, while deferring EV charging.  
+
+## Why this is an RDF Messages example  
+The input is a single runnable example split across an N3 rule file and a TriG sidecar. The default graph records stream order, offsets, and envelope metadata. Each non-empty named graph is treated as an atomic message payload, and the fourth message is an empty heartbeat. The rules inspect each payload with log:includes inside its own formula, then combine only the derived conclusions needed for the microgrid decision. This keeps the explanation tied to message boundaries instead of silently flattening the stream into one global graph.  
+
+This is intentionally not a parser-level VERSION \"1.2-messages\" / MESSAGE delimiter test. It is a reasoning example over an already-materialized sidecar representation of a message log.  

package/examples/output/rdf-messages.md

@@ -6,7 +6,9 @@
 - [Input TriG](../input/rdf-messages.trig)  
 
 ## Answer  
-RDF Message log accepted: 3 explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label _:b0 is safely reused in separate messages.  
+RDF Message replay archive accepted: 3 explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label _:b0 is safely reused in separate message envelopes.  
 
 ## Explanation  
-The N3 source models an RDF Message Log as an ordered sequence of RDF Messages. Each non-empty message has a formula-valued payload that is inspected with log:includes, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, 22 and 23, are different observations from the same stream but are contextualized by their message boundaries.  
+The input is a single runnable example split across an N3 rule file and a TriG sidecar. The TriG file uses application-local envelope facts for stream order and replay metadata, while each non-empty named payload graph is treated as an atomic RDF Message dataset. Payloads are inspected with log:includes inside their own formulas, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, 22 and 23, are different observations from the same stream but are contextualized by their message boundaries.  
+
+This is intentionally not a parser-level VERSION \"1.2-messages\" / MESSAGE delimiter test. It is a reasoning example over an already-materialized sidecar representation of a message log.  

package/examples/rdf-message-flow.n3

@@ -1,14 +1,35 @@
 # ================
 # RDF Message Flow
 # ================
-# A companion to rdf_messages.n3. This example focuses on a live stream where
-# RDF Messages continuously flow through a small processing pipeline. The next
-# message is released only after the current message reaches the sink, so the
-# stream behaves as an ordered, replayable flow rather than a single merged RDF
-# graph.
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-message-flow.n3 examples/input/rdf-message-flow.trig
+#
+# Motivation
+# ----------
+# The RDF Messages draft describes an RDF Message as an RDF dataset interpreted
+# atomically, and an RDF Message Stream as an ordered sequence of such messages.
+# It also defines RDF Message Logs with explicit MESSAGE delimiters. This Eyeling
+# example keeps the same message-level discipline while staying in ordinary
+# N3/TriG that Eyeling can reason over today.
+#
+# The companion TriG file therefore separates two layers:
+#
+#   1. example-local envelope facts in the default graph, such as order,
+#      processing stage, and payload graph; and
+#   2. one named graph per non-empty message payload, treated here as the RDF
+#      dataset/message that must be inspected atomically.
+#
+# The rules below deliberately do not merge all payload graphs into one global
+# graph. Instead, each observation is checked with log:includes inside the named
+# payload formula. The empty heartbeat has no payload graph but still advances
+# through the same pipeline. The next message is released only after the current
+# one reaches the sink, making the example a small back-pressure / flow-control
+# story rather than a batch merge of all input triples.
 
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-flow#>.
-@prefix msg: <https://example.org/msg#>.
+@prefix flow: <https://eyereasoner.github.io/eyeling/examples/rdf-message-flow/vocab#>.
 @prefix prov: <http://www.w3.org/ns/prov#>.
 @prefix sosa: <http://www.w3.org/ns/sosa/>.
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@@ -17,126 +38,120 @@
 @prefix log: <http://www.w3.org/2000/10/swap/log#>.
 @prefix string: <http://www.w3.org/2000/10/swap/string#>.
 
-
-# The stream starts with just the first message at ingress. Later messages are
-# not pre-loaded; each one is released by the previous message after sink.
-
-
-
-# Empty heartbeat: it flows through the same pipeline and keeps the stream live.
-
-
-
-# Stage 1: once a message has entered the stream, validate its envelope.
-
-{ ?Message :atStage :ingest. } => {
-  ?Message :atStage :validate.
+# Stage 1: once an envelope has entered the stream, validate it.
+{ ?Envelope :atStage :ingest. } => {
+  ?Envelope :atStage :validate.
 }.
 
-# Stage 2: validation preserves the message boundary before interpretation.
+# Stage 2: validation records that the envelope keeps an explicit message
+# boundary before the payload is interpreted.
 {
-  ?Message :atStage :validate;
-    a msg:RDFMessage;
-    msg:offset ?Offset.
+  ?Envelope :atStage :validate;
+    a flow:MessageEnvelope;
+    flow:offset ?Offset.
 } => {
-  ?Message msg:boundaryExplicit true.
-  ?Message :atStage :interpret.
+  ?Envelope flow:boundaryExplicit true.
+  ?Envelope :atStage :interpret.
 }.
 
-# Stage 3a: observation payloads are inspected inside their message formula.
+# Stage 3a: observation payloads are inspected inside their own payload graph.
+# This models the RDF Messages idea that messages are separate atomic datasets.
 {
-  ?Message :atStage :interpret;
-    msg:payloadKind :observation;
-    msg:expectedResult ?Result;
-    msg:payload ?Payload.
+  ?Envelope :atStage :interpret;
+    flow:payloadKind :observation;
+    flow:expectedResult ?Result;
+    flow:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes { ?Observation sosa:hasSimpleResult ?Result. }.
 } => {
-  ?Message msg:payloadResult ?Result.
-  ?Message :atStage :route.
+  ?Envelope flow:payloadResult ?Result.
+  ?Envelope :atStage :route.
 }.
 
-# Stage 3b: empty heartbeats have no payload, but still move through the flow.
+# Stage 3b: empty heartbeats contain no quads, but RDF Messages explicitly allow
+# empty messages, so the envelope still moves through the flow.
 {
-  ?Message :atStage :interpret;
-    msg:payloadKind :heartbeat.
+  ?Envelope :atStage :interpret;
+    flow:payloadKind :heartbeat.
 } => {
-  ?Message msg:emptyMessageAllowed true.
-  ?Message :atStage :route.
+  ?Envelope flow:emptyMessageAllowed true.
+  ?Envelope :atStage :route.
 }.
 
 # Stage 4a: hot observations are routed to the alert sink.
 {
-  ?Message :atStage :route;
-    msg:payloadResult ?Result.
+  ?Envelope :atStage :route;
+    flow:payloadResult ?Result.
   :temperatureFlow :highThreshold ?Threshold.
   ?Result math:greaterThan ?Threshold.
 } => {
-  ?Message :route :alertSink.
-  ?Message :atStage :sink.
-  :alertSink :received ?Message.
+  ?Envelope :route :alertSink.
+  ?Envelope :atStage :sink.
+  :alertSink :received ?Envelope.
 }.
 
 # Stage 4b: normal observations are routed to the archive sink.
 {
-  ?Message :atStage :route;
-    msg:payloadResult ?Result.
+  ?Envelope :atStage :route;
+    flow:payloadResult ?Result.
   :temperatureFlow :highThreshold ?Threshold.
   ?Result math:notGreaterThan ?Threshold.
 } => {
-  ?Message :route :archiveSink.
-  ?Message :atStage :sink.
-  :archiveSink :received ?Message.
+  ?Envelope :route :archiveSink.
+  ?Envelope :atStage :sink.
+  :archiveSink :received ?Envelope.
 }.
 
 # Stage 4c: heartbeats are routed separately from observations.
 {
-  ?Message :atStage :route;
-    msg:emptyMessageAllowed true.
+  ?Envelope :atStage :route;
+    flow:emptyMessageAllowed true.
 } => {
-  ?Message :route :heartbeatSink.
-  ?Message :atStage :sink.
-  :heartbeatSink :received ?Message.
+  ?Envelope :route :heartbeatSink.
+  ?Envelope :atStage :sink.
+  :heartbeatSink :received ?Envelope.
 }.
 
-# Continuous-flow rule: reaching the sink releases the next message into ingress.
+# Continuous-flow rule: reaching the sink releases the next envelope into ingress.
+# This mirrors a consumer-visible ordered stream: later messages are not processed
+# until the earlier message has completed the pipeline.
 {
-  ?Message :atStage :sink;
-    msg:nextMessage ?Next.
-  ?Next a msg:RDFMessage.
+  ?Envelope :atStage :sink;
+    flow:nextEnvelope ?Next.
+  ?Next a flow:MessageEnvelope.
 } => {
-  ?Message :releases ?Next.
+  ?Envelope :releases ?Next.
   ?Next :atStage :ingest.
 }.
 
-# The Eyeling verdict is emitted only after all five messages have flowed through
-# ingest, validation, interpretation, routing, and sink.
+# The Eyeling verdict is emitted only after all five envelopes have flowed
+# through ingest, validation, interpretation, routing, and sink while preserving
+# their message boundaries.
 {
-  :temperatureFlow msg:orderedMessages ?Messages;
+  :temperatureFlow flow:orderedEnvelopes ?Envelopes;
     :highThreshold ?Threshold.
-  ?Messages list:length ?Count.
+  ?Envelopes list:length ?Count.
   :m001 :atStage :sink;
-    msg:payloadResult ?FirstResult;
+    flow:payloadResult ?FirstResult;
     :route :archiveSink;
     :releases :m002.
   :m002 :atStage :sink;
-    msg:payloadResult ?SecondResult;
+    flow:payloadResult ?SecondResult;
     :route :archiveSink;
     :releases :m003.
   :m003 :atStage :sink;
-    msg:emptyMessageAllowed true;
+    flow:emptyMessageAllowed true;
     :route :heartbeatSink;
     :releases :m004.
   :m004 :atStage :sink;
-    msg:payloadResult ?FourthResult;
+    flow:payloadResult ?FourthResult;
     :route :alertSink;
     :releases :m005.
   :m005 :atStage :sink;
-    msg:payloadResult ?FifthResult;
+    flow:payloadResult ?FifthResult;
     :route :alertSink.
-  ("# rdf-message-flow\n\n## Source files\n\n- [N3 rules](../rdf-message-flow.n3)\n- [Input TriG](../input/rdf-message-flow.trig)\n\n## Answer\nContinuous RDF Message flow accepted: %d ordered messages moved through the ingest → validate → interpret → route → sink pipeline. The threshold was %d, so results %s and %s were archived, the heartbeat kept the stream alive, and results %s and %s were emitted as alerts.\n\n## Explanation\nThe N3 source starts only :m001 at ingress. Each message must reach :sink before the continuous-flow rule releases its msg:nextMessage. Observation payloads are inspected with log:includes inside each message formula, while the empty heartbeat uses the same envelope and routing stages without a payload. This models messages flowing through a live stream while preserving message boundaries." ?Count ?Threshold ?FirstResult ?SecondResult ?FourthResult ?FifthResult) string:format ?Block.
+  ("# rdf-message-flow\n\n## Source files\n\n- [N3 rules](../rdf-message-flow.n3)\n- [Input TriG](../input/rdf-message-flow.trig)\n\n## Answer\nContinuous RDF Message flow accepted: %d ordered message envelopes moved through the ingest → validate → interpret → route → sink pipeline. The threshold was %d, so results %s and %s were archived, the heartbeat kept the stream alive, and results %s and %s were emitted as alerts.\n\n## Explanation\nThe input is a single runnable example split across an N3 rule file and a TriG sidecar. The TriG file uses example-local envelope facts for stream order and processing state, while each named payload graph is treated as an atomic RDF Message dataset. Only :m001 starts at ingress; each envelope must reach :sink before the continuous-flow rule releases its flow:nextEnvelope. Observation payloads are inspected with log:includes inside their own payload formula, and the empty heartbeat advances without a payload graph. This keeps message boundaries visible to the reasoner instead of merging all payload triples into one global graph." ?Count ?Threshold ?FirstResult ?SecondResult ?FourthResult ?FifthResult) string:format ?Block.
 } => {
   :rdfMessageFlowExample log:outputString ?Block.
   :rdfMessageFlowExample :demonstrates :ContinuousFlow, :BackPressureRelease, :AtomicMessageContext, :HeartbeatInFlow, :ThresholdRouting.
 }.
-

package/examples/rdf-message-microgrid.n3

@@ -0,0 +1,141 @@
+# =====================
+# RDF Message Microgrid
+# =====================
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-message-microgrid.n3 examples/input/rdf-message-microgrid.trig
+#
+# Motivation
+# ----------
+# A clinic has lost grid power during a storm. Several small systems continue to
+# send RDF data: one message describes life-safety loads, another describes the
+# current battery and solar situation, another describes flexible demand that may
+# be deferred, and a fourth message is an empty heartbeat.
+#
+# The RDF Messages draft treats each message as an RDF dataset intended to be
+# interpreted atomically. It also treats a message stream as an ordered sequence
+# and allows empty messages. This example models those ideas in ordinary TriG/N3:
+# the companion TriG file contains application-local envelope facts in the
+# default graph, and each non-empty payload is placed in its own named graph.
+#
+# The point is not only technical. Atomic messages let a small reasoner make a
+# careful decision under pressure: protect the oxygen concentrator and vaccine
+# fridge, defer the EV chargers, and explain the action from the replayed message
+# boundaries instead of silently merging every payload into one timeless graph.
+#
+# This is intentionally not a parser-level VERSION "1.2-messages" / MESSAGE
+# delimiter test. It is a reasoning example over an already-materialized sidecar
+# representation of a message log.
+
+@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-microgrid#>.
+@prefix rmsg: <https://eyereasoner.github.io/eyeling/examples/rdf-message-microgrid/vocab#>.
+@prefix prov: <http://www.w3.org/ns/prov#>.
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
+@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#>.
+
+# Every envelope with an offset is an explicit replay boundary. The envelope is
+# application-local metadata; the payload graph is the dataset/message being
+# interpreted atomically.
+{
+  ?Log a rmsg:MessageLog;
+    rmsg:message ?Message.
+  ?Message a rmsg:MessageEnvelope;
+    rmsg:offset ?Offset.
+} => {
+  ?Message rmsg:boundaryExplicit true.
+  ?Log rmsg:replayContains ?Message.
+}.
+
+# Empty RDF Messages are valid. Here the fourth envelope is a heartbeat that
+# confirms the stream is still alive without adding any payload triples.
+{
+  ?Message a rmsg:MessageEnvelope;
+    rmsg:payloadKind :heartbeat.
+} => {
+  ?Message rmsg:emptyMessageAllowed true.
+}.
+
+# Inspect the life-safety message inside its own payload graph.
+{
+  ?Message rmsg:payloadKind :lifeSafetyLoads;
+    rmsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :oxygenConcentrator :requiresWatts ?Oxygen.
+    :vaccineFridge :requiresWatts ?Fridge.
+  }.
+  (?Oxygen ?Fridge) math:sum ?CriticalWatts.
+} => {
+  :clinicMicrogrid rmsg:criticalWatts ?CriticalWatts.
+  :clinicMicrogrid rmsg:mustKeep :oxygenConcentrator, :vaccineFridge.
+}.
+
+# Inspect the power-status message atomically.
+{
+  ?Message rmsg:payloadKind :powerStatus;
+    rmsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :batteryBank :availableWatts ?BatteryWatts.
+    :solarForecast :expectedWatts ?SolarWatts.
+  }.
+  (?BatteryWatts ?SolarWatts) math:sum ?AvailableWatts.
+} => {
+  :clinicMicrogrid rmsg:availableWatts ?AvailableWatts.
+}.
+
+# Inspect the flexible-demand message atomically. The EV chargers are useful, but
+# they are safe to defer so life-safety loads keep running.
+{
+  ?Message rmsg:payloadKind :flexibleDemand;
+    rmsg:payloadGraph ?Payload.
+  ?Payload log:nameOf ?PayloadContext.
+  ?PayloadContext log:includes {
+    :evChargers :shedWatts ?ShedWatts.
+  }.
+} => {
+  :clinicMicrogrid rmsg:deferrableWatts ?ShedWatts.
+  :clinicMicrogrid rmsg:mayDefer :evChargers.
+}.
+
+# The decision combines conclusions from the separate messages, while preserving
+# the evidence that each conclusion came through an explicit message boundary.
+{
+  :clinicMicrogrid rmsg:criticalWatts ?CriticalWatts;
+    rmsg:availableWatts ?AvailableWatts;
+    rmsg:deferrableWatts ?ShedWatts;
+    rmsg:mustKeep :oxygenConcentrator, :vaccineFridge;
+    rmsg:mayDefer :evChargers.
+  (?AvailableWatts ?ShedWatts) math:sum ?ProtectedBudget.
+  ?ProtectedBudget math:greaterThan ?CriticalWatts.
+} => {
+  :clinicMicrogrid rmsg:protectedBudgetWatts ?ProtectedBudget.
+  :clinicMicrogrid rmsg:resilienceAction :protectClinic.
+  :clinicMicrogrid rmsg:keeps :oxygenConcentrator, :vaccineFridge.
+  :clinicMicrogrid rmsg:defers :evChargers.
+}.
+
+# Emit the example report only when the message stream, empty heartbeat, atomic
+# payload inspection, and protection decision have all been derived.
+{
+  :stormClinicLog rmsg:orderedMessages ?Messages.
+  ?Messages list:length ?Count.
+  :m001 rmsg:boundaryExplicit true.
+  :m002 rmsg:boundaryExplicit true.
+  :m003 rmsg:boundaryExplicit true.
+  :m004 rmsg:boundaryExplicit true;
+    rmsg:emptyMessageAllowed true.
+  :clinicMicrogrid rmsg:criticalWatts ?CriticalWatts;
+    rmsg:availableWatts ?AvailableWatts;
+    rmsg:deferrableWatts ?ShedWatts;
+    rmsg:protectedBudgetWatts ?ProtectedBudget;
+    rmsg:resilienceAction :protectClinic.
+  ("# rdf-message-microgrid\n\n## Source files\n\n- [N3 rules](../rdf-message-microgrid.n3)\n- [Input TriG](../input/rdf-message-microgrid.trig)\n\n## Answer\nStorm clinic microgrid accepted: %d RDF Message envelopes were replayed atomically. Critical care needs %d W, current battery plus solar gives %d W, and deferring the EV chargers frees %d W, so the protected budget is %d W. The reasoned action is to keep the oxygen concentrator and vaccine fridge online, while deferring EV charging.\n\n## Why this is an RDF Messages example\nThe input is a single runnable example split across an N3 rule file and a TriG sidecar. The default graph records stream order, offsets, and envelope metadata. Each non-empty named graph is treated as an atomic message payload, and the fourth message is an empty heartbeat. The rules inspect each payload with log:includes inside its own formula, then combine only the derived conclusions needed for the microgrid decision. This keeps the explanation tied to message boundaries instead of silently flattening the stream into one global graph.\n\nThis is intentionally not a parser-level VERSION \\\"1.2-messages\\\" / MESSAGE delimiter test. It is a reasoning example over an already-materialized sidecar representation of a message log." ?Count ?CriticalWatts ?AvailableWatts ?ShedWatts ?ProtectedBudget) string:format ?Block.
+} => {
+  :rdfMessageMicrogridExample log:outputString ?Block.
+  :rdfMessageMicrogridExample :demonstrates :AtomicMessageContext, :EmptyHeartbeat, :ReplayableMessageLog, :ResilientDecisionSupport.
+}.

package/examples/rdf-messages.n3

@@ -1,16 +1,38 @@
 # ============
 # RDF Messages
 # ============
-# This Eyeling example models the main idea from
-# https://pietercolpaert.be/papers/eswc2026-rdf-messages/:
-# a message stream/log is not just one freely mergeable RDF graph. It is an
-# ordered sequence of RDF Datasets that are interpreted atomically, one message
-# at a time. The middle message is deliberately empty to model a heartbeat, and
-# the local blank-node label "_:b0" is deliberately reused by two messages to
-# show message-scoped blank nodes.
+#
+# Run as:
+#
+#   eyeling -r examples/rdf-messages.n3 examples/input/rdf-messages.trig
+#
+# Motivation
+# ----------
+# The RDF Messages draft defines an RDF Message as an RDF dataset interpreted
+# atomically, an RDF Message Stream as an ordered sequence of messages, and an
+# RDF Message Log as a replayable record of such a stream. The draft also says
+# that messages should not be combined by default and that blank node labels are
+# scoped to the message in which they occur.
+#
+# This Eyeling example demonstrates those ideas in ordinary N3/TriG rather than
+# in a parser-level RDF Message Log with VERSION "1.2-messages" and MESSAGE
+# delimiters. The companion TriG file therefore has two layers:
+#
+#   1. application-local envelope facts in the default graph, such as message
+#      order, offset, expected result, and the textual blank-node label seen in
+#      the original stream; and
+#   2. one named graph per non-empty message payload, treated as the atomic RDF
+#      dataset/message to be inspected.
+#
+# The rules below validate a replay archive with three message envelopes. The
+# middle message is an empty heartbeat. The first and third messages both record
+# the local blank-node label "_:b0"; because this sidecar is normal TriG, the
+# actual TriG blank nodes are unique, while the envelope records show the
+# message-scoped label reuse that a true RDF Message Log parser would preserve
+# by resetting blank-node scope at each MESSAGE delimiter.
 
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-messages#>.
-@prefix msg: <https://w3c-cg.github.io/rsp/spec/messages#>.
+@prefix rmsg: <https://eyereasoner.github.io/eyeling/examples/rdf-messages/vocab#>.
 @prefix prov: <http://www.w3.org/ns/prov#>.
 @prefix sosa: <http://www.w3.org/ns/sosa/>.
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@@ -19,51 +41,49 @@
 @prefix log: <http://www.w3.org/2000/10/swap/log#>.
 @prefix string: <http://www.w3.org/2000/10/swap/string#>.
 
-
-
-# Empty RDF Message: a legal heartbeat/keep-alive event.
-
-
 # A message with an offset inside a log has an explicit replay boundary.
-
+# The envelope resource is application-local; the payload graph is the dataset
+# treated as the RDF Message.
 {
-  ?Log a msg:MessageLog;
-    msg:message ?Message.
-  ?Message a msg:RDFMessage;
-    msg:offset ?Offset.
+  ?Log a rmsg:MessageLog;
+    rmsg:message ?Message.
+  ?Message a rmsg:MessageEnvelope;
+    rmsg:offset ?Offset.
 } => {
-  ?Message msg:boundaryExplicit true.
-  ?Log msg:replayContains ?Message.
+  ?Message rmsg:boundaryExplicit true.
+  ?Log rmsg:replayContains ?Message.
 }.
 
-# The payload is a dataset-like formula. We can inspect it without merging it
-# into the global graph, preserving the message as the unit of interpretation.
+# The payload is a dataset-like named graph. Inspect it with log:includes instead
+# of merging all payload triples into the global graph.
 {
-  ?Message a msg:RDFMessage;
-    msg:expectedResult ?Result;
-    msg:payload ?Payload.
+  ?Message a rmsg:MessageEnvelope;
+    rmsg:expectedResult ?Result;
+    rmsg:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes { ?Observation sosa:hasSimpleResult ?Result. }.
 } => {
-  ?Message msg:payloadResult ?Result.
+  ?Message rmsg:payloadResult ?Result.
 }.
 
-# Heartbeat/keep-alive messages can be empty and still occupy a boundary.
+# Empty messages are legal RDF Messages. Here the empty second envelope acts as
+# a heartbeat/keep-alive and still occupies a boundary in the replay archive.
 {
-  ?Message a msg:RDFMessage;
-    msg:payloadKind :heartbeat.
+  ?Message a rmsg:MessageEnvelope;
+    rmsg:payloadKind :heartbeat.
 } => {
-  ?Message msg:emptyMessageAllowed true.
+  ?Message rmsg:emptyMessageAllowed true.
   :HeartbeatEvidence :accepted ?Message.
 }.
 
-# The same blank-node label may recur in a message log because blank nodes are
-# scoped to their RDF Message, not to the whole replay archive.
+# The same local blank-node label may recur in different messages. In this
+# plain-TriG sidecar the real blank nodes are unique, and the envelope metadata
+# records the per-message label visible in the source stream.
 {
-  ?First a msg:RDFMessage;
-    msg:localBlankLabel ?Label.
-  ?Second a msg:RDFMessage;
-    msg:localBlankLabel ?Label.
+  ?First a rmsg:MessageEnvelope;
+    rmsg:localBlankLabel ?Label.
+  ?Second a rmsg:MessageEnvelope;
+    rmsg:localBlankLabel ?Label.
   ?First log:notEqualTo ?Second.
 } => {
   :BlankNodeScope :reusedLabel ?Label.
@@ -71,35 +91,35 @@
 }.
 
 # Different observations from the same sensor are not a global contradiction:
-# each message is interpreted in its own communication context.
+# by default, message payloads remain separate communication contexts.
 {
-  ?First a msg:RDFMessage;
-    msg:payloadResult ?FirstResult.
-  ?Second a msg:RDFMessage;
-    msg:payloadResult ?SecondResult.
+  ?First a rmsg:MessageEnvelope;
+    rmsg:payloadResult ?FirstResult.
+  ?Second a rmsg:MessageEnvelope;
+    rmsg:payloadResult ?SecondResult.
   ?FirstResult math:notEqualTo ?SecondResult.
   ?First log:notEqualTo ?Second.
 } => {
   :MessageContext :differentObservationsStayContextual true.
 }.
 
-# The Eyeling verdict is emitted only when all message-specific validations have been
-# derived from the log, message metadata, payload formulas, and built-ins.
+# The Eyeling verdict is emitted only when all message-specific validations have
+# been derived from the log metadata, ordered message list, payload graphs, and
+# built-ins.
 {
-  :temperatureLog msg:orderedMessages ?Messages.
+  :temperatureLog rmsg:orderedMessages ?Messages.
   ?Messages list:length ?Count.
-  :m001 msg:boundaryExplicit true;
-    msg:payloadResult ?FirstResult.
-  :m002 msg:boundaryExplicit true;
-    msg:emptyMessageAllowed true.
-  :m003 msg:boundaryExplicit true;
-    msg:payloadResult ?SecondResult.
+  :m001 rmsg:boundaryExplicit true;
+    rmsg:payloadResult ?FirstResult.
+  :m002 rmsg:boundaryExplicit true;
+    rmsg:emptyMessageAllowed true.
+  :m003 rmsg:boundaryExplicit true;
+    rmsg:payloadResult ?SecondResult.
   :BlankNodeScope :reusedLabel ?Label;
     :isPerMessage true.
   :MessageContext :differentObservationsStayContextual true.
-  ("# rdf-messages\n\n## Source files\n\n- [N3 rules](../rdf-messages.n3)\n- [Input TriG](../input/rdf-messages.trig)\n\n## Answer\nRDF Message log accepted: %d explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label %s is safely reused in separate messages.\n\n## Explanation\nThe N3 source models an RDF Message Log as an ordered sequence of RDF Messages. Each non-empty message has a formula-valued payload that is inspected with log:includes, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, %s and %s, are different observations from the same stream but are contextualized by their message boundaries." ?Count ?Label ?FirstResult ?SecondResult) string:format ?Block.
+  ("# rdf-messages\n\n## Source files\n\n- [N3 rules](../rdf-messages.n3)\n- [Input TriG](../input/rdf-messages.trig)\n\n## Answer\nRDF Message replay archive accepted: %d explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label %s is safely reused in separate message envelopes.\n\n## Explanation\nThe input is a single runnable example split across an N3 rule file and a TriG sidecar. The TriG file uses application-local envelope facts for stream order and replay metadata, while each non-empty named payload graph is treated as an atomic RDF Message dataset. Payloads are inspected with log:includes inside their own formulas, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, %s and %s, are different observations from the same stream but are contextualized by their message boundaries.\n\nThis is intentionally not a parser-level VERSION \\\"1.2-messages\\\" / MESSAGE delimiter test. It is a reasoning example over an already-materialized sidecar representation of a message log." ?Count ?Label ?FirstResult ?SecondResult) string:format ?Block.
 } => {
   :rdfMessagesExample log:outputString ?Block.
   :rdfMessagesExample :demonstrates :ExplicitBoundaries, :AtomicMessageContext, :EmptyHeartbeat, :MessageScopedBlankNodes, :ReplayableMessageLog.
 }.
-

package/eyeling.js

@@ -1699,7 +1699,7 @@ function __pushBuiltinDeltaLimited(out, delta, maxResults) {
 
 function __collectListLikeTermsFromTerm(t, out, seen) {
   if (t instanceof ListTerm || t instanceof OpenListTerm) {
-    const k = termFastKey ? termFastKey(t) : null;
+    const k = termFastKey(t);
     if (k === null || !seen.has(k)) {
       if (k !== null) seen.add(k);
       out.push(t);
@@ -11498,6 +11498,20 @@ class Parser {
     if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'a') {
       this.next();
       pred = internIri(RDF_NS + 'type');
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'has') {
+      // N3 syntactic sugar is also valid in predicate-object lists,
+      // including blank node property lists: [ has :p :o ] means _:b :p :o.
+      this.next();
+      pred = this.parseTerm();
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'is') {
+      // N3 syntactic sugar: [ is :p of :s ] means :s :p _:b.
+      this.next();
+      pred = this.parseTerm();
+      if (!(this.peek().typ === 'Ident' && (this.peek().value || '') === 'of')) {
+        this.fail(`Expected 'of' after 'is <expr>', got ${this.peek().toString()}`);
+      }
+      this.next();
+      invert = true;
     } else if (this.peek().typ === 'OpPredInvert') {
       this.next();
       pred = this.parseTerm();

package/lib/builtins.js

@@ -1688,7 +1688,7 @@ function __pushBuiltinDeltaLimited(out, delta, maxResults) {
 
 function __collectListLikeTermsFromTerm(t, out, seen) {
   if (t instanceof ListTerm || t instanceof OpenListTerm) {
-    const k = termFastKey ? termFastKey(t) : null;
+    const k = termFastKey(t);
     if (k === null || !seen.has(k)) {
       if (k !== null) seen.add(k);
       out.push(t);

package/lib/parser.js

@@ -465,6 +465,20 @@ class Parser {
     if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'a') {
       this.next();
       pred = internIri(RDF_NS + 'type');
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'has') {
+      // N3 syntactic sugar is also valid in predicate-object lists,
+      // including blank node property lists: [ has :p :o ] means _:b :p :o.
+      this.next();
+      pred = this.parseTerm();
+    } else if (this.peek().typ === 'Ident' && (this.peek().value || '') === 'is') {
+      // N3 syntactic sugar: [ is :p of :s ] means :s :p _:b.
+      this.next();
+      pred = this.parseTerm();
+      if (!(this.peek().typ === 'Ident' && (this.peek().value || '') === 'of')) {
+        this.fail(`Expected 'of' after 'is <expr>', got ${this.peek().toString()}`);
+      }
+      this.next();
+      invert = true;
     } else if (this.peek().typ === 'OpPredInvert') {
       this.next();
       pred = this.parseTerm();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eyeling",
-  "version": "1.24.25",
+  "version": "1.24.26",
   "description": "A minimal Notation3 (N3) reasoner in JavaScript.",
   "main": "./index.js",
   "keywords": [

package/test/api.test.js

@@ -1245,35 +1245,6 @@ ${U('o1')} ${U('path')} (${U('c')} ${U('d')}).
     ],
   },
 
-  {
-    name: '49c rdf:first/rest bind an unbound rule blank to an N3 list literal',
-    opt: { proofComments: false },
-    input: `@prefix : <http://example.org/> .
-
-(1) <http://a.example/p> <http://a.example/o> .
-
-{
-  _:el1 rdf:first 1 .
-  _:el1 rdf:rest rdf:nil .
-  _:el1 <http://a.example/p> <http://a.example/o> .
-}
-=>
-{
-  :result :has :success-literal-25 .
-}.
-
-{ :result :has :success-literal-25 . }
-=>
-{
-  :test :is true .
-}.
-`,
-    expect: [
-      /:result\s+:has\s+:success-literal-25\s*\./,
-      /:test\s+:is\s+true\s*\./,
-    ],
-  },
-
   {
     name: '50 rdf collection materialization: rdf:first/rdf:rest triples become list terms',
     opt: { proofComments: false },
@@ -1298,6 +1269,38 @@ _:l2 rdf:rest rdf:nil.
   // Newer eyeling.js features
   // -------------------------
 
+  {
+    name: '50b regression: rdf:first/rest with variable subject binds existing N3 list term',
+    opt: { proofComments: false },
+    input: `@prefix : <http://example.org/> .
+
+(1) <http://a.example/p> <http://a.example/o> .
+
+{
+    _:el1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> 1 .
+    _:el1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
+    _:el1 <http://a.example/p> <http://a.example/o> .
+}
+=>
+{
+    :result :has :success-literal-25.
+}.
+
+{} => {
+    :test :contains :success-literal-25.
+}.
+
+{
+    :result :has :success-literal-25.
+}
+=>
+{
+    :test :is true.
+}.
+`,
+    expect: [/:result\s+:has\s+:success-literal-25\s*\./, /:test\s+:is\s+true\s*\./],
+  },
+
   {
     name: '51 automatic output rendering: prints log:outputString values ordered by key (subject)',
     opt: ['-n'],
@@ -1425,6 +1428,111 @@ res:CITY_Chañaral rdfs:label "Chañaral".
     expect: [/:result\s+:has\s+:success-literal-24\s*\./, /:test\s+:is\s+true\s*\./],
   },
 
+  {
+    name: '52d regression: @base and @prefix remapping resolve relative IRIs incrementally',
+    opt: { proofComments: false },
+    input: `# Reference: https://www.w3.org/TR/turtle/#sec-iri-references
+@base <http://foo/bar/> .
+<a1> <b1> <c1> .
+@base <http://example.org/ns/> .
+<a2> <http://example.org/ns/b2> <c2> .
+@base <foo/> .
+<a3> <b3> <c3> .
+@prefix : <bar#> .
+:a4 :b4 :c4 .
+@prefix : <http://example.org/ns2#> .
+:a5 :b5 :c5 .
+
+{
+    <http://foo/bar/a1> <http://foo/bar/b1> <http://foo/bar/c1> .
+    <http://example.org/ns/a2> <http://example.org/ns/b2> <http://example.org/ns/c2> .
+    <http://example.org/ns/foo/a3> <http://example.org/ns/foo/b3> <http://example.org/ns/foo/c3> .
+    <http://example.org/ns/foo/bar#a4> <http://example.org/ns/foo/bar#b4> <http://example.org/ns/foo/bar#c4> .
+    <http://example.org/ns2#a5> <http://example.org/ns2#b5> <http://example.org/ns2#c5> .
+}
+=>
+{
+    :result :has :success-literal-28.
+}.
+
+{} => {
+    :test :contains :success-literal-28.
+}.
+
+{
+    :result :has :success-literal-28.
+}
+=>
+{
+    :test :is true.
+}.
+`,
+    expect: [/:result\s+:has\s+:success-literal-28\s*\./, /:test\s+:is\s+true\s*\./],
+  },
+
+  {
+    name: '52e regression: is/of works in blank node property lists with list values',
+    opt: { proofComments: false },
+    input: `@prefix : <http://example.org/> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+:thing :prop (1 2 3).
+
+{
+    (1 2 3) is :prop of :thing.
+    [ is :prop of :thing ].
+}
+=>
+{
+    :result :has :success-literal-29.
+}.
+
+{} => {
+    :test :contains :success-literal-29.
+}.
+
+{
+    :result :has :success-literal-29.
+}
+=>
+{
+    :test :is true.
+}.
+`,
+    expect: [/:result\s+:has\s+:success-literal-29\s*\./, /:test\s+:is\s+true\s*\./],
+  },
+
+  {
+    name: '52f regression: has works with list values in statement predicate position',
+    opt: { proofComments: false },
+    input: `@prefix : <http://example.org/> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+:thing :prop (1 2 3).
+
+{
+    :thing has :prop (1 2 3).
+}
+=>
+{
+    :result :has :success-literal-30.
+}.
+
+{} => {
+    :test :contains :success-literal-30.
+}.
+
+{
+    :result :has :success-literal-30.
+}
+=>
+{
+    :test :is true.
+}.
+`,
+    expect: [/:result\s+:has\s+:success-literal-30\s*\./, /:test\s+:is\s+true\s*\./],
+  },
+
   {
     name: '53 --stream: prints prefixes used in input (not just derived output) before streaming triples',
     opt: ['--stream', '-n'],