eyeling 1.24.31 → 1.25.0

package/HANDBOOK.md

@@ -793,7 +793,7 @@ Implementation: deterministic Skolem IDs live in `lib/skolem.js`; the per-firing
 A rule whose conclusion is `false` is treated as a hard failure. During forward chaining:
 
 - Eyeling proves the premise (it only needs one solution)
-- if the premise is provable, it prints a message and exits with status code 2
+- if the premise is provable, it prints a message and exits with status code 65 (`EX_DATAERR` in Unix `sysexits.h` terminology)
 
 This is Eyeling’s way to express hard consistency checks and detect inconsistencies.
 
@@ -3417,7 +3417,7 @@ So Eyeling is not only implementing the semantics document; it is also defining
 
 #### G.2.4 Inference fuses (`=> false`) are an engine-level procedural feature
 
-The semantics document discusses `false` in relation to implication and constraints. Eyeling turns `{ ... } => false` into an engine-level hard failure with a visible message and failing exit status. That is a practical tooling feature: it lets a rule act like a checked invariant.
+The semantics document discusses `false` in relation to implication and constraints. Eyeling turns `{ ... } => false` into an engine-level hard failure with a visible message and exit status 65 (`EX_DATAERR`). That is a practical tooling feature: it lets a rule act like a checked invariant.
 
 This is very useful in real programs, but it is an operational behavior of the reasoner, not something a model-theoretic semantics “executes.”
 

package/dist/browser/eyeling.browser.js

@@ -1207,25 +1207,36 @@ function parseXsdDateTerm(t) {
   return d;
 }
 
+function isXsdDateTimeDatatype(dt) {
+  return dt === XSD_NS + 'dateTime' || dt === XSD_NS + 'dateTimeStamp';
+}
+
 function parseXsdDatetimeTerm(t) {
   if (!(t instanceof Literal)) return null;
   const [lex, dt] = literalParts(t.value);
-  if (dt !== XSD_NS + 'dateTime') return null;
+  if (!isXsdDateTimeDatatype(dt)) return null;
   const val = stripQuotes(lex);
+
+  // xsd:dateTimeStamp is a subtype of xsd:dateTime with a required timezone.
+  // Keep xsd:dateTime's existing permissive behaviour, but reject stamp
+  // lexicals that do not actually carry the required timezone.
+  if (dt === XSD_NS + 'dateTimeStamp' && !/(Z|[+-]\d{2}:\d{2})$/.test(val)) return null;
+
   const d = new Date(val);
   if (Number.isNaN(d.getTime())) return null;
   return d; // Date in local/UTC, we only use timestamp
 }
 
 function parseXsdDateTimeLexParts(t) {
-  // Parse *lexical* components of an xsd:dateTime literal without timezone normalization.
+  // Parse *lexical* components of an xsd:dateTime/dateTimeStamp literal without timezone normalization.
   // Returns { yearStr, month, day, hour, minute, second, tz } or null.
   if (!(t instanceof Literal)) return null;
   const [lex, dt] = literalParts(t.value);
-  if (dt !== XSD_NS + 'dateTime') return null;
+  if (!isXsdDateTimeDatatype(dt)) return null;
   const val = stripQuotes(lex);
 
   // xsd:dateTime lexical: YYYY-MM-DDThh:mm:ss(.s+)?(Z|(+|-)hh:mm)?
+  // xsd:dateTimeStamp has the same lexical form, but with the timezone required.
   const m = /^(-?\d{4,})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})(?:\.\d+)?(Z|[+-]\d{2}:\d{2})?$/.exec(val);
   if (!m) return null;
 
