3.1 Topological Temporal Relations

The basic structure of the ontology is based on an algebra of binary relations on intervals (e.g., meets, overlaps) developed by Allen and Ferguson [AL-84, AF-97] for representing qualitative temporal information, and to address the problem of reasoning about such information.

This is implemented in the ontology starting with a class :TemporalEntity which has properties that link to the temporal instants that define its beginning and end. There are two subclasses: :Interval and :Instant, and they are the only two subclasses of :TemporalEntity. Intervals are, intuitively, things with extent and instants are, intuitively, point-like in that they have no interior points, but it is generally safe to think of an instant as an interval with zero length, where the beginning and end are the same. The class :Interval has one subclass :ProperInterval, which corresponds with the common understanding of intervals, in that the beginning and end are distinct, and whose membership is therefore disjoint from :Instant. The class :ProperInterval has one subclass, :DateTimeInterval, whose position and extent may be expressed using a single :GeneralDateTimeDescription or xsd:dateTimeStamp.

Allen and Ferguson [AL-84, AF-97] have developed a calculus of binary relations on intervals (e.g., meets, overlaps) for representing qualitative temporal information and address the problem of reasoning about such information. The relations between intervals defined in their calculus can be defined in a relatively straightforward fashion in terms of :before and identity on the beginning and end points. The standard interval calculus assumes all intervals are proper, whose beginning and end are different.

3.2 Temporal reference systems, clocks, calendars

The position of an Instant may be given using the datatype xsd:dateTimeStamp (or one of the truncated forms xsd:date, xsd:gYearMonth, xsd:gYear) which is built in to OWL 2 [OWL-2], and uses the conventional Gregorian calendar and 24-hour clock. While this satisfies most web applications, 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 16^th 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 currently in use in some communities, and many similar have been used historically. In scientific and technical applications, Julian date counts the number of days since the beginning of 4713 BCE, and 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 [RC-14]), or using named periods associated with specified correlation markers [CR-05, CR-14, MF-13]. Dynastic calendars (counting years within eras defined by the reign of a monarch or dynasty) were used earlier in many cultures. In order to support these more general applications, the representation of temporal position and duration must be flexible, and annotated with the temporal reference system in use.

A set of ordered intervals (e.g. named dynasties, geological periods, geomagnetic reversals, tree rings) can make a simple form of temporal reference system that supports logical reasoning, known as an ordinal temporal reference system [ISO-19108].

Measurement of duration needs a clock. In its most general form a clock is just a regularly repeating physical event ('tick') and a counting mechanism for the 'ticks'. These counts may be used to logically relate two events and to calculate a duration between the events.

A calendar is a set of algorithms that enables clock counts to be converted into practical everyday dates and times related to the movement of astronomical bodies (day, month, year).

For many purposes it is convenient to make temporal calculations in terms of clock durations that exceed everyday units such as days, weeks, months and years, using a representation of temporal position in a temporal coordinate system [ISO-19108], i.e. on a number line with a specified origin, such as Julian date, or Unix time. This may be converted to calendar units when necessary for human consumption.

Nevertheless, in practice much temporal information is not well-defined, in that there may be no clear statement about the assumed underlying calendar and clock.

3.3 Time position and time units

OWL 2 has two built-in datatypes relating to time: xsd:dateTime and xsd:dateTimeStamp [OWL-2]. Other XSD types such as xsd:date, xsd:gYear and xsd:gYearMonth [XSD-D] are also commonly used in OWL applications. These provide for a compact representation of time positions using the conventional Gregorian calendar and 24-hour clock, with timezone offset from UTC.

Three classes in the ontology support a more explicit description of temporal position. All have a property :hasTRS to indicate the temporal reference system :TRS. :TimePosition has properties to alternatively describe the position using a number (i.e. a temporal coordinate), or a nominal value (e.g. geologic time period, dynastic name, archeological era). :GeneralDateTimeDescription has a set of properties to specify a date-time using calendar and clock elements. Its subclass :DateTimeDescription fixes the temporal reference system to the Gregorian calendar, so the :hasTRS property may be omitted on individuals from this class.

