Discussion: adding the concept of an RDF Message

[pietercolpaert]

RDF Messages is a small yet potentially impactful proposal from the W3C RSP CG for adding the concept of a set of quads that belong together as a single communicative act to the RDF model.

Contrary to just an array of quads, an RDF Message cannot be automatically merged with other quads or messages. An assertion step is needed to interpret the message when processing it.

E.g., a stream of messages may include 3 sensor observations, from which I might want to select the “latest” observation based on a property in the message (the contents of a message is up to the message stream designer, this is just a toy example below of what is possible).

@message .
<sensor1> :value 36 ;
    :observationCounter 1 .
@message .
<sensor1> :value 37 ;
    :observationCounter 2 .
@message .
<sensor1> :value 34 ;
    :observationCounter 3 .

Effect on RDF JS:

• Model: A new type in the data model: RDF.Message which is nothing more than an RDF.Quad[], with this property that developers understand that they must interpret the contents with an RDF Message Stream Profile
• Parsers and serializers: We’d introduce (on-going) extensions on top of RDF1.2 serializations that allow to keep the quads grouped when writing or reading Message streams and/or logs.

We don’t need another type of stream, but might want to extend the text in https://rdf.js.org/stream-spec/#stream-interface that RDF.Message would also be a typical type of a stream.

Proposal by a.o. @Ostrzyciel, @jpcik, @tobixdev, @keski, @pbonte and myself

[awwright]

an RDF Message cannot be automatically merged with other quads or messages. An assertion step is needed to interpret the message when processing it.

I'm not sure I follow this, is there a risk that an RDF statement would imply something false if seen in isolation? If not, then how is a graph representation insufficient?

[pietercolpaert]

@awwright Thanks for considering the proposal!

I wrote this out in a blog post here: https://pietercolpaert.be/linkeddata/2025/09/30/named-graphs

Concrete answers to your questions:

1. Is there a risk that an RDF statement implies something false if seen in isolation?

Yes, in practice there is a risk of misinterpretation. More precisely: a triple that is only meant to hold in some context can be mistaken for a global assertion when that context is ignored.

For example, imagine two observations:

import { namedNode, literal, quad } from '@rdfjs/data-model'

const obs1 = namedNode('https://example.org/obs/1')
const obs2 = namedNode('https://example.org/obs/2')
const me = namedNode('https://example.org/me')
const age = namedNode('http://xmlns.com/foaf/0.1/age')
const generatedAtTime = namedNode('http://www.w3.org/ns/prov#generatedAtTime')
const xsdDateTime = namedNode('http://www.w3.org/2001/XMLSchema#dateTime')

const msg1 = [
  quad(obs1, generatedAtTime, literal('2025-09-23T12:00:00Z', xsdDateTime)),
  quad(me, age, literal('25'), obs1),
]

const msg2 = [
  quad(obs2, generatedAtTime, literal('2026-09-23T12:00:00Z', xsdDateTime)),
  quad(me, age, literal('26'), obs2),
]

Each age statement is fine in its own observation context. The problem starts when an application flattens both named graphs into the default graph, or otherwise ignores the context. Then the consumer just sees two unconditional-looking assertions about the same subject.

With our proposal we want to make sure that the concept of a group of statements as communicated together is added to the RDF model, and thus also in RDF-JS.

2. Why is a graph representation insufficient?

Because this is not only about graph membership; it is also about message boundaries.

Named graphs can say “these triples are in graph G”, but they do not say “these quads together were one communicative act and must be interpreted atomically”. A single message may contain quads in several graphs: e.g. one graph for content, one for a signature, one for metadata about receipt/provenance.

At that point, named graphs alone do not tell parsers and serializers where one message starts and ends. If you serialize a stream or log containing quads from multiple named graphs, RDF 1.1 gives you no standard way to preserve those boundaries. Consumers then have to reconstruct the package heuristically.

So I’d say named graphs are useful for contextual assertions, but RDF Messages solve a different problem: preserving the boundary of a single communicative act.

[awwright]

Yes, in practice there is a risk of misinterpretation. More precisely: a triple that is only meant to hold in some context can be mistaken for a global assertion when that context is ignored.

but they do not say “these quads together ... must be interpreted atomically”.

I believe this is impossible, since RDF statements are supposed to be universal.

As an example, suppose I have a Web application that consists of an RDF graph store, an HTML+RDFa template, and an HTTP server that responds to requests by filling variables/placeholders in the HTML template with statements from the RDF graph, such that the resulting RDFa describes a subset of the backend graph store. Since the HTML template might be anything, you don't know what subset of statements the user will be able to read out of the RDFa. So every possible subset of RDF statements must be correct when interpreted in isolation.

