Address issues with gist:Task and gist:ScheduledTask

[turingtest37]

gist 10.0.0 defines Task as

A task which has been defined and either scheduled or accomplished, or both.

It should read "An Event which has been..."

[rjyounes]

I disagree - a task is far more specific than a generic event. It's also wrong to say it's been scheduled. And I agree that it's best if the definition doesn't use the same word as the label. Here are some dictionary definitions:

• A piece of work to be done or undertaken.
• A usually assigned piece of work often to be finished within a certain time.
• A definite piece of work assigned to, falling to, or expect of a person.

Of these, the first looks the best to me, though I don't love any of them. But I'm guessing that between us and them we can come up with good wording.

[uscholdm]

The problem here is that gist:Task, (as intended by its original author) really does correspond to the event of doing something even if that doing has not happened yet. I have long found that confusing, because the dictionary definition is different.

An important question is whether we genuinely want the concept that is currently modeled, but should call it something besides gist:Task or whether we should change the meaning of gist:Task to align better with common usage of the term. The latter is dangerous.

[rjyounes]

Hm, I see. I didn't look at gist when I responded. So the definition as it stands actually means: The event of performing a task in the usual sense and thus the apparent circularity!

I think it's a stretch to call tasks and projects events, and it's unfortunate that they are defined as such. It would be good to find out if that's how people are using it.

In the current hierarchy I don't see a difference between Task and ScheduledTask, defined as "A task planned to occur. When it was scheduled, it would have been in the future, but now might be in the past." Isn't that the same as "A task which has been defined and either scheduled or accomplished, or both."?

There's a lot that's fishy here and I think we should work out what classes are actually needed. I'd consider a Tasksubclass of Intention, and a ScheduledTask that is the intersection of Task and PlannedEvent, as currently. This would be a major change.

I'm going to change the title of this issue to reflect the fact that it's more than a matter of the text definition.

[uscholdm]

In the current hierarchy I don't see a difference between Task and ScheduledTask, defined as "A task planned to occur. When it was scheduled, it would have been in the future, but now might be in the past." Isn't that the same as "A task which has been defined and either scheduled or accomplished, or both."?

The difference is that "A task which has been defined and either scheduled or accomplished, or both." might not have been scheduled. A ScheduledTask by definition is or was scheduled.

[rjyounes]

OK, but is that really a useful distinction? Do we need to know that a task now completed was or wasn't scheduled? Can you describe a context in which that distinction would be important?

[rjyounes]

There's a question of whether to change the skos:definition before addressing the larger issues raised here, or to do them in tandem.

[bolerio]

I'd be in favor of addressing the larger issue. A Task being defined as an Event seems quite problematic to me. +1 to connecting it conceptually to Intention , as a sub-class or some other way.

[rjyounes]

skos:definition of Task has been changed in PR #597. Remaining issues are:

• Should Task be a subclass of Event?
• Is the distinction between ScheduledTask and Task useful?

[dylan-sa]

Following discussion in the 3/24 issue review, I'd like to propose the following changes.

(1) A new definition for gist:Task:

gist:Task
	a owl:Class ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:Requirement
			[
				a owl:Restriction ;
				owl:onProperty gist:hasGoal ;
				owl:someValuesFrom gist:Goal ;
			]
		) ;
	] ;
	skos:definition "A piece of work to be done to achieve a goal."^^xsd:string ;
	skos:prefLabel "Task"^^xsd:string ;
	skos:scopeNote "A task itself is distinct from the event of completing that task. Use gist:isBasisFor to relate a gist:Task to a gist:Event. The event of carrying out the task may have already occurred, or it may be scheduled to occur in the future."^^xsd:string ;
	.

Notable changes:

• gist:Event changes to gist:Requirement
• Range in property restriction goes from gist:Intention to gist:Goal
• skos:definition changes to align more closely with common usage / dictionary definitions
• skos:scopeNote added to provide direction on connecting tasks with events (I believe @rjyounes floated gist:isBasisFor as a potential link in 3/24 issue review)

