Re: Hello, Semantic Complex Event Processing, and Narratology

Piotr,
Pedro,

Thank you for the hyperlink to the current specification draft of RDF Messages.

Determining which subject or subjects that each RDF message in a stream is "about" could be achieved using a special relationship, e.g., "special:about", while simultaneously using "<>" to refer to each message's base IRI.

That is, if one can use "<>" in RDF messages along with some sort of "special:about" predicate, this would enable the described scenarios.

Borrowing the first example from that specification draft, one could add a statement to connect the message to its subject or subjects:

PREFIX as: <https://www.w3.org/ns/activitystreams#>
PREFIX ex: <http://example.org/>
PREFIX special: <http://tbd.org/>

<> special:about ex:like-1 .
ex:like-1 a as:Like ;
  as:object ex:blogpost-1 ;
  as:actor <https://pietercolpaert.be/#me> .

With something like that, one could create queries utilizing the declared subject(s) of each RDF message occurring in a stream.


Best regards,
Adam

________________________________
From: Piotr Sowiński <piotr@neverblink.eu>
Sent: Wednesday, December 17, 2025 9:40 AM
To: Pedro Martinez-Julia <pedromj@ieee.org>
Cc: Adam Sobieski <adamsobieski@hotmail.com>; public-rsp@w3.org <public-rsp@w3.org>
Subject: Re: Hello, Semantic Complex Event Processing, and Narratology

Dear Adam,

Thank you for your interest in the work of the CG!

Regarding linking events to RDF messages – please have a look at the current specification draft of RDF Messages: https://w3c-cg.github.io/rsp/spec/messages
Is this aligned with your needs?
Please note that we intend RDF Messages to be as generic as possible, to allow for adding richer functionality on top of them. So, while it likely does not solve your problem 100%, it may be a part of the solution. I'm curious if you would agree with that.

Regarding SPARQL query templates – indeed, as Pedro wrote, this is a common (and useful) feature of RDF libraries, but it's not standardized. It may be worth it to check if the RDF & SPARQL WG<https://www.w3.org/groups/wg/rdf-star/> is considering or has considered such a feature. I think this feature is very generic, and is not specifically tied to streaming problems, so it's probably out of scope for the RSP CG.

The RSP CG has discussed streaming SPARQL variants in the past (see the wiki for examples in CQELS and C-SPARQL<https://www.w3.org/community/rsp/wiki/RSP_Query_Features>). There is an ongoing discussion to resume that work. However, these streaming SPARQL extensions do not use query templates, but rather rely on specialized syntax for stream processing.


On Wed, 17 Dec 2025 at 03:30, Pedro Martinez-Julia <pedromj@ieee.org<mailto:pedromj@ieee.org>> wrote:
Dear Adam,

Welcome to RSP. Please, find my comments inline.

On Tue, Dec 16, 2025 at 11:30:15PM +0000, Adam Sobieski wrote:
> RDF Stream Processing Community Group,
>
> Hello. I am new to the RSP CG and am interested in the overlaps
> between RDF stream processing, complex event processing, and
> computational narratology.
>
> I am recently exploring a number of interrelated topics and approaches
> including that event or message objects could each have an Id property
> and an accompanying semantic dataset or graph, available via an About
> property.
>
> public interface IEvent
> {
>    public INode Id { get; }
>    public ITripleStore About { get; }
> }
>
> I am considering that such interfaces would allow developers to have
> instant traction with respect to processing individual events or
> messages. Developers could be provided with semantic starting points,
> in this case the id's of things that messages' or events' graphs or
> datasets were primarily about. For example, events or messages could
> each describe one event, in another sense of the word, occurring in
> some unfolding story.

I think this is a good topic to discuss. It is preferable to base our
discussion on a more generic representation of the structure---e.g., in
RDF/OWL---, and some example that illustrates its benefits. If you have
some in mind, please share. Thank you very much.

> I am also recently exploring SPARQL query templates which would allow
> abstract SPARQL query patterns to be reused across message instances.
> A SPARQL query template could be instantiated with a message's id to
> produce a concrete SPARQL query, for example a concrete ASK query
> about the specific event or message.
>
> A SPARQL query template might be represented as a text string using a
> popular double-curly-bracket notation, e.g., "{{?variable}}", where
> template variable parameters could, then, be mechanically substituted
> with provided arguments to produce syntactically-valid concrete SPARQL
> queries.
>
> A SPARQL query template, for example, might contain a substring,
> "{{?id}}", which could be replaced by a particular event's id to
> produce a concrete query pertaining to that specific event or message.
>
> A SPARQL query object could provide a "Substitute(variable, node)"
> method, or a similar extension method, for developers to use to
> replace one SPARQL variable in it with one URI node, returning a
> SPARQL query object.

In my experience, this function is currently supported by some SPARQL
libraries. Supporting it in server side would require some sort of
"parametrized stored queries", which, in my opinion, add undesired state
to the servers. Stateless is better for SPARQL and similar streaming
processing.

> I am also interested in state-machines and automata as pertaining to
> these topics and approaches, e.g., with respect to their uses in
> processing streams of graphs or datasets.

I am interested in the standardization aspects of such state machines
from the theoretical foundations point of view. If you have a ToC or
similar to generate a specification document, please share it. Thank
you very much.

> Best regards,
> Adam Sobieski
> http://www.phoster.com

Let's keep contact.

Regards,
Pedro

--
Pedro Martinez-Julia
Email: pedromj@ieee.org<mailto:pedromj@ieee.org>
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***



--
Piotr Sowiński
CTO & Co-Founder @ NeverBlink
https://neverblink.eu