Task Groups & Condition structures don't allow free connections.

On 14/03/2019 14:52, Borut Fabjan wrote:
> Hi Thomas,
>
> looks like (you&me) are not going to advance on this topic.

sure we can - we just need to see some real use cases; also I'll look at what would be needed to make it work.

I have never seen any theory or principles, or anything other than ad hoc arguments from the FHIR guys, so I don't think we are working like them. (Have a look at their 'Care plan' for example.) Unlike the FHIR guys, I've spent over a decade on biomedical ontology, and also a few years more recently on details care pathways and guidelines. So I'm interested in grounding our solution in reality.

Another technical thing to consider: the various CONDITION_GROUP / BRANCH structures were not originally intended to be descendants of TASK_GROUP; in v0.9 of the model they were not. I changed them as part of a refactoring, and then we hit the moment where the Moscow project needed a v1.0 published, so I left it like that.

Personally I would be happy to change that part of the model, and in doing so I suspect we could get back to a more open graph structure for decisions (still really should be supported by a Petri net analysis).

BUT... both Marand and DIPS now have code for all this, so making that kind of change would impact the code. If we think about this like engineers, we should potentially contemplate doing such changes, but in a v2 version of the spec (and code). Since I think that the decision structure you raised is unlikely to be encountered in reality, I think this would be ok. If that is not true, then we need to think about minimum impact changes to obtain the technical effect we want in a v1.2 release.

From Fabio:
looks like (you&me) are not going to advance on this topic.

>>
> so let me say out the outset, the TP model is a theory, like any model. I'll defend it to the extent that I think it is a sort-of-good-enough theory, and internally coherent, but I work on a science basis. If we have new better concept or new evidence, the theory has to get modified... So I have no problems with making changes, but they either need to be coherent with what is there, or else it is a different paradigm, which is a lot more work.
>
> So with that in mind: my argument in the previous post isn't to do with converting the example to the form of the TP model; it's to do with the real ontology and logic structures one encounters in real structured medical guidelines like these.
>

This sounds a lot like FHIR guys. If I never encounter number 53, it doesn’t mean it doesn’t exist. I guess basic concepts need to be generic enough to withstand more then few use cases.
Of course there’s also a question of elegance. You can do math with roman numbers. But it’s not really practical.

>>
>> With branch merge I exposed two issues in TP;
>>
>> a) duplicating (nesting) of decision groups where you end up having the same condition in two places (decision_group) - that’s not in line with good design practice
>>
> which good design practice? It's only contingently 'the same condition' - in many cases I think it won't be, it will be more like a category condition like $stable v $unstable. This is how clinical guidelines are usually written BTW - mostly binary classification choices - have a look at NICE.org.uk.
>

For user is one condition with 3 branches. Due to a possible merge in later stages, TP requires additional ‘explicit’ nesting using a ’synthetic’ condition.
Which eventually could be a ’silent’ OR condition internal to a server.

>> b) “beforehand” nesting of “synthetic” containers - feels unnatural to target audiance/modellers. They are probably not going to start with tones of “artificial” joint flows for branch merges happening far later in the flow.
> I don't disagree that this might sometimes be the case, but OTOH I don't believe it will be seen as strange by people who work with clinical guidelines - these are mostly based on making ever finer binary category choices down different paths. Check Oxford handbook of medicine for example. The way I structured the example is more realistic than the original in a clinical sense. I don't claim there are no examples where n branches of m need to proceed in one path, but I have not seen one yet.
>

It surely lacks the elegance & simplicity.
But I guess you & me are not the best audience to judge either it is strange or not. Let’s ask potential modellers (Ian, Silje, …) how they feel about it.

