The heuristics of finding an optimal conceptual model/structure are practically limited by the modeling time available, as well as by the knowledge and imagination the modeler brings to the task and can inspire in other stakeholders.

in: Metapattern as context orientation: meeting Odell's challenge of object orientation

 

[T]he modeler may already feel familiar with some parts of the problem, seeing opportunities for reuse of conceptual models. A more or less stable conceptual solution may then be called a pattern, but even then a modeler should always question its stability (perhaps an established pattern does not really serve a particular new requirement). With microscopic possibilities for contexts, existing patterns are easily modified or entirely new patterns developed.

in: The pattern of metapattern: ontological formalization of context and time for open interconnection

 

Formal flexibility should not overwhelm the designer as a contradiction. He must pursue it as a practical reality; again, perspectival phenomenology offers guidelines. Most practically, too, the conceptual formalism for controlling — dynamics of — perspectival variety serves the express purpose of implementation with digital technology.

in: The constitutional force of perspectival phenomenology: philosophical unification in information systems

 

I’ve written these remarks on Metapattern in order to support the claim that in some other sense it provides not a metameta- but instead a subsubmodel, or something. It aims to contribute, not to rule. So, please don’t read the-explanation-of-the-world in it. I would prefer it, if you’d ‘just’ favor and apply Metapattern’s powerful … instrumentality.

in: note 47.29

 

Whether ambiguity has been sufficiently dealt with, can only be determined pragmatically. Does the exchange of information so specified lead to intended behavior? For “every sign is a request for compliance.”

in: Metapattern for complementarity modeling

 

It is what theory should be directed at. When it seems that current theory is insufficiently practical, as it often is, I’m afraid, there’s in my view no escaping the practicality of developing a better theory, and so on. This is what a responsible engineer understands, and practices.

in: note 53.4

 

That nothing exists outside situation (also read: context) is no doubt — still — counterintuitive, but it certainly helps solve problems in information systems[.]

in: note 53.14

 

Please understand, […] that Metapattern is ‘just’ meant to be a most practical method for broadening the scope of conceptual modeling. For there is a demonstrable need, here and now, on account of increasingly interconnected coverage through digital technologies. […] So, the system-to-engineer is — the use of — infrastructure for sign exchange facilitating interdependent behaviors.

in: note 56.26

 

The only way to find out which contexts are relevant, is to draw up a conceptual model for what seems fit as integrated order. And the only reasonable approach is to model, say, operationally relevant subject matter.

in: note 71.21

 

In fact, I abhor exercises that are implicitly general. For nothing is general, everything practical is limited in relevance. Therefore, the equally practical task we face is to order such relevant differences without ambiguity. Forget formal logic based on atomist assumptions of general, i.e., context-free, validity. Beyond the most limited scale of application, it is nonsense (and also involves a counterproductive simplification of noun use).

in: note 71.21

 

I am happy to assist with understanding 1. the need for a paradigm shift, 2. Metapattern as the modeling method of choice at the scale of an integration order and 3. an information roundabout for getting the shift started both quickly and cheaply.

in: note 71.40