eyeling 1.24.31 → 1.24.33

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;

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/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

package/examples/input/rdf-messages.trig

@@ -1,90 +1,47 @@
-# ==========================
-# RDF Messages input sidecar
-# ==========================
+# ===============================
+# RDF Messages parser-level input
+# ===============================
 #
 # 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.
+# It is a true RDF Message Log. VERSION "1.2-messages" tells Eyeling to parse
+# MESSAGE delimiters as message boundaries before ordinary N3 reasoning starts.
+# Eyeling then materializes an internal eymsg: replay view with ordered envelopes
+# and one payload graph per non-empty 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 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#> .
-@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#> .
-@prefix see: <https://example.org/see#> .
-@prefix in: <https://example.org/see/input#> .
-
-: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 .
-
-: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:payload001 {
-  _:m001b0 a sosa:Observation .
-  _:m001b0 sosa:madeBySensor :thermometerA .
-  _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z"^^xsd:dateTime .
-  _:m001b0 sosa:hasSimpleResult 22 .
-}
-
-in:payload003 {
-  _:m003b0 a sosa:Observation .
-  _:m003b0 sosa:madeBySensor :thermometerA .
-  _:m003b0 sosa:resultTime "2026-05-12T18:25:00Z"^^xsd:dateTime .
-  _:m003b0 sosa:hasSimpleResult 23 .
-}
-
-in:metadata {
-  in:run a see:InputDataset .
-  in:run see:name "rdf_messages" .
-  in:run see:title "RDF Messages" .
-  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" .
-}
+# The second message is deliberately empty. The first and third messages both use
+# the source-local blank-node label _:b0. Because blank-node labels are scoped to
+# each RDF Message, Eyeling rewrites them into distinct internal blank nodes.
+
+VERSION "1.2-messages"
+PREFIX : <https://eyereasoner.github.io/eyeling/examples/rdf-messages#>
+PREFIX sosa: <http://www.w3.org/ns/sosa/>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
+PREFIX see: <https://example.org/see#>
+PREFIX in: <https://example.org/see/input#>
+
+# Message 1: first temperature observation plus example metadata.
+_:b0 a sosa:Observation ;
+  sosa:madeBySensor :thermometerA ;
+  sosa:resultTime "2026-05-12T18:20:00Z"^^xsd:dateTime ;
+  sosa:hasSimpleResult 22 .
+
+in:run a see:InputDataset ;
+  see:name "rdf_messages" ;
+  see:title "RDF Messages" ;
+  see:sourceFile "examples/rdf-messages.n3" ;
+  see:description "A true RDF 1.2 Message Log. Eyeling parses VERSION 1.2-messages and MESSAGE delimiters into replayable internal message envelopes." ;
+  see:compiler "Eyeling RDF Message Log input" .
+
+MESSAGE
+
+# Message 2: empty heartbeat.
+MESSAGE
+
+# Message 3: second observation. The _:b0 label is intentionally reused here.
+_:b0 a sosa:Observation ;
+  sosa:madeBySensor :thermometerA ;
+  sosa:resultTime "2026-05-12T18:25:00Z"^^xsd:dateTime ;
+  sosa:hasSimpleResult 23 .

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

@@ -3,12 +3,10 @@
 ## Source files  
 
 - [N3 rules](../rdf-message-microgrid.n3)  
