A Process Model Ontology

Author
Dorian Taylor
Created
July 22, 2009
Updated
February 6, 2014
April 6, 2017
March 8, 2020
Namespace URI
https://privatealpha.com/ontology/process-model/1#
Preferred Namespace Prefix
pm

This vocabulary encodes a model for expressing generic business processes. Its purpose is to provide a language and exchange format for software applications designed to facilitate project management. This vocabulary extends the IBIS vocabulary in the natural fashion that once we have framed an issue and decided to solve it, we must then specify a method, nominate a person responsible, and allocate time and material resources to carry out the solution.

Goal, Task, Target

In deliberate contravention to the received wisdom of management gurus and their business books, as well as countless project management and to-do applications, this vocabulary separates the concept of an abstract goal from the task of achieving it. It likewise separates these two concepts from the stipulation of a budget and/or deadline. Finally, it separates a concrete task from the abstract method by which it is completed.

By separating these concepts into distinct logical objects, we gain new capabilities:

  1. Budgets and deadlines become subordinate to the real availability of people, materials, equipment, and methods to achieve stated goals.
  2. We can record unintended consequences, both negative and positive, of carrying out tasks.
  3. The development of a method to carry out a given task is itself promoted to a first-order task.
  4. We can generate a library of methods, with statistics on people, time and costs, to inform future allocations of tasks and targets.

This process model vocabulary connects and extends the following vocabularies:

Classes

The classes in this vocabulary are refined as follows:

The central concepts, pm:Goal and pm:Task, extend the ibis:Issue and ibis:Position types, so that goals, tasks and targets can be mixed into, as well as graduated from, generic collaborative argumentation and decision-making sessions. Likewise, the pm:Action class extends ev:Event so that actions and tasks can be mixed in with generic events on a timeline.

State

A State can be understood as a snapshot of a system at a given time, such as before or after an event.

A State is distinct from a particular instant, but it is analogous to it. At the time of observation, a State is either true or false.

Subclass of:
skos:Concept

Back to Top

Goal

A Goal extends a State by way of being explicitly desired by an Agent.

Subclass of:
pm:State
ibis:Issue

Back to Top

Target

A Target connects an abstract Goal to a specific Task, budget and deadline.

Subclass of:
pm:Goal
Properties:
pm:anchors
pm:initiates
pm:budget
pm:due

Back to Top

Action

An Action specializes an Event in that it is performed by (at least one) real, living Person.

Subclass of:
ev:Event
Disjoint with:
pm:State
Properties:
pm:context
pm:dependency
pm:performer
pm:outcome
pm:variant

Back to Top

Method

A method specifies an abstract sequence of events.

Subclass of:
pm:Action
Disjoint with:
pm:State

Back to Top

Task

A Task specializes an Action in that it has one or more Goals, and connects a Method of execution with a responsible Person who will carry it out.

Subclass of:
pm:Action
ibis:Position
Properties:
pm:achieves
pm:method
pm:responsible
pm:recipient
pm:status
pm:subtask

Back to Top

Properties

The properties in this vocabulary are refined as follows. For brevity, properties that have no inheritance path have been omitted from this image:

achieves

The purpose of a task is to achieve a goal. All tasks specified in this vocabulary must also specify the goal they are intended to achieve.

Domain:
pm:Task
Range:
pm:Goal
Sub-property of:
pm:outcome

Back to Top

anchors

By anchoring a Goal to a Target, we give it a concrete budget and deadline.

Domain:
pm:Target
Range:
pm:Goal
Sub-property of:
ibis:specializes

Back to Top

budget

All Targets require a quantitative budget.

Domain:
pm:Target
Range:
xsd:decimal
Cardinality:
1

Back to Top

context

The context of an Action is a State.

Domain:
pm:Action
Range:
pm:State
Sub-property of:
ev:factor

Back to Top

dependency

A State the Action depends on to be actionable.

Domain:
pm:Action
Range:
pm:State
Sub-property of:
ibis:suggests

Back to Top

desires

A foaf:Agent may desire a Goal.

Domain:
foaf:Agent
Range:
pm:Goal
Sub-property of:
ibis:endorses

Back to Top

due

All Targets must have a due date.

Domain:
pm:Target
Range:
xsd:dateTime
Cardinality:
1

Back to Top

initiates

A valid target must initiate exactly one task to carry it out.

Domain:
pm:Target
Range:
pm:Task
Cardinality:
1

Back to Top

method

All Tasks must identify an associated Method which will be used to complete them.

Domain:
pm:Task
Range:
pm:Method

Back to Top

outcome

All Actions have an outcome, which is some kind of State.

Domain:
pm:Action
Range:
pm:State
Sub-property of:
ev:product

Back to Top

performer

A performer is a real, live (at the time of performance) person who performs a task.

Sub-property of:
ev:agent
Domain:
pm:Action
Range:
foaf:Person

Back to Top

responsible

The person responsible for a task may not be the one performing it, but they are the one accountable for its completion.

Sub-property of:
ev:agent
Domain:
pm:Task
Range:
foaf:Person

Back to Top

recipient

A recipient of a task is a (real, live at the time of receipt) person who receives and approves its product or products.

Domain:
pm:Task
Range:
foaf:Person

Back to Top

status

The status of a Task at any instant is a State.

Domain:
pm:Task
Range:
pm:State

Back to Top

subtask

This property narrows the domain and range of ev:sub_event to Tasks.

Domain:
pm:Task
Range:
pm:Task
Sub-property of:
ev:sub_event

Back to Top

variant

A variant is an alternate method of performing the same action.

Domain:
pm:Action
Range:
pm:Action
Sub-property of:
ev:sub_event

Back to Top

Individuals

Currently, the only individuals defined by this vocabulary are those common, reusable States which can be used as values for pm:status. Most other statuses, such as whether a Task has a responsible person assigned or a valid Method, should be able to be derived from other data.

ABORTED

The task is aborted.

Back to Top

COMPLETE

The task is complete.

Back to Top

IN-PROGRESS

The task is in progress.

Back to Top

STALLED

The task is stalled.

Back to Top