Fix Project and Task

[rjyounes]

In gist 11.1.0 we have the following:

• TaskExecution, subclass of Event, defined as "An event characterized by a defined piece of work that is either scheduled, accomplished, or both." This is identical to gist 11.0.0 Task.
• ProjectExecution, subclass of TaskExecution, defined as "A project execution is a task execution (usually a longer duration task) made up of other task executions."
• ScheduledTaskExecution, subclass of TaskExecution, defined as "The execution of a task that was planned to occur at a given time. When it was scheduled, it would have been in the future, but now might be in the past."

We also have TaskTemplate, subclass of Template, defined as "An outline of a task of a particular type, which is the basis for executing such tasks." This is roughly like a process specification - a recipe or set of instructions.

My interpretation of TaskTemplate is that it's not meant to be a one-off - like it's superclass Template, it should be able to serve as the basis for a number of outputs. E.g., a recipe for chocolate cake can be the basis for a number of chocolate-cake making events that results in different chocolate cakes.

@mkumba asks: "If we define a Project[Execution], say the Juniper project, is that not a Project[Execution] either until it gets scheduled?"

I think we need a third type of object here, DefinedTask and DefinedProject. Task and Project are probably the preferred terms if starting from scratch, but that's not currently possible because they have been deprecated and replaced by TaskExecution and ProjectExecution.

TaskExecution would be related to a Task - use isBasedOn? Similarly for ProjectExecution.

In a similar vein, @mkumba writes:

"Something got lost along the way.

A task template is a cookie cutter. It is something you create tasks from. In Pipedrive or Jira or a project management system, or a patient scheduling system, or a calendar, when you say “new” or “create” you create a task, and the nature and that task is determined by the template. But the template isn’t a task or anything you can do, its a template.

Used to be in gist we had three stages a task went through. It went from being defined, to being scheduled to being completed. So a defined task is like a Jira ticket in the backlog, we know what it is and what its about we just haven’t scheduled it yet. We can then schedule it. In some domains there is another step to resource it, and then finally we do it. In most domains the task accretes more dates, resources and activity, but in some domains it makes sense to create a separate instance for the actual task (execution in 11.1 parlance) and refer to the schedule, but a lot of domains the task just evolves.