-- [Input TriG](../input/rdf-message-microgrid.trig)  
+- [Input RDF Message Log](../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.  
+Storm clinic microgrid accepted: 4 parser-replayed RDF Messages were processed 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.  
+## Why this is an RDF Message Log example  
+The input now uses VERSION \"1.2-messages\" and MESSAGE delimiters. Eyeling parses those boundaries internally into an eymsg: replay view, so the rules do not need hand-written application envelopes. Each non-empty message is inspected with log:includes inside its own payload formula, and the final delimiter-only message is replayed as an empty heartbeat. The decision combines only the derived conclusions needed for load shedding while keeping the explanation tied to explicit message boundaries.  

package/examples/output/rdf-messages.md

@@ -3,12 +3,10 @@
 ## Source files  
 
 - [N3 rules](../rdf-messages.n3)  
-- [Input TriG](../input/rdf-messages.trig)  
+- [Input RDF Message Log](../input/rdf-messages.trig)  
 
 ## Answer  
-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.  
+RDF Message Log accepted: 3 parser-replayed message boundaries are preserved. The middle message is an empty heartbeat, and the same source-local blank-node label is safely reused because Eyeling scopes blank nodes per message.  
 
 ## Explanation  
-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.  
+The input now uses VERSION \"1.2-messages\" and MESSAGE delimiters instead of hand-written application envelope facts. Eyeling parses the log internally into an eymsg: replay view with ordered envelopes and one payload graph per non-empty message. The rules inspect each payload with log:includes inside its own message formula, 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 and remain contextualized by their message boundaries.  

package/examples/rdf-message-microgrid.n3

@@ -6,63 +6,46 @@
 #
 #   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
+# 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
 # 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.
+# The companion input is now a true parser-level RDF Message Log. Eyeling handles
+# VERSION "1.2-messages" and MESSAGE delimiters internally, then exposes a replay
+# view using eymsg: ordered envelopes and payload graphs. The N3 rules therefore
+# focus on the domain decision rather than recreating log replay by hand.
 
 @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 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#>.
 
-# 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.
+# Every envelope in the replay view is an explicit parser-recognized boundary.
 {
-  ?Log a rmsg:MessageLog;
-    rmsg:message ?Message.
-  ?Message a rmsg:MessageEnvelope;
-    rmsg:offset ?Offset.
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:envelope ?Message.
+  ?Message a eymsg:MessageEnvelope;
+    eymsg:offset ?Offset.
 } => {
-  ?Message rmsg:boundaryExplicit true.
-  ?Log rmsg:replayContains ?Message.
+  ?Message :boundaryExplicit true.
+  ?Stream :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 a eymsg:MessageEnvelope;
+    eymsg:payloadKind eymsg:empty.
 } => {
-  ?Message rmsg:emptyMessageAllowed true.
+  ?Message :emptyMessageAllowed true.
 }.
 
-# Inspect the life-safety message inside its own payload graph.
+# Inspect the life-safety message inside its own parser-replayed payload graph.
 {
-  ?Message rmsg:payloadKind :lifeSafetyLoads;
-    rmsg:payloadGraph ?Payload.
+  ?Message eymsg:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes {
     :oxygenConcentrator :requiresWatts ?Oxygen.
@@ -70,14 +53,13 @@
   }.
   (?Oxygen ?Fridge) math:sum ?CriticalWatts.
 } => {
-  :clinicMicrogrid rmsg:criticalWatts ?CriticalWatts.
-  :clinicMicrogrid rmsg:mustKeep :oxygenConcentrator, :vaccineFridge.
+  :clinicMicrogrid :criticalWatts ?CriticalWatts.
+  :clinicMicrogrid :mustKeep :oxygenConcentrator, :vaccineFridge.
 }.
 
 # Inspect the power-status message atomically.
 {
-  ?Message rmsg:payloadKind :powerStatus;
-    rmsg:payloadGraph ?Payload.
+  ?Message eymsg:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes {
     :batteryBank :availableWatts ?BatteryWatts.
@@ -85,57 +67,61 @@
   }.
   (?BatteryWatts ?SolarWatts) math:sum ?AvailableWatts.
 } => {
-  :clinicMicrogrid rmsg:availableWatts ?AvailableWatts.
+  :clinicMicrogrid :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.
+  ?Message eymsg:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes {
     :evChargers :shedWatts ?ShedWatts.
   }.
 } => {
-  :clinicMicrogrid rmsg:deferrableWatts ?ShedWatts.
-  :clinicMicrogrid rmsg:mayDefer :evChargers.
+  :clinicMicrogrid :deferrableWatts ?ShedWatts.
+  :clinicMicrogrid :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.
+  :clinicMicrogrid :criticalWatts ?CriticalWatts;
+    :availableWatts ?AvailableWatts;
+    :deferrableWatts ?ShedWatts;
+    :mustKeep :oxygenConcentrator, :vaccineFridge;
+    :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.
+  :clinicMicrogrid :protectedBudgetWatts ?ProtectedBudget.
+  :clinicMicrogrid :resilienceAction :protectClinic.
+  :clinicMicrogrid :keeps :oxygenConcentrator, :vaccineFridge.
+  :clinicMicrogrid :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.
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:orderedEnvelopes ?Messages;
+    eymsg:firstEnvelope ?M1.
   ?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.
+  ?M1 :boundaryExplicit true;
+    eymsg:nextEnvelope ?M2.
+  ?M2 :boundaryExplicit true;
+    eymsg:nextEnvelope ?M3.
+  ?M3 :boundaryExplicit true;
+    eymsg:nextEnvelope ?M4.
+  ?M4 :boundaryExplicit true;
+    :emptyMessageAllowed true.
+  :clinicMicrogrid :criticalWatts ?CriticalWatts;
+    :availableWatts ?AvailableWatts;
+    :deferrableWatts ?ShedWatts;
+    :protectedBudgetWatts ?ProtectedBudget;
+    :resilienceAction :protectClinic.
+  ("# rdf-message-microgrid\n\n## Source files\n\n- [N3 rules](../rdf-message-microgrid.n3)\n- [Input RDF Message Log](../input/rdf-message-microgrid.trig)\n\n## Answer\nStorm clinic microgrid accepted: %d parser-replayed RDF Messages were processed 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 Message Log example\nThe input now uses VERSION \\\"1.2-messages\\\" and MESSAGE delimiters. Eyeling parses those boundaries internally into an eymsg: replay view, so the rules do not need hand-written application envelopes. Each non-empty message is inspected with log:includes inside its own payload formula, and the final delimiter-only message is replayed as an empty heartbeat. The decision combines only the derived conclusions needed for load shedding while keeping the explanation tied to explicit message boundaries." ?Count ?CriticalWatts ?AvailableWatts ?ShedWatts ?ProtectedBudget) string:format ?Block.
 } => {
   :rdfMessageMicrogridExample log:outputString ?Block.
-  :rdfMessageMicrogridExample :demonstrates :AtomicMessageContext, :EmptyHeartbeat, :ReplayableMessageLog, :ResilientDecisionSupport.
+  :rdfMessageMicrogridExample :demonstrates :ParserLevelMessageLog, :AtomicMessageContext, :EmptyHeartbeat, :ReplayableMessageLog, :ResilientDecisionSupport.
 }.

package/examples/rdf-messages.n3

@@ -11,115 +11,102 @@
 # 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
+# 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:
+# This example now uses the parser-level syntax directly: the companion input
+# starts with VERSION "1.2-messages" and separates messages with MESSAGE
+# delimiters. Eyeling handles those delimiters before N3 reasoning starts and
+# exposes an internal eymsg: replay view: a stream resource, ordered envelopes,
+# next-envelope links, payload kind, and one payload graph per non-empty message.
 #
-#   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.
+# The rules below validate that replay view. They never hand-model message
+# envelopes in the TriG sidecar. They inspect payload graphs atomically, accept
+# the delimiter-only heartbeat, and check that a reused source-local blank-node
+# label becomes two distinct message-scoped blank nodes.
 
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-messages#>.
-@prefix rmsg: <https://eyereasoner.github.io/eyeling/examples/rdf-messages/vocab#>.
-@prefix prov: <http://www.w3.org/ns/prov#>.
+@prefix eymsg: <https://eyereasoner.github.io/eyeling/vocab/message#>.
 @prefix sosa: <http://www.w3.org/ns/sosa/>.
-@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#>.
 
-# 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.
+# Every parser-replayed envelope is an explicit message boundary.
 {
-  ?Log a rmsg:MessageLog;
-    rmsg:message ?Message.
-  ?Message a rmsg:MessageEnvelope;
-    rmsg:offset ?Offset.
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:envelope ?Envelope.
+  ?Envelope a eymsg:MessageEnvelope;
+    eymsg:offset ?Offset.
 } => {
-  ?Message rmsg:boundaryExplicit true.
-  ?Log rmsg:replayContains ?Message.
+  ?Envelope :boundaryExplicit true.
+  ?Stream :replayContains ?Envelope.
 }.
 
-# The payload is a dataset-like named graph. Inspect it with log:includes instead
-# of merging all payload triples into the global graph.
+# Payload graphs are inspected with log:includes, so the observations remain
+# inside their message contexts instead of being silently merged.
 {
-  ?Message a rmsg:MessageEnvelope;
-    rmsg:expectedResult ?Result;
-    rmsg:payloadGraph ?Payload.
+  ?Envelope a eymsg:MessageEnvelope;
+    eymsg:payloadKind eymsg:nonEmpty;
+    eymsg:payloadGraph ?Payload.
   ?Payload log:nameOf ?PayloadContext.
   ?PayloadContext log:includes { ?Observation sosa:hasSimpleResult ?Result. }.
 } => {
-  ?Message rmsg:payloadResult ?Result.
-}.
-
-# 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 rmsg:MessageEnvelope;
-    rmsg:payloadKind :heartbeat.
-} => {
-  ?Message rmsg:emptyMessageAllowed true.
-  :HeartbeatEvidence :accepted ?Message.
+  ?Envelope :payloadObservation ?Observation.
+  ?Envelope :payloadResult ?Result.
 }.
 
