Time-varying Semantics #3

AdamSobieski · 2026-08-01T13:06:43Z

AdamSobieski
Aug 1, 2026
Maintainer

Introduction

Ideas involving time-varying knowledge graphs and datasets are explored.

WebVTT

Drawing inspiration from WebVTT, time-varying semantics could be expressed as follows:

WEBVTT

00:00.000 --> 02:00.000
@prefix ex: <http://www.example.org/ns#> .
ex:s1 ex:p1 ex:o1 .

00:22.000 --> 00:27.000
@prefix ex: <http://www.example.org/ns#> .
ex:s1 ex:p2 ex:o2 .
ex:s1 ex:p3 ex:o3 .

00:40.000 --> 00:43.000
@prefix ex: <http://www.example.org/ns#> .
ex:s1 ex:p2 ex:o4 .
ex:s1 ex:p3 ex:o5 .

00:58.000 --> 02:00.000
@prefix ex: <http://www.example.org/ns#> .
ex:s1 ex:p2 ex:o6 .
ex:s1 ex:p3 ex:o7 .

The active graph or dataset would be equivalent to the union of, or the merging of, those graphs or datasets in the active cues at an instant. At 00:42.000, for example, the active graph would be equivalent to:

@prefix ex: <http://www.example.org/ns#> .
ex:s1 ex:p1 ex:o1 .
ex:s1 ex:p2 ex:o4 .
ex:s1 ex:p3 ex:o5 .

RDF Message Streams

Drawing inspiration from RDF Message Streams, adding a @metadata directive, time-varying semantics could be expressed as follows:

@version "1.2-messages" .
@prefix ex: <http://www.example.org/ns#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema> .

@message .
@metadata <> prov:startedAtTime "00:00:00.000Z"^^xsd:time .
@metadata <> prov:endedAtTime "00:02:00.000Z"^^xsd:time .
ex:s1 ex:p1 ex:o1 .

@message .
@metadata <> prov:startedAtTime "00:00:22.000Z"^^xsd:time .
@metadata <> prov:endedAtTime "00:00:27.000Z"^^xsd:time .
ex:s1 ex:p2 ex:o2 .
ex:s1 ex:p3 ex:o3 .

@message .
@metadata <> prov:startedAtTime "00:00:40.000Z"^^xsd:time .
@metadata <> prov:endedAtTime "00:00:43.000Z"^^xsd:time .
ex:s1 ex:p2 ex:o4 .
ex:s1 ex:p3 ex:o5 .

@message .
@metadata <> prov:startedAtTime "00:00:58.000Z"^^xsd:time .
@metadata <> prov:endedAtTime "00:02:00.000Z"^^xsd:time .
ex:s1 ex:p2 ex:o6 .
ex:s1 ex:p3 ex:o7 .

Considered Use Cases

Education

Using these techniques, one could declare semantics for how-to knowledge presented in instructional videos, e.g., using Schema.org's HowTo, utilizing time-varying graphs or datasets to indicate which hierarchical steps and substeps were being shown in a video at an instant.

Accessibility

Using these techniques, one could provide corresponding time-varying alternative text and/or spatiotemporal scene graphs for content in videos. As explored in Steiner, Mühleisen, Verborgh, Champin, Encelle, and Prié (2014), one could use Media Fragments URI, e.g., in JSON-LD cue payloads in metadata tracks, to reference spatial bounding boxes, temporal intervals, tracks, and named temporal fragments by id's, i.e., chapters, in videos.

Artificial Intelligence

Time-varying semantics have artificial-intelligence applications.

Computational Narratology

Time-varying semantics have computational-narratological applications.

The History of Ideas

Using these techniques, one could represent ideas and concepts diachronically and, thus, they could be useful for the history of ideas.

Animated Data Visualizations and Infographics

RDF data can be visualized in a number of ways including by means of techniques like SolidOS panes.

One could use time-varying graphs or datasets to provide dynamic data for animated data visualizations and infographics (e.g., tables, charts, and diagrams). Time-varying graphs and datasets can also express selection- and highlighting-related features for data visualizations and infographics.

Conclusion

What do you think about these ideas? Thank you.

Bibliography

Gutierrez, Claudio, Carlos Hurtado, and Alejandro Vaisman. "Temporal RDF." In European Semantic Web Conference, pp. 93-107. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005.

Steiner, Thomas, Hannes Mühleisen, Ruben Verborgh, Pierre-Antoine Champin, Benoit Encelle, and Yannick Prié. "Weaving the Web (VTT) of Data." In 7th Workshop on Linked Data on the Web. 2014.

pietercolpaert · 2026-08-23T09:28:22Z

pietercolpaert
Aug 23, 2026

We need to be cautious about adding yet another extension to RDF

When we introduced RDF Messages as an RDF1.2 extension using the version identifiers, there were concerns that this would become a slipery slope towards anyone just positioning anything as a pragma in RDF and thus the danger that there would be a lot of dialects. We tried to model RDF Messages in a way that all the rest could be done from within RDF itself, not by extending RDF again.

When we do introduce another extension, the semantics need to be crystal clear

