Time ontology extended for non-Gregorian calendar applications

Abstract

We have extended OWL-Time to support the encoding of temporal position in a range of reference systems, in addition to the Gregorian calendar and conventional clock. Two alternative implementations are provided: as a pure extension or OWL-Time, or as a replacement, both of which preserve the same representation for the cases originally supported by OWL-Time. The combination of the generalized temporal position encoding and the temporal interval topology from OWL-Time support a range of applications in a variety of cultural and technical settings. These are illustrated with examples involving non-Gregorian calendars, Unix-time, and geologic time using both chronometric and stratigraphic timescales.

1. Introduction

OWL-Time [7] provides a lightweight model for the formalization of temporal objects, based on Allen’s temporal interval calculus [1]. Developed primarily to support web applications, date-time positions are expressed using the familiar Gregorian calendar and conventional clock.

Many other calendars and temporal reference systems are used in particular cultural and scholarly contexts. For example, the Julian calendar was used throughout Europe until the 16th century, and is still used for computing key dates in some orthodox Christian communities. Lunisolar (e.g. Hebrew) and lunar (e.g. Islamic) calendars are still used, and many similar have been used historically. Dynastic calendars (counting years within eras defined by the reign of a monarch or dynasty) were used earlier in many cultures. In more contemporary applications, Loran-C, Unix and GPS time are based on seconds counted from a specified origin (in 1958, 1970 and 1980, respectively). Archaeological and geological applications use chronometric scales based on years counted backwards from ‘the present’ (defined as 1950 for radiocarbon dating [6]), or named periods associated with specified correlation markers [4,5,10].

Since OWL-Time only allows for Gregorian dates and times, applications that require other reference systems must look elsewhere. However, the basic structures provided by OWL-Time are not specific to a particular reference system, so it would be preferable to use them in the context of a more generic solution. Some previous extensions to OWL-Time have been proposed, in particular to deal with aggregates and recurrent intervals [13]. Perrin et al. [14] use the OWL-Time temporal relations in their geologic timescale ontology, but introduce a new class and property for geochronologic instants.

In this paper we describe extensions to OWL-Time, which support

• the use of an explicit temporal reference system when specifying temporal position,

• general encodings for dates and times not based on the Gregorian calendar and clocks.

We provide two implementations: “Time-plus” is a pure extension to OWL-Time, and “Time-new” is a generalized replacement,1

¹

The Time-plus ontology is published at http://def.seegrid.csiro.au/ontology/time/plus and Time-new at http://def.seegrid.csiro.au/ontology/time/new. Elements of the ontologies are denoted in this paper with the namespace prefixes tplus: and tnew:, respectively.

which preserves the core of OWL-Time within a modified class hierarchy.

We illustrate the application of the ontology with a number of examples. While we do not provide a model for describing temporal reference systems, we show how the extended ontology supports the description of ordinal temporal reference systems also extending into deep time.

2. Time-plus – extension to OWL-time

2.1. Temporal reference system

A useful classification of temporal reference systems is provided in ISO 19108 [9]. Four kinds of system are distinguished:

• Coordinate systems, in which a (temporal) position is expressed as a signed quantity, offset from a specified origin

• Ordinal reference systems, based on ordered named intervals

• Calendars, in which position is expressed using a year-month-day structure

• Clocks, in which position within a day is expressed in hours-minutes-seconds.

The temporal reference system used in OWL-Time is not explicitly specified [7], but can be inferred to be the Gregorian calendar and conventional clock as this is specified for the xsd:dateTime, xsd:gYear, xsd:gMonth and xsd:gDay datatypes used in encoding values [3,8].

In Time-plus we introduce an additional property, denoted tplus:hasTRS, to support explicit indication of a temporal reference system. Its range is the class of temporal reference systems, denoted tplus:TRS. As defined in this ontology, this class is a stub that is only a placeholder for the top of a hierarchy of temporal reference system types, so no properties are defined with the domain tplus:TRS, and there are no local restrictions.

2.2. Temporal position

Two encodings for temporal position are provided in OWL-Time. Using the datatype xsd:dateTime, position is encoded as a structured literal, with a precision of seconds or finer indicated by the precision of the seconds field in the value. Using the class time:DateTimeDescription temporal position is given as a value structured using separate properties, with precision in the range from seconds to years, indicated by the value of the time:unitType property.2

²

Resources from OWL-Time are denoted in this paper with the prefix “time”.

The properties time:year, time:month and time:day have range xsd:gYear, xsd:gMonth and xsd:gDay respectively, which are tied to the Gregorian calendar [3,15]. Thus, OWL-Time is only capable of expressing temporal position in terms of the conventional 12-month calendar with January being the first month of the year, and using the 24-hour clock within each day. Furthermore, strictly speaking, the Gregorian calendar is valid only for time positions in the ‘Common Era’ (i.e. commencing with the year 1 C.E.).

Table 1

Elements of the ontology