>> The example/usecase you gave has a tendency to obfuscate the true nature of a problem.
>> The assumption that two independent branches which in some later stage (possibly) interact/intersect with some specific sub-sub flow branch, are inherently co-related, it’s a great simplification.
>>
> well, you just gave an abstract example - it's a classic IT person's (I don't mean you, I mean BPMN designers, like Steve White, whom I met last year) fantasy idea of representing all possible structures. But reality doesn't usually have such pathological logic. So we really need to get better examples that show we need this kind of thing.
>

Well, classic IT person knows how to merge two branches in BPMN. Even non classic IT person knows how to merge 2 branches in any flow notation.
But I’m sure most people don’t know how to merge two branches in TP. We can easily test this. I did.

>> I guess if we possibly take a bus as a mean of transportation, that doesn’t inherently mean we are about the same thing. We just possibly share one small part of a common flow in advent of specific event.
>>

Have a thought on above. Might change a prospective.

>>
>> btw:
>>
>> Transforming BPMN2 in Petri Net it’s not a novelty. //
>> https://open.hpi.de/courses/bpm2016/items/6h518QNGNObfqI9jPjz4yp
>>
>> Most BPMN engines follow the token concept for execution and some use petri internally.
>>
> there's a full analysis of it in the van der Aalst book.

Have you checked the above link? You’ll be surprised, mapping branches to petri has never been an issue.

>
> Don't get me wrong - I don't mind upgrading TP in a way that allows us to do this kind of thing - if we can convince ourselves that it really is needed in real-world modelling. Right now I am not convinced, and the example we have isn't realistic (in a medical sense), so we should in principle find at least one real world example.

Yes, Roman numbers are good enough.

> Secondly, allowing the equivalent of a free graph structure will certainly complicate the reasoning logic in an execution engine. So we need to be sure we really want to do that - e.g. maybe we add 200% complication to solve 10% edge cases, which otherwise are just a bit more 'inconvenient' to model with an extra node. Now, if it's a 100% complication but fixes 50% of the use cases, well we need to think about it.

If you checked the link (I’m sure you did, but let’s put it once more: https://open.hpi.de/courses/bpm2016/items/6h518QNGNObfqI9jPjz4yp
There’s no dramatic change. It’s just about putting silent states which resemble OR statement.

I guess TP must be convenient to use for users.

>
> So let's be scientific and investigate further.
>
> On the topic of modelling - did you make any progress on doing it graphically? I've created a rough language in the form of draw.io stencils to survive at the moment, it's actually quite an educational exercise to match formal semantics with graphic elements. But you might want to take a more 'live' approach, which is what my team at Intermountain Healthcare did for graphic modelling - problem is you can't 'see' the workflow, you can only drill through it interactively.
>

Well, right now I invest most of the energy hiding the complexity of TP hierarchies to make it digestable for modellers.
I’ve checked the visual languages but I don’t see any advantage compared to BPMN.

On 14/03/2019 10:44, Borut Fabjan wrote:
> Hi Thomas,
>
> every author of the specification is a bit in love with his work. Naturally converting any issue to the same line of thought.

so let me say out the outset, the TP model is a theory, like any model. I'll defend it to the extent that I think it is a sort-of-good-enough theory, and internally coherent, but I work on a science basis. If we have new better concept or new evidence, the theory has to get modified... So I have no problems with making changes, but they either need to be coherent with what is there, or else it is a different paradigm, which is a lot more work.

So with that in mind: my argument in the previous post isn't to do with converting the example to the form of the TP model; it's to do with the real ontology and logic structures one encounters in real structured medical guidelines like these.

>
> With branch merge I exposed two issues in TP;
>
> a) duplicating (nesting) of decision groups where you end up having the same condition in two places (decision_group) - that’s not in line with good design practice

which good design practice? It's only contingently 'the same condition' - in many cases I think it won't be, it will be more like a category condition like $stable v $unstable. This is how clinical guidelines are usually written BTW - mostly binary classification choices - have a look at NICE.org.uk.
> b) “beforehand” nesting of “synthetic” containers - feels unnatural to target audiance/modellers. They are probably not going to start with tones of “artificial” joint flows for branch merges happening far later in the flow.

I don't disagree that this might sometimes be the case, but OTOH I don't believe it will be seen as strange by people who work with clinical guidelines - these are mostly based on making ever finer binary category choices down different paths. Check Oxford handbook of medicine for example. The way I structured the example is more realistic than the original in a clinical sense. I don't claim there are no examples where n branches of m need to proceed in one path, but I have not seen one yet.
> The example/usecase you gave has a tendency to obfuscate the true nature of a problem.
> The assumption that two independent branches which in some later stage (possibly) interact/intersect with some specific sub-sub flow branch, are inherently co-related, it’s a great simplification.

