| Resource | Count | SKOS mapping |
|---|
| "The semantic of this relation is defined in the sublclass of undirected Dependency on which this property is stated. (The subject of the statment where this property is expressed)" | 2 |
| "A symmetric relations between task." | 1 |
| "AbilityCarrier is an abstract class which circumferences 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 AbilityCarrier because it is not neccessarily "active".
The execution of a task relies on certain abilities. The abstract concept of
Abilitiy_Carriers circumference all those more concrete concepts
of which one can think of while working on tasks. Using this abstract
class enables to substitute such Ability Carrier'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, OrganizationalUnit, InformalDescribedAbility)
and the role of involvement (required, request, used) is enabled. The role
hereby allows specifying how the ability carrying entity is or was
involved." | 1 |
| "AttachmentRoles further specify the type of how an attachment relates to a task. Example instances of AttachmentRoles are e.g. "desired_request", "required" and "used"." | 1 |
| "Between the tasks, further dependencies 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 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." | 1 |
| "By means of attachments, references to other resources can be established. Resources are information objects. Every Thing, which can be referenced, on the SSD is an information object. In contrast to the usual SSD references/associations, here additionally information can be specified. Further metadata about the role an attachment plays can be stated by means of instances of 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." | 1 |
| "By means of the SuperSubTaskDependency one can further describe the subtask-supertask relation .e.g by an descriptin. This enables an n-ary relation between subtask and supertask." | 1 |
| "By means of the TransmissionType one can distinguish several different types which might imply a different business logic. e.g. delegation can mean that the results of the task fulfillment care to be reported back to the sender of the task." | 1 |
| "Endusers can clarify why they created a depedency." | 1 |
| "Examples instances of AbilityCarrirRoles are e.g. "requested", "required" and "used" which further specify the type a person was involved in." | 1 |
| "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." | 1 |
| "In a PredecessorDependency the dependencyMemberA is the task which is to be executed before dependencyMemberB." | 1 |
| "In a SuccessorrDependency the dependencyMemberA is the task which is to be executed after dependencyMemberB." | 1 |
| "Inverse of attachment, connects an Attachment Association to the associated Task. Is required for every instance of Attachment." | 1 |
| "On the SSD, 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." | 1 |
| "Ordering of the subtasks listed in the tmo:subTasks property of this Task. This is only for ordering/sorting in GUIs, the semantic relation is defined in subTasks, and if this and subTasks differ, subTasks is the correct list." | 1 |
| "PersonInvolvement realizes n-ary associations to Persons which are realtedd to an task. The involvement is further characterized by an PersonTaskRole." | 1 |
| "Privacy Status 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.
This separation may arise as a general Nepomuk issue and may therefore be handled in conjunction with a privacy preserving SSD architecture." | 1 |
| "StateTypeRole is an abstract class which subsumes various other classes which represent "states" or roles e.g. in role based modelling conpetualisations." | 1 |
| "States a task can go through during transmission of an task." | 1 |
| "The PredecessorSuccessorDependency enables a directed relation between task. By means of the concrete sublcasses one can further distinguish from which point of view this relation is created." | 1 |
| "The Task Identifier allows a unique identification of a task object within the range of all Nepomuk objects.
The Task Identifier is automatically generated during the creation of a task. The generation of identifiers (IDs) is a Nepomuk architecture issue (Wp2000/WP6000)." | 1 |
| "The Task Name helps the user to identify a task in a list. It should be expressive enough to give a meaningful recognition. Details should be written in the description attribute instead. A name attribute is not allowed to contain line breaks." | 1 |
| "The class AbilityCarrier_Involvement ties together an AbilityCarrier with an AbilityCarrier_Role. This is a role based modelling approach. An n-ary relation is realized." | 1 |
| "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.
A Task Description can be either an informal, described textual content (TextualDescription) or it can be a more formally structured representation (FormalDescription).
Technology considerations: Informal descriptions allow for text similarity processing, a formal description allows for applying case based similarity measures." | 1 |
| "The task state describes the current state of the task as described in Section 5.2.7." | 1 |
| "The task state property allows tracking a task during its lifecycle. Initially the state is just "created".
The TaskState class was modeled 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." | 1 |
| "The tmo:task is the central entitiey 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 forseeable manner. It is not unrealisitc to assume that knowledge worker have hundred or more tasks a day." | 1 |
| "They further specify the type a person was related to an task.
Examples instances of AttachmentRoles are e.g." | 1 |
| "connects a Task with an Attachment object. Attachments are associations of Things." | 1 |
| "dateTime subsumes various properties with Range XMLSchema:dateTime. If possible they are further grouped by "abstract" properties." | 1 |
| "examples are e.g. technologies like Java, XML, ..." | 1 |
| "examples: Architect, Developer, ..." | 1 |
| "here can be stated from which sources a task was derived. e.g from another task or from an task pattern" | 1 |