Following the theoretical basis laid out by Allen and Ferguson [AL-84, AF-97], a time position has a finite extent, corresponding to the precision or temporal unit used. Thus, a :GeneralDateTimeDescription or :DateTimeDescription is strictly always a description of an interval, not an instant, with a duration corresponding to the value of its :unitType.

We use two different sets of properties for :GeneralDateTimeDescription or :DateTimeDescription and :GeneralDurationDescription or :DurationDescription, because their ranges are different. For example, :year (in :DateTimeDescription) has a range of xsd:gYear, while :years (in :GeneralDurationDescription) has a range of xsd:decimal so that you can say duration of 2.5 years.

3.4 Duration

The duration of an interval (or temporal sequence) can have many different descriptions. An interval can be 1 day 2 hours, or 26 hours, or 1560 minutes, and so on. It is useful to be able to talk about these descriptions in a convenient way as independent objects, and to talk about their equivalences. An interval can have multiple duration descriptions (e.g., 2 days, 48 hours), but can only have one duration.

Three classes support the description of the duration of an entity. :Duration has properties to describe the duration using a scaled number (i.e. a temporal quantity). :GeneralDurationDescription has a set of properties to specify a duration using calendar and clock elements, the definitions of which are given in the associated TRS description. Its subclass :DurationDescription fixes the temporal reference system to the Gregorian calendar, so the :hasTRS property may be omitted on individuals from this class.

5.1 DateTimeDescription vs dateTime

The following example illustrates the difference between using :DateTimeDescription and using the XML datatype xsd:dateTimeStamp. An instant that represents the start of a meeting, called ex:meetingStart, happens at 10:30am EST on 01/01/2006 can be expressed using both :inXSDDateTime and :inDateTime in OWL as:

ex:meetingStart
  a                    :Instant ;
  :inDateTime          ex:meetingStartDescription ;
  :inXSDDateTimeStamp  2006-01-01T10:30:00-5:00 .

ex:meetingStartDescription
  a           :DateTimeDescription ;
  :unitType   :unitMinute ;
  :minute     30 ;
  :hour       10 ;
  :day        1 ;
  :dayOfWeek  :Sunday ;
  :dayOfYear  1 ;
  :week       1 ;
  :month      1 ;
  :timeZone   <https://www.timeanddate.com/time/zones/est> ;
  :year       2006 .

It is much more concise to use the XML Schema datatype xsd:dateTimeStamp. However, using :DateTimeDescription more information can be expressed, such as "week", "day of week" and "day of year", so in the example, we can also know that 01/01/2006 is Sunday, on the first day of the year, and in the first week of the year. Since, each field of :DateTimeDescription is separate it is easier to extract the value of some fields for the later use and easier to reason about.

The :timeZone property points to a definition of US Eastern Standard Time.

5.2 Use of different temporal reference systems

The use of different temporal reference systems for the same absolute time is illustrated in the following examples. Abby's birthday is an :Instant whose position may be expressed using the conventional XSD xsd:dateTimeStamp type as 2001-05-23T08:20:00+08:00:

ex:AbbyBirthday
  a               :Instant ;
  :inDateTime     ex:AbbyBirthdayHebrew ;
  :inTimePosition ex:AbbyBirthdayUnix ;
  rdfs:label      "Abby's birthdate"^^xsd:string ;
  :inDateTime     ex:AbbyBirthdayGregorian ;
  :inXSDDateTime  "2001-05-23T08:20:00+08:00"^^xsd:dateTimeStamp ;
.

Using the :DateTimeDescription class, the elements of the date and time using the Gregorian Calendar are split out into separate properties:

ex:AbbyBirthdayGregorian
  a           :DateTimeDescription ;
  :day        "---23"^^xsd:gDay ;
  :dayOfWeek  :Wednesday ;
  :hour       "8"^^xsd:nonNegativeInteger ;
  :minute     "20"^^xsd:nonNegativeInteger ;
  :month      "--05"^^xsd:gMonth ;
  :timeZone   <https://www.timeanddate.com/time/zones/awst> ;
  :unitType   :unitMinute ;
  :year       "2001"^^xsd:gYear ;
.

The :GeneralDateTimeDescription class may be used to express the same date using the Hebrew calendar:

ex:AbbyBirthdayHebrew
  a         :GeneralDateTimeDescription ;
  :day      "---01"^^:generalDay ;
  :hasTRS   <http://dbpedia.org/resource/Hebrew_calendar> ;
  :month    "--03"^^:generalMonth ;
  :year     "5761"^^:generalYear ;
  :unitType :unitDay ;
.

The :TimePosition class may be used to express the same position on the Unix time scale (i.e. the number of seconds since 1st January 1970):

ex:AbbyBirthdayUnix
  a                 :TimePosition ;
  :hasTRS           <http://dbpedia.org/resource/Unix_time> ;
  :numericPosition  990577200 ;
  rdfs:label        "Abby's birthdate in Unix time"^^xsd:string ;
.

Each of these examples refers to either a temporal reference system or time zone described externally, using its URI. RDF representations are available from DBPedia (e.g. http://dbpedia.org/resource/Unix_time) though these do not have specific time semantics.

The RDF representation of this example is available here.

5.3 Temporal precision using DateTimeDescription vs dateTime vs TimePosition

For the purposes of radiocarbon dating (which is the technique used in geological age determination for materials up to around 60,000 years old) 'the Present' is conventionally fixed at 1950 [RC-14]. This can be described as an individual :Instant, with its position expressed using any of the three alternatives:

geol:Present
  a :Instant ;
  :inDateTime [
    a :DateTimeDescription ;
    :unitType :unitYear ;
    :year "1950"^^xsd:gYear ;
  ] ;
  :inTimePosition [
    a :TimePosition ;
    :hasTRS <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
    :numericPosition "0.0"^^:Number ;
  ] ;
  :inXSDDateTime "1950-01-01T00:00:00Z"^^xsd:dateTimeStamp ;
  rdfs:label "The present"^^xsd:string ;
.

Expressed using ::DateTimeDescription the ::unitType - which determines the precision - is set to :unitYear, and only the :year element is provided in the value. The TRS value is not provided explicitly, as it is fixed in the ontology description to http://www.opengis.net/def/uom/ISO-8601/0/Gregorian.

In the :TimePosition variant, the TRS is given as http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime which has units of millions of years, starting from the present, positive backwards.

For the value expressed using xsd:dateTimeStamp the position within the year is set arbitrarily to midnight at the beginning of 1st January. This level of precision is strictly spurious, but is required to satisfy the lexical pattern of the datatype.

5.4 iCalendar

iCalendar [DE-09] is a widely supported standard for personal data interchange. It provides the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. The representation of temporal concepts in this time ontology can be straightforwardly mapped to iCalendar. For example, duration of 15 days, 5 hours and 20 seconds is represented in iCalendar as P15DT5H0M20S, which can be represented in the time ontology as:

:hasDurationDescription
  a         :DurationDescription ;
  :seconds  20 ;
  :hours    5 ;
  :days     15 .

The iCalendar homepage features the example of Abraham Lincoln's birthday as celebrated in 2008. This may be represented in multiple ways using OWL-Time, including the following.

As a :DateTimeInterval using the :DateTimeDescription form:

_:DTI-1
  rdf:type :DateTimeInterval ;
  dc:coverage """LOCATION:Hodgenville, Kentucky
    GEO:37.5739497;-85.7399606""" ;
  dc:date "2015-04-21T14:14:03.00"^^xsd:dateTimeStamp ;
  dc:description """Born February 12\\, 1809\\nSixteenth President (1861-1865)
    http://AmericanHistoryCalendar.com""" ;
  dc:subject "Civil War People" ;
  dc:subject "U.S. Presidents" ;
  rdfs:label "Abraham Lincoln" ;
  skos:closeMatch <2008-04-28-04-15-56-62-@americanhistorycalendar.com> ;
  :hasDateTimeDescription [
    rdf:type :DateTimeDescription ;
    :day "---12"^^xsd:gDay ;
    :hasTRS <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian> ;
    :month "--02"^^xsd:gMonth ;
    :unitType :unitDay ;
    :year "2008"^^xsd:gYear ;
  ] ;
.

The boundaries of the interval are implicitly the beginning and end of the day specified in the :DateTimeDescription.

As a :DateTimeInterval using the :xsdDateTime form:

al:DTI-3
  rdf:type :DateTimeInterval ;
  rdfs:label "Abraham Lincoln" ;
  :xsdDateTime "2008-02-12T00:00:00.00-05:00"^^xsd:dateTimeStamp ;
.

In this formulation, the length of the entity is implicitly one day, as there is no sub-day value provided in the :xsdDateTime property.

As a :TemporalEntity using the :TimePosition to define the beginning and end:

_:TE-2
  rdf:type :TemporalEntity ;
  rdfs:label "Abraham Lincoln" ;
  :hasBeginning [
    rdf:type :Instant ;
    :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http://dbpedia.org/resource/Unix_time> ;
      :numericPosition "1202752800"^^:Number ;
    ] ;
  ] ;
  :hasDuration [
    rdf:type :Duration ;
    :numericDuration "1"^^:Number ;
    :unitType :unitDay ;
  ] ;
  :hasEnd [
    rdf:type :Instant ;
    :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http://dbpedia.org/resource/Unix_time> ;
      :numericPosition "1202839200"^^:Number ;
    ] ;
  ] ;