well, you just gave an abstract example - it's a classic IT person's (I don't mean you, I mean BPMN designers, like Steve White, whom I met last year) fantasy idea of representing all possible structures. But reality doesn't usually have such pathological logic. So we really need to get better examples that show we need this kind of thing.
> I guess if we possibly take a bus as a mean of transportation, that doesn’t inherently mean we are about the same thing. We just possibly share one small part of a common flow in advent of specific event.
>
> btw:
>
> Transforming BPMN2 in Petri Net it’s not a novelty. // https://open.hpi.de/courses/bpm2016/items/6h518QNGNObfqI9jPjz4yp
> Most BPMN engines follow the token concept for execution and some use petri internally.

there's a full analysis of it in the van der Aalst book.

Don't get me wrong - I don't mind upgrading TP in a way that allows us to do this kind of thing - if we can convince ourselves that it really is needed in real-world modelling. Right now I am not convinced, and the example we have isn't realistic (in a medical sense), so we should in principle find at least one real world example.

Secondly, allowing the equivalent of a free graph structure will certainly complicate the reasoning logic in an execution engine. So we need to be sure we really want to do that - e.g. maybe we add 200% complication to solve 10% edge cases, which otherwise are just a bit more 'inconvenient' to model with an extra node. Now, if it's a 100% complication but fixes 50% of the use cases, well we need to think about it.

So let's be scientific and investigate further.

On the topic of modelling - did you make any progress on doing it graphically? I've created a rough language in the form of draw.io stencils to survive at the moment, it's actually quite an educational exercise to match formal semantics with graphic elements. But you might want to take a more 'live' approach, which is what my team at Intermountain Healthcare did for graphic modelling - problem is you can't 'see' the workflow, you can only drill through it interactively.

From Fabio:
Hi Thomas,

every author of the specification is a bit in love with his work. Naturally converting any issue to the same line of thought.

With branch merge I exposed two issues in TP;

a) duplicating (nesting) of decision groups where you end up having the same condition in two places (decision_group) - that’s not in line with good design practice
b) “beforehand” nesting of “synthetic” containers - feels unnatural to target audiance/modellers. They are probably not going to start with tones of “artificial” joint flows for branch merges happening far later in the flow.

The example/usecase you gave has a tendency to obfuscate the true nature of a problem.
The assumption that two independent branches which in some later stage (possibly) interact/intersect with some specific sub-sub flow branch, are inherently co-related, it’s a great simplification.
I guess if we possibly take a bus as a mean of transportation, that doesn’t inherently mean we are about the same thing. We just possibly share one small part of a common flow in advent of specific event.

btw:

Transforming BPMN2 in Petri Net it’s not a novelty. // https://open.hpi.de/courses/bpm2016/items/6h518QNGNObfqI9jPjz4yp
Most BPMN engines follow the token concept for execution and some use petri internally.

Well, it depends on what you think the semantics of the structure really are. TP takes the view that Task1 and Task2 are bound in with the 'Joint Task Flow' Task, it's just that the first OR split hides this. But the real semantics are unavoidably something like this (I attached the .xml file for draw.io, and you can get the stencil libs to include from here):

[see TP attachment]

The condition '$atrial_fib or $vent_fib' is your joint case 1 + case 2 expression. But this is the real semantics - it's saying that in case of any kind of fibrillation, treat the fibrillation and then do another thing ('joint') that applies to fibrillation cases; if it's not fibrillation, follow the other path, which does not pass through the 'joint' Task.

Now, where I have '$atrial_fib or $vent_fib' I could have put '$fibrillation' or '$unstable_heart_rhythm' - i.e. it is semantically a different thing from stable tachycardia (which is just fast HR).

I get that it kind of looks ugly in the node editor, but it makes sense in the graphic form - no doc is going to consider that a choice between a-fib, v-fib and stable tachycardia is an equivalent 3-way choice point. In clinical terms, it isn't, the underlying ontological structure is:

unstable ->
atrial fibrillation --> cardioversion + warfarin
ventricular fib (emergency!) --> restart the heart with an AED
stable ->
beta-blocker

(NB, this is of course a bit fake, V-fib is rare and the person is dying, a-fib happens all the time, but you get the general idea)

Now, you might say, ah bit this is just this specific case. But if you think about it, every situation in which 2 decision branches out of 3 flow though one execution path and the 3rd through another are all the same - by definition, the 'joint' pathway of those 2 branches is related to what distinguishes them qualitatively from the 3rd branch. In the TP structure, you have to make this explicit.

An advantage of the TP structure is that it is easier to determine the execution paths, because the structure is easier to reason with - it's always regular containment. The BPMN approach would require a fair bit more complexity in the engine to deal with the fact that you can more or less put lines where you like, and I suspect (I will have to check) whether van der Aalst (YAWL) and colleagues didn't already demonstrate that some BPMN structures are not guaranteed processable according to coloured Petri net processing.

This is a YAWL example of the same form [YAWL attachment]