search

semanticarts / gist

Semantic Arts gist upper enterprise ontology
Creative Commons Attribution 4.0 International
155 stars 18 forks source link

Fix Project and Task #760

Closed rjyounes closed 1 year ago

rjyounes commented 1 year ago

In gist 11.1.0 we have the following:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

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 GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1285623529, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPW6BV7RWMOSZ6VLFQ3WEFHUXANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

rjyounes commented 1 year ago

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 commented 1 year ago

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

mkumba commented 1 year ago

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 GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1286119379, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPTMR2Y463HLK3N2U2TWEGUTVANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

mkumba commented 1 year ago

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 GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1286114893, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPW7KCBC5PSQFGQUUCLWEGUHBANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

rjyounes commented 1 year ago

So the proposal is:

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

mkumba commented 1 year ago

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:

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1286845110, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPTQSNFU6JOM7Q7STATWEJ6OVANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

uscholdm commented 1 year ago

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 commented 1 year ago
  • 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 commented 1 year ago

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.

mkumba commented 1 year ago

Dictionary Definitions from Oxford Languageshttps://languages.oup.com/google-dictionary-en · Learn morehttps://support.google.com/websearch/answer/10106608?hl=en e·vent https://www.google.com/search?client=safari&rls=en&q=how+to+pronounce+event&stick=H4sIAAAAAAAAAOMIfcRozi3w8sc9YSm9SWtOXmPU4OINKMrPK81LzkwsyczPExLkYglJLcoV4pRi52JNLUvNK7FiUWJKzeNZxCqWkV-uUJKvUADUkA_UkaoAlgcAzC9OllUAAAA&pron_lang=en&pron_country=us&sa=X&ved=2ahUKEwiN97KDg_T6AhVRAjQIHZQoA-wQ3eEDegQICBAI https://www.google.com/search?client=safari&rls=en&q=how+to+pronounce+event&stick=H4sIAAAAAAAAAOMIfcRozi3w8sc9YSm9SWtOXmPU4OINKMrPK81LzkwsyczPExLkYglJLcoV4pRi52JNLUvNK7FiUWJKzeNZxCqWkV-uUJKvUADUkA_UkaoAlgcAzC9OllUAAAA&pron_lang=en&pron_country=us&sa=X&ved=2ahUKEwiN97KDg_T6AhVRAjQIHZQoA-wQ3eEDegQICBAI Learn to pronounce noun

1. a thing that happens, especially one of importance. "one of the main political events of the late 20th century" * a planned public or social occasion. "events to raise money for charity"

The first google definition for task

Dictionary Definitions from Oxford Languageshttps://languages.oup.com/google-dictionary-en · Learn morehttps://support.google.com/websearch/answer/10106608?hl=en task https://www.google.com/search?client=safari&rls=en&q=how+to+pronounce+task&stick=H4sIAAAAAAAAAOMIfcRoxi3w8sc9YSndSWtOXmNU5-INKMrPK81LzkwsyczPExLgYglJLcoV4pBi42IpSSzOtmJRYkrN41nEKpqRX65Qkq9QAFSfD9SQqgCSBgDFfHbyUwAAAA&pron_lang=en&pron_country=us&sa=X&ved=2ahUKEwjCofvRgvT6AhWyMDQIHRklCz0Q3eEDegQIFRAI https://www.google.com/search?client=safari&rls=en&q=how+to+pronounce+task&stick=H4sIAAAAAAAAAOMIfcRoxi3w8sc9YSndSWtOXmNU5-INKMrPK81LzkwsyczPExLgYglJLcoV4pBi42IpSSzOtmJRYkrN41nEKpqRX65Qkq9QAFSfD9SQqgCSBgDFfHbyUwAAAA&pron_lang=en&pron_country=us&sa=X&ved=2ahUKEwjCofvRgvT6AhWyMDQIHRklCz0Q3eEDegQIFRAI Learn to pronounce noun

1. a piece of work to be done or undertaken.

I don’t think either of them imply that either must have a date to be an event or task.

The philosophers aren’t much help. I’ve been mining the BFO definition of occurrent, and all I can find is

BFO 2 Reference: every occurrent that is not a temporal or spatiotemporal region is s-dependent on some independent continuant that is not a spatial region

Which weirdly suggests that the are occurrents that are not temporal, I think they have it covered a couple of comments later

Every occurrent occupies_spatiotemporal_region some spatiotemporal region.

And

b is an occurrent entity iff b is an entity that has temporal parts.

Without, as near as I can tell ever defining “temporal” (I will recheck my BFO book when I get in the office) but there are 136 references to the term temporal without a definition (does it require a date to be temporal? Don’t know “date” is referenced 0 times)

I think to be on more solid ground, we should consider when does a new instance (uri) come into existence.

A new instance of TaskTemplate (recipe) comes into existence every time we create a new recipe, but not every time we make a cake. It's the instantiate function that creates a new task. In Rebeccas instance, the wedding planner (Franck if you saw Father of the Bride) has a TaskTemplate for how a wedding should go. It gets instantiated when someone like Steve Martin shows up and decides he is going to fund a wedding for his daughter. It is not the date that makes the wedding an event, its its instantiation from an abstraction to a real individual that makes it an event (in my opinion)