Where I think this thing drifted was maybe:
Somewhere along the way we dropped the concept “definedTask” and just said that’s just a task that hasn’t yet been scheduled or accomplished.
We tightened the definition of event, to where now it has to have and start and end date (we were kind of loose historically with some values, yeah this task (say a Jira ticket) may not have a start date yet, but it will eventually. Weirdly the current definition should create an inconsistency, (it says an event has exactly 1 endDate, but one of its children, contemporaneousEvent is max 0) I think its not throwing an exception because exactly 1 rarely does any inference.

My suggestion is we relax event to include things that happened, are scheduled to happened, or we expect to schedule or something like that."

[rjyounes]

On second thought, I think a TaskExecution could be related to a DefinedTask (and similarly for project) but doesn't have to be. That is, in some contexts a project may always come with a schedule. We don't want to materialize an abstract defined task object if it doesn't add value.

[rjyounes]

A different proposal: Have just a single class for each, Project and Task. If it's scheduled for execution, add dates, but it wouldn't be an event. This is much simpler than having two distinct objects, DefinedProject and ProjectExecution. However, we wouldn't be capturing the distinction between the event of executing a project and the project itself. I'm not sure how useful this is, as opposed to a scheduled vs unscheduled project/task.

It seems like this is where we were at one point, based on Dave's comment above:

"Where I think this thing drifted was maybe:
Somewhere along the way we dropped the concept “definedTask” and just said that’s just a task that hasn’t yet been scheduled or accomplished."

[mkumba]

Yeah I think I’m warming up to this. What I’m still not quite sure on. When you put a meeting on your caledar, that seems like an event. Just saying we should meet sometime, doesn’t seem like an event. Maybe this is where this whole thread started. Let’s take the simplest and work up from there. Let’s say I wanted to make a JIRA ticket to add three classes and a property to an ontology. * This ticket (and lets call it ticket 217) is not a task template. The task template is in the JIRA application and knows that when you say “new ticket” here are the fields you expect to fill in. * But it seems like ticket 217 is a task. Even if its sitting in the backlog, its still a task * At some point we schedule it. We might put it on a calendar. At that point its a lot like a meeting. It is a scheduled task. * Once we start work on it, it is a comtemporaneous (maybe open would be a better term) task. * At some point we complete it. Unlike the meeting we likely didn’t complete it when we planned to, but we completed it and its now an historical task. So the question is: does it become an event (in addition to being a task) at some point in its life cycle? Or did it start life as a degenerate event (with no dates) On Oct 20, 2022, at 8:14 AM, Rebecca Younes ***@***.******@***.***>> wrote: A different proposal: Have just a single class for each, Project and Task. If it's scheduled for execution, add dates, but it wouldn't be an event. This is much simpler than having two distinct objects, DefinedProject and ProjectExecution. However, we wouldn't be capturing the distinction between the event of executing a project and the project itself. I'm not sure how useful this is, as opposed to a scheduled vs unscheduled project/task. It seems like this is where we were at one point, based on Dave's comment above: "Where I think this thing drifted was maybe: Somewhere along the way we dropped the concept “definedTask” and just said that’s just a task that hasn’t yet been scheduled or accomplished." — Reply to this email directly, view it on GitHub<#760 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPW6BV7RWMOSZ6VLFQ3WEFHUXANCNFSM6AAAAAARHEDD64>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[rjyounes]

Now I see how the issue of whether events must have dates enters into this. If I'm planning a wedding, but haven't scheduled it yet, am I not planning an event? I think I am, which means that events don't have to have dates.

[rjyounes]

And I'm really finding the idea of having to have both a DefinedProject and a ProjectExecution shadowing on another distasteful.

[mkumba]

Agreed On Oct 20, 2022, at 2:38 PM, Rebecca Younes ***@***.******@***.***>> wrote: And I'm really finding the idea of having to have both a DefinedProject and a ProjectExecution shadowing it distasteful. — Reply to this email directly, view it on GitHub<#760 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPTMR2Y463HLK3N2U2TWEGUTVANCNFSM6AAAAAARHEDD64>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mkumba]

Yeah I think that’s where we started. It seems kind of weird, but I think that’s the best way to think of it. On Oct 20, 2022, at 2:34 PM, Rebecca Younes ***@***.******@***.***>> wrote: Now I see how the issue of whether events must have dates enters into this. If I'm planning a wedding, but haven't scheduled it yet, am I not planning an event? I think I am, which means that events don't have to have dates. — Reply to this email directly, view it on GitHub<#760 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPW7KCBC5PSQFGQUUCLWEGUHBANCNFSM6AAAAAARHEDD64>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[rjyounes]

So the proposal is:

• Change the names back to Project and Task and deprecate ProjectExecution and TaskExecution.
• Define a Task as something like "A piece of work which is proposed, planned, scheduled, underway, or completed."
• Restore former definition of Project: "A task (usually a longer duration task) made up of other tasks."
• Remove the date restrictions on Event, based on examples above, allowing Project and Event to remain as subclasses of it.

I am not fully convinced of the subclassing of Event, but that's for another issue.

[mkumba]

Yeah, maybe throw “occurent” in the definition of event. I don’t think BFO has any more formalism than that

…

Sent from my iPhone On Oct 21, 2022, at 05:41, Rebecca Younes ***@***.***> wrote:  So the proposal is: * Change the names back to Project and Task and deprecate ProjectExecution and TaskExecution. * Remove the date restrictions on Event. That makes the semantics of the term rather thin * Define a Task as something like "A piece of work which is proposed, planned, predicted, scheduled, or completed." * Restore former definition of Project: "A task (usually a longer duration task) made up of other tasks." — Reply to this email directly, view it on GitHub<#760 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPTQSNFU6JOM7Q7STATWEJ6OVANCNFSM6AAAAAARHEDD64>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[uscholdm]

What seems to be missing here are the building blocks of a plan, which are specific things to do that are not planned per se, so they do not morph into a particular event. They correspond to the steps in a recipe.

1. heat a frying pan with light olive oil
2. crack open egg
3. place the egg into the heated frying pan

Or a travel plan to get from Ithica to Fort Collins.

1. buy plane ticket
2. travel to Ithica airport
3. fly to denver
4. take shuttle to FC

These are the building blocks for countless recipes or trips. There are lots of names for them, 'activity' being one, let's call them 'action steps' for the moment. Anyone who can perform these action steps has a capability or skill. When they decide to do one of them, it can be what we call a planned event. But sitting in empty space as building block for countless recipes or plans it is a stretch to think of an action step as a task or an event of any sort. A task is something to do, not something that merely can be done. THere are plans in place with action steps to nuke Moscow. They are not tasks nor planned events. I can mow the lawn, but I sure as hell will not do so unless my Dad assigns me to that task. If plan to make scrambled eggs, I follow several action steps in recipe. The recipe itself might be a template. When I decide to make scrambled eggs for a breakfast gathering on Sunday morning, the making of the eggs is a planned event. It is built up from reusable action steps, none of which are in any sense events or defined tasks. It's a description of something that can and will be done countless times in what are events.

[uscholdm]

• Remove the date restrictions on Event, based on examples above, allowing Project and Event to remain as subclasses of it.

I am not fully convinced of the subclassing of Event, but that's for another issue.

Task being a subclass of Event has always been controversial. I suspect most philosophers and many ontologists would say it is ontologically wrong - and I would agree with them. But as a practical matter, it might be convenient. It may be proving to be inconvenient in that any real event, which is something that happens always and necessarily has a start time. It is sleight of hand (however practically convenient) to pretend that it does not. It is a clear sign that we are doing something that is ontologically dubious if we have to model an event as not necessarily having a start time. It goes against our 'model the real world' mantra. The thing that does not have a start time is a planned event. We are defining something called Event that is really the union of a planned event and a real event.

[uscholdm]

And I'm really finding the idea of having to have both a DefinedProject and a ProjectExecution shadowing on another distasteful.

Seems similar to having two individuals for a statue, one for the statue itslef and another for the metal that it is composed of. If you melt it down, you still have the metal, but not the statue. Having to is arguably ontologically correct, but in practice rarely useful. IF you ever need it thought, gist has you covered.