I’m afraid of dubious semantics.

What does timestamp exactly mean? Is it the moment these triples were received by a server? Is it the moment they were logged in a file? Is it the moment the real-world measurement or claim was made? Etc. This was the main reason to not include a timestamp in the @message. syntax in RDF Messages. Instead, we rely on existing semantics from e.g., Activity Streams, PROV-O, SSN/SOSA, SAREF, LDES, etc.
We already have RDF1.1 named graphs (cfr. context associations) and RDF1.2 triple terms if we want to associate metadata with one or multiple triples. The @metadata (isn’t everything and nothing _meta_data anyway?) can entirely

WebVTT

I didn’t know this spec, but this is interesting though. The semantics could be limited to a replayer of a message stream that could be requested to preserve the durations in between messages. The authentic timestamp could then still be retrieved from the RDF.

2 replies

AdamSobieski Aug 23, 2026
Maintainer Author

@pietercolpaert, with both the envisioned @metadata directive and Context Associations in RDF, users could select which semantic relation(s) between a message and a datetime or time that they desired to utilize, e.g., dc:created.

@version "1.2-messages" .
@prefix ex: <http://www.example.org/ns#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema> .

@message .
@metadata <> dc:created "2026-08-23T10:30:00Z"^^xsd:dateTime .
ex:s1 ex:p1 ex:o1 .

@message .
@metadata <> dc:created "2026-08-23T10:31:00Z"^^xsd:dateTime .
ex:s1 ex:p2 ex:o2 .
ex:s1 ex:p3 ex:o3 .

@message .
@metadata <> dc:created "2026-08-23T10:32:00Z"^^xsd:dateTime .
ex:s1 ex:p2 ex:o4 .
ex:s1 ex:p3 ex:o5 .

@message .
@metadata <> dc:created "2026-08-23T10:33:00Z"^^xsd:dateTime .
ex:s1 ex:p2 ex:o6 .
ex:s1 ex:p3 ex:o7 .

@metadata directives could be used to refer to external metadata resources.

@prefix ex: <http://www.example.org/ns#> .
@metadata <> ex:hasMetadata <http://www.data.org/metadata.ttl> .

ex:s1 ex:p1 ex:o1 .

Some other uses for both @metadata and context associations are indicated in the following example:

@prefix dc: <http://purl.org/dc/terms/> .
@prefix ex: <http://www.example.org/ns#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema> .
@metadata <> dc:contributor _:alice .
@metadata _:alice foaf:name "Alice Smith" .
@metadata <> dc:contributor _:bob" .
@metadata _:bob foaf:name "Bob Jones" .
@metadata <> dc:created "2026-08-22T14:45:30Z"^^xsd:dateTime .
@metadata <> prov:wasDerivedFrom <https://www.example.org/resource.ttl> .
@metadata <> sh:shapesGraph <https://www.shapes.org/123.shacl> .

ex:s1 ex:p1 ex:o1 .

@metadata directives can be transformed into, stored using, and queried using named graphs utilizing the context-associations pattern in TriG:

@prefix ca: <https://w3id.org/context-associations#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix ex: <http://www.example.org/ns#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema> .

ex:dataG {
  ex:s1 ex:p1 ex:o1 .
}
ex:ctxG {
  ex:ctxG ca:aboutGraph ex:dataG .
  ex:dataG dc:contributor [ foaf:name "Alice Smith" ] , [ foaf:name "Bob Jones" ] ;
           dc:created "2026-08-22T14:45:30Z"^^xsd:dateTime ;
           prov:wasDerivedFrom <https://www.example.org/resource.ttl> ;
           sh:shapesGraph <https://www.shapes.org/123.shacl> .
}

Ostrzyciel Aug 23, 2026

I support Pieter here. RDF Message's extension of the abstract RDF syntax is minimal (just one new concept) and it's already not trivial to specify or implement.

Introducing more complex extensions where the same can be done within RDF in my opinion violates the Occam's razor principle. You cannot cut the messages with the razor, however, because as we argued in our paper, RDF simply does not have the concept of message boundaries: https://arxiv.org/pdf/2604.22619

Navigation Menu

Time-varying Semantics #3

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Time-varying Semantics #3

Uh oh!

Uh oh!

AdamSobieski Aug 1, 2026 Maintainer

Introduction

WebVTT

RDF Message Streams

Considered Use Cases

Education

Accessibility

Artificial Intelligence

Computational Narratology

The History of Ideas

Animated Data Visualizations and Infographics

Conclusion

Bibliography

Replies: 1 comment · 2 replies

Uh oh!

pietercolpaert Aug 23, 2026

We need to be cautious about adding yet another extension to RDF

When we do introduce another extension, the semantics need to be crystal clear

WebVTT

Uh oh!

Uh oh!

AdamSobieski Aug 23, 2026 Maintainer Author

Uh oh!

Ostrzyciel Aug 23, 2026

AdamSobieski
Aug 1, 2026
Maintainer

Replies: 1 comment 2 replies

pietercolpaert
Aug 23, 2026

AdamSobieski Aug 23, 2026
Maintainer Author