Linked Data Event Streams Vocabulary

Living Standard,

This version:
https://w3id.org/ldes
Issue Tracking:
GitHub
Editor:
Pieter Colpaert

Abstract

This document defines the Linked Data Event Streams (LDES) Vocabulary, which provides terms for describing append-only, immutable collections of events as Linked Data. The vocabulary extends existing standards such as the TREE and DCAT vocabularies to support event streams, versioning, retention policies, and transactional semantics.

1. Introduction

This specification introduces terms used to describe event streams. While these terms can be used independently of the LDES specification, the main LDES specification is available at https://w3id.org/ldes/specification.

2. Terms

This document introduces terms in the namespace https://w3id.org/ldes# with the preferred prefix ldes:. There is also a Turtle version available.

Used prefixes are:

@prefix ldes: <https://w3id.org/ldes#> .
@prefix tree: <https://w3id.org/tree#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

2.1. ldes:EventStream

The class ldes:EventStream is a subclass of tree:Collection, which in turn is a subclass of dcat:Dataset, specialized such that all members are immutable, making the collection append-only.

2.2. ldes:timestampPath

The path to the xsd:dateTime literal in each member that defines the order of the event stream.

Domain: ldes:EventStream

Range: a SHACL property path

2.3. ldes:sequencePath

The path to an xsd-typed literal in each member that defines the order of the event stream in addition to the ldes:timestampPath.

Domain: ldes:EventStream

Range: a SHACL property path

2.4. ldes:versionOfPath

The path to the IRI in each member that defines the entity of which this member is a version.

Domain: ldes:EventStream

Range: a SHACL property path

2.5. ldes:versionTimestampPath

For out-of-order event streams, this defines the path to the xsd:dateTime literal in each member that defines the order of versioned members.

Only relevant when the ldes:versionOfPath has been set.

Domain: ldes:EventStream

Range: a SHACL property path

2.6. ldes:versionSequencePath

For out-of-order event streams, this defines the path to an xsd-typed literal in each member that defines the order of the event stream in addition to the ldes:versionTimestampPath.

Domain: ldes:EventStream

Range: a SHACL property path

2.7. ldes:pollingInterval

The number of seconds the client should keep between synchronization run calls.

Domain: ldes:EventStream Range: xsd:integer

2.8. ldes:immutable

If the node is not going to contain new relations leading to new members, or new members itself, it can be set to immutable.

Domain: tree:Node Range: xsd:boolean

2.9. ldes:EventSource

The class ldes:EventSource is a subclass of dcat:Distribution, specialized to represent a feed that uses a chronological search tree to make a Linked Data Event Stream available in order.

An ldes:EventSource can only be published for LDESs that have ldes:timestampPath set, and thus publishes its entities in chronological order.

2.10. ldes:retentionPolicy

Links to a retention policy.

Domain: Preferably on the root node. Alternatively, it can occur on any entity linked from the root node using tree:viewDescription.

Range: ldes:RetentionPolicy

2.11. ldes:RetentionPolicy

The class for a retention policy that indicates how long members are preserved in this view.

2.11.1. ldes:startingFrom

The view only keeps members starting from a certain timestamp.

Domain: ldes:RetentionPolicy

Range: xsd:dateTime with a timezone

2.11.2. ldes:versionDuration

The view keeps versions (for which ldes:versionAmount MUST be set) only for a specific time window.

Domain: ldes:RetentionPolicy

Range: xsd:duration

2.11.3. ldes:versionAmount

The number of versions to keep. This MUST be greater than 0.

Domain: ldes:RetentionPolicy

Range: xsd:integer

2.11.4. ldes:versionDeleteDuration

The view only keeps its deletions for a certain duration.

Domain: ldes:RetentionPolicy

Range: xsd:duration

2.11.5. ldes:fullLogDuration

The view keeps its full log for a certain duration.

Domain: ldes:RetentionPolicy

Range: xsd:duration

2.11.6. Former retention policy terms

2.12. Terms for versioning and transactions on top of ldes:EventStream

2.12.1. ldes:versionCreatePath

Path whose object indicates that the member represents a create. Defaults to rdf:type.

2.12.2. ldes:versionUpdatePath

Path whose object indicates that the member represents an update. Defaults to rdf:type.

2.12.3. ldes:versionDeletePath

Path whose object indicates that the member represents a delete. Defaults to rdf:type.

2.12.4. ldes:versionCreateObject

If the object at ldes:versionCreatePath equals this value, the member represents a create.

2.12.5. ldes:versionUpdateObject

If the object at ldes:versionUpdatePath equals this value, the member represents an update.

2.12.6. ldes:versionDeleteObject

If the object at ldes:versionDeletePath equals this value, the member represents a delete.

2.12.7. ldes:transactionPath

Path whose object indicates whether the member is part of a transaction.

2.12.8. ldes:transactionFinalizedPath

Path indicating whether the transaction has been finalized.

2.12.9. ldes:transactionFinalizedObject

If the object at ldes:transactionFinalizedPath equals this value, the member indicates the transaction has been finalized.

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.

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