Task Model Ontology (TMO)
Task-Force Ontologies 02.09.2008
- Latest Version:
- http://www.semanticdesktop.org/ontologies/tmo
- This Version:
- This file refers to the Revision 1.0 of TMO. Minor changes may be implemented in future revisions. With each new revision, the documentation and all serializations of the ontology will be updated. The URI identifying this version (but not the namespace) is http://www.semanticdesktop.org/ontologies/2008/05/20/tmo/v1.0/
- Authors:
- Marko Brunzel, DFKI, marko.brunzel@dfki.de
- Olaf Grebner, SAP, olaf.grebner@sap.com
- Editors:
- Marko Brunzel, DFKI, marko.brunzel@dfki.de
- Olaf Grebner, SAP, olaf.grebner@sap.com
- Contributors:
- Leo Sauermann, DFKI, leo.sauermann@dfki.de
- Michael Sintek, DFKI, michael.sintek@dfki.de
- Ludger van Elst, DFKI, elst@dfki.de
- Ansgar Bernardi, DFKI, ansgar.bernardi@dfki.de
- Uwe Riss, SAP, uwe.riss@sap.com
- Ontology:
- XML/RDFS Serialization: TMO (Data Graph Only)
- XML/RDFS Serialization: TMO (Metadata Graph Only)
- TriG Serialization: TMO (Graph Set)
Copyright © 2008 OSCAF®
The ontologies are made available under the terms of OSCAF software license
Abstract
The TMO Ontology can be used to describe personal tasks of individuals, also known as to-do lists. It is based on RDF and NRL, the NEPOMUK Representational Language and other Semantic Web ontologies. This document describes the fundamental elements of the language and how to use them.
Status of this document
This section describes the status of this document at the time of its publication. The form used for this status message and document is inspired by the W3C process.
This document is an Editors Draft produced by Olaf Grebner and Marko Brunzel as part of the work package task management in the NEPOMUK project. The task-force intends this document to become a NEPOMUK standard. The editors of this document value feedback from the public and from NEPOMUK members. Please add comments as tickets in the NEPOMUK tracker using the category ontology-tmo. This document is accompanied by a RDFS/NRL ontology, which should be read in parallel to learn more about TMO.
This document and the TMO ontology as such are a continuation and improvement of existing work. Other documents may supersede this document. Parts of this document will be published in other documents, such as scientific publications. This document is based on various other publications by the authors, and is a continuation of existing work. Some formulations from the RDFS primer and SKOS primer documents were reused.
1. Introduction
The Task Management Model Ontology (TMO) is a conceptual representation of tasks for use in personal task management applications for knowledge workers.
Knowledge workers perform knowledge work. For example, managers, researchers and sales representatives are knowledge workers. Knowledge work is goal driven, i.e., a knowledge worker strives to achieve a goal with the execution of her work. Knowledge work can be broken down into tasks where each task has a goal that the knowledge worker needs to achieve in order to complete the task. Knowledge workers can reach their goals using different approaches and methods which can differ individually from knowledge worker to knowledge worker. Knowledge is thus rather characterized by variety than by routine.
Tasks are units of work. We address a kind of tasks which often arise during performing the work, compared to task which are apriory given. Or in other words, the modelling of tasks is also done during task execution. Workflows are usually not enforced upon those tasks. Such tasks can form flexible workflows where recommendations regarding the execution of particular tasks are made.
In the NEPOMUK environment, information chunks are expressed by the NAO, NIE and PIMO ontologies. In principle, every piece of information can have the character of a task.
Personal Task Management (PTM) helps knowledge workers to manage their personal, scarce work capacity to achieve their given goals in the desired quality. PTM focuses a personal process perspective, i.e., to manage the activities the knowledge worker performs to get the work done. Tackling information and task overload, the knowledge worker can manage the task workload so that the tasks can be executed on time, scope and budget. A core part of task management is thus enabling prioritization decisions that allow the knowledge worker to decide on what tasks to execute when, to what extent and to what cost.
PTM applications support knowledge workers in performing efficient task management to achieve their goals in the best possible way. PTM applications offer functionality to help the knowledge worker to manage the whole set of tasks that the knowledge worker has to accomplish. This happens in the form of a task list, as well known as to-do lists. Task lists here use lists of explicit task representations, i.e., for each task in the list, a dedicated task representation exists and contains the task information needed for the knowledge worker to identify, use and prioritize the task.
Bringing together PTM and PIM, the TMO is an ontology that enables the knowledge worker to organize lists of tasks in conjunction with organizing information needed to execute these tasks. Foremost, the TMO captures the knowledge worker's tasks and applications using it enable the knowledge worker to get on overview on what needs to be done and how the knowledge worker can prioritize this. In addition, the TMO supports applications to manage the information that is needed from a knowledge worker's perspective to fulfil the task. This includes for example information on who else is involved in the task and what category the task belongs to.
Further information on the TMO going beyond this document can be found at [TASKMODEL]. This includes background information on task management, state of the art in task modelling, modelling considerations in the personal task space and explains modelling decisions taken for the TMO.
2. Scope and Covered Use Cases
The TMO is designed for use as part the of PIM platform Nepomuk. The respective Nepomuk Ontology framework provides ontologies for conducting personal information management in particular on the desktop, see [PIMO], [NIE]. The TMO is an extension of the PIMO ontology focusing on tasks and the support of PTM applications. However, applications can use the TMO as well without accessing this Nepomuk ontology framework to support personal task management. Using Nepomuk, the knowledge worker and application developer gain the support for desktop integration, i.e., the integration with information models that represent the entities of a desktop, like e.g. emails and files.
The TMO covers with its task model a number of task management use cases that can be implemented in task management applications. The TMO provides the conceptual basis for these use cases. These use cases are:
- Personal Task Management - Personal Task Management consists of several parts.
- Basic task handling - Basic task handling deals with organizing a knowledge workers task, e.g., creating and populating a task.
- Task list management - Task list management deals with the knowledge worker handling a personal to-do list where the Knowledge worker manages a list of personal tasks that are due for execution or are already executed.
- Task priority management - Task priority management helps the knowledge worker to maintain the priorities coming with a task.
- Task time management - Task time management focuses on the time needed to execute a task and the knowledge worker can assign a task due date to manage the time-related aspects of work.
- Task planning - Task planning helps the knowledge worker to structure the workload and perform work decomposition, i.e., breaking down and categorizing tasks.
- Task Information Management - Task Information Management helps the knowledge worker to collect and associate information needed for executing a task. This includes task tags to group tasks, information object attachments to connect tasks to, e.g., emails and files, and as social aspect persons involved in a task.
- Social Task Management - Social Task Management focuses on collaboration in the task domain. This means, that knowledge workers can delegate tasks to each other, can perform and task tracking and conduct information sharing.
In addition, knowledge workers and application developers can extend the TMO to cover further use cases. These TMO extensions (TMOE) can for example support experience and knowledge management for tasks with task patterns [TASKMODEL].
3. TMO Modelling
The core class of the TMO is the class tmo:Task. The tmo:Task is a subclass of pimo:ProcessConcept. The inheritance hierarchy of the tmo:Task is shown in the figure below.
Details of a task are represented by attributes modelled as shown in the figure below. Tasks can be grouped by means of the tmo:TaskCollection class.
There are some classes that have been modelled according to a role based modelling approach. Hereby it is possible to model n-ary relations. In particular attachments, the involvement of persons and of actors and resource (furthermore referred as AbilityCarriers) and task dependencies have been modelled this way. The overviews on those four circumstances are shown in the figures below:
tmo:PersonInvolvement
tmo:AbilityCarrierInvolvement
tmo:Attachment
tmo: TaskDependency
The transmission of tasks is represented by the tmo:TaskTransmission class.
References
- [PIMO]
- Personal Information Model ontology (PIMO) , Leo Sauermann, Ludger van Elst, Knud Möller, http://www.semanticdesktop.org/ontologies/pimo
- [NIE]
- NEPOMUK Information Element Ontology (NIE) , Antoni Mylka, Leo Sauermann, Michael Sintek, Ludger van Elst, http://www.semanticdesktop.org/ontologies/nie
- [TASKMODEL]
- Task Management Model (TMO) , Olaf Grebner, Ernie Ong, Uwe Riss, Marko Brunzel, Ansgar Bernardi, Thomas Roth-Berghofer, http://nepomuk.semanticdesktop.org/xwiki/bin/download/Main1/D3-1/D3.1_v10_NEPOMUK_Task_Management_Model.pdf
Ontology Classes Description
AbilityCarrier
| rdfs:Resource |
| tmo:Role, tmo:Skill |
| -- |
| tmo:abilityCarrier |
| Description | tmo:AbilityCarrier is an abstract class which comprises all entities which can take action or which are somehow involved in tasks.
This is in other task conceptualizations rather named "actor". But here it is named tmo:AbilityCarrier because it is not necessarily "active".
The execution of a task relies on certain abilities. The abstract concept of
tmo:AbilitiyCarrier's comprise all those more concrete concepts
of which one can think of while working on tasks. Using this abstract
class enables to substitute such tmo:AbilityCarrier's in the process of
generating patterns from task instances and vice versa in the process of
instantiating task instances from patterns without violating the schema.
With this attribute, a series of ability carrying entities (Person, Role,
Skill) and the role of involvement (required, request, used) is enabled. The role
hereby allows specifying how the ability carrying entity is or was
involved. |
AbilityCarrierInvolvement
| pimo:Association, pimo:ClassOrThingOrPropertyOrAssociation, rdfs:Resource |
| -- |
| tmo:abilityCarrier, tmo:abilityCarrierRole, tmo:abilityCarrierTask |
| tmo:abilityCarrierInvolvement |
| Description | For a task it is possible to state which kinds of actors are involved in a task. Even more importantly the desired role or skills for this task can be explicitly stated. This provides guidance to which persons should be included and the role they might play in the task. To such as actors, we refer to as "Ability Carrier", which is more passive than the label "Actor", since not each involved thing is necessarily acting. The Involvement is further characterized by different roles: Requested, Required and Used.
The class AbilityCarrierInvolvement ties together an AbilityCarrier with an AbilityCarrierRole. |
AbilityCarrierRole
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:abilityCarrierRole |
| Description | Examples instances of tmo:AbilityCarrierRole's are e.g. "requested", "required" and "used" which further specify the type a person was involved in. |
| tmo:TMO_Instance_AbilityCarrierRole_Requested, tmo:TMO_Instance_AbilityCarrierRole_Required, tmo:TMO_Instance_AbilityCarrierRole_Used |
AssociationDependency
Attachment
| pimo:Association, pimo:ClassOrThingOrPropertyOrAssociation, rdfs:Resource |
| -- |
| tmo:attachmentReference, tmo:attachmentRole, tmo:attachmentTask, tmo:createdBy |
| tmo:attachment |
| Description | By means of attachments, references to other resources can be established. Resources are information objects. Every Thing, which can be referenced, on the Nepomuk Social Semantik Desktop is an information object. In contrast to the usual Nepomuk Social Semantik Desktop references/associations, here additionally information can be specified. Further metadata about the role an attachment plays can be stated by means of instances of tmo:AttachmentRole. It can be expressed what the Role of attachment is e.g., regarding "desired/requested" or "required" or "potentially useful / somehow related" or "used/produced/achieved". The reference property models the actual link to the attached piece of information. |
AttachmentRole
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:attachmentRole |
| Description | tmo:AttachmentRoles further specify the type of how an tmo:Attachment relates to a tmo:Task. Example instances of tmo:AttachmentRoles are e.g. "desired_request", "required" and "used". |
| tmo:TMO_Instance_AttachmentRole_Desired_Requested, tmo:TMO_Instance_AttachmentRole_Related, tmo:TMO_Instance_AttachmentRole_Required, tmo:TMO_Instance_AttachmentRole_Used |
Delegability
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:delegability |
| Description | The extent to which a task is suited to be delegated. The stated instances are only proposals. The user should create instances which reflect his desired nuances. Aslo a straight Boolean decision is considerable. |
| tmo:TMO_Instance_Delegability_High, tmo:TMO_Instance_Delegability_Low, tmo:TMO_Instance_Delegability_Medium, tmo:TMO_Instance_Delegability_Never, tmo:TMO_Instance_Delegability_Unrestricted |
Importance
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:importance |
| Description | The importance of a task according to the "ABC analysis" (see also http://en.wikipedia.org/wiki/Time_management for a general description of "ABC" like task ordering). We envision not only two shades but allow for more fine grain nuances. There are a couple if instances realizing named instances of importance. This property is usually combined with the property/class tmo:Urgence.. |
| tmo:TMO_Instance_Importance_01, tmo:TMO_Instance_Importance_02, tmo:TMO_Instance_Importance_03, tmo:TMO_Instance_Importance_04, tmo:TMO_Instance_Importance_05, tmo:TMO_Instance_Importance_06, tmo:TMO_Instance_Importance_07, tmo:TMO_Instance_Importance_08, tmo:TMO_Instance_Importance_09, tmo:TMO_Instance_Importance_10 |
Interdependence
PersonInvolvement
PersonInvolvementRole
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:involvedPersonRole |
| Description | Specifies the role a person plays in a task. These Roles are e.g. Creator, Controller, Requester, Contributor, Analyst, External Observer, Delegate, Task Owner, Executor, or Internal Observer. Some roles are only for information purpose, some are used for functionality e.g. for collaborative tasks. |
| tmo:TMO_Instance_PersonInvolvementRole_Analyst, tmo:TMO_Instance_PersonInvolvementRole_Co-worker, tmo:TMO_Instance_PersonInvolvementRole_Collaborator, tmo:TMO_Instance_PersonInvolvementRole_Controller, tmo:TMO_Instance_PersonInvolvementRole_Creator, tmo:TMO_Instance_PersonInvolvementRole_Delegate, tmo:TMO_Instance_PersonInvolvementRole_Executor, tmo:TMO_Instance_PersonInvolvementRole_ExternalObserver, tmo:TMO_Instance_PersonInvolvementRole_Initiator, tmo:TMO_Instance_PersonInvolvementRole_InternalObserver, tmo:TMO_Instance_PersonInvolvementRole_Involved, tmo:TMO_Instance_PersonInvolvementRole_Observer, tmo:TMO_Instance_PersonInvolvementRole_Owner, tmo:TMO_Instance_PersonInvolvementRole_Receiver, tmo:TMO_Instance_PersonInvolvementRole_Related, tmo:TMO_Instance_PersonInvolvementRole_Reviewer, tmo:TMO_Instance_PersonInvolvementRole_Suggested |
PredecessorDependency
PredecessorSuccessorDependency
Priority
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:priority |
| Description | The priority of a task. See http://en.wikipedia.org/wiki/Time_management for different approaches on finding priorities. There are 3 default instances: low, medium and high. |
| tmo:TMO_Instance_Priority_High, tmo:TMO_Instance_Priority_Low, tmo:TMO_Instance_Priority_Medium |
Role
| tmo:AbilityCarrier, rdfs:Resource |
| -- |
| -- |
| -- |
| Description | The realizes roles in the sense that humans play various roles in their activities. Examples are e.g. : architect, developer or moderator. |
SimilarityDependence
Skill
| tmo:AbilityCarrier, rdfs:Resource |
| -- |
| -- |
| -- |
| Description | Skill humans posess and which are involved in activities. Examples areexamples are e.g. technologies like Java, XML, ... |
StateTypeRole
| rdfs:Resource |
| tmo:AbilityCarrierRole, tmo:AttachmentRole, tmo:Delegability, tmo:Importance, tmo:PersonInvolvementRole, tmo:Priority, tmo:TaskEffortAccuracy, tmo:TaskEffortType, tmo:TaskPrivacyState, tmo:TaskState, tmo:TransmissionState, tmo:TransmissionType, tmo:Urgency |
| -- |
| -- |
| Description | tmo:StateTypeRole is an abstract class which subsumes various other classes which represent "states" or roles e.g. in role based modelling conceptualisations. |
| tmo:TMO_Instance_AbilityCarrierRole_Requested, tmo:TMO_Instance_AbilityCarrierRole_Required, tmo:TMO_Instance_AbilityCarrierRole_Used, tmo:TMO_Instance_AttachmentRole_Desired_Requested, tmo:TMO_Instance_AttachmentRole_Related, tmo:TMO_Instance_AttachmentRole_Required, tmo:TMO_Instance_AttachmentRole_Used, tmo:TMO_Instance_Delegability_High, tmo:TMO_Instance_Delegability_Low, tmo:TMO_Instance_Delegability_Medium, tmo:TMO_Instance_Delegability_Never, tmo:TMO_Instance_Delegability_Unrestricted, tmo:TMO_Instance_Importance_01, tmo:TMO_Instance_Importance_02, tmo:TMO_Instance_Importance_03, tmo:TMO_Instance_Importance_04, tmo:TMO_Instance_Importance_05, tmo:TMO_Instance_Importance_06, tmo:TMO_Instance_Importance_07, tmo:TMO_Instance_Importance_08, tmo:TMO_Instance_Importance_09, tmo:TMO_Instance_Importance_10, tmo:TMO_Instance_PersonInvolvementRole_Analyst, tmo:TMO_Instance_PersonInvolvementRole_Co-worker, tmo:TMO_Instance_PersonInvolvementRole_Collaborator, tmo:TMO_Instance_PersonInvolvementRole_Controller, tmo:TMO_Instance_PersonInvolvementRole_Creator, tmo:TMO_Instance_PersonInvolvementRole_Delegate, tmo:TMO_Instance_PersonInvolvementRole_Executor, tmo:TMO_Instance_PersonInvolvementRole_ExternalObserver, tmo:TMO_Instance_PersonInvolvementRole_Initiator, tmo:TMO_Instance_PersonInvolvementRole_InternalObserver, tmo:TMO_Instance_PersonInvolvementRole_Involved, tmo:TMO_Instance_PersonInvolvementRole_Observer, tmo:TMO_Instance_PersonInvolvementRole_Owner, tmo:TMO_Instance_PersonInvolvementRole_Receiver, tmo:TMO_Instance_PersonInvolvementRole_Related, tmo:TMO_Instance_PersonInvolvementRole_Reviewer, tmo:TMO_Instance_PersonInvolvementRole_Suggested, tmo:TMO_Instance_Priority_High, tmo:TMO_Instance_Priority_Low, tmo:TMO_Instance_Priority_Medium, tmo:TMO_Instance_TaskEffortAccuracy_Approximate, tmo:TMO_Instance_TaskEffortAccuracy_Exact, tmo:TMO_Instance_TaskPrivacy_Private, tmo:TMO_Instance_TaskPrivacy_Professional, tmo:TMO_Instance_TaskState_Archived, tmo:TMO_Instance_TaskState_Completed, tmo:TMO_Instance_TaskState_Deleted, tmo:TMO_Instance_TaskState_Finalized, tmo:TMO_Instance_TaskState_New, tmo:TMO_Instance_TaskState_Running, tmo:TMO_Instance_TaskState_Suspended, tmo:TMO_Instance_TaskState_Terminated, tmo:TMO_Instance_TransmissionState_Accepted_NotTransmitted, tmo:TMO_Instance_TransmissionState_Accepted_Transmitted, tmo:TMO_Instance_TransmissionState_NotTransmitted, tmo:TMO_Instance_TransmissionState_Rejected_NotTransmitted, tmo:TMO_Instance_TransmissionState_Rejected_Transmitted, tmo:TMO_Instance_TransmissionState_Transmitted, tmo:TMO_Instance_TransmissionType_Delegation, tmo:TMO_Instance_TransmissionType_Join, tmo:TMO_Instance_TransmissionType_Transfer, tmo:TMO_Instance_Urgency_01, tmo:TMO_Instance_Urgency_02, tmo:TMO_Instance_Urgency_03, tmo:TMO_Instance_Urgency_04, tmo:TMO_Instance_Urgency_05, tmo:TMO_Instance_Urgency_06, tmo:TMO_Instance_Urgency_07, tmo:TMO_Instance_Urgency_08, tmo:TMO_Instance_Urgency_09, tmo:TMO_Instance_Urgency_10 |
SuccessorDependency
SuperSubTaskDependency
| pimo:Association, pimo:ClassOrThingOrPropertyOrAssociation, rdfs:Resource, tmo:TaskDependency |
| -- |
| -- |
| -- |
| Description | Stating that a task is a subtask of aanother tasks is accomplised by the property tmo:subtask. By means of the tmo:SuperSubTaskDependency one can additionally describe the subtask-supertask relation e.g. by an description. This enables an n-ary relation between subtask and supertask. |
Task
| pimo:ClassOrThing, pimo:ClassOrThingOrPropertyOrAssociation, pimo:ProcessConcept, rdfs:Resource, pimo:Task, pimo:Thing |
| -- |
| tmo:abilityCarrierInvolvement, tmo:actualCompletion, tmo:actualEndTime, tmo:actualStartTime, tmo:actualTimeUsage, tmo:attachment, tmo:contextThread, tmo:delegability, tmo:dependency, tmo:dueDate, tmo:importance, tmo:indexPosition, tmo:lastReviewDate, tmo:logEntry, tmo:nextReviewIntervall, tmo:personInvolvement, tmo:priority, tmo:subTask, tmo:subTaskOrdering, tmo:superTask, tmo:targetCompletion, tmo:targetEndTime, tmo:targetStartTime, tmo:targetTimeUsage, tmo:taskDescription, tmo:taskEffort, tmo:taskGoal, tmo:taskId, tmo:taskName, tmo:taskPrivacyState, tmo:taskSource, tmo:taskState, tmo:taskTransmission, tmo:urgency |
| tmo:abilityCarrierTask, tmo:attachmentTask, tmo:containsTask, tmo:contextTask, tmo:dependencyMemberA, tmo:dependencyMemberB, tmo:involvedPersonTask, tmo:subTask, tmo:superTask, tmo:taskReference, tmo:transmissionTask |
| Description | The tmo:task is the central entity of the tmo. Task can range from vague things to be possibly done in e distant future to concrete things to be done in a precise foreseeable manner. It is not unrealistic to assume that knowledge worker have hundred or more tasks a day.
A task can have subtasks. Or the other way around, a task can be assigned to a supertask. A subtask is an independent task, which refers to another task via a subtask relation. Usually this means that the execution of the subtask is required in order to fulfil the execution of the super task. But finally this is left to the user; the user is free to finish a supertask while some subtasks are not finished. Subtasks can be used to structure complex task into manageable parts. Consequently subtasks can also be used to transfer a certain aspect of a complex task to other participants.
A tmo:Task is modelled as a subclass of pimo:ProcessThing which is a subclass of pimo:Thing. This was done because the information artefacts which a knowledge worker has in his mind are supposed to be represented in the PIMO and tasks can be such concepts. This implies practically that tasks are not only visible within special task management applications but also within PIMO editing and viewing applications . This does not necessarily mean that in such a generic PIMO editing environment all task properties can be altered but rather that the task is at least displayed by its name. |
TaskContainer
TaskDependency
| pimo:Association, pimo:ClassOrThingOrPropertyOrAssociation, rdfs:Resource |
| tmo:AssociationDependency, tmo:Interdependence, tmo:PredecessorDependency, tmo:PredecessorSuccessorDependency, tmo:SimilarityDependence, tmo:SuccessorDependency, tmo:SuperSubTaskDependency, tmo:UndirectedDependency |
| tmo:dependencyDescription, tmo:dependencyMemberA, tmo:dependencyMemberB, tmo:dependencyOrderNumber |
| tmo:dependency |
| Description | By means of the tmo:subtask property hierarchiesof tasks can be represented. This is the primary dependency structure. But further dependencies among tasks may exist. These dependencies allow for a graph network structure. For ease of use, dependencies should not be too frequent, otherwise the primarily character of a hierarchy would be diminished and a consequent graph (opposed to tree) representation would become considerable. However, such a graph representation has other drawbacks, the user is likely to loose oversight, tree structures are more helpful in structuring the work.
A dependency relation is characterized by the type of the relation and by an additional description. There are different possibilities for dependency relations between tasks. |
TaskEffort
| rdfs:Resource |
| -- |
| tmo:taskEffortAccuracy, tmo:taskEffortDuration, tmo:taskEffortEndDate, tmo:taskEffortStartDate, tmo:taskEffortType |
| tmo:taskEffort |
| Description | The class tmo:TaskEffort can be used to represent periods of time a task is intented to be work on, or was actually worked on. This differentiation is modelled by the three instances of tmo:TaskEffortType (Planned/Actual/Running). For the time, there are two diifferent wys of representation. one is the start and end time as two points of time, the other is the duration as an intervall. When start and end time are known the duration can be calculated, but there are also situations where only the duration is known or where the actual duration is not exactly the time between start and end time. |
TaskEffortAccuracy
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:taskEffortAccuracy |
| Description | The class tmo:TaskEffortAccuracy can be used to differentiate whether the effort facts are "Exact" or wheather they are "Approximate". |
| tmo:TMO_Instance_TaskEffortAccuracy_Approximate, tmo:TMO_Instance_TaskEffortAccuracy_Exact |
TaskEffortTaskEffortType
| -- |
| -- |
| -- |
| -- |
| Description | |
| tmo:TMO_Instance_TaskEffortType_Actual, tmo:TMO_Instance_TaskEffortType_Planned, tmo:TMO_Instance_TaskEffortType_Running |
TaskEffortType
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:taskEffortType |
| Description | The class tmo:TaskEffortType provides instances which can be used to separate between the state of and task Effort; if this is planned for the future (Planned), if this is currently pending (Running) or if the effort was already done (Actual). |
TaskPrivacyState
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:taskPrivacyState |
| Description | The tmo:TaskPrivacyState serves for the separation between a professional and a private purpose of a task. This attribute provides with the values "professional/private" a high-level separation of privacy in terms of setting distribution and access
rights to other users for the task. |
| tmo:TMO_Instance_TaskPrivacy_Private, tmo:TMO_Instance_TaskPrivacy_Professional |
TaskState
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| tmo:taskStateChangesFrom, tmo:taskStateChangesTo |
| tmo:taskState, tmo:taskStateChangesFrom, tmo:taskStateChangesTo |
| Description | The tmo:taskState property allows tracking a task during its lifecycle. The tmo:TaskState class was modelled so that for each state can be set which the typical prior and posterior states are. This has the advantage that e.g. a UI can retrieve the allowed states at runtime from the ontology; rather can having this potentially changing knowledge hard coded. But the prior and posterior states are only defaults; the human user is always free to change the state. |
| tmo:TMO_Instance_TaskState_Archived, tmo:TMO_Instance_TaskState_Completed, tmo:TMO_Instance_TaskState_Deleted, tmo:TMO_Instance_TaskState_Finalized, tmo:TMO_Instance_TaskState_New, tmo:TMO_Instance_TaskState_Running, tmo:TMO_Instance_TaskState_Suspended, tmo:TMO_Instance_TaskState_Terminated |
TaskTransmission
| rdfs:Resource |
| -- |
| tmo:receiveDateTime, tmo:sendDateTime, tmo:transmissionFrom, tmo:transmissionState, tmo:transmissionTask, tmo:transmissionTo, tmo:transmissionType |
| tmo:taskTransmission |
| Description | Tasks are not restricted to one person and may cross from
the PTM of one person to the PTM of another. With transmission, we
refer to the process of sending a task from one person (sender) to one
or more other persons (receiver(s)) (see Section 5.2.1.3 Task
Transmission). Task delegation and task transfer are two special kinds of
task transmission which are described at the end of this section. In
addition, the collaborative task is realized by task transmission.
For the process of sending a task, some information is required. This
information is also modelled in the task ontology. This information is still
useful after the process of sending a task was completed. Task Delegation is a process where the sender of the task restricts the
access rights of the receiver. This includes the right to distribute further
this task and additionally the obligation to give feedback to the sender.
The person that receives a task by delegation usually has not the full
control about the task. The attributes described in the following section
have the purpose to enable such "access rights". The receiver will also
probably have obligations regarding what to report to whom at which
time.
In contrast, the simplest case is that all rights are granted to the receiver
and there is no feedback desired by the sender. What to do with the task
may be apparent by the organization context, or it may be left to the
receiver. This is like sending an email, but with the advantage that the
information is transferred in the "task space" of the participating persons. |
TransmissionState
TransmissionType
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:transmissionType |
| Description | By means of the tmo:TransmissionType one can distinguish several different types which might imply different business logic. e.g. delegation can mean that the results of the task fulfilment care to be reported back to the sender of the task. |
| tmo:TMO_Instance_TransmissionType_Delegation, tmo:TMO_Instance_TransmissionType_Join, tmo:TMO_Instance_TransmissionType_Transfer |
UndirectedDependency
Urgency
| rdfs:Resource, tmo:StateTypeRole |
| -- |
| -- |
| tmo:urgency |
| Description | The urgence of a task according to the "ABC analysis" (see also http://en.wikipedia.org/wiki/Time_management for a general description of "ABC" like task ordering). We envision not only two shades but allow for more fine grain nuances. There are a couple if instances realizing named instances of urgence. This property is usually combined with the property/class tmo:Importance. |
| tmo:TMO_Instance_Urgency_01, tmo:TMO_Instance_Urgency_02, tmo:TMO_Instance_Urgency_03, tmo:TMO_Instance_Urgency_04, tmo:TMO_Instance_Urgency_05, tmo:TMO_Instance_Urgency_06, tmo:TMO_Instance_Urgency_07, tmo:TMO_Instance_Urgency_08, tmo:TMO_Instance_Urgency_09, tmo:TMO_Instance_Urgency_10 |
Ontology Properties Description
abilityCarrier
abilityCarrierInvolvement
abilityCarrierRole
abilityCarrierTask
actualCompletion
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:float |
| 1 |
| tmo:progress |
| -- |
| Description | The degree (in percent) to which a task is completed. |
actualEndTime
actualStartTime
actualTime
| rdf:Property, rdfs:Resource |
| -- |
| xsd:dateTime |
| 1 |
| tmo:dateTime |
| tmo:actualEndTime, tmo:actualStartTime |
| Description | It can be important to state when a task should be performed; to set a proper start date (time) and end date (time) for working on a task. First, this is planning information about what the user wants to do (or is supposed to do). We refer to this type of dates as "target". When the time passes and the task is started and finally finished, statements about the "actual" start and end dates can be set.
This super property subsumes points of times, which have values which are realized, in contrast to values which only have been intended (targetTime) |
actualTimeUsage
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:int |
| 1 |
| tmo:timeUsage |
| -- |
| Description | Represents the amount of time actually spend on a task. |
attachment
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:Attachment |
| tmo:attachmentTask |
| -- |
| -- |
| Description | Connects the complex (n-ary, role described) Attachment and the task. See tmo:Attachment and section 3 for details. |
attachmentReference
attachmentRole
attachmentTask
| rdf:Property, rdfs:Resource |
| tmo:Attachment |
| tmo:Task |
| tmo:attachment |
| 1 |
| pimo:associationMember |
| -- |
| Description | Inverse of attachment, connects an Attachment Association to the associated Task. Is required for every instance of Attachment. Used in the role based modeling of tmo:Attachment. See section 3. |
containsTask
contextTask
| rdf:Property, rdfs:Resource |
| -- |
| tmo:Task |
| tmo:contextThread |
| 1 |
| -- |
| -- |
| Description | This property realizes the connection fromo the user work context by an relation to an workcontext:contextThread. |
contextThread
| rdf:Property, rdfs:Resource |
| tmo:Task |
| x:MediumTermContextThread |
| tmo:contextTask |
| 1 |
| -- |
| -- |
| Description | This property realizes the connection to the user work context by an relation to an workcontext:contextThread. |
createdBy
dateTime
| rdf:Property, rdfs:Resource |
| -- |
| xsd:dateTime |
| 1 |
| -- |
| tmo:actualEndTime, tmo:actualStartTime, tmo:actualTime, tmo:dueDate, tmo:endTime, tmo:lastReviewDate, tmo:receiveDateTime, tmo:sendDateTime, tmo:startTime, tmo:targetEndTime, tmo:targetStartTime, tmo:targetTime, tmo:taskEffortEndDate, tmo:taskEffortStartDate |
| Description | tmo:dateTime subsumes various properties with Range XMLSchema:dateTime. If possible the properties are further grouped by "abstract" properties. |
delegability
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:Delegability |
| 1 |
| tmo:timemanagement |
| -- |
| Description | This property determines how appropriate a task is to be delegated to another Person. Some task have to be performed by the owning person and cannot be delegated. |
dependency
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:TaskDependency |
| -- |
| -- |
| Description | Tasks can be associated with each other in various ways. Those associations are realized by instances of tmo:TaskDependency. |
dependencyDescription
| rdf:Property, rdfs:Resource |
| tmo:TaskDependency |
| -- |
| 1 |
| rdfs:Comment, nao:description |
| -- |
| Description | Endusers can clarify why they created a tmo:TaskDependency. |
dependencyMemberA
| rdf:Property, rdfs:Resource |
| tmo:TaskDependency |
| tmo:Task |
| 1 |
| 1 |
| pimo:associationMember, tmo:taskReference |
| -- |
| Description | The semantic of this relation is defined in the subclass of undirected Dependency on which this property is stated. (The subject of the statement where this property is expressed).
Used in the role based modeling of tmo:TaskDependency. See section 3. |
dependencyMemberB
| rdf:Property, rdfs:Resource |
| tmo:TaskDependency |
| tmo:Task |
| 1 |
| 1 |
| pimo:associationMember, tmo:taskReference |
| -- |
| Description | The semantic of this relation is defined in the subclass of undirected Dependency on which this property is stated. (The subject of the statement where this property is expressed). Used in the role based modeling of tmo:TaskDependency. See section 3. |
dependencyOrderNumber
| rdf:Property, rdfs:Resource |
| tmo:TaskDependency |
| xsd:int |
| 1 |
| 1 |
| -- |
| -- |
| Description | Task Dependencies can be ordered. |
dueDate
endTime
| rdf:Property, rdfs:Resource |
| -- |
| xsd:dateTime |
| 1 |
| tmo:dateTime |
| tmo:actualEndTime, tmo:targetEndTime |
| Description | It can be important to state when a task
should be performed; to set a proper start date (time) and end
date (time) for working on a task. First, this is planning
information about what the user wants to do (or is supposed to
do). We refer to this type of dates as "target". When the time
passes and the task is started and finally finished, statements
about the "actual" start and end dates can be set.
This super property subsumes ending points of times. The subproperty tmo:targetEndTime is meant to capture the time when the task should be finished as envisioned in planning, in contrast tmo:actualEndTime is meant to capture the time when the task was actually finished. |
importance
indexPosition
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:int |
| 1 |
| -- |
| -- |
| Description | The position of ordered subtasks regarding their parent task. It is possible to use this property because we allow for only one parent task. More exactly this should be realized by an rdf:List, but those has the disadvantage that no typing is possible. This issue needs to be clarified in future revisions. |
involvedPerson
involvedPersonRole
involvedPersonTask
lastReviewDate
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:dateTime |
| 1 |
| tmo:dateTime |
| -- |
| Description | The last date a task was reviewed. |
logEntry
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdfs:Resource |
| -- |
| -- |
| Description | Tasks are not static entities which are created once and then they remain constant until they are finished. The tasks as we see it should be able to evolve together with the beliefs/ideas/thoughts of the human user. Tasks are not only requirements to be fulfilled but tasks can reflect the usage of task related information, e.g. attachment documents are added during the lifespan of tasks where the exact point of time of the attachment can be important to understand the task proceeding or if due dates might be shifted. This information can be kept. We leave it open how this is done in concrete cases. |
nextReviewIntervall
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:integer |
| 1 |
| -- |
| -- |
| Description | The time when the next review should be performed |
personInvolvement
priority
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:Priority |
| 1 |
| tmo:timemanagement |
| -- |
| Description | The priority of a task. See http://en.wikipedia.org/wiki/Time_management for different approaches on finding priorities. |
progress
receiveDateTime
sendDateTime
startTime
| rdf:Property, rdfs:Resource |
| -- |
| xsd:dateTime |
| 1 |
| tmo:dateTime |
| tmo:actualStartTime, tmo:targetStartTime |
| Description | It can be important to state when a task
should be performed; to set a proper start date (time) and end
date (time) for working on a task. First, this is planning
information about what the user wants to do (or is supposed to
do). We refer to this type of dates as "target". When the time
passes and the task is started and finally finished, statements
about the "actual" start and end dates can be set.
This super property subsumes starting points of times. The subproperty tmo:targetStartTime is meant to capture the time when the task should start as envisioned in planning, in contrast tmo:actualStartTime is meant to capture the time when the task was actually started. |
stateTypeRole
| rdf:Property, rdfs:Resource |
| -- |
| rdfs:Resource |
| 1 |
| -- |
| tmo:abilityCarrierRole, tmo:attachmentRole, tmo:involvedPersonRole, tmo:taskPrivacyState, tmo:taskState, tmo:taskStateChangesFrom, tmo:taskStateChangesTo, tmo:transmissionState, tmo:transmissionStateChangesFrom, tmo:transmissionStateChangesTo, tmo:transmissionType |
| Description | The sub-properties of tmo:stateTypeRole realize role described associations. Some of those instances which are rather generic are stated in the TMO. |
subTask
subTaskOrdering
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdf:List |
| 1 |
| -- |
| -- |
| Description | This property allows to optionally state the ordering of the subtasks listed in the tmo:subTask property a task. This is only for ordering/sorting in GUIs, the semantic relation is defined in tmo:subTask, and if this and tmo:subTask differ, tmo:subTasks is the correct list (while ordering is lost). See also tmo:indexPosition for a property which realizes this by means of an workaround since the support of rdf:List is often limited on tool support. Also there is no support for range restrictions. |
superTask
targetCompletion
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:float |
| 1 |
| tmo:progress |
| -- |
| Description | The degree (in percent) to which a task should be completed. This property has a rather rare usage, but one can imagine situations where one explicitly states that a task has only to be performed to a certain extend. |
targetEndTime
targetStartTime
targetTime
| rdf:Property, rdfs:Resource |
| -- |
| xsd:dateTime |
| 1 |
| tmo:dateTime |
| tmo:targetEndTime, tmo:targetStartTime |
| Description | It can be important to state when a task
should be performed; to set a proper start date (time) and end
date (time) for working on a task. First, this is planning
information about what the user wants to do (or is supposed to
do). We refer to this type of dates as "target". When the time
passes and the task is started and finally finished, statements
about the "actual" start and end dates can be set.
This super property subsumes points of times, which have values which are intended, in contrast to values which only have been actually realized (actualTime) |
targetTimeUsage
| rdf:Property, rdfs:Resource |
| tmo:Task |
| xsd:int |
| 1 |
| tmo:timeUsage |
| -- |
| Description | Represents the amount of time planned to be spend on a task. |
taskDescription
| rdf:Property, rdfs:Resource |
| tmo:Task |
| -- |
| 1 |
| rdfs:Comment, nao:description |
| -- |
| Description | For short identifying descriptions of task one should use the tmo:taskName, more elaborate textual content can be placed in the tmo:taskDescription property. The description is amongst others meant to specify what needs to be done in the task in an informal way. The task description is the right place to state information about what to do with a task. The task description helps users to understand the goal and the proceeding of a task. It can also describe the context of a task. The task description is composed at minimum of a summary of what is done to reach the goal. The task description is the main source for identifying related information, e.g., suitable patterns. |
taskEffort
taskEffortAccuracy
taskEffortDuration
| rdf:Property, rdfs:Resource |
| tmo:TaskEffort |
| xsd:int |
| 1 |
| -- |
| -- |
| Description | The amount of time a tmo:TaskEffort should represent in seconds. This can be eighter calculated from tmo:taskEffortStartDate and tmo:taskEffortEndDate or it can be set explicitly. |
taskEffortEndDate
taskEffortStartDate
taskEffortType
taskGoal
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdfs:Resource |
| -- |
| -- |
| Description | The goal which is to be accomplished by a task. Goal orientation is a primary objective in task management. For goal articulation there are different possibilities on a tmo:Task instance. First there is a set of already articulated goals, which are made available to the user for simple selection. In contrast to Web 2.0 style applications those goals can be conceptualized as instances. The semantic desktop user is free to enhance his present goal repertoire by new instances. In principle the user can also use the tmo:taskName property for short sequences of text or the tmo:taskDescription property with its ability to display longer sequences of text to manifest goals. In the long term this is not desirable. When a phrase is repeatedly used as a goal, it should be uses as a typed "marker" and a instance should be used. The range is kept very flexible as a Thing. |
taskId
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdfs:Literal |
| 1 |
| 1 |
| -- |
| -- |
| Description | The tmo:taskId allows a unique identification of a task object within the range of all Nepomuk objects.
The tmo:taskId is automatically generated during the creation of a task. Using UUID is an valid approach to generate id's. |
taskName
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdfs:Literal |
| 1 |
| rdfs:Label, nao:prefLabel |
| -- |
| Description | The tmo:taskName helps the user to identify a tmo:task in a list. It should be expressive enough to give a meaningful recognition. Details should be written in the tmo:taskDescription attribute instead. A tmo:taskName attribute is not allowed to contain line breaks. The name property is a sub-property of the nao:prefLabel , so this instance can by default be displayed correctly in places which are not specialized towards the TMO alone. |
taskPrivacyState
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:TaskPrivacyState |
| 1 |
| tmo:stateTypeRole |
| -- |
| Description | For the separation between professional and private purpose of a task, this attribute provides with the values "professional/private" a high level separation of privacy in terms of setting distribution rights to other users for the task.
This separation may arise as a general Nepomuk issue and may therefore be handled in conjunction with a privacy preserving SSD architecture. |
taskReference
taskSource
| rdf:Property, rdfs:Resource |
| tmo:Task |
| rdfs:Resource |
| 1 |
| tmo:taskReference |
| -- |
| Description | The taskSopurce property can be used to state from which sources a task was derived, e.g from another task or from an task pattern |
taskState
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:TaskState |
| 1 |
| 1 |
| tmo:stateTypeRole |
| -- |
| Description | The task state property allows tracking a task during its lifecycle. A tmo:taskState is required, initially it can e.g. be set to "new". |
taskStateChangesFrom
taskStateChangesTo
taskTransmission
timeUsage
timemanagement
transmissionFrom
transmissionState
transmissionStateChangesFrom
transmissionStateChangesTo
transmissionTask
transmissionTo
transmissionType
urgency
| rdf:Property, rdfs:Resource |
| tmo:Task |
| tmo:Urgency |
| 1 |
| tmo:timemanagement |
| -- |
| Description | The urgence of a task according to the "ABC analysis" (see http://en.wikipedia.org/wiki/Time_management). |