.

In this formulation, the length of the entity is explict, as the value of the :hasDuration property.

Several other formulations are possible, some of which are shown in the RDF representation is available here.

5.5 Geologic timescale described as a graph of ProperInterval individuals

The geologic timescale is defined as a set of named intervals arranged in a hierarchy, such that there is only one subdivision of the intervals of each rank (e.g. 'Era') by a set of intervals of the next rank (in this case 'Period') [CR-05]. Since the relative ordering is well-defined this graph can therefore serve as an ordinal temporal reference system. Fig. 5 shows how the geologic timescale can be expressed as a set of :ProperIntervals related to each other using only :intervalMetBy, :intervalStartedBy, :intervalFinishedBy. Many other interval relationships follow logically from the ones shown (for example 'Neogene Period' :intervalDuring 'Cenozoic Era') but the ones shown are sufficient to describe the full topology.

For example, the 'Phanerozoic Eon' is a :ProperInterval described as follows:

geol:Phanerozoic
  rdf:type            :ProperInterval ;
  :hasBeginning       geol:BasePhanerozoic ;
  :hasEnd             geol:Present ;
  :intervalFinishedBy geol:Cenozoic ;
  :intervalMetBy      geol:Proterozoic ;
  :intervalStartedBy  geol:Paleozoic ;
  rdfs:label          "Phanerozoic Eon"^^xsd:string ;
.

The beginning of the Phanerozoic Eon is an :Instant, described as follows:

geol:BasePhanerozoic
  rdf:type :Instant ;
  :inTimePosition [
    rdf:type          :TimePosition ;
    :hasTRS           <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
    :numericPosition  "541.0"^^:Number ;
  ] ;
  rdfs:label "Base of Phanerozoic Eon"^^xsd:string ;
. 

Note that the position of this :Instant is specified using a :TimePosition, which is a numeric value relative to the temporal coordinate system indicated as the value of the :hasTRS property.

The RDF representation of this example is available here.

5.6 Specialization by sub-classing

It may be useful to define specialized concepts by specialization.

January

For example, "January" can be defined as a a subclass of :DateTimeDescription with the restrictions that the :unitType property has allValuesFrom unitMonth and property :month hasValue of 1:

