summaryrefslogtreecommitdiff
path: root/tmo
diff options
context:
space:
mode:
authorSebastian Trueg <trueg@kde.org>2009-07-10 18:54:09 +0000
committerSebastian Trueg <trueg@kde.org>2009-07-10 18:54:09 +0000
commit2c3c3fb9b1cb5bd0df53f467269488b8204ce015 (patch)
tree0a0350a02d48fcc3be1e44a5f793a78b2c67804c /tmo
Created dir structure as agreed upon at the Gran Canaria Desktop Summit 2009:
* One dir for each ontology. * All ontologies serialized as trig (ontology + metadata graph) * Each onto dir has a subdir "doc" which contains the template for documentation generation * The tools folder will contain the scripts used to generate the docs * The tools/files folder contains pics and stylesheet used for all onto docs (simply need to be copied to the destination dir) Also: * Moving old stuff into branches/legacy * One special ontology dir "base" which contains RDF, RDFS, and the Dublin Core ontologies. Here one thing still needs to be discussed: these ontos only exist as rdf+xml. Should we convert them for us and add metadata or should we handle them differently?
Diffstat (limited to 'tmo')
-rw-r--r--tmo/doc/tmo-header.html225
-rw-r--r--tmo/tmo.trig1122
2 files changed, 1347 insertions, 0 deletions
diff --git a/tmo/doc/tmo-header.html b/tmo/doc/tmo-header.html
new file mode 100644
index 0000000..8db62de
--- /dev/null
+++ b/tmo/doc/tmo-header.html
@@ -0,0 +1,225 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
+ <title>Task Model Ontology (TMO)</title>
+
+</head>
+<body>
+
+<div class="head">
+<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
+
+<h1>Task Model Ontology (TMO)</h1>
+
+<big style="color: rgb(0, 90, 156);">Task-Force Ontologies<br />
+
+</big>
+<dl>
+
+ <dt>Latest Version:</dt>
+
+ <dd><a href="http://www.semanticdesktop.org/ontologies/tmo">http://www.semanticdesktop.org/ontologies/tmo</a>
+ </dd>
+
+ <dt></dt>
+
+ <dt>This Version:</dt>
+
+ <dd><a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo">http://www.semanticdesktop.org/ontologies/2008/05/20/tmo</a>
+ <br/>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.</dd>
+
+ <dt></dt>
+
+ <dt>Authors:</dt>
+
+ <dd>Marko Brunzel, DFKI, <a href="mailto:marko.brunzel@dfki.de">marko.brunzel@dfki.de</a></dd>
+
+ <dd>Olaf Grebner, SAP, <a href="mailto:olaf.grebner@sap.com">olaf.grebner@sap.com</a></dd>
+
+ <dt></dt>
+
+ <dt>Editors:</dt>
+
+ <dd>Marko Brunzel, DFKI, <a href="mailto:marko.brunzel@dfki.de">marko.brunzel@dfki.de</a></dd>
+
+ <dd>Olaf Grebner, SAP, <a href="mailto:olaf.grebner@sap.com">olaf.grebner@sap.com</a></dd>
+
+ <dt></dt>
+
+ <dt>Contributors:</dt>
+
+ <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
+ <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
+ <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.de">elst@dfki.de</a></dd>
+ <dd>Ansgar Bernardi, DFKI, <a href="mailto:ansgar.bernardi@dfki.de">ansgar.bernardi@dfki.de </a></dd>
+ <dd>Uwe Riss, SAP, <a href="mailto:uwe.riss@sap.com">uwe.riss@sap.com</a></dd>
+
+ <dt><span style="font-weight: bold;">Ontology:</span></dt>
+
+ <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo/tmo_data.rdfs">TMO (Data Graph Only)</a></dd>
+ <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo/tmo_metadata.rdfs">TMO (Metadata Graph Only)</a></dd>
+ <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo#/tmo.trig">TMO (Graph Set)</a></dd>
+
+</dl>
+
+</div>
+
+<p class="copyright"> Copyright &copy; 2007-2008 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>&reg;</sup>
+The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
+</p>
+
+<hr />
+<h2 id="sec:abstract">Abstract</h2>
+<p>
+ The TMO Ontology can be used to describe personal tasks of individuals, also known as to-do lists. It is based on RDF and <a href="http://www.semanticdesktop.org/ontologies/nrl/"> NRL</a>, the NEPOMUK Representational Language and other Semantic Web ontologies. This document describes the fundamental elements of the language and how to use them.
+ </p>
+
+<h2 id="sec:status">Status of this document</h2>
+
+<p>
+ 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.
+</p>
+<p>
+ This document is an Editors Draft produced by Olaf Grebner and Marko Brunzel as part of the work package task management in the <a href="http://nepomuk.semanticdesktop.org/">NEPOMUK</a> 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.
+</p>
+<p>
+ 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.<br/>
+</p>
+
+<h2 id="sec:introduction">1. Introduction</h2>
+
+<p>
+The Task Management Model Ontology (TMO) is a conceptual representation of tasks for use in personal task management applications for knowledge workers.<br/>
+</p>
+<p>
+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.
+</p>
+<p>
+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.
+</p>
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+<p>
+Further information on the TMO going beyond this document can be found at <a href="#ref:taskmodel">[TASKMODEL]</a>. 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.
+</p>
+
+
+<h2 id="sec:scope_and_usecases">2. Scope and Covered Use Cases</h2>
+
+<p>
+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 <a href="#ref:pimo">[PIMO]</a>, <a href="#ref:nie">[NIE]</a>. 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.
+</p>
+
+
+<p>
+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:
+<ul>
+<li>Personal Task Management - Personal Task Management consists of several parts.</li>
+ <ul>
+ <li>Basic task handling - Basic task handling deals with organizing a knowledge workers task, e.g., creating and populating a task.</li>
+ <li>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.</li>
+ <li>Task priority management - Task priority management helps the knowledge worker to maintain the priorities coming with a task.</li>
+ <li>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.</li>
+ <li>Task planning - Task planning helps the knowledge worker to structure the workload and perform work decomposition, i.e., breaking down and categorizing tasks.</li>
+ </ul>
+<li>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.</li>
+<li>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.</li>
+</ul>
+
+
+
+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 <a href="#ref:taskmodel">[TASKMODEL]</a>.
+</p>
+
+<h2 id="sec:modelling">3. TMO Modelling</h2>
+
+<p>
+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.
+<br/>
+<img alt="tmo class and ist super-classes" src="img/tmo_task_pimo_subclass_part1.gif" />
+<img alt="tmo class and ist super-classes" src="img/tmo_task_pimo_subclass_part2.gif" />
+</p>
+
+<p>
+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.<br/>
+<img alt="overview on tmo" src="img/tmo_overview_part1.gif" /><br/>
+<img alt="overview on tmo" src="img/tmo_overview_part2.gif" /><br/>
+<img alt="overview on tmo" src="img/tmo_overview_part3.gif" /><br/>
+</p>
+
+
+
+
+
+
+<p>
+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:
+
+<h3>tmo:PersonInvolvement</h3>
+<p>
+<img alt="Role based modelling of tmo:PersonInvolvement" src="img/tmo_personinvolvement.gif" /><br/>
+<img alt=" Role based modelling of tmo:Attachment " src="img/tmo_attachment.gif" />
+<br/>
+</p>
+
+<h3>tmo:AbilityCarrierInvolvement</h3>
+<p>
+<img alt="Role based modelling of tmo:AbilityCarrierInvolvement" src="img/tmo_abilitycarrierinvolvement.gif" />
+<br/>
+</p>
+
+<h3>tmo:Attachment</h3>
+<p>
+<img alt="Role based modelling of tmo:Attachment" src="img/tmo_attachment.gif" />
+<br/>
+</p>
+
+<h3>tmo: TaskDependency</h3>
+<p>
+<img alt="Role based modelling of tmo:TaskDependency" src="img/tmo_dependencies.gif" />
+<br/>
+
+</p>
+
+
+<p> The transmission of tasks is represented by the tmo:TaskTransmission class.
+<br/>
+<img alt="tmo:TaskTransmission" src="img\tmo_transmission.gif" />
+<br/>
+</p>
+
+
+
+
+<h2 id="sec:references">References</h2>
+
+<dl>
+ <dt><a name="ref:pimo"></a>[PIMO]</dt>
+ <dd><cite><a href="http://www.semanticdesktop.org/ontologies/pimo">Personal Information Model ontology (PIMO)</a> </cite>, Leo Sauermann, Ludger van Elst, Knud M&ouml;ller, http://www.semanticdesktop.org/ontologies/pimo</dd>
+
+ <dt><a name="ref:nie"></a>[NIE]</dt>
+ <dd><cite><a href="http://www.semanticdesktop.org/ontologies/nie">NEPOMUK Information Element Ontology (NIE)</a> </cite>, Antoni Mylka, Leo Sauermann, Michael Sintek, Ludger van Elst, http://www.semanticdesktop.org/ontologies/nie</dd>
+
+ <dt><a name="ref:taskmodel"></a>[TASKMODEL]</dt>
+ <dd><cite><a href="http://nepomuk.semanticdesktop.org/xwiki/bin/download/Main1/D3-1/D3.1_v10_NEPOMUK_Task_Management_Model.pdf">Task Management Model (TMO)</a> </cite>, 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</dd>
+
+</dl>
+
+
+
diff --git a/tmo/tmo.trig b/tmo/tmo.trig
new file mode 100644
index 0000000..ff649f8
--- /dev/null
+++ b/tmo/tmo.trig
@@ -0,0 +1,1122 @@
+@prefix dc: <http://purl.org/dc/elements/1.1/> .
+@prefix exif: <http://www.kanzaki.com/ns/exif#> .
+@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
+@prefix protege: <http://protege.stanford.edu/system#> .
+@prefix nao: <http://www.semanticdesktop.org/ontologies/2007/08/15/nao#> .
+@prefix nfo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#> .
+@prefix nie: <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#> .
+@prefix ncal: <http://www.semanticdesktop.org/ontologies/2007/04/02/ncal#> .
+@prefix nco: <http://www.semanticdesktop.org/ontologies/2007/03/22/nco#> .
+@prefix dcterms: <http://purl.org/dc/terms/> .
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix pimo: <http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#> .
+@prefix nmo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#> .
+@prefix nrl: <http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#> .
+@prefix tmo: <http://www.semanticdesktop.org/ontologies/2008/05/20/tmo#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
+@prefix nid3: <http://www.semanticdesktop.org/ontologies/2007/05/10/nid3#> .
+@prefix nexif: <http://www.semanticdesktop.org/ontologies/2007/05/10/nexif#> .
+
+tmo: {tmo:TMO_Instance_PersonInvolvementRole_Creator
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Creator" .
+
+ tmo:abilityCarrierRole
+ a rdf:Property ;
+ rdfs:domain tmo:AbilityCarrierInvolvement ;
+ rdfs:label "abilityCarrierRole" ;
+ rdfs:range tmo:AbilityCarrierRole ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:PersonInvolvement
+ a rdfs:Class ;
+ rdfs:comment "PersonInvolvement realizes n-ary associations to Persons which are realtedd to an task. The involvement is further characterized by an PersonTaskRole." ;
+ rdfs:label "PersonInvolvement" ;
+ rdfs:subClassOf rdfs:Resource , pimo:Association .
+
+ tmo:TMO_Instance_TaskState_Running
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Running" .
+
+ tmo:SimilarityDependence
+ a rdfs:Class ;
+ rdfs:label "SimilarityDependence" ;
+ rdfs:subClassOf tmo:UndirectedDependency .
+
+ tmo:PredecessorDependency
+ a rdfs:Class ;
+ rdfs:comment "In a PredecessorDependency the dependencyMemberA is the task which is to be executed before dependencyMemberB." ;
+ rdfs:label "PredecessorDependency" ;
+ rdfs:subClassOf tmo:PredecessorSuccessorDependency .
+
+ tmo:TMO_Instance_TaskContainer_outbox
+ a tmo:TaskContainer ;
+ rdfs:label "TMO_Instance_TaskContainer_outbox" .
+
+ tmo:dueDate
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "dueDate" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf pimo:taskDueTime , tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Urgency_04
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_04" .
+
+ tmo:Priority
+ a rdfs:Class ;
+ rdfs:label "Priority" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:TaskContainer
+ a rdfs:Class ;
+ rdfs:label "TaskContainer" ;
+ rdfs:subClassOf pimo:Collection .
+
+ tmo:Task
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "Task" ;
+ rdfs:subClassOf pimo:Task .
+
+ tmo:PersonInvolvementRole
+ a rdfs:Class ;
+ rdfs:comment """They further specify the type a person was related to an task.
+Examples instances of AttachmentRoles are e.g.""" ;
+ rdfs:label "PersonInvolvementRole" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:actualCompletion
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "actualCompletion" ;
+ rdfs:range rdfs:Literal ;
+ rdfs:subPropertyOf tmo:progress ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Co-worker
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Co-worker" .
+
+ tmo:urgency
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "urgency" ;
+ rdfs:range tmo:Urgency ;
+ rdfs:subPropertyOf tmo:timemanagement ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_TaskContainer_archive
+ a tmo:TaskContainer ;
+ rdfs:label "TMO_Instance_TaskContainer_archive" .
+
+ tmo:dependency
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "dependency" ;
+ rdfs:range tmo:TaskDependency .
+
+ tmo:TMO_Instance_Importance_10
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_10" .
+
+ tmo:targetStartTime
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "targetStartTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:targetTime , tmo:startTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:dependencyDescription
+ a rdf:Property ;
+ rdfs:comment "Endusers can clarify why they created a depedency." ;
+ rdfs:domain tmo:TaskDependency ;
+ rdfs:label "dependencyDescription" ;
+ rdfs:subPropertyOf nao:description ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Importance_09
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_09" .
+
+ tmo:transmissionState
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "transmissionState" ;
+ rdfs:range tmo:TransmissionState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:AbilityCarrierRole
+ a rdfs:Class ;
+ rdfs:comment "Examples instances of AbilityCarrirRoles are e.g. \"requested\", \"required\" and \"used\" which further specify the type a person was involved in." ;
+ rdfs:label "AbilityCarrierRole" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:TMO_Instance_TaskState_Finalized
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Finalized" .
+
+ tmo:abilityCarrier
+ a rdf:Property ;
+ rdfs:domain tmo:AbilityCarrierInvolvement ;
+ rdfs:label "abilityCarrier" ;
+ rdfs:range tmo:AbilityCarrier ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:TMO_Instance_TransmissionState_Rejected_Transmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_Rejected_Transmitted" .
+
+ tmo:TMO_Instance_Delegability_High
+ a tmo:Delegability ;
+ rdfs:label "TMO_Instance_Delegability_High" .
+
+ tmo:TMO_Instance_Urgency_10
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_10" .
+
+ tmo:taskId
+ a rdf:Property ;
+ rdfs:comment """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).""" ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskId" ;
+ rdfs:range rdfs:Literal ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:TMO_Instance_Importance_01
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_01" .
+
+ tmo:TMO_Instance_TransmissionType_Transfer
+ a tmo:TransmissionType ;
+ rdfs:label "TMO_Instance_TransmissionType_Transfer" .
+
+ tmo:priority
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "priority" ;
+ rdfs:range tmo:Priority ;
+ rdfs:subPropertyOf tmo:timemanagement ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Urgency_03
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_03" .
+
+ tmo:involvedPersons
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "involvedPersons" ;
+ rdfs:range tmo:PersonInvolvement ;
+ nrl:inverseProperty tmo:involvedPersonTask .
+
+ tmo:involvedPerson
+ a rdf:Property ;
+ rdfs:domain tmo:PersonInvolvement ;
+ rdfs:label "involvedPerson" ;
+ rdfs:range pimo:Person ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:TaskTransmission
+ a rdfs:Class ;
+ rdfs:comment """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.""" ;
+ rdfs:label "TaskTransmission" ;
+ rdfs:subClassOf rdfs:Resource .
+
+ tmo:containsTask
+ a rdf:Property ;
+ rdfs:domain tmo:TaskContainer ;
+ rdfs:label "containsTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:hasPart .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Suggested
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Suggested" .
+
+ tmo:TMO_Instance_TaskState_Archived
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Archived" .
+
+ nao:description
+ a rdf:Property ;
+ rdfs:label "nao:description" .
+
+ tmo:targetTime
+ a rdf:Property ;
+ rdfs:label "targetTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:indexPosition
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "indexPosition" ;
+ rdfs:range rdfs:Literal ;
+ nrl:maxCardinality "1" .
+
+ tmo:dependencyType
+ a rdf:Property ;
+ rdfs:label "dependencyType" ;
+ rdfs:range rdfs:Resource ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:targetEndTime
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "targetEndTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:targetTime , tmo:endTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:PredecessorSuccessorDependency
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "PredecessorSuccessorDependency" ;
+ rdfs:subClassOf tmo:TaskDependency ;
+ protege:role "abstract" .
+
+ tmo:TMO_Instance_Importance_08
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_08" .
+
+ tmo:attachmentReference
+ a rdf:Property ;
+ rdfs:domain tmo:Attachment ;
+ rdfs:label "attachmentReference" ;
+ rdfs:range rdfs:Resource ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:TMO_Instance_Delegability_Never
+ a tmo:Delegability ;
+ rdfs:label "TMO_Instance_Delegability_Never" .
+
+ tmo:superTask
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "superTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:partOf , tmo:taskReference ;
+ nrl:inverseProperty tmo:subTask ;
+ nrl:maxCardinality "1" .
+
+ tmo:taskDescription
+ a rdf:Property ;
+ rdfs:comment """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.""" ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskDescription" ;
+ rdfs:subPropertyOf nao:description ;
+ nrl:maxCardinality "1" .
+
+ tmo:SuperSubTaskDependency
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "SuperSubTaskDependency" ;
+ rdfs:subClassOf tmo:TaskDependency .
+
+ tmo:contextTask
+ a rdf:Property ;
+ rdfs:label "contextTask" ;
+ rdfs:range tmo:Task ;
+ nrl:inverseProperty tmo:contextThread ;
+ nrl:maxCardinality "1" .
+
+ tmo:SuccessorDependency
+ a rdfs:Class ;
+ rdfs:comment "In a SuccessorrDependency the dependencyMemberA is the task which is to be executed after dependencyMemberB." ;
+ rdfs:label "SuccessorDependency" ;
+ rdfs:subClassOf tmo:PredecessorSuccessorDependency .
+
+ tmo:stateTypeRole
+ a rdf:Property ;
+ rdfs:label "stateTypeRole" ;
+ rdfs:range rdfs:Resource ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_TransmissionState_NotTransmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_NotTransmitted" .
+
+ tmo:TMO_Instance_Urgency_06
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_06" .
+
+ tmo:abilityCarrierInvolvement
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "abilityCarrierInvolvement" ;
+ rdfs:range tmo:AbilityCarrierInvolvement ;
+ nrl:inverseProperty tmo:abilityCarrierTask .
+
+ tmo:TMO_Instance_AbilityCarrierRole_Required
+ a tmo:AbilityCarrierRole ;
+ rdfs:label "TMO_Instance_AbilityCarrierRole_Required" .
+
+ tmo:actualStartTime
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "actualStartTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:actualTime , tmo:startTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:transmissionType
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "transmissionType" ;
+ rdfs:range tmo:TransmissionType ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:taskTransmission
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskTransmission" ;
+ rdfs:range tmo:TaskTransmission ;
+ nrl:inverseProperty tmo:transmissionTask .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Executor
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Executor" .
+
+ tmo:targetCompletion
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "targetCompletion" ;
+ rdfs:range rdfs:Literal ;
+ rdfs:subPropertyOf tmo:progress ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Delegability_Medium
+ a tmo:Delegability ;
+ rdfs:label "TMO_Instance_Delegability_Medium" .
+
+ tmo:AgentAbilityCarrier
+ a rdfs:Class ;
+ rdfs:label "AgentAbilityCarrier" ;
+ rdfs:subClassOf tmo:AbilityCarrier ;
+ protege:role "abstract" .
+
+ tmo:transmissionTask
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "transmissionTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf tmo:taskReference ;
+ nrl:inverseProperty tmo:taskTransmission ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:Attachment
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "Attachment" ;
+ rdfs:subClassOf rdfs:Resource , pimo:Association .
+
+ tmo:TMO_Instance_TaskPrivacy_Private
+ a tmo:TaskPrivacyState ;
+ rdfs:label "TMO_Instance_TaskPrivacy_Private" .
+
+ tmo:TMO_Instance_Importance_07
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_07" .
+
+ tmo:AssociationDependency
+ a rdfs:Class ;
+ rdfs:label "AssociationDependency" ;
+ rdfs:subClassOf tmo:UndirectedDependency .
+
+ tmo:nextReviewIntervall
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "nextReviewIntervall" ;
+ rdfs:range xsd:integer ;
+ nrl:maxCardinality "1" .
+
+ tmo:transmissionFrom
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "transmissionFrom" ;
+ rdfs:range pimo:Person ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:taskState
+ a rdf:Property ;
+ rdfs:comment "The task state describes the current state of the task as described in Section 5.2.7." ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskState" ;
+ rdfs:range tmo:TaskState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:delegability
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "delegability" ;
+ rdfs:range tmo:Delegability ;
+ rdfs:subPropertyOf tmo:timemanagement ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Related
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Related" .
+
+ tmo:TMO_Instance_TaskContainer_inbox
+ a tmo:TaskContainer ;
+ rdfs:label "TMO_Instance_TaskContainer_inbox" .
+
+ tmo:TMO_Instance_AttachmentRole_Required
+ a tmo:AttachmentRole ;
+ rdfs:label "TMO_Instance_AttachmentRole_Required" .
+
+ tmo:taskPrivacyState
+ a rdf:Property ;
+ rdfs:comment """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.""" ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskPrivacyState" ;
+ rdfs:range tmo:TaskPrivacyState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ nao:Tag
+ a rdfs:Class ;
+ rdfs:comment "Represents a generic tag" ;
+ rdfs:label "nao:Tag" ;
+ rdfs:subClassOf rdfs:Resource .
+
+ tmo:taskName
+ a rdf:Property ;
+ rdfs:comment "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." ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskName" ;
+ rdfs:range rdfs:Literal ;
+ rdfs:subPropertyOf nao:prefLabel ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_AbilityCarrierRole_Requested
+ a tmo:AbilityCarrierRole ;
+ rdfs:label "TMO_Instance_AbilityCarrierRole_Requested" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Controller
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Controller" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Delegate
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Delegate" .
+
+ tmo:transmissionStateChangesFrom
+ a rdf:Property ;
+ rdfs:domain tmo:TransmissionState ;
+ rdfs:label "transmissionStateChangesFrom" ;
+ rdfs:range tmo:TransmissionState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ tmo:TransmissionState
+ a rdfs:Class ;
+ rdfs:comment "States a task can go through during transmission of an task." ;
+ rdfs:label "TransmissionState" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:transmissionStateChangesTo
+ a rdf:Property ;
+ rdfs:domain tmo:TransmissionState ;
+ rdfs:label "transmissionStateChangesTo" ;
+ rdfs:range tmo:TransmissionState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_ExternalObserver
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_ExternalObserver" .
+
+ tmo:TMO_Instance_Urgency_05
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_05" .
+
+ tmo:TaskDependency
+ a rdfs:Class ;
+ rdfs:comment """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.""" ;
+ rdfs:label "TaskDependency" ;
+ rdfs:subClassOf rdfs:Resource , pimo:Association ;
+ protege:role "abstract" .
+
+ tmo:TMO_Instance_TaskState_Completed
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Completed" .
+
+ tmo:TMO_Instance_Importance_06
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_06" .
+
+ tmo:attachmentRole
+ a rdf:Property ;
+ rdfs:domain tmo:Attachment ;
+ rdfs:label "attachmentRole" ;
+ rdfs:range tmo:AttachmentRole ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ nao:prefLabel
+ a rdf:Property ;
+ rdfs:label "nao:prefLabel" .
+
+ tmo:TMO_Instance_TaskPrivacy_Professional
+ a tmo:TaskPrivacyState ;
+ rdfs:label "TMO_Instance_TaskPrivacy_Professional" .
+
+ tmo:TMO_Instance_TaskState_Terminated
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Terminated" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Owner
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Owner" .
+
+ tmo:TMO_Instance_AttachmentRole_Desired_Requested
+ a tmo:AttachmentRole ;
+ rdfs:label "TMO_Instance_AttachmentRole_Desired_Requested" .
+
+ tmo:involvedPersonTask
+ a rdf:Property ;
+ rdfs:domain tmo:PersonInvolvement ;
+ rdfs:label "involvedPersonTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:inverseProperty tmo:involvedPersons ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_TransmissionState_Accepted_NotTransmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_Accepted_NotTransmitted" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Analyst
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Analyst" .
+
+ tmo:logEntry
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "logEntry" ;
+ rdfs:range rdfs:Resource .
+
+ tmo:transmissionTo
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "transmissionTo" ;
+ rdfs:range pimo:Person ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:Importance
+ a rdfs:Class ;
+ rdfs:label "Importance" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:TMO_Instance_TransmissionType_Join
+ a tmo:TransmissionType ;
+ rdfs:label "TMO_Instance_TransmissionType_Join" .
+
+ tmo:Delegability
+ a rdfs:Class ;
+ rdfs:label "Delegability" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:lastReviewDate
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "lastReviewDate" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:Role
+ a rdfs:Class ;
+ rdfs:comment "examples: Architect, Developer, ..." ;
+ rdfs:label "Role" ;
+ rdfs:subClassOf tmo:AbilityCarrier .
+
+ tmo:timemanagement
+ a rdf:Property ;
+ rdfs:label "timemanagement" ;
+ rdfs:range rdfs:Literal ;
+ nrl:maxCardinality "1" .
+
+ tmo:taskGoal
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskGoal" ;
+ rdfs:range rdfs:Resource .
+
+ tmo:dependencyMemberA
+ a rdf:Property ;
+ rdfs:comment "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)" ;
+ rdfs:domain tmo:TaskDependency ;
+ rdfs:label "dependencyMemberA" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf tmo:taskReference , pimo:associationMember ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:startTime
+ a rdf:Property ;
+ rdfs:label "startTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Urgency_08
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_08" .
+
+ tmo:taskStateChangesFrom
+ a rdf:Property ;
+ rdfs:domain tmo:TaskState ;
+ rdfs:label "taskStateChangesFrom" ;
+ rdfs:range tmo:TaskState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ tmo:receiveDateTime
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "receiveDateTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:createdBy
+ a rdf:Property ;
+ rdfs:domain tmo:Attachment ;
+ rdfs:label "createdBy" ;
+ rdfs:range pimo:Person ;
+ nrl:maxCardinality "1" .
+
+ tmo:progress
+ a rdf:Property ;
+ rdfs:label "progress" ;
+ rdfs:range rdfs:Literal ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_AbilityCarrierRole_Used
+ a tmo:AbilityCarrierRole ;
+ rdfs:label "TMO_Instance_AbilityCarrierRole_Used" .
+
+ tmo:TMO_Instance_Importance_05
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_05" .
+
+ tmo:TMO_Instance_TaskContainer_activetasks
+ a tmo:TaskContainer ;
+ rdfs:label "TMO_Instance_TaskContainer_activetasks" .
+
+ tmo:sendDateTime
+ a rdf:Property ;
+ rdfs:domain tmo:TaskTransmission ;
+ rdfs:label "sendDateTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Collaborator
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Collaborator" .
+
+ tmo:TMO_Instance_TaskState_Suspended
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Suspended" .
+
+ tmo:AbilityCarrierInvolvement
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "AbilityCarrierInvolvement" ;
+ rdfs:subClassOf rdfs:Resource , pimo:Association .
+
+ tmo:endTime
+ a rdf:Property ;
+ rdfs:label "endTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:dependencyMemberB
+ a rdf:Property ;
+ rdfs:comment "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)" ;
+ rdfs:domain tmo:TaskDependency ;
+ rdfs:label "dependencyMemberB" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf tmo:taskReference , pimo:associationMember ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:TMO_Instance_Priority_High
+ a tmo:Priority ;
+ rdfs:label "TMO_Instance_Priority_High" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Observer
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Observer" .
+
+ tmo:TMO_Instance_Delegability_Unrestricted
+ a tmo:Delegability ;
+ rdfs:label "TMO_Instance_Delegability_Unrestricted" .
+
+ tmo:TMO_Instance_Priority_Medium
+ a tmo:Priority ;
+ rdfs:label "TMO_Instance_Priority_Medium" .
+
+ tmo:TMO_Instance_Delegability_Low
+ a tmo:Delegability ;
+ rdfs:label "TMO_Instance_Delegability_Low" .
+
+ tmo:Interdependence
+ a rdfs:Class ;
+ rdfs:label "Interdependence" ;
+ rdfs:subClassOf tmo:UndirectedDependency .
+
+ tmo:involvedPersonRole
+ a rdf:Property ;
+ rdfs:domain tmo:PersonInvolvement ;
+ rdfs:label "involvedPersonRole" ;
+ rdfs:range tmo:PersonInvolvementRole ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:AttachmentRole
+ a rdfs:Class ;
+ rdfs:comment "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\"." ;
+ rdfs:label "AttachmentRole" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:TMO_Instance_Urgency_07
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_07" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Reviewer
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Reviewer" .
+
+ tmo:TransmissionType
+ a rdfs:Class ;
+ rdfs:comment "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." ;
+ rdfs:label "TransmissionType" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:actualEndTime
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "actualEndTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:endTime , tmo:actualTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:subTask
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "subTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:hasPart ;
+ nrl:inverseProperty tmo:superTask .
+
+ tmo:TMO_Instance_TransmissionType_Delegation
+ a tmo:TransmissionType ;
+ rdfs:label "TMO_Instance_TransmissionType_Delegation" .
+
+ tmo:TMO_Instance_Importance_04
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_04" .
+
+ tmo:TaskState
+ a rdfs:Class ;
+ rdfs:comment """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.""" ;
+ rdfs:label "TaskState" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:taskSource
+ a rdf:Property ;
+ rdfs:comment "here can be stated from which sources a task was derived. e.g from another task or from an task pattern" ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskSource" ;
+ rdfs:range rdfs:Resource ;
+ rdfs:subPropertyOf tmo:taskReference ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Urgency_02
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_02" .
+
+ tmo:TMO_Instance_TransmissionState_Accepted_Transmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_Accepted_Transmitted" .
+
+ tmo:TMO_Instance_TaskState_New
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_New" .
+
+ tmo:Urgency
+ a rdfs:Class ;
+ rdfs:label "Urgency" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:StateTypeRole
+ a rdfs:Class ;
+ rdfs:comment "StateTypeRole is an abstract class which subsumes various other classes which represent \"states\" or roles e.g. in role based modelling conpetualisations." ;
+ rdfs:label "StateTypeRole" ;
+ rdfs:subClassOf rdfs:Resource .
+
+ tmo:TMO_Instance_TaskContainer_trashtasks
+ a tmo:TaskContainer ;
+ rdfs:label "TMO_Instance_TaskContainer_trashtasks" .
+
+ tmo:contextThread
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "contextThread" ;
+ rdfs:range <http://ontologies.opendfki.de/repos/ontologies/wcon/workcontext#MediumTermContextThread> ;
+ nrl:inverseProperty tmo:contextTask ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_AttachmentRole_Used
+ a tmo:AttachmentRole ;
+ rdfs:label "TMO_Instance_AttachmentRole_Used" .
+
+ tmo:abilityCarrierTask
+ a rdf:Property ;
+ rdfs:domain tmo:AbilityCarrierInvolvement ;
+ rdfs:label "abilityCarrierTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:inverseProperty tmo:abilityCarrierInvolvement ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_TransmissionState_Rejected_NotTransmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_Rejected_NotTransmitted" .
+
+ tmo:TMO_Instance_Priority_Low
+ a tmo:Priority ;
+ rdfs:label "TMO_Instance_Priority_Low" .
+
+ tmo:TMO_Instance_TransmissionState_Transmitted
+ a tmo:TransmissionState ;
+ rdfs:label "TMO_Instance_TransmissionState_Transmitted" .
+
+ tmo:TMO_Instance_Importance_03
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_03" .
+
+ tmo:TMO_Instance_AttachmentRole_Related
+ a tmo:AttachmentRole ;
+ rdfs:label "TMO_Instance_AttachmentRole_Related" .
+
+ tmo:taskReference
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "taskReference" ;
+ rdfs:range tmo:Task ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Involved
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Involved" .
+
+ tmo:AbilityCarrier
+ a rdfs:Class ;
+ rdfs:comment """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.""" ;
+ rdfs:label "AbilityCarrier" ;
+ rdfs:subClassOf rdfs:Resource ;
+ protege:role "abstract" .
+
+ tmo:importance
+ a rdf:Property ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "importance" ;
+ rdfs:range tmo:Importance ;
+ rdfs:subPropertyOf tmo:timemanagement ;
+ nrl:maxCardinality "1" .
+
+ tmo:subTaskOrdering
+ a rdf:Property ;
+ rdfs:comment "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." ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "subTaskOrdering" ;
+ rdfs:range rdf:List ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_Urgency_01
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_01" .
+
+ tmo:dependencyOrderNumber
+ a rdf:Property ;
+ rdfs:domain tmo:TaskDependency ;
+ rdfs:label "dependencyOrderNumber" ;
+ rdfs:range xsd:int ;
+ nrl:maxCardinality "1" ;
+ nrl:minCardinality "1" .
+
+ tmo:actualTime
+ a rdf:Property ;
+ rdfs:label "actualTime" ;
+ rdfs:range xsd:dateTime ;
+ rdfs:subPropertyOf tmo:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Initiator
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Initiator" .
+
+ tmo:dateTime
+ a rdf:Property ;
+ rdfs:comment "dateTime subsumes various properties with Range XMLSchema:dateTime. If possible they are further grouped by \"abstract\" properties." ;
+ rdfs:label "dateTime" ;
+ rdfs:range xsd:dateTime ;
+ nrl:maxCardinality "1" .
+
+ tmo:UndirectedDependency
+ a rdfs:Class ;
+ rdfs:comment "A symmetric relations between task." ;
+ rdfs:label "UndirectedDependency" ;
+ rdfs:subClassOf tmo:TaskDependency .
+
+ tmo:attachment
+ a rdf:Property ;
+ rdfs:comment "connects a Task with an Attachment object. Attachments are associations of Things." ;
+ rdfs:domain tmo:Task ;
+ rdfs:label "attachment" ;
+ rdfs:range tmo:Attachment ;
+ nrl:inverseProperty tmo:attachmentTask .
+
+ tmo:attachmentTask
+ a rdf:Property ;
+ rdfs:comment "Inverse of attachment, connects an Attachment Association to the associated Task. Is required for every instance of Attachment." ;
+ rdfs:domain tmo:Attachment ;
+ rdfs:label "attachmentTask" ;
+ rdfs:range tmo:Task ;
+ rdfs:subPropertyOf pimo:associationMember ;
+ nrl:inverseProperty tmo:attachment ;
+ nrl:maxCardinality "1" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_Receiver
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_Receiver" .
+
+ tmo:TMO_Instance_TaskState_Deleted
+ a tmo:TaskState ;
+ rdfs:label "TMO_Instance_TaskState_Deleted" .
+
+ tmo:taskStateChangesTo
+ a rdf:Property ;
+ rdfs:domain tmo:TaskState ;
+ rdfs:label "taskStateChangesTo" ;
+ rdfs:range tmo:TaskState ;
+ rdfs:subPropertyOf tmo:stateTypeRole ;
+ nrl:maxCardinality "1" .
+
+ tmo:TaskPrivacyState
+ a rdfs:Class ;
+ rdfs:comment """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.""" ;
+ rdfs:label "TaskPrivacyState" ;
+ rdfs:subClassOf tmo:StateTypeRole .
+
+ tmo:TMO_Instance_Urgency_09
+ a tmo:Urgency ;
+ rdfs:label "TMO_Instance_Urgency_09" .
+
+ tmo:TMO_Instance_Importance_02
+ a tmo:Importance ;
+ rdfs:label "TMO_Instance_Importance_02" .
+
+ tmo:TMO_Instance_PersonInvolvementRole_InternalObserver
+ a tmo:PersonInvolvementRole ;
+ rdfs:label "TMO_Instance_PersonInvolvementRole_InternalObserver" .
+
+ tmo:Skill
+ a rdfs:Class ;
+ rdfs:comment "examples are e.g. technologies like Java, XML, ..." ;
+ rdfs:label "Skill" ;
+ rdfs:subClassOf tmo:AbilityCarrier .
+}
+
+<http://www.semanticdesktop.org/ontologies/2008/05/20/tmo_metadata#> {tmo: a nrl:Ontology ;
+ nao:creator <http://www.dfki.uni-kl.de/~brunzel/> ;
+ nao:hasDefaultNamespace
+ "http://www.semanticdesktop.org/ontologies/2008/05/20/tmo#" ;
+ nao:hasDefaultNamespaceAbbreviation
+ "tmo" ;
+ nao:lastModified "2008-11-06T14:54:25.546Z" ;
+ nao:status "Unstable" ;
+ nao:updatable "0 " ;
+ nao:version "0.9" .
+
+ <http://www.semanticdesktop.org/ontologies/2008/05/20/tmo_metadata#>
+ a nrl:GraphMetadata ;
+ nrl:coreGraphMetadataFor
+ tmo: .
+}
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-05 04:57:57 +0000