@@ -1236,6 +1247,7 @@ function parseXsdDateTimeLexParts(t) {
   const minute = parseInt(m[5], 10);
   const second = parseInt(m[6], 10);
   const tz = m[7] || null;
+  if (dt === XSD_NS + 'dateTimeStamp' && !tz) return null;
 
   if (!(month >= 1 && month <= 12)) return null;
   if (!(day >= 1 && day <= 31)) return null;
@@ -1302,7 +1314,8 @@ function parseIso8601DurationToSeconds(s) {
 }
 
 function parseNumericForCompareTerm(t) {
-  // Strict: only accept xsd numeric literals, xsd:duration, xsd:date, xsd:dateTime
+  // Strict: only accept xsd numeric literals, xsd:duration, xsd:date,
+  // xsd:dateTime, and xsd:dateTimeStamp.
   // (or untyped numeric tokens).
   const bi = parseIntLiteral(t);
   if (bi !== null) return { kind: 'bigint', value: bi };
@@ -1369,7 +1382,7 @@ function parseNumOrDuration(t) {
     }
   }
 
-  // xsd:date / xsd:dateTime
+  // xsd:date / xsd:dateTime / xsd:dateTimeStamp
   const dtval = parseDatetimeLike(t);
   if (dtval !== null) {
     return dtval.getTime() / 1000.0;
@@ -5504,6 +5517,10 @@ const {
   copyQuotedGraphMetadata,
 } = require('./prelude');
 
+// Inference fuses use sysexits.h EX_DATAERR (65): input/rules made a
+// forbidden condition provable, rather than a generic usage/runtime error.
+const INFERENCE_FUSE_EXIT_CODE = 65;
+
 // In N3/Turtle, rdf:nil is the canonical IRI for the empty RDF list.
 // Eyeling represents list literals with ListTerm; ensure rdf:nil unifies with ().
 const RDF_NIL_IRI = RDF_NS + 'nil';
@@ -8432,7 +8449,7 @@ function forwardChain(facts, forwardRules, backRules, onDerived /* optional */,
         // Allow dynamic fuses: ... => ?X. where ?X becomes false
         if (dynTerm instanceof Literal && dynTerm.value === 'false') {
           __printTriggeredFuse(r, opts && opts.prefixes, s, 'Dynamic head resolved to false.');
-          __exitReasoning(2, 'Inference fuse triggered.');
+          __exitReasoning(INFERENCE_FUSE_EXIT_CODE, 'Inference fuse triggered.');
         }
 
         const dynTriples = __graphTriplesOrTrue(dynTerm);
@@ -8593,7 +8610,7 @@ function forwardChain(facts, forwardRules, backRules, onDerived /* optional */,
           // Inference fuse
           if (r.isFuse && sols.length) {
             __printTriggeredFuse(r, opts && opts.prefixes, sols[0]);
-            __exitReasoning(2, 'Inference fuse triggered.');
+            __exitReasoning(INFERENCE_FUSE_EXIT_CODE, 'Inference fuse triggered.');
           }
 
           for (const s of sols) {
@@ -9130,6 +9147,7 @@ module.exports = {
   registerBuiltinModule,
   loadBuiltinModule,
   listBuiltinIris,
+  INFERENCE_FUSE_EXIT_CODE,
 };
 
   };
@@ -9157,6 +9175,7 @@ module.exports = {
   rdfjs: dataFactory,
   main: engine.main,
   version: engine.version,
+  INFERENCE_FUSE_EXIT_CODE: engine.INFERENCE_FUSE_EXIT_CODE,
 
   // internals for playground.html
   lex: engine.lex,

package/dist/browser/index.mjs

@@ -10,6 +10,8 @@ function getBrowserApi() {
   return api;
 }
 
+export const INFERENCE_FUSE_EXIT_CODE = 65;
+
 export function reasonStream(input, opts) {
   return getBrowserApi().reasonStream(input, opts);
 }
@@ -64,6 +66,7 @@ const eyeling = {
   get version() {
     return getBrowserApi().version;
   },
+  INFERENCE_FUSE_EXIT_CODE,
   reasonStream,
   reasonRdfJs,
   rdfjs,

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

@@ -0,0 +1,273 @@
+# RDF Message Logs in Eyeling — from stream to reasoning
+
+This deck explains the example `rdf-message-flow.n3` and its input file `input/rdf-message-flow.trig`.
+
+The goal is to show, in plain language, how Eyeling can now read an RDF Message Log directly instead of asking the example data to describe its own message envelopes by hand.
+
+---
+
+## The everyday problem
+
+Many real systems do not receive one big dataset.
+
+They receive a stream of small updates:
+
+- a sensor reading,
+- a command,
+- a status heartbeat,
+- an alert,
+- another sensor reading.
+
+Each update matters as a separate communication event.
+
+If we simply merge everything into one graph, we lose the order and the boundary between messages.
+
+---
+
+## A message is a sealed packet
+
+Think of an RDF Message as a sealed packet of RDF data.
+
+Inside the packet there may be triples or named graphs.
+
+Outside the packet there is the stream order: first message, second message, third message, and so on.
+
+The important idea is:
+
+> The reasoner should know when one message ends and the next one begins.
+
+---
+
+## What an RDF Message Log adds
+
+An RDF Message Log is a replayable record of a message stream.
+
+Instead of saying “subscribe to this live channel”, the file says:
+
+> Here are the messages that arrived, in order.
+
+That makes it useful for examples, tests, audits, debugging, reproducible reasoning, and explanations.
+
+---
+
+## The new syntax in the input file
+
+The input begins with:
+
+```trig
+VERSION "1.2-messages"
+```
+
+That tells Eyeling:
+
+> This file contains message boundaries.
+
+Then each boundary is written as:
+
+```trig
+MESSAGE
+```
+
+So the file can look like this:
+
+```trig
+# message 1 data
+:temperatureFlow :highThreshold 26 .
+_:obs sosa:hasSimpleResult 21 .
+
+MESSAGE
+
+# message 2 data
+_:obs sosa:hasSimpleResult 22 .
+
+MESSAGE
+
+# message 3: empty heartbeat
+MESSAGE
+
+# message 4 data
+_:obs sosa:hasSimpleResult 28 .
+```
+
+---
+
+## What Eyeling does internally
+
+Eyeling does not treat `MESSAGE` as an ordinary RDF term.
+
+It handles it before normal N3 reasoning starts.
+
+Internally, Eyeling turns the log into a replay view:
+
+- one stream resource,
+- one envelope per message,
+- an offset for each envelope,
+- a link to the next envelope,
+- a payload graph for each non-empty message,
+- and an explicit marker for empty messages.
+
+The rules then reason over that replay view.
+
+---
+
+## Why this is better than hand-written envelopes
+
+Before this change, the example input had to describe the stream manually:
+
+- message `:m001`,
+- message `:m002`,
+- payload graph `in:payload001`,
+- next message links,
+- payload kind markers,
+- offsets.
+
+That worked, but it made the example bulky.
+
+It also mixed two concerns:
+
+1. the message-log machinery, and
+2. the domain logic of routing temperature observations.
+
+Now Eyeling handles the message-log machinery.
+
+The N3 file can focus on the logic.
+
+---
+
+## What the temperature-flow example does
+
+The example models a small stream processor.
+
+Messages move through these stages:
+
+1. ingest,
+2. validate,
+3. interpret,
+4. route,
+5. sink.
+
+The stream contains temperature readings and one empty heartbeat.
+
+The rules route normal readings to an archive sink and high readings to an alert sink.
+
+---
+
+## The empty heartbeat matters
+
+One message in the example contains no RDF triples.
+
+That is not an error.
+
+It represents a heartbeat:
+
+> “The stream is still alive, even though there is no new observation payload.”
+
+Eyeling still creates an envelope for it.
+
+That means the empty message keeps its place in the ordered replay.
+
+---
+
+## Blank nodes stay message-local
+
+The input deliberately reuses the same blank-node label in several messages:
+
+```trig
+_:obs sosa:hasSimpleResult 21 .
+
+MESSAGE
+
+_:obs sosa:hasSimpleResult 22 .
+```
+
+That does not mean both messages talk about the same blank node.
+
+In a message log, blank-node labels are scoped to the message.
+
+Eyeling rewrites them internally so each message gets its own blank nodes.
+
+---
+
+## How the N3 rules see the replay
+
+The N3 rules do not see `MESSAGE` directly.
+
+They see Eyeling’s replay vocabulary, `eymsg:`.
+
+For example, a rule can ask:
+
+```n3
+?Stream a eymsg:RDFMessageStream;
+  eymsg:firstEnvelope ?Envelope.
+```
+
+Another rule can inspect a payload:
+
+```n3
+?Envelope eymsg:payloadGraph ?Payload.
+?Payload log:nameOf ?PayloadContext.
+?PayloadContext log:includes {
+  ?Observation sosa:hasSimpleResult ?Result.
+}.
+```
+
+That keeps each message payload inside its own context.
+
+---
+
+## Back pressure in one sentence
+
+The example releases only the first envelope at the start.
+
+Each envelope must reach the sink before the next envelope is released.
+
+That gives a simple form of ordered replay or back pressure:
+
+> process this message, then release the next one.
+
+---
+
+## What the final answer says
+
+When the example succeeds, Eyeling reports that five parser-replayed envelopes moved through the flow.
+
+With a threshold of 26:
+
+- 21 is archived,
+- 22 is archived,
+- the empty heartbeat is accepted,
+- 28 becomes an alert,
+- 29 becomes an alert.
+
+The important part is not only the routing result.
+
+The important part is that the result was derived while preserving message boundaries.
+
+---
+
+## Why a wide audience should care
+
+This pattern is useful wherever data arrives over time:
+
+- sensors,
+- event logs,
+- audit trails,
+- clinical systems,
+- energy systems,
+- pub/sub channels,
+- digital twins,
+- provenance streams.
+
+You can replay the stream, reason over each message atomically, and explain what happened without flattening the whole history into one graph.
+
+---
+
+## The takeaway
+
+`MESSAGE` is the boundary.
+
+Eyeling turns those boundaries into ordered replay envelopes.
+
+The N3 rules consume the replay and focus on the domain logic.
+
+That makes the example shorter, clearer, and closer to how a real pub/sub channel would be processed.

package/examples/fuse.n3

@@ -2,7 +2,7 @@
 # Inference fuse
 # ==============
 
-# expect-exit: 2
+# expect-exit: 65
 
 @prefix : <https://eyereasoner.github.io/ns#>.
 

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

@@ -1,89 +1,56 @@
-# ===================================
-# RDF Message Microgrid input sidecar
-# ===================================
+# ==================================
+# RDF Message Microgrid message log
+# ==================================
 #
 # 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#> .
+# data arrives as a true RDF Message Log: life-safety loads, power status,
+# flexible demand, and an empty heartbeat. Eyeling parses the MESSAGE boundaries
+# internally and exposes the replay to the N3 rules as eymsg: envelopes.
 
-: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" .
+VERSION "1.2-messages"
+PREFIX : <https://eyereasoner.github.io/eyeling/examples/rdf-message-microgrid#>
+PREFIX see: <https://example.org/see#>
+PREFIX in: <https://example.org/see/input#>
 
-: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 .
+# Message 1: life-safety loads plus example metadata.
+:oxygenConcentrator a :LifeSafetyLoad ;
+  :requiresWatts 500 ;
+  :serves :respiratoryCareRoom .
 
-: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 .
+:vaccineFridge a :ColdChainLoad ;
+  :requiresWatts 120 ;
+  :serves :vaccineColdChain .
 
-: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 .
+in:run a see:InputDataset ;
+  see:name "rdf_message_microgrid" ;
+  see:title "RDF Message Microgrid" ;
+  see:sourceFile "examples/rdf-message-microgrid.n3" ;
+  see:description "A true RDF 1.2 Message Log for a storm clinic microgrid. Eyeling parses MESSAGE delimiters into replayable internal message envelopes for bounded, explainable load-shedding." ;
+  see:compiler "Eyeling RDF Message Log input" .
 
-:m004 a rmsg:MessageEnvelope .
-:m004 rmsg:offset 4 .
-:m004 prov:generatedAtTime "2026-05-15T19:03:00Z"^^xsd:dateTime .
-:m004 rmsg:payloadKind :heartbeat .
+MESSAGE
 
-in:lifeSafetyPayload {
-  :oxygenConcentrator a :LifeSafetyLoad .
-  :oxygenConcentrator :requiresWatts 500 .
-  :oxygenConcentrator :serves :respiratoryCareRoom .
+# Message 2: current power status.
+:batteryBank a :PowerReserve ;
+  :availableWatts 650 ;
+  :state :islanded .
 
-  :vaccineFridge a :ColdChainLoad .
-  :vaccineFridge :requiresWatts 120 .
-  :vaccineFridge :serves :vaccineColdChain .
-}
+:solarForecast a :NearTermForecast ;
+  :expectedWatts 150 .
 
-in:powerPayload {
-  :batteryBank a :PowerReserve .
-  :batteryBank :availableWatts 650 .
-  :batteryBank :state :islanded .
+MESSAGE
 
-  :solarForecast a :NearTermForecast .
-  :solarForecast :expectedWatts 150 .
-}
+# Message 3: flexible demand that can safely be shed.
+:evChargers a :FlexibleLoad ;
+  :shedWatts 600 ;
+  :serves :staffVehicles .
 
-in:flexPayload {
-  :evChargers a :FlexibleLoad .
-  :evChargers :shedWatts 600 .
-  :evChargers :serves :staffVehicles .
-}
+MESSAGE
 
-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" .
-}
+# Message 4: empty heartbeat. The next MESSAGE delimiter finalizes this empty
+# message and leaves no trailing payload.
+MESSAGE