-# 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.
+# Empty messages are valid RDF Messages. The second envelope is a heartbeat even
+# though it has no payload graph.
 {
-  ?First a rmsg:MessageEnvelope;
-    rmsg:localBlankLabel ?Label.
-  ?Second a rmsg:MessageEnvelope;
-    rmsg:localBlankLabel ?Label.
-  ?First log:notEqualTo ?Second.
+  ?Envelope a eymsg:MessageEnvelope;
+    eymsg:payloadKind eymsg:empty.
 } => {
-  :BlankNodeScope :reusedLabel ?Label.
-  :BlankNodeScope :isPerMessage true.
+  ?Envelope :emptyMessageAllowed true.
+  :HeartbeatEvidence :accepted ?Envelope.
 }.
 
-# Different observations from the same sensor are not a global contradiction:
-# by default, message payloads remain separate communication contexts.
+# The input deliberately reuses the same source-local blank-node label in message
+# 1 and message 3. Eyeling rewrites labels per message, so these are distinct
+# blank nodes after replay.
 {
-  ?First a rmsg:MessageEnvelope;
-    rmsg:payloadResult ?FirstResult.
-  ?Second a rmsg:MessageEnvelope;
-    rmsg:payloadResult ?SecondResult.
-  ?FirstResult math:notEqualTo ?SecondResult.
-  ?First log:notEqualTo ?Second.
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:firstEnvelope ?First.
+  ?First eymsg:nextEnvelope ?Second;
+    :payloadObservation ?FirstObservation;
+    :payloadResult ?FirstResult.
+  ?Second eymsg:nextEnvelope ?Third;
+    :emptyMessageAllowed true.
+  ?Third :payloadObservation ?ThirdObservation;
+    :payloadResult ?ThirdResult.
+  ?FirstObservation log:notEqualTo ?ThirdObservation.
+  ?FirstResult math:notEqualTo ?ThirdResult.
 } => {
+  :BlankNodeScope :reusedSourceLabelIsMessageScoped true.
   :MessageContext :differentObservationsStayContextual true.
 }.
 
