Pattern:Activity 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?).

The concept of activities arises in many cases in city data: there are trip activities that contribute to the demand on a transportation system, and the routine activities that motivate these trips; there are educational and recreational activities offered by various city services. In the most general sense, activities are things that happen; events that occur (scheduled or not) or actions that are performed by some agent. Activities may be described by the time and location of their occurrence, their preconditions and effects, as well through the identification of any objects that are somehow involved. There are many OWL ontologies that in some way address the concept of activities. However, most are lacking with respect to the basic representation requirements. The Activity Pattern adopts the Activity Specification design pattern that was presented in Reference [13] as a solution to address these limitations. The representation of activity specifications is based on the activity clusters introduced by Fox, Sathi, and colleagues.[14],[15]. A precursor to the TOronto Virtual Enterprise[16] and Process Specification Language[17] activity ontologies, an activity cluster provides a basic structure for representing activity specifications. Illustrated in Figure 10, it consists of an activity connected to an enabling and caused state, each of which may be a state tree that defines complex states via decomposition into conjunctions and disjunctions of states.

In this approach an activity is interpreted as a class of occurrences, in contrast with other approaches where activities are separate entities that are related to occurrences via an "occurrence of" relation. This decision was motivated by several pragmatic factors: in many cases it is sufficient to capture information regarding individual activities (i.e. occurrences or events). These activities may be categorized via different subclasses of “Activity”, but there is no need to associate them with a single activity type entity, unless it is wished to characterize the activity type itself. The capability for this more complex formalization is supported, if necessary, by the Recurring Event Pattern (see 6.9). Dividing these representations into two separate ontologies allows users of the ISO/IEC 5087 series the discretion to only include what is needed. In addition, much of the semantics that relate activity types and occurrences is not expressible in OWL. The Activity Ontology works within the limitations of OWL to capture the concepts of activities, their composition, preconditions and effects, and ordering.

Key Concepts and Classes

  • Activity: An Activity describes something that occurs in the domain. It has the following set of core properties:
    • hasSubactivity: identifies a more granular Activity into which the Activity may be decomposed.
    • hasStatus: identifies an ActivityStatus. This specifies the status of the Activity at some point or interval in time. For example, the Activity may be “scheduled, “executing” or “completed”.
    • hasPrecondition: identifies a State that must be realized in order for the Activity to occur.
    • hasEffect: identifies a State that is realized once the Activity has occurred.
    • occursAt: identifies a time Interval over which the Activity occurs.
    • hasLocation: identifies a location (a spatial Feature) where the Activity occurs.
    • scheduledFor: identifies the time Interval that an Activity was scheduled to be performed/occur at.
    • occursBefore: identifies an Activity that the Activity occurred before.

An Activity may also be described with the following, supplemental properties:

    • enabledByState: identifies a State that in some (indirect) way enabled the Activity to occur. An Activity is enabled by a State if the State is a precondition for the Activity or if the State is a precondition of some subactivity of the Activity. The enabledByState property is a generalization (super-property) of the hasPrecondition property.
    • causesState: identifies a State that in some (indirect) way was caused by the occurrence of the Activity. An Activity is caused by a State if the State is an effect of the Activity or if the State is an effect of some subactivity of the Activity. The causes property is a generalization (super-property) of the hasEffect property.
    • occursDirectlyBefore: identifies an Activity that occurred immediately prior to the Activity. The ** occursDirectlyBefore property is a sub-property of the occursBefore property.
    • beginOf: identifies the time Instant at which the Activity occurs.
    • endOf: identifies the time Instant at which the Activity ends.
  • State: A State specifies some snapshot of objects in the domain as they exist at some point in time. States have the following core set of properties:
    • hasStatus: identifies the StateStatus at some point or interval in time. For example, the State may be “unsatisfied, “satisfied” or “completed”.
    • achievedAt: identifies the time Interval or Instant during which the State was satisfied.
    • scheduledFor: identifies a time Interval during which the State is scheduled to be realized.
    • effectOf: identifies an Activity that the State was realized by.
    • preconditionOf: identifies an Activity that requires the State to be realized in order to occur.

A State may also be described with the following, supplemental properties:

    • enablesActivity: identifies an Activity that in some (indirect) way was enabled by the State. The enables property is the inverse of the enabledBy property and is a generalization (super-property) of the preconditionOf property.
    • causedByActivity: identifies an Activity that in some (indirect) way caused the State to be realized. The causedBy property is the inverse of the causes property and is a generalization (super-property) of the effectOf property.
  • TerminalState: A State may be either non-terminal or terminal. A TerminalState has no sub-states.
  • ManifestationState: A specialization of TerminalState, the ManifestationState specifies a Manifestation class that an individual must satisfy in order for the ManifestationState to be true.
    • satisfiedBy: specifies the Manifestation that is to be satisfied (i.e., realized).
  • NonTerminalState: a NonTerminalState has child States, which may be TerminalStates, or further define some other complex state types. A State cannot be both non-terminal and terminal. NonTerminalStates have the following core properties:
    • hasDecomp: identifies two or more States into which the State may be immediately decomposed, i.e. its direct children.

NonTerminalState has the following supplemental properties:

    • hasSubState: identifies a State into which the complex state decomposes, at any level (i.e. its child state, grandchild state, etc.). The hasSubState property is transitive and a super-property of the hasDecomp property.
  • ConjunctiveState: a ConjunctiveState is a type of NonTerminalState that is defined by the conjunction of its child States.
  • DisjunctiveState: a DisjunctiveState is a type of NonTerminalState that is defined by the disjunction of its child States. A State cannot be both conjunctive and disjunctive. Conjunctive and disjunctive States, which do have substates, are achieved at some time if their decomposition of States is achieved.

Has Class(es)

DisjunctiveState, ISO5087-1:ConjunctiveState, ManifestationState, NonTerminalState, State, TerminalState ISO5087-1:Activity

Status

Pending Approval


Supplementary Figures

Figure Caption
Activity Pattern.jpg
Activity Pattern Example
Retrieved from "http://citydatastandard.org/index.php?title=Pattern:Activity_Pattern&oldid=31740"