For quick reference, see
Metapattern, overview of notation

 

In actual modeling practice, cascading nil nodes are a prominent feature of Metapattern. […] Making cascading nil nodes easier to draw, and thereby information models overall clearer to read et cetera, has been the primary motivation for partially changing, about 2002, Metapattern’s notation[.]

in: Cascading nil nodes in Metapattern

 

My favorite is the rectangle, for reasons of both aesthetics and economy.

in: Modifying Object-Role Modeling into Situated-Object-Behavior Modeling with Metapattern

 

[T]he line connecting the original situation and object traverses the rectangle that stands for the resulting situated object. It is Metapattern’s way of expressing that a relationship is object and, the other way around, an object is relationship.

in: Modifying Object-Role Modeling into Situated-Object-Behavior Modeling with Metapattern

 

[I]t is not a particular notation, distinctive as it may be, that effectively makes out Metapattern […]. Other symbols may be used […] but that doesn’t detract in any way from Metapattern’s focus on disambiguating behavior through additional differentiation by recursively situating objects.

in: Get into the rhythm of Metapattern

 

Of course, the relationship being dual, one direction is equivalent to the other. The basic requirement is that some direction should be consistently applied within a single model.

in: Get into the rhythm of Metapattern

 

A model is, so to speak, bootstrapped from the horizon.

in: Get into the rhythm of Metapattern

 

Someone ‘reading’ a model drawn up with Metapattern may focus on a particular node (signature). Following relationships in the direction of the arrows up to the horizon yields its context. In the other direction, i.e. against the arrows, the path of object differentiation (in Bohr’s terms, also read: complementarization) is traced. This way, context-as-sign corresponds to situation-as-real. A signature corresponds to an object’s nil-identity.

in: Metapattern for complementarity modeling

 

I changed to a notation yielding models that are more understandable to ‘normal’ people. What I sacrificed, […] is the explicit modeling of nil identity. It is now implied[. …] But what is gained with the new notation is a far more fluent expression of recursion. That is of great practical value.

in: note 56.24

 

Metapattern[’s] principle has remained unchanged, but since approx. 2002 I have adopted a more ‘rectangular’ notation.

in: note 71.1

 

As there is just a single modeling construct, quite a simple one at that, you really cannot go wrong on syntax.

in: note 71.4

 

I myself start modeling on the proverbial back of an envelope. When I want the diagram to look more, say, official, I take to PowerPoint (in case I don’t expect the model to be extensive). I do use some sort of template, see [the note referred to]; please feel free to use it.
For coming to better grips with a few concepts that seem confusing for lack of contextual differentiation, I find that a presentation tool such as PowerPoint is already more than sufficient. And of course leaving out the template, I advise you to present it as a developing model, i.e., a progressive series of models […]. It makes eliciting relevant comments easier.
You may find, however, that for a more extensive conceptual design you run against limits of space with PowerPoint and the likes. I did, anyway. […] I [mysef] use […] Visio to draw [those].

in: note 71.4

 

As I am familiar with the need for turning nodes downside-up, I start the model by including a classification scheme. For its structure. I have assumed a homogeneous hierarchy. By that I mean that to a keyword at one level, keywords at the next level may be connected, and so on. Then, a particular classification term entails the ordered set of keywords up to the — in this case — horizon. The structure of such a homogenous hierarchy is abstracted into a single symbol.

in: note 71.20

 

I am favoring a single symbol for an open-ended homogeneous hierarchy. As I believe that most classification schemes are structured as such a hierarchy, that is how I include them in a model. Please note, as the model is about types, that any number of actual coding systems, or whatever, fit (as long as for every scheme its unique name, or whatever, is included as its top-most element).

in: note 71.30

 

Usually with Metapattern, only types are shown in conceptual models.

in: note 71.36