-# 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.
+# The Eyeling verdict is emitted only when all parser-replayed message-specific
+# validations have been derived from the stream, ordered envelopes, payload
+# graphs, and built-ins.
 {
-  :temperatureLog rmsg:orderedMessages ?Messages.
+  ?Stream a eymsg:RDFMessageStream;
+    eymsg:orderedEnvelopes ?Messages;
+    eymsg:firstEnvelope ?First.
   ?Messages list:length ?Count.
-  :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.
+  ?First :boundaryExplicit true;
+    :payloadResult ?FirstResult;
+    eymsg:nextEnvelope ?Second.
+  ?Second :boundaryExplicit true;
+    :emptyMessageAllowed true;
+    eymsg:nextEnvelope ?Third.
+  ?Third :boundaryExplicit true;
+    :payloadResult ?SecondResult.
+  :BlankNodeScope :reusedSourceLabelIsMessageScoped 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 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.
+  ("# rdf-messages\n\n## Source files\n\n- [N3 rules](../rdf-messages.n3)\n- [Input RDF Message Log](../input/rdf-messages.trig)\n\n## Answer\nRDF Message Log accepted: %d parser-replayed message boundaries are preserved. The middle message is an empty heartbeat, and the same source-local blank-node label is safely reused because Eyeling scopes blank nodes per message.\n\n## Explanation\nThe input now uses VERSION \\\"1.2-messages\\\" and MESSAGE delimiters instead of hand-written application envelope facts. Eyeling parses the log internally into an eymsg: replay view with ordered envelopes and one payload graph per non-empty message. The rules inspect each payload with log:includes inside its own message formula, 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 and remain contextualized by their message boundaries." ?Count ?FirstResult ?SecondResult) string:format ?Block.
 } => {
   :rdfMessagesExample log:outputString ?Block.
-  :rdfMessagesExample :demonstrates :ExplicitBoundaries, :AtomicMessageContext, :EmptyHeartbeat, :MessageScopedBlankNodes, :ReplayableMessageLog.
+  :rdfMessagesExample :demonstrates :ParserLevelMessageLog, :ExplicitBoundaries, :AtomicMessageContext, :EmptyHeartbeat, :MessageScopedBlankNodes.
 }.