At that point, named graphs alone do not tell parsers and serializers where one message starts and ends. If you serialize a stream or log containing quads from multiple named graphs, RDF 1.1 gives you no standard way to preserve those boundaries. Consumers then have to reconstruct the package heuristically.

Is there a practical reason the consumer would need to know both the content of the RDF triples, and the order and manner in which they were received?

Can't you store this as a data as RDF equally well? e.g. a resource that is an ref:Seq of Message resources that, in turn, points to the graph URIs for the content and signature, and lists additional metadata? If not, that would involve expanding the semantics of RDF itself.

[pietercolpaert]

I believe this is impossible, since RDF statements are supposed to be universal.

Supposedly, yes, but not in practice :-) See https://pietercolpaert.be/linkeddata/2025/09/30/named-graphs

Is there a practical reason the consumer would need to know both the content of the RDF triples, and the order and manner in which they were received?

Yes, see the use cases in the spec: https://w3c-cg.github.io/rsp/spec/messages#examples

There’s always a way to store this as well in RDF using for example containers as you propose. But also reification in RDF1.2 could instead be done using an rdf:List (e.g. <triple1> rdf:reifies ( <s> <p> <o> ) . ) but still they decided to add the concept of a triple term to RDF1.2 to make sure systems can support more interoperably. In the same way, I think for message broker-like use cases in Linked Data Event Streams, RDF Stream Processing, PROV-O, SSN/SOSA, ActivityStreams, Nanopublications, etc., this pattern would be very useful to have. It’s what for example Jelly RDF does with something they call “frames” or why Linked Data Event Streams clients use an RDF profile algorithm specification so that understanding the concept of a “message” is not just up to a heuristic.

[awwright]

Yes, I definitely agree RDF semantics doesn't describe graphs and especially datasets well enough to be widely useful...

After reading the links, I'm still not clear why a heuristic would ever be necessary to accomplish your goal, I can't say I've run into the problem you're describing either.

Your post in the first link opens with the sentence "...about the semantics of named graphs that were left open" and to me this could plausibly mean two things, that semantics of named graphs are undefined, or that named graphs are uncapped, and it's not clear which interpretation this uses reading the rest of the post.

Here's what I understand so far:

Supposedly, yes, but not in practice :-)

