skip to main content

Content language

Vocabulary information

ACDH-CH Linked Open Date Entities
Gregorian calendar
Julian calendar
Linked Open Data
Linked Open Date Entities
This is an Entity Model to describe historical dates. Currently, the entities provide lookups for the time concepts between 3000 BC and AD 3000, for the precision of day, month, year, decade, century, and millennium. It is complemented to the ACDH-CH Unit of Time Entities, which specifies the time unit concepts used for the time instances in this model. For example, the concept of the 2nd millennium (Date Entity) is an instance of the concept of millennium (Unit of Time Entity). The basic structure of the two Entity Models is based on the Wikidata ontology. However, SKOS is adopted 1) to capitalise its simple loose semantics, and 2) to avoid debates on a formal ontology on time concepts. Most relations of time concepts are described by skos:broader and skos:narrower. The specifications and policies of the two Entity Models are described below. More details on the project can be found in a paper in the 14th International Conference on Metadata and Semantics Research (MTSR 2020).

--Default URI syntax--
URI syntax consists of a base URI (, temporal system scheme (e.g. gregoriancalendar) and date (e.g. 1999-03-22). For example, a date in the Julian calendar can be expressed as

By default (i.e.without specifying temporal system scheme), ISO8601:2019-based syntax is used for date representation (see details below) such as YYYY-MM-DD, YYYY-MM, YYYY, because ISO8601 is used for many software and programming languages (SQL, PHP, Python) and web schemas (XMLSchema 1.1). The most common syntax would look like,, and
See the details on ISO8601:2019 convention below. To simplify and standardise the syntax, will be redirected to, because our syntax is a subset of the ISO8601 syntax.

--ISO8601:2019 convention--
It is possible to represent all temporal entities used (day, month, year, decade, century, and millennium) with the ISO8601:2019 standard:

Exactly 4 digits (YYYY) represents a year: (AD 1922) (AD 192) (AD 19) (AD 1) (1 BC) (20 BC) (193 BC) (1923 BC)

Exactly 3 digits (YYY) represents a decade: (1920s) (190s) (10s) (0s) (0s BC) (10s BC) (190s BC) (1920s BC)

Exactly 2 digits (YY) represents a century: (19th century)
(Although the period specified in ISO8601:2019 is also allowed as alternative, the following would be less used (3rd century BC)

YYYY/YYYY (with percent coding: YYYY%2FYYYY) represents a millennium (/ in between represents duration): (2nd Millennium AD) (2nd Millennium BC)

Year followed by "-" and exactly 2 digits (typically YYYY-MM) represents a month: (March 12000) (March 1) (April 1 BC) (March 12001 BC)

Year followed by "-", exactly 2 digits, "-", and exactly 2 digits (typically YYYY-MM-DD) represents a day: (12 March 12000) (1 March 1) (2 April 1 BC) (11 March 12001 BC)

Before the adaptation of the Gregorian calendar, ISO8601:2019 applies the proleptic Gregorian calendar. It is the extension of the Gregorian calendar backward to the dates before AD 1852 including time Before Christ.

While Year Zero does not exist in the Julian and Gregorian calendar, ISO8601 uses 0000 for 1 BC, and "-" (minus)
for Before Christ (-0001 is 2 BC).

00 (0th century) does not exist.

Hypothetically centuries more than more than 2 digits exists (e.g. 100 may mean 100th century) and cannot be distinguished from expressions of decades (e.g. 100 is 1000s). However they are out of scope/range of our entities.

More than 4 digits are reserved for years. For instance, (AD 12000), and (250001 BC). However, Date Entity Model only covers from 3000 BC to AD 3000 in the first instance. Nevertheless, this does not limit data creators to mint such URIs, thus, data can still be interlinked, as long as URIs are identical (see above about the motivation for human inferable URIs).

The reason to use ISO8601 syntax as much as possible is to maximise the inference capability of human users. Opaque URIs such as ones in Wikidata ( means 1982) will be extremely hard to infer. In particular, this strategy would help them to enrich data easily (see Data Enrichment below).

--Known issues (data inconsistency for the data model)--
There are a few known issues on the use of decades and centuries that confuses our users. There are two major perceptions for the concept of century and decade. As for centuries, in the strict construction of the Gregorian calendar, a century start from a year ending in a 1 to a year ending in a 0 (e.g. the 19st century began with 1901 and ended with 2000). In the popular usage, it starts from a year ending in a 0 to a year ending in a 9 (e.g. the 19th century began with 1900 and ended with 1999). The latter implies the 1st century (both BC and AD) consists of only 99 years. A similar construct occurs for decades. A popular usage is that a decade start from a year ending in a 0 to a year ending in a 9 (1960s began with 1960 and ended with 1969), while a decade start from a year ending in a 1 to a year ending in a 0 in a rarer version.

Our model follows the construction of Wikidata. It uses the strict version of centuries and popular version of decades. As a result, there are unfortunately logical inconsistencies: 1) two specific decades (i.e. 0s and 0s BC) consist of only 9 years, due to the lack of Year Zero. 2) skos:narrower and skos:broader are not entirely correct every hundred year. For example, the 11th century consists of years between 1001 and 1100. 1000s is a narrower concept of the 11th century, but it consists of years between 1000 and 1009. Whereas Wikidata uses a formal ontology, our model is based on loose SKOS, which might reduce the impact of data inconsistency. In addition, mathematical calculation by the XMLSchema data type can be executed for literals, regardless the inconsistencies on our entities.

Hypothetically speaking, some concepts would not existed at the time of date entity. For example, there was probably no concept of "22 September" for the people who lived in 1000 BC, because it was not yet invented. However, this does not mean we are unable to refer to the equivalent time of 22 September (or roughly 22 September) in 1000 BC, if we would like to. This may happen, for instance, if an archaeologist estimates the time by the autumnal or fall equinox. The same goes for 1581-01-01 in the proleptic Gregorian calendar, which only exists conceptually. Therefore, Date Entity, by default, deliberately includes such concept of time as a reference point for the purpose of data consistency, because it follows the construct of ISO8601 in order to indicate non-existent time concepts, due to the adaptation of the proleptic Gregorian calendar. It would be more confusing to change the URI syntax described above to indicate the 276th day of a year with condition (i.e. only apply before certain date in BC). Please be aware that it is always possible to extend Date Entity Model by adding a new scheme (see below) and link to the dates in other schemes, in order to facilitate imperfect data (missing concepts etc.) and problematic realisation of data model. Also, it is a choice of the user if s/he would like to refer to an entity, or not.

There is uncertainty about the use of "0000". Historically ISO8601 seems to switch it on and off. It is not allowed in the XML Schema Part 2: Datatypes Second Edition. However the schema specifications have a note that ISO8601 is likely to include it, thus, it will be allowed in a subsequent versions. For the time being, Date Entity Model includes it as the representation of 1 BC in the sense of the proleptic Gregorian calendar. If changes are needed in the future, it will be announced in this documentation accordingly.

--URI syntax for other temporal system schemes--
It is possible to add date entities in other temporal system scheme in future. For example, we could use the following suffix for different calendars and dating system:

gregorian_calendar/0001-12-02 (recommended syntax), or gregorian_calendar/AD0001-12-02
julian_calendar/-0001-12-02 (recommended syntax), or julian_calendar/BC0001-12-02
islamic_calendar/1441-05-25, or islamic_calendar/25_Jumada_I_1441

The suffixes are merely suggestions to avoid strict specifications. Nevertheless, the Gregorian and the Julian calendar can follow the convention of YYYY-MM-DD format from ISO8601 for simplicity and convenience. Still, 0000 could be avoided in order not to be confused with ISO8601 (i.e. -1 means 1 BC). If required, BC (Before Christ) and AD (Anno Domini) could be expressed in the syntax before or after the digits (e.g. 189 BC or BC 189). BCE (Before Common Era) and CE (Common Era) could be used, instead of BC and AD respectively. 0 could be omitted if a year has less than 4 digits (e.g. 645 rather than 0645), but the URIs may become unintuitive and confusing. Therefore, it is highly recommended to comply with the YYYY-MM-DD format as much as possible, even if one of the Christian calendar systems is declared. In case a unit name is applied such as the Japanese calendar (e.g. Heisei) and the Islamic calendar (e.g. Jumada), it can be separated or concatenated, depending on practicality. IRI could be considered (e.g. 平成/31 rather than Heisei/31). BP (Before Present/Physics) could be used for scientific dating.

--Data Enrichment--
Linked Open Data implementers are encouraged to create or enrich their data by including the Unit of Time and the Date Entities (i.e. URIs), in order to create connections to other LOD resources. Enrichment could be done through "materialisation" of RDF nodes, using existing text literals. For instance, 11-10-2020 can generate a new graph: . In this case, it is important to preserve the original literal, so that one can still use XML-Schema based calculations. It may be a good idea to additionally generate upper level dates: and

Major LOD resource providers (Wikidata, DBpedia, etc.) are kindly encouraged to include links to our entities in their datasets. It is also excellent if they can create more time entities and mint their own URIs. In that case, it is recommended to create links to our entities, so that the users can access LOD resources that use our entities.

--Linked Open Date entities--
Our entity includes labels in different languages (currently only English and German), corresponding date in the Julian calendar, additional information such as the following/previous time concept, the day of the week, and links to other LOD such as DBpedia and YAGO. More information such as the date in the Mayan calendar and festivities (e.g. Easter) could be added in future.

Any feedback (bugs, suggestions, supports) are welcome to improve the Date Entity Model. Go Sugimoto (
Go Sugimoto
Hannes Pirker
Ksenia Zaytseva
Klaus Illmayer
Monday, February 3, 2020 00:00:00
Monday, October 12, 2020 00:00:00
Monday, October 12, 2020 00:00:00