package/eyeling.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;

package/lib/builtins.js

@@ -1196,25 +1196,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;
 
@@ -1225,6 +1236,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;
@@ -1291,7 +1303,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 };
@@ -1358,7 +1371,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;

package/package.json

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

package/test/api.test.js

@@ -323,6 +323,35 @@ const cases = [
       assert.match(out, /\\"2023-04-01T18:06:04Z\\"\^\^xsd:dateTime \./);
     },
   },
+  {
+    name: '00d math comparison accepts xsd:dateTimeStamp with xsd:dateTime',
+    opt: { proofComments: false },
+    input: `
+@prefix : <http://example.org/> .
+@prefix math: <http://www.w3.org/2000/10/swap/math#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+{
+  "2026-05-30T00:00:00Z"^^xsd:dateTimeStamp math:notGreaterThan "2027-02-12T00:00:00Z"^^xsd:dateTime .
+}
+=>
+{
+  :mixedDateTimeStampCompare :is true .
+}.
+
+{
+  "2026-05-30T00:00:00Z"^^xsd:dateTimeStamp math:notGreaterThan "2026-05-30T00:00:00Z"^^xsd:dateTimeStamp .
+}
+=>
+{
+  :sameDateTimeStampCompare :is true .
+}.
+`,
+    expect: [
+      /:mixedDateTimeStampCompare\s+:is\s+true\s*\./,
+      /:sameDateTimeStampCompare\s+:is\s+true\s*\./,
+    ],
+  },
   {
     name: '01 forward rule: p -> q',
     opt: { proofComments: false },