[OWL-Time] OWL 2 violation: `DateTimeDescription` uses `xsd:gDay`, `xsd:gMonth`, `xsd:gYear` datatypes

[manuel-j-diaz]

Summary

time:DateTimeDescription restricts the :day, :month, and :year properties using owl:allValuesFrom with xsd:gDay, xsd:gMonth, and xsd:gYear, respectively. These three XML Schema types are not part of the OWL 2 datatype map (OWL 2 Syntax §4), which means OWL 2 DL reasoners, e.g. HermiT, reject the ontology.

OWL-Time already defines OWL 2-compatible alternatives for exactly this purpose — time:generalDay, time:generalMonth, and time:generalYear — and uses them in the parent class time:GeneralDateTimeDescription. However, DateTimeDescription still uses the non-OWL 2 XSD types. So if they were swapped with their respective OWL 2-compatibles ones, the issue is addressed.

Affected Axioms

In time.ttl, DateTimeDescription is defined as:

# time.ttl lines 43-67
:DateTimeDescription
  rdf:type owl:Class ;
  rdfs:comment "Description of date and time structured with separate values for the various elements of a calendar-clock system. The temporal reference system is fixed to Gregorian Calendar, and the range of year, month, day properties restricted to corresponding XML Schema types `xsd:gYear`, `xsd:gMonth` and `xsd:gDay`, respectively."@en ;
  rdfs:label "Date-Time description"@en ;
  rdfs:subClassOf :GeneralDateTimeDescription ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:allValuesFrom xsd:gDay ;        # ← line 49: not in OWL 2 datatype map
      owl:onProperty :day ;
    ] ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:allValuesFrom xsd:gMonth ;      # ← line 54: not in OWL 2 datatype map
      owl:onProperty :month ;
    ] ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:allValuesFrom xsd:gYear ;       # ← line 59: not in OWL 2 datatype map
      owl:onProperty :year ;
    ] ;

Why It Matters

The OWL 2 Datatype Map

The OWL 2 specification (§4 Datatype Maps) enumerates exactly which XSD types a conformant OWL 2 DL reasoner must support:

xsd:string, xsd:boolean, xsd:decimal, xsd:integer, xsd:double, xsd:float, xsd:dateTime, xsd:dateTimeStamp, xsd:anyURI, xsd:base64Binary, xsd:hexBinary, xsd:byte, xsd:short, xsd:int, xsd:long, xsd:unsignedByte, xsd:unsignedShort, xsd:unsignedInt, xsd:unsignedLong, xsd:positiveInteger, xsd:nonNegativeInteger, xsd:negativeInteger, xsd:nonPositiveInteger, xsd:normalizedString, xsd:token, xsd:language, xsd:Name, xsd:NCName, xsd:NMTOKEN

xsd:gDay, xsd:gMonth, and xsd:gYear are absent from this list.

When a reasoner operates in OWL 2 DL mode, it may:

• Silently ignore the restrictions (lenient mode) — losing intended semantics
• Reject the ontology outright (strict mode) — blocking all reasoning

How This Breaks in Practice

In isolation, many reasoners tolerate these types because they never need to evaluate the restrictions. However, when OWL-Time is imported alongside ontologies that define custom datatype restrictions (using owl:onDatatype / owl:withRestrictions on OWL 2-supported types like xsd:decimal), reasoners like HermiT switch into strict datatype validation mode. In strict mode, HermiT validates all types in the import closure and rejects xsd:gDay/gMonth/gYear:

HermiT supports all and only the datatypes of the OWL 2 datatype map, see
http://www.w3.org/TR/owl2-syntax/#Datatype_Maps.
The datatype 'http://www.w3.org/2001/XMLSchema#gDay' is not part of the OWL 2 datatype map
and no custom datatype definition is given;
therefore, HermiT cannot handle this datatype.

This means any ontology that:

1. imports OWL-Time (directly or transitively), and
2. defines custom datatype restrictions on OWL 2-supported types (e.g., owl:onDatatype xsd:decimal with owl:withRestrictions)

...will fail consistency and satisfiability checking under HermiT, even though its own datatype definitions are perfectly valid OWL 2 DL.

Reproduction

1. Create an ontology that imports OWL-Time and defines any custom datatype restriction:

@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

<http://example.org/test> a owl:Ontology ;
    owl:imports <http://www.w3.org/2006/time> .

## A perfectly valid OWL 2 DL custom datatype
<http://example.org/test#PercentageValue> a rdfs:Datatype ;
    owl:equivalentClass [ a rdfs:Datatype ;
        owl:onDatatype xsd:decimal ;
        owl:withRestrictions ( [ xsd:minInclusive "0.0"^^xsd:decimal ]
                               [ xsd:maxInclusive "100.0"^^xsd:decimal ] ) ] .