Classes	tplus:TRS tplus:GenDateTimeDescription tplus:TimePosition
Properties	tplus:hasTRS	domain tplus:TimePosition|tplus:GenDateTimeDescriptionrange tplus:TRS
	tplus:inDateTime	domain time:Instantrange tplus:GenDateTimeDescription
	tplus:daytplus:monthtplus:year	domain tplus:GenDateTimeDescriptionrange tplus:genDayrange tplus:genMonthrange tplus:genYear
	tplus:inTimePosition	range tplus:TimePosition
	tplus:numericValuetplus:nominalValue	domain tplus:TimePositionrange tplus:Numberrange xsd:string
Datatypes	tplus:genDay tplus:genMonth tplus:genYear	String with pattern constraint matching lexical representation of xsd:gDay|xsd:gMonth|xsd:gYear
	tplus:Number	set of numbers

Fig. 1.

Extended time ontology for supporting additional temporal position encodings. Resources from OWL-Time use the namespace prefix “time:”. (UML-style representation of classes and properties from TopBraid.)

In order to support a wider range of temporal position descriptions, in Time-plus we introduce two classes – tplus:GenDateTimeDescription and tplus:TimePosition. The former is a generalization of time:DateTimeDescription, with the range of tplus:year, tplus:month and tplus:day properties adapted for use with non-Gregorian calendars. In tplus:TimePosition, two properties provide alternative encodings for the value: tplus:numericValue for position described using a number, and tplus:nominalValue for position indicated as a name. The property tplus:hasTRS (described above) is mandatory on individuals from both classes, to indicate the reference system. We also introduce properties tplus:inDateTime and tplus:inTimePosition as alternatives to time:inDateTime and time:inXSDDateTime provided in OWL-Time. The new classes and properties are summarized in Table 1, with relationships to OWL-Time shown in Fig. 1.

These extensions allow temporal position to be specified using all the temporal reference system types mentioned in Section 2.1:

• A temporal coordinate using a tplus:TimePosition with a tplus:numericValue

• An ordinal position using a tplus:TimePosition with a tplus:nominalValue

• A position in the Gregorian calendar using time:DateTimeDescription with time:unitType set to time:unitDay

• A position in an arbitrary calendar using tplus:GenDateTimeDescription with time:unitType set to time:unitDay

• A position in a calendar/clock system using either

The range of tplus:nominalValue in the context of the generalized tplus:TimePosition is a string, since the requirement is to support designation of position in any ordinal reference system, the full set of which is not known (e.g. ‘beginning of Late Cambrian’, ‘end of the bronze age’, ‘end of Ming dynasty’, ‘start of the reign of Pope Leo IX’).

The range of each generalized date property is defined using the datatype restriction capability of OWL2 [12] so that it has the same lexical form as the original property used in OWL-Time, extended as necessary. For example, the definition of tplus:genMonth is shown in Listing 1, which allows month values up to 20 in order to accommodate calendars such as the Hebrew lunisolar calendar (which has a leap-month in some years), the Baha’i calendar (19 months in a year) and the Mayan calendars (18 and 20 periods per year). A note in Section 3.3.14 of the XML Schema – Datatypes specification [15] draws attention to the difficulty of converting month values between calendars, and warns against use of gMonth for non-Gregorian calendars.

Note, however, that a generic OWL processor will not support value-based reasoning over purely lexical representations.

3. Time-new – generalization of OWL-time

The Time-plus ontology described above extends OWL-Time non-intrusively. However, while the class tplus:TimePosition adds distinct new functionality, the class tplus:GenDateTimeDescription merely clones time:DateTimeDescription, with the ranges of the three date properties generalized, plus a mandatory tplus:hasTRS property. A more natural implementation would recognize that the membership of time:DateTimeDescription is a subclass of tplus:GenDateTimeDescription.

Listing 1.