ex:January
  a               owl:Class ;
  rdfs:subClassOf :DateTimeDescription ;
  rdfs:subClassOf
  [ a               owl:Restriction ;
    owl:onProperty  :unitType
    owl:hasValue    :unitMonth
  ] ;
  rdfs:subClassOf
  [ a               owl:Restriction ;
    owl:onProperty  :month
    owl:hasValue    --01 ;
  ] .

Year

For example, duration "Year" could be defined as a subclass of "DurationDescription" with the restrictions that the "years" property is required (with "cardinality" of 1) and all other properties (e.g., "hours", "months") should not be present (with "cardinality" of 0):

ex:Year
  a       owl:Class ;
  rdfs:subClassOf :DurationDescription ;
  rdfs:subClassOf
  [ a       owl:Restriction ;
    owl:cardinality 1 ;
    owl:onProperty :years
  ] ;
  rdfs:subClassOf
  [ a       owl:Restriction ;
    owl:cardinality 0 ;
    owl:onProperty :months
  ] ;
...
  rdfs:subClassOf
  [ a       owl:Restriction ;
    owl:cardinality 0 ;
    owl:onProperty :seconds
  ] .

We use "cardinality = 0" instead of restricting the values of days, etc. to 0. The reason is that using "cardinality = 0" means all those properties/fields (days, etc.) should not be specified (i.e., the granularity is "year"), while restricting all those values to 0 means they all have a fixed value of 0 (i.e., x years 0 months 0 days ...) and the granularity is actually "second", which is not the correct semantics of "year".

Note that there is a distinction between a year as a duration and a calendar year. The year from December 22, 2006 to December 21, 2007 is the former but not the latter.

5.7 A Use Case for Scheduling

Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. You would like to make an appointment with him for 2:00pm PST on the same day, and expect the meeting to last 45 minutes. Will there be an overlap?

In this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict:

ex:telecon
  a             :Interval ;
  :hasBeginning ex:teleconStart .

ex:meeting
  a                       :Interval ;
  :hasBeginning           ex:meetingStart ;
  :hasDurationDescription ex:meetingDuration .

ex:teleconStart
  a               :Instant ;
  :inXSDDateTime  "2006-11-05T18:00:00-5:00"^^xsd:dateTimeStamp .

ex:meetingStart
  a               :Instant ;
  :inXSDDateTime  "2006-11-05T14:00:00-8:00"^^xsd:dateTimeStamp .

ex:meetingDuration
  a         :DurationDescription ;
  :minutes  45 .

The telecon and the meeting are defined as intervals. :hasBeginning is used for specifying the start times of the meetings. The datetimes are specified using :inXSDDateTime. The duration of the meeting is specified using the :DurationDescription class.

5.8 Web commerce applications

Congo.com and Bravo Air are examples from the OWL-S 0.9 draft release [OWL-S]. Congo.com is a fictitious book-selling service site, and Bravo Air is a fictitious airline-ticketing service site. These examples demonstrate how the time ontology can be used to support OWL-S, including use cases for defining input parameters and (conditional) output parameters.

Input Parameters

In the profile of the Congo.com example (i.e. CongoProfile.owl), for example, our time ontology is currently used for describing the input parameter CreditCardExpirationDate:

profile:CreditCardExpirationDate
  a                     profile:ParameterDescription ;
  profile:parameterName ex:creditCardExpirationDate ;
  profile:restrictedTo  :Instant ;
  profile:referTo       congoProcess:creditCardExpirationDate .

In this example :Instant is used to describe CreditCardExpirationDate, because the expiration date is actually an instant -- the midnight, of the day the credit card expires.

In the Bravo Air example, our time ontology can be used to describe the existing input parameters, DepartureDate and ArrivalDate. We will change this to the more appropriate DepartureTime and ArrivalTime. We can define DepartureTime in the profile of the Bravo Air example (i.e. BravoAirProfile.owl) as:

profile:DepartureTime
  a                     profile:ParameterDescription ;
  profile:parameterName ex:DepartureTime ;
  profile:restrictedTo  :Instant ;
  profile:referTo       ba_process:outboundDate_In .

