Pattern:Recurring Event Pattern

From City Data Model Project Collaboratory
Jump to navigation Jump to search


Description

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

A specification of recurring events, in particular those that are defined according to calendar dates (e.g. every Monday, every March), is required in order to capture information regarding hours of operation, road restrictions, restrictions on parking policies, and so on. 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 can exist. For example, while a business can be open at some recurring intervals, it is possible that in the case of some exceptional circumstances (for example, a power failure) they are not open during the predefined days and times. The recurring event pattern is a specification of the scheduled recurrence of an activity. The actual performance of the activity can be captured as an instance of an activity that is a subclass of manifestation. Hence, changes to the properties of the specific activity, as it is performed, can be captured as manifestations. For example, a store operation could have a data property representing total sales for the day, whose value increases throughout the day. Each change in value could be captured as a manifestation of the activity.

Key Concepts and Classes

The key classes are formalized in Table 13. The Recurring Event Pattern adopts the following representation of recurring events: daily, weekly, and monthly recurring events (and their related properties) are defined, however the ontology may be extended with similar definitions of other type of recurring events, as required. Note that despite the close relationship, a recurring event is distinct from an activity. An instance of a recurring event corresponds to a class of activities (e.g. all of the occurrences of a Tuesday, all of the occurrences of the weekly waste pickup), but it is not itself an activity. The intuition is that the occurrences of a recurring event are all the same type of activity. What defines a recurring event is a combination of the activity type (e.g. a transit trip from point A to point B or the provision of a service) and the frequency at which it recurs. The pattern captures the associated activity type with the hasActivity property that relates recurring events to activities. Classes of recurring events may be captured by identifying their associated classes of Activities, while individual recurring events may be associated with one or more instances of an activity. The Recurring Event pattern uses the Activity pattern, as the concept of an activity is central to the notion of a recurring event: the activities are the recurrences. It is important to note that while the concept of Activity defined in the Activity pattern is necessary for the definition of a RecurringEvent, it is not the case that the concept of RecurringEvents is required for the definition of an Activity. This allows for a simpler representation of events in cases where the notion of recurrence not be required. Recurring events are also identified based on the regular interval at which they occur; this is captured using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties. Using these properties, the pattern supports definitions of specializations of the RecurringEvent class. In particular, subclasses for daily, weekly, monthly, and yearly recurring events are defined; other classes of recurring events may be defined similarly, as required. In addition, the properties startState and endState are used to identify fuzzy recurring events that occur due to certain circumstances, i.e., States, rather than at specific points in time. Exceptions to recurring events may also be defined. For example, a business may normally operate on Monday-Friday, except for public holidays. Exceptions may also be defined on specific dates (e.g. June 23, 2018), for example due to construction or on special calendar days (e.g. holidays) with the ExceptionDay class. If applicable, exceptions may be defined for recurring events with the recursExcept property. Conversely, so-called exceptions may involve an additional, unusual occurrences. This is captured with the recursAddition property. A RecurringEvent is defined to have the following properties: — hasActivity: identifies the Activities that take place at the time and location. — associatedLocation: identifies the locations (Features) where the event occurs. — hasSubRecurringEvent: identifies the sub-recurring events that comprise the RecurringEvent. As with an Activity, a RecurringEvent may be decomposed/decomposed into simpler/more complex RecurringEvents to support varying levels of granularity. — startTime: specifies the start time of the RecurringEvent's activity using xsd:time format. — endTime: specifies the end time of the RecurringEvent’s activity using xsd:time format. — schema:dayOfWeek: specifies the day of the week on which a Weekly RecurringEvent occurs. — hasMonth: specifies the month on which which a YearlyRecurringEvent occurs. — dayOfMonth: specifies the day of the month on which a MonthlyRecurringEvent occurs. — beginsRecurringTime: defines a time to initiate the RecurringEvent. — endsRecurringTime: defines a time to terminate the RecurringEvent . — beginsRecurringState: defines a State that is required to be true in order to initiate the RecurringEvent. — endsRecurringState: defines a State that is required to be true in order terminate the RecurringEvent. — recursExcept: defines the exceptions for the RecurringEvent, i.e. conditions when it does not occur. This can specify a time, day of the week, or specific dates. — recursAddition: defines a condition when the RecurringEvent should be added to. This can specify a time, day of the week, or specific dates. An ExceptionDay specifies a day or days that recursExcept and recursAddition use to specify unique days that do not recur on the same day each year, for example, holidays. It has the following properties: — hasName: the name of the exception day, e.g. Labour Day. — time:hasTIme: specifies the year/month/day on which the exception occurs. A DailyRecurringEvent occurs every day. It has a maximum of one associated time, the start time. Typically, a daily recurring event will occur at the same time every day, but there is potentially no commitment to a recurring start time for the event, in which case no start time is specified. A DailyEvent does not necessarily have a recurring end time (this would require a constant duration), therefore this is not part of the definition (although it is possible to specify). A WeeklyRecurringEvent recurs regularly on the same day of the week, as specified by the schema:dayOfWeek property. A MonthlyRecurringEvent recurs regularly on the same day of each month, as specified by the dayOfMonth data property. Note that there is often ambiguity regarding the semantics of a monthly recurring event: in this formalization, a MonthlyRecurringEvent is any event that recurs regularly on the same day of each month; other interpretations sometimes consider events that recur on the same day of week, or first or last day, in which case the day of month will vary. Such a representation is not included in this ontology, but could be captured in an extension. A YearlyRecurringEvent recurs regularly on the same day of the same month, as specified by the hasMonth and dayOfMonth properties. As with MonthlyRecurringEvent, there can be ambiguity regarding the semantics of a yearly recurring event. However, this formalization captures only the notion of an event that recurs on the same day of the same month (e.g. a birthday). Figures 12 and 13 illustrate 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.

Has Class(es)

ExceptionDay, MonthlyRecurringEvent, RecurringEvent, WeeklyRecurringEvent, YearlyRecurringEvent, ISO5087-1:DailyRecurringEvent ISO5087-1:Activity

Status

Pending Approval


Supplementary Figures

Figure Caption
RecurrentEvent-Pattern.jpg
Recurring Event Pattern Example