2. Run HermiT via ROBOT:

robot reason --reasoner HermiT --input test.ttl

3. HermiT fails with the xsd:gDay error, even though the test ontology's own datatype is valid.

Proposed Fix

OWL-Time already provides the solution. The ontology defines three OWL 2-compatible alternatives — time:generalDay, time:generalMonth, time:generalYear — as custom types built on xsd:string with pattern restrictions. They are designed to "reproduce the same lexical form as gDay" while staying within OWL 2 DL, and are already used by GeneralDateTimeDescription.

• So, replace the three non-OWL 2 restrictions in DateTimeDescription (lines 49, 54, 59) with the OWL 2-compatible alternatives:

   # time.ttl lines 43–62
   :DateTimeDescription
     rdf:type owl:Class ;
  -  rdfs:comment "...restricted to corresponding XML Schema types xsd:gYear, xsd:gMonth and xsd:gDay, respectively."@en ;
  +  rdfs:comment "...restricted to corresponding OWL 2-compatible types time:generalYear, time:generalMonth and time:generalDay, respectively."@en ;
     rdfs:label "Date-Time description"@en ;
     rdfs:subClassOf :GeneralDateTimeDescription ;
     rdfs:subClassOf [
         rdf:type owl:Restriction ;
  -      owl:allValuesFrom xsd:gDay ;          # line 49
  +      owl:allValuesFrom :generalDay ;
         owl:onProperty :day ;
       ] ;
     rdfs:subClassOf [
         rdf:type owl:Restriction ;
  -      owl:allValuesFrom xsd:gMonth ;        # line 54
  +      owl:allValuesFrom :generalMonth ;
         owl:onProperty :month ;
       ] ;
     rdfs:subClassOf [
         rdf:type owl:Restriction ;
  -      owl:allValuesFrom xsd:gYear ;         # line 59
  +      owl:allValuesFrom :generalYear ;
         owl:onProperty :year ;
       ] ;

  addresses the problem.

• DateTimeDescription's skos:definition annotation should also be updated to match.

  • The Spanish-language annotations (lines 1460–1461) should be updated similarly.

• similar updates to time.rdf, time.jsonld, and the other formats.

• Updates to documentation

Why This Fix Is Correct

1. OWL-Time's own design intent: GeneralDateTimeDescription (line 175) was specifically created to use OWL 2-compatible types. DateTimeDescription is a subclass that narrows to the Gregorian calendar. The generalized types reproduce the same lexical form — generalDay even says so in its rdfs:comment (line 695): "formulated as a text string with a pattern constraint to reproduce the same lexical form as gDay".

2. Semantic preservation: generalDay accepts the same lexical values as xsd:gDay (and more — values up to 99 for non-Gregorian calendars). For DateTimeDescription, which is fixed to the Gregorian calendar, the valid values are identical.

3. OWL 2 DL compliance: xsd:string and owl:withRestrictions with xsd:pattern are fully supported by the OWL 2 datatype map. This is the mechanism OWL-Time itself already uses for GeneralDateTimeDescription.

4. No impact on existing data: Any valid xsd:gDay literal (e.g., "---15") matches the generalDay pattern. Existing example instance data remains valid as-is.

5. No impacts to extensions: Temporal Aggregates and Time Entity Relations extensions are OK as-is

Environment and versions tested

• Reasoner: HermiT 1.4.x (via ROBOT v1.9.8, obolibrary/robot Docker image)
• OWL-Time version: http://www.w3.org/2006/time#2016 latest

[dr-shorthair]

Thanks @manuel-j-diaz for the report and solution.

I'm hoping to get to a revision of OWL-Time in a few months time.
It is already underway but work is currently suspended.
Preview: https://w3c.github.io/sdw/time/

Question: would it be better still to define additional datatypes time:gDay, time:gMonth, time:gYear with the lexical pattern further constrained to match Gregorian calendar rules - i.e. no more than 31 days in a month, 12 months in a year? Good to know that your OWL 2 processors cope OK with lexical patterns.

[manuel-j-diaz]

I only tried this with HermiT, which doesn't really support lexical patterns.

Out of curiosity, would you consider incorporating Gregorian datatypes that are numerical instead of string, e.g.

  :gregorianMonth # or :gregorianMonthInteger?
    a rdfs:Datatype ;
    owl:equivalentClass [
      a rdfs:Datatype ;
      owl:onDatatype xsd:integer ;
      owl:withRestrictions (
        [ xsd:minInclusive 1 ]
        [ xsd:maxInclusive 12 ]
      ) ;
    # plus usual skos:definition, rdfs:label, etc.
    ] .

I think you'd lose the very strict ISO 8601 MM with single digit months and timezone Z offset, but reasoners would enforce the constraints and integer parsing is, well, easy to parse.