definition of tplus:genMonth as a string pattern (Turtle syntax [2].

Fig. 2.

Generalized time ontology for supporting additional temporal position encodings. In the context of tnew:DateTimeDescription, tnew:hasTRS is constrained to take the value <http://dbpedia.org/resource/Gregorian_calendar>.

We have used the latter approach in Time-new, which is summarized in Fig. 2. The class tnew:DateTimeDescription is sub-classed from the generalized version tnew:GenDateTimeDescription, using local OWL constraints to reproduce the original semantics as shown in Listing 2.

Listing 2.

Local constraints on values of day, month and year properties in the context of a Gregorian date-time description.

While this appears to reflect the class semantics better, the mechanics of OWL datatype definition and derivation introduce complications.

The datatypes xsd:gYear, xsd:gMonth and xsd:gDay, used in the original OWL-Time and in the constraints on the corresponding class in Time-new, are specified in the Gregorian calendar [15] (else there would be no need for the generalized class). However, the date-fragment datatypes are ‘atomic types’ [15], which cannot be derived from a more generalized datatype by restriction on facets. Thus, while tnew:year, tnew:month and tnew:day are defined as datatype properties, their ranges are left unspecified, and so not even the lexical form is constrained when used in the context of individuals from the class tnew:GenDateTimeDescription. This points towards a pattern where a subclass, sibling to tnew:DateTimeDescription, should be defined for each calendar of interest, with suitable constraints on at least the lexical space of the day, month and year properties, following the pattern of Listings 1 and 2. Note that tnew:DateTimeDescription is the only specialization built-in to Time-new, because it is required for the most common (Gregorian) applications, and it only leverages the standard XML Schema datatypes.

Overshadowing all this, however, is the fact that even the XML Schema date-fragment datatypes are not built in to OWL [12], so are not supported by generic OWL reasoning applications. The “temporal reasoner” referred to in the OWL-Time specification [7] might be expected to deal with this, and “Time-new reasoners” could in turn map each additional lexical form to a rigorous value-space in order to support value-based processing. Note that the definition of the date-fragment datatypes is a particularly complex area in XML Schema, with them strictly being understood as elements in the “seven-property model” of a calendar/clock system. It is notable that the values are not integers: the lexical representation of xsd:gDay has a prefix “- - -“, xsd:gMonth a leading “- -”, and values in xsd:gYear must include at least four digits and there are complications around the interpretation of values below “0001” since there is no year zero in the conventional calendar [15].

Listing 3.

A single event with temporal position encoded in multiple temporal reference systems.

4. OWL profile and conformance

Time-plus and Time-new inherit the limitations of OWL-Time [7] concerning OWL 2 conformance:

• restrictions on cardinalities of properties in the time:DateTimeDescription class are not expressible using the OWL 2 EL, RL or QL profiles [11];

• the date-fragment datatypes used in time:DateTimeDescription are not built-in to OWL, so may not be recognized by a generic OWL processor.

Time-plus and Time-new meet the requirements for the OWL 2 DL profile, except that some vocabularies used only for metadata annotations on the ontology are not formal OWL ontologies (e.g. Dublin Core and its imports).

Listing 4.

Events in geologic time encoded using a deep-time coordinate (in “years before present”), and using a named element from the geologic timescale.

Listing 5.

Elements from the geologic timescale, showing some topological relations.

5. Examples

Listing 3 provides an example of a time instant with position formalized in four different ways, using Time-plus:

• time:inXSDDateTime shows the date and time encoded in compact form using the standard datatype derived from ISO 8601

• my:AbbyBirthdayGregorian encodes the date and time according to the Gregorian calendar using separate properties for its elements

• my:AbbyBirthdayHebrew encodes the date and time according to the Hebrew calendar using separate properties for its elements

• my:AbbyBirthdayUnix encodes the birthday and time as a temporal coordinate, specifically as the integer number of seconds since the epoch 1970-01-01T00:00:00.00Z.

Listing 4 provides two examples of events in geologic time. The time of formation of the earth is given as a coordinate in the reference system that counts years backwards from the present. The time of the end of the dinosaurs is given as a named position within the international chronostratigraphic chart [5].

Listing 5 shows how the extended ontology supports the description of elements in an ordinal temporal reference system. The Cambrian Period is modeled as a time:ProperInterval. The beginning and end are modeled as time:Instants, whose positions are given as temporal coordinates in millions of years counted backwards, using the new tplus:TimePosition class. Topological relations with other Eons, Periods and Epochs are described using the properties provided in OWL-Time (non-exhaustively).

Using the Time-new ontology, these examples will be structurally identical, but with the prefixes time: and tplus: both replaced by tnew:, and tplus:genYear, tplus:genMonth and tplus:genDay in Listing 3 replaced by suitable datatypes defined for the Hebrew calendar.

Note that in both Time-plus and Time-new, the cases supported by OWL-Time are represented identically to the original. This was a key design goal of the new ontologies.

6. Summary

We have introduced an extension to OWL-Time to support description of temporal position with an explicit temporal reference system, allowing use of temporal coordinate systems, ordinal temporal reference systems, and generalized calendars. The ontology uses the interval topology from OWL-Time. The new ontology is implemented as a non-intrusive extension with three new classes, eight new properties, and four datatypes, or alternatively as a replacement for OWL-Time with a smaller total element count.

The primary complications arise from the involvement of datatypes from XML Schema that are tied to the Gregorian calendar, which must be generalized for use in a wider range of applications. We define generalized types for date-fragments to match the familiar lexical productions from XSD. However, the value space for both the XSD types used in OWL-Time and the new types defined here are not supported in OWL2, so no standard reasoning support should be expected or relied upon when used in class descriptions.

Aside from the datatypes concern, the new ontologies are capable of OWL2-conformant encoding of temporal concepts used in a variety of cultural and technical settings, covering all of the temporal reference system types described in ISO 19108, but retaining exactly the same form as OWL-Time for the cases handled by the original ontology.