Difference between revisions of "RecurringEvent"

From City Data Model Project Collaboratory
Jump to navigation Jump to search
(Created page with "{{Class Definition |Description=Recurring events are defined based on the regular interval at which they occur; this is captures using some combination of the hasTime, dayOfWe...")
 
Line 1: Line 1:
 
{{Class Definition
 
{{Class Definition
|Description=Recurring events are defined based on the regular interval at which they occur; this is captures using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties.  Using these properties, ontology defines the following specizliations of the RecurringEvent class. Other subclasses may be defined similarly, as required.
+
|Description=A recurring event is a means of describing scenarios where some activity is scheduled to recur at some regular interval. It is important to note that recurring events such as scheduled transit trips and operating hours represent planned or usual occurrences. But exceptions to the planned recurrence may exist. For example, while a business may be open at some recurring intervals, it's possible that given some exceptional circumstances (for example, a power failure) they may not be open during the predefined days and times. Recurring events are defined based on the regular interval at which they occur; this is captures using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties.  Using these properties, ontology defines the following specizliations of the RecurringEvent class. Other subclasses may be defined similarly, as required.
 +
|Class Diagram Description=Figure 1 illustrates how the Recurring Event Pattern could be used to define the concept of a scheduled bus trip. In this example, the scheduled bus trip “sched_bus_trip” recurs daily at 8:00 am so all occurrences of the event (i.e. activities “bustrip1_123”, “bustrip1_321”) should occur at 8:00 am on their respective dates.
 
|Definition Status=Pending Approval
 
|Definition Status=Pending Approval
 
}}
 
}}
Line 63: Line 64:
 
}}
 
}}
 
}}
 
}}
{{Supplementary Figures}}
+
{{Supplementary Figures
 +
|Figure Row={{Figure Row
 +
|Figure=Recurring1.png,
 +
|Caption=Figure 1: Example use of the Recurring Event Pattern.
 +
}}{{Figure Row
 +
|Figure=Recurring2.png,
 +
|Caption=Figure 2: Basic structure of the Recurring Event Pattern.
 +
}}
 +
}}

Revision as of 21:08, 3 July 2021


Pattern

This class has been associated with the following pattern:

Pattern:Recurring Event Pattern

Subclass Of

Description

An English description of the definition (what distinguishes this sense of the term?).

A recurring event is a means of describing scenarios where some activity is scheduled to recur at some regular interval. It is important to note that recurring events such as scheduled transit trips and operating hours represent planned or usual occurrences. But exceptions to the planned recurrence may exist. For example, while a business may be open at some recurring intervals, it's possible that given some exceptional circumstances (for example, a power failure) they may not be open during the predefined days and times. Recurring events are defined based on the regular interval at which they occur; this is captures using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties. Using these properties, ontology defines the following specizliations of the RecurringEvent class. Other subclasses may be defined similarly, as required.

Class Diagram Description

Figure 1 illustrates how the Recurring Event Pattern could be used to define the concept of a scheduled bus trip. In this example, the scheduled bus trip “sched_bus_trip” recurs daily at 8:00 am so all occurrences of the event (i.e. activities “bustrip1_123”, “bustrip1_321”) should occur at 8:00 am on their respective dates.

Required by Use Case(s)

(why is this specialized definition needed?)


CDM References

What other classes or properties reference this term?

Interface Specification References

This class has been associated with the following interface specification items:


Sources

Sources considered when developing the class:


Status

Pending Approval

Has Subclass(es)



Annotations

Annotation Value


Manchester Syntax Specification

Property Restriction Value
hasOccurrence only activity:Activity
AssociatedLocation only Feature
HasSubRecurringEvent only RecurringEvent
StartTime only xsd:time
EndTime only xsd:time
Schema:dayOfWeek only DayOfWeek
HasMonth only Month
DayOfMonth only rdfs:Literal
BeginsRecurringTime only Time:TemporalEntity
EndsRecurringTime only Time:TemporalEntity
BeginsRecurringState only State
EndsRecurringState only State
RecursExcept only time:TemporalEntity or DayOfWeek or ExceptionDay
RecursAddition only time:TemporalEntity or DayOfWeek or ExceptionDay


Supplementary Figures

Figure Caption
Figure 1: Example use of the Recurring Event Pattern.
Figure 2: Basic structure of the Recurring Event Pattern.