- From: Pieter Colpaert <pieter.colpaert@ugent.be>
- Date: Sat, 3 Jan 2026 21:01:41 +0100
- To: Adam Sobieski <adamsobieski@hotmail.com>, Piotr Sowiński <piotr@neverblink.eu>, Pedro Martinez-Julia <pedromj@ieee.org>
- Cc: "public-rsp@w3.org" <public-rsp@w3.org>
- Message-ID: <eba670bd-8f94-4d59-a2a8-2fef953acb0f@ugent.be>
Hi Adam,
Yes, with Linked Data Event Streams, we even have a meta-property for
that: ldes:versionOfPath. This property allows you to point to your
“special” property that indicates the “version identifier” in your
stream, or basically the primary topic.
The example would then become:
@prefix as: <https://www.w3.org/ns/activitystreams#> .
@prefix ex: <http://example.org/>.
@prefix ldes: <https://w3id.org/ldes#> .
@prefix special: <http://special.example/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# The current page is a view of the feed
</MyFeed> ldes:view <> .
# The Event Stream has a member
</MyFeed> a ldes:EventStream ;
ldes:timestampPath as:published ;
ldes:versionOfPath as:object ;
# This points at a member of the stream - you could see this as the
subject of the envelope in the RDF Message
tree:member ex:create1 .
# @message → this is a pragma cfr.
https://w3c-cg.github.io/rsp/spec/messages
ex:create1 a as:Create ;
# Through versionOfPath, we know that this is the identifier of the
blogpost that was created, that can be updated, undone, or maybe deleted
later on
as:object ex:blogpost1 ;
as:actor <https://pietercolpaert.be/#me> ;
# Through timestampPath we know that this is the chronological order of
the stream
as:published "2026-01-03-20:50:00+01:00"^^xsd:dateTime .
ex:create1 {
# And we also allow to further expand on ex:blogpost-1 in a named
graph: these are triples that are being put in the context defined in
the envelope
ex:blogpost1 a as:Article ;
as:name "..." ;
as:content "..." .
}
This comes from the observation that different styles and types of
properties exist, and that we will never be able to standardize on just one.
Kind regards,
Pieter
On 3/01/2026 19:42, Adam Sobieski wrote:
> 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
> <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/
> <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/
> <https://neverblink.eu/>
--
https://pietercolpaert.be/
+32486747122
Received on Saturday, 3 January 2026 20:01:53 UTC