DepartureTime is defined as :Instant. With this definition, as we discussed in the previous datetime description section, an instance of DepartureTime can has either an :inXSDDateTime property/relation pointing to a specific value of XML Schema datatype dateTime, say 2006-01-01T10:30:00-5:00, or an :inDateTime object-property/relation pointing to an instance of :DateTimeDescription class specifying a specific time, say 10:30am EST on 01/01/2006, Sunday. It would be the user’s decision to define the time in either way based on the trade-offs discussed in the previous section.

(Conditional) Output Parameters

In fact, there is much more that our time ontology can do to support OWL-S. In the Congo.com and Bravo Air examples, the time ontology is not used for any output parameters. However, in the real world many service outputs are time-related. For example, in the Congo.com example we can add two outputs that are very common in real world book-selling sites: process time and delivery duration.

Adding a ProcessTime output parameter

ProcessTime is a conditional output parameter that specifies how long before the book will be ready for delivery, say, 24 hours, which depends on whether the book is in stock. In this use case, the process time is returned only if the book is in stock. It can be defined in the process model of the Congo.com example (i.e. CongoProcess.owl) as:

ex:ProcessTime
  a               owl:Class ;
  rdfs:subClassOf :Interval ;
.

ex:fullCongoBuyProcessTime
  a                   rdf:Property ;
  rdfs:subPropertyOf  process:output ;
  rdfs:domain         ex:FullCongoBuy ;
  rdfs:range       
    [ a               owl:Class ;
      rdfs:subClassOf process:ConditionalOutput ;
      rdfs:subClassOf 
        [ a                 owl:Restriction ;
          owl:allValuesFrom ex:BookInStock ;
          owl:onProperty    process:coCondition
        ] ;
    ] ;
  rdfs:subClassOf
    [ a                 owl:Restriction ;
      owl:allValuesFrom ex:ProcessTime ;
      owl:onProperty    process:coOutput
    ] ;
.

ProcessTime is defined as an interval, rather than a duration. As discussed previously, in our time ontology durations are properties of intervals. Thus to talk about a duration, i.e. a quantity of time, an interval must be defined first. This approach may look roundabout at first glance. However, the process time is not purely a quantity of time; it has a location on the time line. The beginning of the process time is the time the user places the order, and the end of the process time is the time the order is shipped out. An advantage of defining ProcessTime as an interval is that if the relationship among the order time, the shipping time, and the process time is known, any one of them (e.g. the shipping time) can be computed from the other two (e.g. the order time and the process time) by temporal arithmetic.

Adding a DeliveryDuration output parameter

DeliveryDuration is a conditional output parameter that specifies how long it will take for the customer to receive the book after it is shipped out, which depends on the delivery type the customer selects. As defined in the process model of the Congo.com example (i.e. CongoProcess.owl), the current delivery types are FedExOneDay, FedEx2-3day, UPS, and OrdinaryMail.

To add this output parameter may seem similar to the above ProcessTime example. However, since an instance of Condition is a logical formula that evaluates to true or false (see the comment with the definition of Condition [PR-OS]), DeliveryType cannot be directly used as a condition to determine the delivery duration. Thus one property and one condition are defined for each delivery type.

DeliveryDuration is defined with two boundaries: one minDeliveryDuration and one maxDeliveryDuration. For example, an order with the FedEx2-3day delivery type takes 2 to 3 days, so its min delivery duration is 2 days, and its max delivery duration is 3 days. For the delivery duration of the order with FedExOneDay delivery type, the min and max delivery duration will both be 1 day. We can define DeliveryDuration in the process model of the Congo.com example (i.e. CongoProcess.owl) as:

ex:DeliveryDuration
  a       owl:Class ;
  rdfs:subClassOf
    [ a               owl:Restriction ;
      owl:cardinality 1 ;
      owl:onProperty  ex:maxDeliveryDuration
    ] ;
  rdfs:subClassOf
    [ a               owl:Restriction ;
      owl:cardinality 1 ;
      owl:onProperty  ex:minDeliveryDuration
    ] .