Rationale:

The proposed changes are motivated by the idea that a task is distinct from the event of carrying out that task. The question becomes where to place gist:Task if it's not an event. @rjyounes and @bolerio have suggested tying it to gist:Intention. I agree and think it can be tied more specifically to gist:Requirement, a subclass of gist:Intention. To motivate the connection to gist:Requirement, consider a statement like 'Bob was tasked with completing the report', which implies that that he is required to complete it. 'Bob was assigned a task' also implies a requirement.

The advantage of this definition is that it more closely aligns with common usage of 'task'. However, @uscholdm rightly points out that there may be good use for the concept that is currently modeled, even if it's not what we'd ordinarily think of as a task. To partly address this concern, my thought is that the scope note could serve as a roadmap for modeling events that fall under that concept.

Suppose something is currently modeled in the following way:

ex:_Event_CompletionOfAssignment a gist:Task ;
    gist:startDateTime "2010-10-26T21:32:52"^^xsd:dateTime ;
    gist:endDateTime "2001-10-26T21:32:52"^^xsd:dateTime ;
    gist:hasGoal ex:_Goal_RaiseAverage ;
    .

The current proposal suggests an alternative model:

ex:_Event_CompletionOfAssignment a gist:Event ;
    gist:startDateTime "2010-10-26T21:32:52"^^xsd:dateTime ;
    gist:endDateTime "2001-10-26T21:32:52"^^xsd:dateTime ;
    .

ex:_Task_CompleteAssignment a gist:Task ;
     gist:hasGoal ex:_Goal_RaiseAverage ;
     gist:isBasisFor ex:_Event_CompletionOfAssignment ;
    .

(2) A new definition for gist:ScheduledTask:

gist:ScheduledTask
	a owl:Class ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:Task
            [
                a owl:Restriction ;
                owl:onProperty gist:isBasisFor ;
                owl:someValuesFrom gist:PlannedEvent ;
            ]
		) ;
	] ;
	skos:definition "A task scheduled to be completed."^^xsd:string ;
	skos:prefLabel "Scheduled Task"^^xsd:string ;
	skos:scopeNote "All scheduled tasks serve as the basis for some planned event, which is the actual carrying out (or completion) of the task. That planned event may have already occurred, or it may be scheduled to occur in the future."^^xsd:string ;
	.

Notable changes:

In the equivalence class assertion, gist:PlannedEvent is switched for a property restriction--namely, the class of things that serve as a basis for a planned event.

Rationale:

This proposed definition for gist:ScheduledTask keeps the spirit of the current one in tying to gist:PlannedEvent, but it changes to more closely align with the above proposal for gist:Task. There is an open question as to whether we should keep this class. I do not have strong feelings on this one, but I would propose this definition if we choose to keep it.

[rjyounes]

A lot of this looks good, though I need to study it a bit more closely. The one thing that strikes me immediately is that gist:Requirement is not the right superclass. It is defined as

"A documented physical or functional need that a particular design, product, or process must be able to perform. Alternately, the obligation of a person or organization to behave in a certain way (i.e., drive on the right side of the road)."

I don't see that this describes a task. This is meant to be, for example, a requirement for a software application. The task has requirements; e.g., the task of washing the dishes requires that the dishes be clean on completion of the task.

Goal doesn't work for the same reasons: task has a goal, but is not itself the goal. The goal of the dishwashing task is to end up with clean dishes, not to perform the action of washing the dishes. This is actually what your triples above suggest:

ex:_Task_CompleteAssignment a gist:Task ;
     gist:hasGoal ex:_Goal_RaiseAverage ;
     gist:isBasisFor ex:_Event_CompletionOfAssignment ;
    .

I'm not sure about Intention any more either. What are we trying to say if we say that a task is an intention? That it's something someone intends to do? Certainly that's not correct: I have a pile of dishes in my sink, and I can define a task which is to wash them, but in fact I have no intention of washing them. Here are some dictionary definitions of intention:

Merriam-Webster: "...what one intends to do or bring about. A determination to act in a certain way."
Collins: "An intention is an idea or plan of what you are going to do." Examples:

• The company has every intention of keeping the share price high.
• It is my intention to remain in my position until a successor is elected

We also need to look at TaskTemplate, defined as "An outline of a task of a particular type, that will, when instantiated, generate an actual (unscheduled) task."

I think here gist is making the same distinction we are between the task itself and the event of completing the task, but the former is the TaskTemplate and the latter is the Task (the event). We are proposing that Task be the former and there is no specific event type for the latter.

I believe the problem would be solved by renaming Task to TaskExecution, which satisfies our ordinary-language intuition that a task itself is not an event. Perhaps TaskTemplate could be just Task.

[rjyounes]

Then for consistency we'd have to rename Project as well.

BTW we've stumbled over these definitions more than once, which leads me to believe that they do need to be renamed.

[dylan-sa]

Thinking some more about this, I'm in agreement with Rebecca's latest comments about renaming gist:Task to gist:TaskExecution. (Similarly, Project could change to ProjectExecution, ScheduledTask to ScheduledTaskExecution.) This is a simpler way of respecting the intuition that a task is not an event.

There is still a question of whether gist:TaskTemplate should be revised in some way, though perhaps this is a separate issue. Regarding the name, I think having 'Template' in the name is nice because it is suggestive of a "general recipe" for task execution. It is also a helpful hint to its superclass, gist:Template. Regarding the formal definition, one of Rebecca's comments makes me wonder whether all task templates are specifications of how a task ought to be executed. Following discussion in #60 and #175, it's probably not the case that all templates in general are specifications. However, maybe all task templates are specifications. Arguably, task templates are similar to service specifications in that they are an outline of something to be done that provides a basis for some event. (Task templates aren't catalog items like service specifications are, but I think there's still a similarity there.) Putting the idea out there for some further discussion...

[rjyounes]

You raise an issue here that we've gone around more than once. At one point we had decided that TaskTemplate should be a subclass of Specification, but Dave wanted to limit the latter to specifications of what will be provided rather than how. E.g., an SOW specifies services to be provided, but not how they will be executed, whereas a TaskTemplate is a series of steps detailing how something should be done. It's a good distinction, but our names should be clearer so that we don't keep tripping over the meanings.

[dylan-sa]

Ah, right--that does seem like a good distinction to keep in place. Maybe for now then we can have the following name changes on the table:

Part 1:

• Task --> TaskExecution
• Project --> ProjectExecution
• ScheduledTask --> ScheduledTaskExecution

(Some nearby alternatives to 'execution' for consideration: 'completion', 'delivery', 'implementation', 'performance', 'realization')

Part 2:

• TaskTemplate --> Task (Conditional on the current version of Task being renamed in Part 1)

[rjyounes]

Keep TaskTemplate; semantically clearer than Task.

Dan: TaskEvent instead of TaskExecution.

Rebecca: Then just leave as they are. We need to look at the formal and textual definitions to understand the exact meaning, rather than making assumption from the name.

Michael: Add scopeNotes to clarify.

DECISION: Leave names as is, add scope notes to all four classes.

[rjyounes]

Include #408.

[JonathonGist]

I appreciate the careful thought being put into this, and the changes being made.

[rjyounes]

@uscholdm Discussed with Dave, he suggests avoiding the ambiguous Task and using TaskTemplate and TaskExecution.

[rjyounes]

REVISED DECISION:

• Deprecate Task
• Replace Task with TaskExecution
• Leave TaskTemplate as is.

[uscholdm]

What about:

• Project could change to ProjectExecution,
• ScheduledTask could change to ScheduledTaskExecution.

Certainly, the latter, given we will be having TaskExecution.
I also like the former given the tight link between Project and Task.

[JonathonGist]

I agree with Michael's proposal.

[rjyounes]

DECISION: Change all three classes to use "Execution."

[rjyounes]

Completed in September.