Activity (to your other email) is a way of describing a behavior, one of the parts of the Task Template or of the Event. Organ Playing could be an Activity. The Task Template could refer to Organ Playing, and the real event could decide to include a task (part of the wedding project, which is now a project due to its have subtasks) Organ Playing (again before they scheduled it or resourced it (by finding a n organ player and an organ))

In most settings the uri when you define an event, persists as you schedule it and as it “unfolds”. I start planning a vacation (event) and later accrete planned dates, book resources (airlines, rental cars, hotels etc) and then eventually add actual dates to my planned dates.

There are a few domains where they seem to prefer to create a new uri to distinguish the plan from the actual, but that is more the exception.

On Oct 21, 2022, at 7:46 PM, Michael Uschold @.**@.>> wrote:

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.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1287576642, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPQKQY3LRBROYUDSEPDWENBQPANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

mkumba commented 1 year ago

So I’m rereading Barry Smiths book.

I’m still on the fence as to whether occurrents must have dates or not.

In the chapter 6 on Occurrent,

“..an entity that unfolds in time …”.which to me suggests the entity could exist and get scheduled later, but

“… that exists in time by occurring or happening… “ which suggests it must have dates (in fact that suggests, I think, actual dates and not planned dates, but I might be reading too much in.

On Oct 21, 2022, at 7:46 PM, Michael Uschold @.**@.>> wrote:

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.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1287576642, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPQKQY3LRBROYUDSEPDWENBQPANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

mkumba commented 1 year ago

One more thing then I really need to get back to work.

It seems from the attached p 478 that occurrents are only historical events.

It gets weirder if you read further

On Oct 21, 2022, at 7:46 PM, Michael Uschold @.**@.>> wrote:

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.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1287576642, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPQKQY3LRBROYUDSEPDWENBQPANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

BrianSchulte commented 1 year ago

very grateful smart people are wrestling with this stuff and reflecting it in gist

On Sat, Oct 22, 2022 at 12:24 PM mkumba @.***> wrote:

So I’m rereading Barry Smiths book.

I’m still on the fence as to whether occurrents must have dates or not.

In the chapter 6 on Occurrent,

“..an entity that unfolds in time …”.which to me suggests the entity could exist and get scheduled later, but

“… that exists in time by occurring or happening… “ which suggests it must have dates (in fact that suggests, I think, actual dates and not planned dates, but I might be reading too much in.

On Oct 21, 2022, at 7:46 PM, Michael Uschold @.**@.>> wrote:

  • 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.

— Reply to this email directly, view it on GitHub< https://github.com/semanticarts/gist/issues/760#issuecomment-1287576642>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AAAGJPQKQY3LRBROYUDSEPDWENBQPANCNFSM6AAAAAARHEDD64>.

You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/semanticarts/gist/issues/760#issuecomment-1287845384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQAYLTKZFXMVQDBRCXPHQJDWEQIL5ANCNFSM6AAAAAARHEDD64 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

dylan-sa commented 1 year ago

“… that exists in time by occurring or happening… “ which suggests it must have dates (in fact that suggests, I think, actual dates and not planned dates, but I might be reading too much in.)

@mkumba FWIW, I think you've got the right reading. BFO's concept of process (a subclass of occurrent) is pretty close to what we'd think of as an event. All processes will have what they call "process boundaries," which are really just the start and end times. They are definitely thinking of events in this more restrictive sense where they've got to have start and end times. They'd even say these start/end times are actual, not just planned--we may just not have reached them yet, so we don't know what they are.

To one of Michael's points:

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.

This seems correct to me. The proposed notion of Event would be more general than BFO's process, as it doesn't require start and end times.

That said, I also agree that there is pragmatic value in having the more general concept--i.e., in keeping both planned events and "real" events in the same bucket, gist:Event. It's natural to create an IRI for a defined task that may or may not be carried out and then add dates later on when it does--it can follow the 3-stage cycle that Dave mentioned at the outset.

rjyounes commented 1 year ago

any real event, which is something that happens always and necessarily has a start time

I disagree. See the planned wedding example above. In gist a PlannedEvent is a subclass of Event. I certainly think you can plan an event before you have specified dates. The idea that something you are planning can only be an event once you've assigned dates to it is counter-intuitive.

there is pragmatic value in having the more general concept

As I'm proposing, this is not simply an issue of pragmatics, but of semantics.

rjyounes commented 1 year ago

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.

We already have this: it's called a TaskTemplate. Quite different from a particular event that is being proposed, planned, underway, or accomplished.

mkumba commented 1 year ago

If we ever go back and remap gist to bfo I guess we should make gist:HistoricalEvent == bfo:Occurrent

On Oct 23, 2022, at 9:38 AM, dylan-sa @.**@.>> wrote:

“… that exists in time by occurring or happening… “ which suggests it must have dates (in fact that suggests, I think, actual dates and not planned dates, but I might be reading too much in.)

@mkumbahttps://github.com/mkumba FWIW, I think you've got the right reading. BFO's concept of process (a subclass of occurrent) is pretty close to what we'd think of as an event. All processes will have what they call "process boundaries," which are really just the start and end times. They are definitely thinking of events in this more restrictive sense where they've got to have start and end times. They'd even say these start/end times are actual, not just planned--we may just not have reached them yet, so we don't know what they are.

To one of Michael's points:

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.

This seems correct to me. The proposed notion of Event would be more general than BFO's process, as it doesn't require start and end times.

That said, I also agree that there is pragmatic value in having the more general concept--i.e., in keeping both planned events and "real" events in the same bucket, gist:Event. It's natural to create an IRI for a defined task that may or may not be carried out and then add dates later on when it does--it can follow the 3-stage cycle that Dave mentioned at the outset.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1288139733, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPWGGXQCSLVELOOBCBLWEVLWNANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

dylan-sa commented 1 year ago

If we ever go back and remap gist to bfo I guess we should make gist:HistoricalEvent == bfo:Occurrent

@mkumba Yep, I'll take another look and make sure we've got them linked up correctly. It'll hold in one direction but not the other. gist:HistoricalEvent will be a subclass of bfo:Process (and therefore bfo:Occurrent), but bfo:Process would (in principle, at least) also include contemporary events and possibly future events (events that will happen but just haven't yet).

It seems from the attached p 478 that occurrents are only historical events.

The attachment didn't come through for me, but I don't think they'd want to put it that way. Part of the weirdness here is that BFO commits to a "4D-block" perspective of reality (something we don't need to commit to), with the idea being that reality consists of a big block which is the totality of the past and present (and on some variants of the view, even the future). The upshot on this kind of view is that contemporary events do have actual end times just like historical events, but we just haven't yet drifted into that part of the spacetime block and so don't know for sure what they are yet.

