Day 1: Core Concepts



The primary objective of information systems is to bring together:

  • Comprehensive and consistent descriptions of managed organizations, processes, and systems.
  • Partial and conjectural descriptions of external business environments.

That can be done with:

  • Thesaurus: ontologies covering terms and concepts.
  • Document Management: ontologies covering documents with regard to topics.
  • Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
  • Engineering: ontologies pertaining to the symbolic representation of products and services.


With regard to the symbolic representations (aka surrogates) of business’s objects and activities it is necessary to define:

  • The categories to be represented.
  • The identification mechanisms that will ensure continuous and consistent mapping between environments and systems.
  • The features to be associated with instances within each category.


Classifications (aka ontologies) are built on purpose, and as far as symbolic representations are concerned, targeted instances can be neatly classified along six basic categories, with another two for containers:

descr110Physical containers

Physical containers are holders introduced to address actual objects and control processes execution.

descrPackSymbolic containers

Symbolic containers don’t deal instances but with descriptions whose semantics are managed under a single authority. For instance, organizational units will usually be simultaneously associated to different physical (locations) and symbolic (business objects and processes) containers. They should not be confused with collections which are abstract constructs used by containers to manage sets of instances, actual or symbolic.


Physical realizations of symbolic containers introduced to manage instances (aka surrogates) of digital objects.

descr21Physical entity

Actual objects (active or passive) with stable (but not necessarily persistent) physical identity. Identities, life-cycle and behaviors are set by the businesses under consideration. Documents, systems, or locations can also be defined as physical entities.

descr20Symbolic description

Describe how instances of objects and activities are to be represented by surrogates, whether as paper or digital documents. Not o be confounded with symbolic physical objects (e.g documents) or digital hybrids (e.g digital signatures).


Active physical entity with social identity.


Part played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents (physical identity) or associations (static).


Change in the state of business objects, processes, or users’ expectations. Since the execution of  activities is defined by time-frames, they appear as events when start and completion cannot be distinguished.


Functional description of operations and flows (data and control) defined independently of the part played by supporting systems. Equivalent to UML and BPM terms.

descr41Execution state (aka mode)

Operational description of activities with regard to processes’ control and execution.

Refined categories can then be defined by crossing primary ones.


A key purpose of the above classification is to tally with identification mechanisms supporting the continuous and consistent alignment of business objects and activities with their symbolic counterpart:

  • Source of identification: natural, physical, or social.
  • Life-cycle of identified instances: persistent (objects), transient (activities), or instant (events).


The primary objective of categories is to select the relevant features shared by instances. It’s worth to note that while features can be initially defined independently of their nature (attribute, operation, or reference), they must be classified with regard to representation constraints:

  • Structural features are bound to identities.
  • Functional features can be modified.
  • Derived features are computed.

These constraints will mark out the way models can be built.

A Little Practice

Find three examples of each category in the Garage case study.

Further Reading