RDF Time Series Snippets

Living Document,

This version:
https://knowledgeonwebscale.github.io/rdf-timeseriessnippets/
Issue Tracking:
GitHub
Inline In Spec
Editors:
Dylan Van Assche
Pieter Colpaert
Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 27 February 2025, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

An RDF Time Series Snippet is a segment of data points from a time series dataset, typically used for analysis or visualization. The specification uses SPARQL Common Data Types coined by AWS Lab to encode the data points in a values literal. The entity can then be used for annotating this snippet, which is a time interval subset of a potentially larger time series.

1. Introduction

Sensor observations, positioning data, measurements, mobility information... are commonly published as Time Series data with a timestamp and a value. Representing Time Series data in RDF drastically raises the verbosity, as each data point is often given its own identifier, for which contextual information is repeated on all data points. With Time Series Snippets, we allow a data publisher to compact the data points in subsets of a Time Series, called the Snippet, by using SPARQL Common Data Types such as cdt:List and cdt:Map. This way, you can greatly reduce the amount of triples when describing a Time Series.

Time Series Snippets use the following prefix and namespace:

@prefix tss: <https://w3id.org/tss#>;

A first example illustrates the features of a tss:Snippet:

<snippet/2026-01-01>
  a tss:Snippet;
  tss:points """[
    { "time": "2026-01-01T06:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.4"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/0"},
    { "time": "2026-01-01T06:59:59Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.2"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/1"},
    { "time": "2026-01-01T08:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.2"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/2"},
    { "time": "2026-01-01T09:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "6.1"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/3"},
  ]"""^^cdt:List;
  tss:from "2026-01-01T00:00:00Z"^^xsd:dateTime;
  tss:until "2026-01-02T00:00:00Z"^^xsd:dateTime;
  tss:pointType sosa:Observation;
  tss:timePath sosa:resultTime;
  tss:valuePath sosa:hasSimpleResult;
  tss:about [
    sosa:madeBySensor <temp_sensor_1>;
    sosa:observedProperty <temperature>;
  ];
.

The intention of Time Series Snippets is to be a lossless format as, if needed, it can be expanded again. Example 1 for example can be expanded to this RDF dataset:

<https://example.org/0>
  a sosa:Observation ;
  sosa:madeBySensor <temp_sensor_1> ;
  sosa:hasSimpleResult "5.4"^^xsd:double ;
  sosa:observedProperty <temperature> ;
  sosa:resultTime "2026-01-01T06:00:00Z"^^xsd:dateTime .

<https://example.org/1>
  a sosa:Observation ;
  sosa:madeBySensor <temp_sensor_1> ;
  sosa:hasSimpleResult "5.2"^^xsd:double ;
  sosa:observedProperty <temperature> ;
  sosa:resultTime "2026-01-01T06:59:59Z"^^xsd:dateTime .

<https://example.org/2>
  a sosa:Observation ;
  sosa:madeBySensor <temp_sensor_1> ;
  sosa:hasSimpleResult "5.2"^^xsd:double ;
  sosa:observedProperty <temperature> ;
  sosa:resultTime "2026-01-01T08:00:02Z"^^xsd:dateTime .

<https://example.org/3>
  a sosa:Observation ;
  sosa:madeBySensor <temp_sensor_1> ;
  sosa:hasSimpleResult "6.1"^^xsd:double ;
  sosa:observedProperty <temperature> ;
  sosa:resultTime "2026-01-01T09:00:00Z"^^xsd:dateTime .

2. Definitions

A Time Series is a set of data points ordered by timestamp, where each data point consists of a timestamp and corresponding value.

A Snippet describes a subset of a Time Series within a certain period defined by a start and end timestamp, and a description of the entity providing the data points.

A Data Point is a single point of a Time Series containing an ISO timestamp, a value with datatype, and optionally an identifier.

3. Snippet properties

Each Snippet SHOULD have the following properties:

Discuss whether these properties are required or optional. E.g., a publisher might decide to do a lossy conversion for their goal, and not include valuePath, pointType and timePath. However, we can still analyze and visualize the data without that information.

3.1. Data Points

tss:points MUST have a cdt:List as datatype. Each Data Point itself MUST be a cdt:Map consisting of 2 required properties and 1 optional property:

[
    { "time": "2026-01-01T06:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.4"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/0" },
    { "time": "2026-01-01T06:59:59Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.2"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/1" },
    { "time": "2026-01-01T08:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "5.2"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/2" },
    { "time": "2026-01-01T09:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>, "value": "6.1"^^<http://www.w3.org/2001/XMLSchema#double>, "id": "https://example.org/3" },
]

3.2. Expanding data points

When tss:timePath and tss:valuePath are set (mind this is not required), a Snippet can be expanded to a verbose RDF representation, for example using its original vocabulary. The properties tss:about and tss:pointType will influence that process.

For each Data Point, it can be mapped as follows:

  1. When the id is set and it is a valid IRI, set this id as the subject. If it is not, create a new blank node and set this as the subject.

  2. When tss:pointType is set, create a triple stating this id is of rdf:type the object of the pointType triple.

  3. Create a triple for the time based on the tss:timePath. For unknown intermediary named nodes, a blank node is to be created.

  4. Similarly, create a triple for the value based on the tss:valuePath.

  5. Now apply the tss:about blank node entity to this point.

Discuss whether a SHACL Path makes sense to use as the intermediary steps will be mapped to blank nodes. Probably we could simplify here and make this a tss:timeProperty instead?

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Issues Index

Discuss whether these properties are required or optional. E.g., a publisher might decide to do a lossy conversion for their goal, and not include valuePath, pointType and timePath. However, we can still analyze and visualize the data without that information. ↵
Discuss whether a SHACL Path makes sense to use as the intermediary steps will be mapped to blank nodes. Probably we could simplify here and make this a tss:timeProperty instead? ↵