Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/doriantaylor/owl-process-model
A Process Model Ontology
https://github.com/doriantaylor/owl-process-model
Last synced: about 1 month ago
JSON representation
A Process Model Ontology
- Host: GitHub
- URL: https://github.com/doriantaylor/owl-process-model
- Owner: doriantaylor
- License: apache-2.0
- Created: 2022-04-26T19:29:40.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2024-03-10T17:39:32.000Z (11 months ago)
- Last Synced: 2024-03-10T18:46:26.574Z (11 months ago)
- Language: Makefile
- Size: 38.1 KB
- Stars: 1
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# A Process Model Ontology
Author
Dorian Taylor
Created
July 22, 2009
Updated
February 6, 2014
April 6, 2017
March 8, 2020
Namespace URI
https://vocab.methodandstructure.com/process-model#
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](https://vocab.methodandstructure.com/ibis#) 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 airport 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:
- The IBIS (bis) Vocabulary
- The
Event Ontology
- Simple
Knowledge Organization System
## Classes
The classes in this vocabulary are refined as follows:
The central concepts,
[pm:Goal](https://vocab.methodandstructure.com/process-model#Goal) and
[pm:Task](https://vocab.methodandstructure.com/process-model#Task),
extend the [ibis:Issue](https://vocab.methodandstructure.com/ibis#Issue)
and [ibis:Position](https://vocab.methodandstructure.com/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](https://vocab.methodandstructure.com/process-model#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
### Goal
A Goal extends a State by way of being explicitly desired by an Agent.
A Goal is not actionable itself, although Tasks, which are Actions, must
achieve at least one Goal. At the time of observation, a Goal, like its
superclass, State, is either true or false. This entails that a Goal is
not expressed in terms of quantitative results or deadlines. That is the
job of a Target.
Subclass of:
pm:State
### Target
A Target connects an abstract Goal to a specific Task, budget and
deadline.
The logical separation of a Target from a Goal makes it possible to
speak of a Goal in abstract terms, and generate several equivalent
candidate Tasks, each with one or more candidate Methods, which may
achieve it.
Subclass of:
pm:Goal
Properties:
pm:anchors
### 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
### Method
A method specifies an abstract sequence of events.
This class is provisional. It isn't entirely clear that we need a
distinct Method class, since Tasks and the like could be appropriated as
prototypes of methods.
Subclass of:
pm:Action
Disjoint with:
pm:State
### 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.
Since pm:Task is a descendant of ev:Event, we can use the ev:time
relation to specify a time:Interval to record the time taken to complete
a task.
Subclass of:
pm:Action
Properties:
pm:achieves
## 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
### 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
### budget
All Targets require a quantitative budget.
It is not clear, prior to implementation, if we should keep the budget
as a raw quantity, or create some kind of resource envelope object.
Domain:
pm:Target
Range:
xsd:decimal
Cardinality:
1
### context
The context of an Action is a State.
The pm:context and pm:outcome properties can be used to chain pm:Actions
together.
Domain:
pm:Action
Range:
pm:State
Sub-property of:
ev:factor
### dependency
A State the Action depends on to be actionable.
Domain:
pm:Action
Range:
pm:State
Sub-property of:
ibis:suggests
### desires
A foaf:Agent may desire a Goal.
Domain:
foaf:Agent
Range:
pm:Goal
Sub-property of:
ibis:endorses
### initiates
A valid target must initiate exactly one task to carry it out.
Domain:
pm:Target
Range:
pm:Task
Cardinality:
1
### method
All Tasks must identify an associated Method which will be used to
complete them.
Domain:
pm:Task
Range:
pm:Method
### outcome
All Actions have an outcome, which is some kind of State.
Domain:
pm:Action
Range:
pm:State
Sub-property of:
ev:product
### 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
### 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
### 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
### 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
### variant
A variant is an alternate method of performing the same action.
Domain:
pm:Action
Range:
pm:Action
Sub-property of:
ev:sub_event
## Individuals
Currently, the only individuals defined by this vocabulary are those
common, reusable States which can be used as values for
[pm:status](https://vocab.methodandstructure.com/process-model#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.