ex:maxDeliveryDuration
  a           rdf:Property ;
  rdfs:domain ex:DeliveryDuration ;
  rdfs:range  :Interval .

ex:minDeliveryDuration
  a           rdf:Property ;
  rdfs:domain ex:DeliveryDuration ;
  rdfs:range  :Interval .

Both minDeliveryDuration and maxDeliveryDuration are defined as properties of DeliveryDuration. For the same reason discussed for the process time example, both properties use Interval as their ranges. The cardinality of 1 for both properties in the definition of DeliveryDuration indicates that an instance of DeliveryDuration must have one and only one property value for minDeliveryDuration and maxDeliveryDuration respectively. For example, in order to define delivery duration for FedEx2-3day, we have to first define a condition of FedEx2-3day being selected:

ex:FedEx2-3dayCondition
  a               owl:Class ;
  rdfs:subClassOf process:Condition .

Then we define an output property, called deliverySelectFedEx2-3day that is conditional on FedEx2-3dayCondition defined above:

ex:deliverySelectFedEx2-3day
  a                   rdf:Property ;
  rdfs:subPropertyOf  process:output ;      
  rdfs:domain         ex:SpecifyDeliveryDetails ;
  rdfs:range 
    [ a               owl:Class ;
      rdfs:subClassOf process:ConditionalOutput ;
      rdfs:subClassOf
        [ a                 owl:Restriction ;
          owl:allValuesFrom ex:FedEx2-3dayDuration ;
          owl:onProperty    process:coOutput
        ] ;
      rdfs:subClassOf
        [ a                 owl:Restriction ;
          owl:allValuesFrom ex:FedEx2-3dayCondition ;
          owl:onProperty    process:coCondition
        ] ;
    ] .

This definition says that deliverySelectFedEx2-3day is a conditional output, and if FedEx2-3dayCondition is true, an instance of FedEx2-3dayDuration class will be the output. FedEx2-3dayDuration is not defined yet. In order to define it, we have to define its min delivery duration, i.e. 2 days, and max delivery duration, i.e. 3 days. Since the range of minDeliveryDuration and maxDeliveryDuration is :Interval, intervals with specific durations need to be created first. For FedEx2-3dayDuration, we need to define Interval2Days and Interval3Days first as follows:

ex:Interval2Days
  a               owl:Class ;
  rdfs:subClassOf :Interval ;
  rdfs:subClassOf
    [ a               owl:Restriction ;
      owl:hasValue    P2D ;
      owl:onProperty  :durationDescriptionDataType
    ] .

ex:Interval3Days
  a               owl:Class ;
  rdfs:subClassOf :Interval ;
  rdfs:subClassOf
    [ a               owl:Restriction ;
      owl:hasValue    P3D ;
      owl:onProperty  :durationDescriptionDataType
    ] .

These two definitions use durationDescriptionDataType, a relatively simpler duration property of :Interval using the XML Schmea datatype xsd:duration as its range. P2D and P3D are values of the XML Schema datatype xsd:duration, meaning 2 days and 3 days.

Finally, FedEx2-3dayDuration restricts the value of minDeliveryDuration and maxDeliveryDuration to class Interval2Days and Interval3Days respectively as follows:

ex:FedEx2-3dayDuration
  a               owl:Class ;
  rdfs:subClassOf ex:DeliveryDuration ;
  rdfs:subClassOf
    [ a                 owl:Restriction ;
      owl:allValuesFrom ex:Interval3Days ;
      owl:onProperty    ex:maxDeliveryDuration
    ] ;
  rdfs:subClassOf
    [ a                 owl:Restriction ;
      owl:allValuesFrom ex:Interval2Days ;
      owl:onProperty    ex:minDeliveryDuration
    ] .

Properties to output delivery durations when the user selects other delivery types (FedExOneDay, UPS, and OrdinaryMail) can be defined similarly.