💾 Archived View for siiky.srht.site › petri_nets › log008.gmi captured on 2024-08-18 at 18:17:37. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-07-09)

-=-=-=-=-=-=-

Petri Nets Log #008

siiky

2024/07/02

2024/07/02

en

The PNEE implementation uses the collective (vs. individual) token philosophy. In general, along with high-level Petri nets, it doesn't pose a problem. However, without being able to match across different places in the "consumer" functions, it's seemingly impossible to implement any kind of RPC with high-level open Petri nets that's simultaneously reliable (the crux of the problem with collective token philosophy), and generally useful/usable (simple scenarios are possible, as long as the relevant flows are sequential, i.e., don't have parallel paths).

It's a major flaw, and unfortunately I just noticed it now... 大変だ!!!

PNEE consume loop

RE: individual token philosophy (search for "cases")

RE: high-level Petri nets & open Petri nets

Searched through the site and I'm surprised I never wrote about token philosophy! Literature touching this subject, besides the paper above:

Jade Master, "Petri Nets Based on Lawvere Theories"

(IIRC) Statebox, "The Mathematical Specification of the Statebox Language"

Example from van der Aalst's WF-nets paper: tokens in WF-nets are data related to SOMEONE (e.g., a client)! So it doesn't make sense to, e.g., mix the address of one person with the age of another in the same case -- different cases, different persons, and vice-versa.

index.gmi