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> 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
> ---------------------------------------------------------
> *** Entia non sunt multiplicanda praeter necessitatem ***
>
>

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