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.


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 JSON data types for the data points. This allows re-usability of existing tooling for analyzing or visualizing these time series snippet literals, for whih the RDF provides useful context information.

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 with JSON objects, allowing to re-use existing tooling for analyzing time series. 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", "value": "5.4", "id": "https://example.org/0"},
    { "time": "2026-01-01T06:59:59Z", "value": "5.2", "id": "https://example.org/1"},
    { "time": "2026-01-01T08:00:00Z", "value": "5.2", "id": "https://example.org/2"},
    { "time": "2026-01-01T09:00:00Z", "value": "6.1", "id": "https://example.org/3"}
  ]"""^^rdf:JSON;
  tss:from "2026-01-01T00:00:00Z"^^xsd:dateTime;
  tss:until "2026-01-02T00:00:00Z"^^xsd:dateTime;
  tss:pointType sosa:Observation;
  tss:context """
    "@context":{
        "id": "@id", 
        "time": {
            "@id":"http://www.w3.org/ns/sosa/resultTime",
      "@type":"http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "value": {
            "@id": "http://www.w3.org/ns/sosa/resultTime",
            "@type":"http://www.w3.org/2001/XMLSchema#integer"
        }
    }
  """^^rdf:JSON;
  tss:about [ a tss:PointTemplate;
    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 a JSON-LD context or pointType. However, we can still analyze and visualize the data without that information.

3.1. Data Points

tss:points MUST be a JSON array with JSON objects (rdf:JSON as datatype). Each Data Point itself MUST be a JSON object consisting of 2 required properties and 1 optional property:

"""[
    { "time": "2026-01-01T06:00:00Z", "value": "5.4", "id": "https://example.org/0" },
    { "time": "2026-01-01T06:59:59Z", "value": "5.2", "id": "https://example.org/1" },
    { "time": "2026-01-01T08:00:00Z", "value": "5.2", "id": "https://example.org/2" },
    { "time": "2026-01-01T09:00:00Z", "value": "6.1", "id": "https://example.org/3" }
]"""^^rdf:JSON;

3.2. Expanding data points

When the optional JSON-LD context is provided through tss:context, a Snippet can be expanded to a verbose RDF representation, for example using its original vocabulary as defined in the JSON-LD specification to transform JSON-LD into RDF quads. The following default JSON-LD context is used if no context is specified:

{
  "@context": {
    "id": "@id",
    "time": {
      "@id": "https://w3id.org/tss#time",
      "@type":"http://www.w3.org/2001/XMLSchema#dateTime"
    },
    "value": "https://w3id.org/tss#value" 
  }
}

The properties tss:about and tss:pointType will influence that process.

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

  1. Use the JSON-LD process to convert the given JSON to RDF using the JSON-LD context.

  2. For each entity (which may be a blank node or an IRI),

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

    • When tss:about is set, apply the subject-based star pattern of the template, except for the type, to this entity.

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 a JSON-LD context or pointType. However, we can still analyze and visualize the data without that information.