I don't see the article addressing that question, though it states some problems with RDF nicely. I mean a situation like assuming "This graph says Alice owns one stamp, therefore Alice owns exactly one stamp" (instead of at least one stamp). Though you may have an additional statement like "Alice owns exactly the stamps mentioned in graph G" which is possible since I understand individual graphs are capped (can be completely enumerated, let's ignore the fact they can change over time for now). (Although there's another problem in that two different URIs may still identify the same stamp, let's assume there's a statement for that too.)

So while you can query a single graph like "How many stamps are described in graph G?" you can't take a strict subset of G and present only that subset to someone else as graph G, that would be akin to truncating an xsd:string and saying it's the same RDF statement, or truncating a Turtle file and saying it's the same file.

So if I understand correctly, you have some networked application that transmits e.g. Turtle files around to transfer data, and some part of this application needs to operate on the complete graph, waiting until the entire graph is received to complete processing. You have many of these messages you want to talk about at the same time. While you could concatenate all of the Turtle files together, you also want to preserve the fact these were delivered in separate documents. But isn't this exactly what a named graph is for, and can't you represent this as a dataset?

That is, you have the ability to mint a URI, so assign all of the statements from a Turtle file to a graph URI identifying the statements within that Turtle file. (Since the URI you are minting is under your authority, it will not clash with any graph URIs in quads, in the case of TriG.)

So hopefully if I understand the problem correctly, could you clarify why a dataset is insufficient for this? Do you need to preserve the ordering of the statements too? I'm not sure how a heuristic comes into play when you can ask "return me the complete list of statements that was delivered in G".

---

In response to some of your thoughts in your post, I think one common misconception is around the nature of the "default graph". The default graph is not some unnamed graph separate from the named graphs. It is simply those triples within the dataset not known to belong to any named graph, but that still exists in the graph of triples in the dataset.

A quad is an assertion that a particular triple exists in a particular graph, and a graph is a particular (capped) set of triples, so for each triple inside the graph, this implies a quad (that asserts said triple exists in said graph).

Finally, there is much confusion around the nature of a dataset: is a dataset a set of graphs, or just a set of quads—this is what needs to be clarified. In the former case, you can recreate complete graphs, and in the latter, there are no (capped) graphs, only subsets of graphs. (There is plausibly a need for both, and so these should have different names!)

---

Thanks for entertaining my questions!

[pietercolpaert]

After reading the links, I'm still not clear why a heuristic would ever be necessary to accomplish your goal, I can't say I've run into the problem you're describing either.

The goal is not that overly complex and should not be overthought, so let’s us the example I started with in the beginning: a sensor putting observations on a stream (e.g., using websockets, a message broker, a Linked Data Event Stream, ...).

<sensor1> :value 36 ;
   :property <X> .

You could argue indeed that this example is very poor modeling, yet the triples that are part of the message are just the triples attached to <sensor1>, which woul dindeed make sense. The “heuristic” therefore becomes: the message is the subject-based star-pattern of <sensor1>.

<sensor1> a ex:Sensor;
  ex:otherEntity <entity2> ;
  ex:otherEntity [
    ex:label "Yet another entity" .
  ] .
<entity2> a ex:Type ;
  ex:label "another entity" .

The heuristic becomes more complex from the moment your messages of course get more complex: what do you do in this case with the other entity linked as a blank node? The Concise Bounded Description heuristic argues you should include it on top of the subject based star pattern, but not include <entity2>, but in this case, I intended <entity2> to be part of the message. There’s no way for the consumer to know anymore.

The examples above would be considered poor modeling because when merging the triples with the triples from other messages, it might appear as if the sensor has multiple values, and there’s no way to do a contextual assertion anymore to understand when sensor1 had a certain value. It should in fact use a named graph for this purpose as you indicated:

_:b0 {
 <sensor1> :value 36 ;
    :property <X> .
} .
_:b0 prov:generatedAtTime "x" .

The named graph could be added from the moment the message stream is consumed, or it could be added by the publisher itself. This works, but now we get into the territory that named graphs cannot solve anymore: what if I now want to create a “log” in a file of messages that I want to replay later on? Named graphs are not the solution for that for 2 reasons:

1. If I use a named graph identifier for a message, it could still be that my TRiG file log has a quad at the entire end of my big log file with that named graph identifier: I can thus not stream out messages, I’ll need to read the entire file and load it into memory before I can replay the stream.
2. I actually also want to include the triple about the named graph in another named graph (such as the default graph in the latter example) in the message here in order to then do the contextual assertion.

I could do that using a newline delimited JSON-LD file, or in a parquet file, or using Jelly RDF. However, there’s no concept in RDF-JS, or RDF in general at this moment, that captures this idea interoperably across all of RDF. This is the proposal however: let’s standardize this simple concept, so we can serialize / deserialize stream logs from disk.

[awwright]

If I use a named graph identifier for a message, it could still be that my TRiG file log has a quad at the entire end of my big log file with that named graph identifier: I can thus not stream out messages, I’ll need to read the entire file and load it into memory before I can replay the stream.

I see the trouble: We need a way to denote EOF for a particular graph when streaming quads. (This would also solve the problem of denoting an empty graph within a Dataset.)

That is, you shouldn't need to assume there might be additional quads that "add" triples to a graph after it has already been filled out. Since graphs are exact sets, adding triples to the graph creates a new, different graph. So if I have a TriG document like:

:G {:a :b :d.}
:G {:c :d e.}

This is defining the graph to be two different sets of triples, and therefore poses a contradiction. (While TriG says "a graph IRI or blank node may be used as label for more than one graph statements", it doesn't say what you must do in this situation; TriG allows for all sorts of contradictions and there is no reason to forbid this.)

In fact, the very notion of "streaming quads" poses a problem because, like I said earlier, a set quads does not denote a graph, only a subset of a graph.

So if while streaming a TriG document you reach the end of a wrappedGraph production, that ought to indicate EOF for the definition of that graph. While the TriG semantics are not clear about this, this ought to be clarified.

In any event, the current API interfaces don't have any mechanism for graph-level EOF events mid-stream (named or otherwise), only an EOF for the whole stream. This is definitely a deficiency.

[pietercolpaert]

A demo of this working can now be found here: https://www.pieter.pm/rdf-parser.ts/example/ → check the text example.

In my project I would love to be able to use RDF JS types for this as well, and define in the RDFJS datamodel:

• MessageSink / MessageSource
• MessageQuad<Q extends RDF.BaseQuad = RDF.Quad>: [{ quad: Q; messageCounter: number }]
• MessageStream<MessageQuad>: A stream of MessageQuad entries.