rjyounes commented 1 year ago

We agreed that I will create a PR including two things:

uscholdm commented 1 year ago
  • Bring back Project and Event and deprecate ProjectExecution and TaskExecution.

I Think you meant:

Also include ScheduledTaskExecution

rjyounes commented 1 year ago

Good catch. Corrected version:

mkumba commented 1 year ago

No the template isn’t a defined task

The template is “generic wedding plan” when you supply the bride and groom you instantiate a defined task, that we will start scheduling and resourcing. The template may give us some clues (typically 4-6 brides maids and 4-6 best men or whatever they are called) etc. but the defined task is going to do what it does

On Nov 7, 2022, at 7:39 PM, Rebecca Younes @.**@.>> wrote:

Or do we want just one class, DefinedTask? Since a task can be made up of subtasks, what we're calling TaskTemplate could be a DefinedTask made up of other DefinedTasks.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1306540874, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPXVXY6J4VBGB5H23Y3WHG4N5ANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

mkumba commented 1 year ago

Maybe “defined task” should be “instantiated task”

In the recipe the subtasks are sub task templates. One sub task template says “bake at 350 for 30 minutes”

We instantiate that task (along with all the others) we know that this cake will take at least 30 minutes to make, but we haven’t yet decided when we are going to do it. The “defined task” (or maybe “instantiated task) is specific to this dinner, and this set of ingredients (chocolate), but not yet scheduled.

We have a defined task, (this cake will need 30 minutes in the oven) and we have to juggle the other things that are going in the oven that day.

After a bit of resource planning we realize if we take the ham out at 4:30 we can put the cake in, so the cake is now planned to go in from 4:30 -5:00

When the big day comes, the ham takes longer than we thought. The cake doesn’t go in til 4:45, we now plan to take it out at 5:15, but we forget and it comes out at 5:30 (overcooked, rats!)

So we have

Bake this cake (#27) (planned on xx/xx 4:30 - 5:00) (actual 4:45 - 5:30), based on template 1 which said we should cook it for 30 minutes

On Nov 7, 2022, at 7:33 PM, Rebecca Younes @.**@.>> wrote:

I'm starting to wonder if, in addition to making the changes specified above, we don't also need a DefinedTask, which is disjoint with ScheduledTask. If a recipe for chocolate cake is a TaskTemplate, and it consists of steps like

What are each one of those steps in the recipe? When I bake a cake, I am executing a Task based on the TaskTemplate. Each of the individual steps I perform is a subtask - also a Task. So we also need a name for the individual steps in the recipe. DefinedTask seems fitting. These are exactly parallel:

A DefinedTask may be part of a TaskTemplate, or a standalone task.

@uscholdmhttps://github.com/uscholdm I'm not sure, but this may have been what you were getting at somewhere above.

— Reply to this email directly, view it on GitHubhttps://github.com/semanticarts/gist/issues/760#issuecomment-1306537092, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAGJPVANIJDCAQFLMT2WODWHG3Y3ANCNFSM6AAAAAARHEDD64. You are receiving this because you were mentioned.Message ID: @.***>

rjyounes commented 1 year ago

In the PR, I've also changed PlannedEvent to ScheduledEvent, like ScheduledTask, to reflect the fact that a planned wedding without dates is planned but not scheduled.