Ready.
copycat82 is a worse than trivial attempt to collapse prior art content. Its plagiarism, leaves it with its fault-prone "method".
The so-called "single" graph is much ado about nothing, with its cluttered, and vague structure. The vagueness does increase, especially in subnets.
copycat82 does not present-list any example formally. It contains only (vague, and faultfull) figures, as its examples. Is everything only the graph? Then, to obtain a little information, an exhaustive search is needed:
The former question needs to visit every subnet, all around the net. The latter, needs to go up, until that data is last seen, and next, to notice whether the first-level subnets of that uppermost container, refer to that data-item. These are easily computable, by a computer, but copycat82 is paper-based, and it is, in any case, it is an attempt to model nets - by humans! It is very tedious, whether to prepare, and/or to read.
What is worst, is the fact that, such exhaustive-search needs turn out to be lopsided.
e.g: If subA1 contains subA2, and subB1 contains subB2, if subA2 and subB2 share some data-item, then subA1 and subB1, point at it, too.
To avoid (unrepresented) race-conditions (nondeterminacy), every operator/transition must refer to its used-data. This is an advantage of a data-graph, and those data-arcs. VD78 does employ data-graph with success (after LOGOS). With VD78, any label points at the data-graph, and we find the data cozily organized, with its operators, next to it. Subnets of copycat82, show external-data as labels, too, but tedious to both prepare, and trace.
A graph (or, table), to look-up the associations, would be sufficient, all by itself, without anything which copycat82 attempts to do. Those "data-item"s merged with a Petri net, do not inform, unless with exhaustive searches.
It appears, copycat82 is caught in between E-nets and VD78 . It merges the two-graphs of VD78, in a way equivalent to writing the E-net formal-listings within the E-net figure. i.e: It turns the data-item names (isolated in token-attributes, and resolution-locations) inside-out - drawn as rectangles, with the names of the data-items.
E-nets do not constrain the data-representation. (i.e: The environment-variables might be represented by a separate data-graph, too, if that information is wanted that way, the token-atributes are local-data, shared between two transitions.) The ambivalence about data, is a problem of copycat82.
Even the least specified, as concerns data-specifics, the E-nets is more informative, with its well-identified local-data (within token-attributes of E-nets), and NN73 publishes its (machine-processable) formal-listings, too.
When the control-graph (Petri net) is merged with a (LOGOS) data-graph, the linkage is possibly other than one-to-one.
unity The mentioned complications exist. Each operator of that data, get associated with some Petri net transition, somewhere around the net. Exhaustive search is needed, probably often.e.g: If your neighbor also plans to paint the seats, without abitration, seats may get painted zebra-wise, or one of you may erase the other's work (i.e: race condition).
multiplicity Exhaustive search is needed even among instances of a single data-operator, (2.a) because of multiplicity, when one-to-many (e.g: if multiple instances/copies of O2 exist, associated with a variety of transitions), and/or (2.b) because copycat82 duplicates, in its examples, even the ordinary places within a single figure (e.g: the place "p4" exists twice in a figure, in a producer-consumer example).
These two varieties of exhaustive search, compound.
Such a "single-graph" is a cluttered-graph, with many pieces, on many pages In subnets, it is not even understandable (not visibly tellable) whether a data-item is local, or it is an external-label. The graph-reader must turn to the page of its container-graph to find this out. Next, the same question is current about that container. So, next, the reader must turn the page to its container, and so on, throughout the hierarchy, until it turns out to be localized at some point, or the global-level is reached.
With copycat82, the data-search need is the absurd. To identify local-information, an exhaustive search is needed, throughout the net, whereas copycat82 attempts to keep the (tedious) hierarchical-data-linkages, all-through many-levels of the subnet-within-subnet figures, along with the control-flow. In other words, when there is no interest in a hierarchy, an exhaustive-search is necessary. But when we already traverse the hierarchy, we find everything explicitly presented - unless the tediousness might have lead to faultfullness, as in examples of copycat82, itself.
This totally kills usability, at design time, because everytime a new data-use is to be represented, we must traverse possibly every subnet in the system, if the data-item is not already visibly in use. It is only a tedious, and vague attempt at commentary.
The reachability-test neglects data altogether, any way. Presumably, copycat82 could attempt to do something similar to VD78-level-two (static proofs of determinism/determinacy), but the vagueness of data-associations (and vague data-semantics, too) may kill/hurt such an attempt, too.
Much ado about nothing: