A situation can be tuned to any degree of differential behavior. […] The sustained decomposition of both situation and behavior to the detail of interdependent identity is the practical method for requisite variety at the scale of open interconnectivity.

in: Ontology for interdependency: steps to an ecology of information management

 

A conceptual information model without boundary value definitions indicates that concepts at a still-higher level of abstraction may be discovered.

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

 

[A] preemptive (a priori) boundary between information structure and information values does not exist.

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

 

Metapattern allows a wide range of model alternatives. At one end is the radical possibility of a single overall object; at the other, as many overall objects may be modeled as there are separately identifiable contexts. Within these extremes, the proper balance must be modeled in light of prevailing information requirements.

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

 

[W]hat should be considered an object cannot be absolutely fixed. It is a matter of focus, or particular interest. […] The choice of instance, i.e., situated behavior of an object, is […] essentially purposeful, utilitarian or pragmatic.

in: What is an instance in information modeling?

 

Getting information technology to work optimally comes down to creating a balance between - what used to be called - data and process. My inclination is to apply a data-perspective and then also accommodate processes-as-data.
Metapattern goes a long way toward establishing a balance. Still, it starts from data, subsequently treating process declarations as data, too.

in: Notes on Metapattern, part 1

 

The possibility of infinite decomposition reflects an essential insight. How I see it, contextual specification should continue until the point where the traditional concepts of 'object' and 'aspect' are reconciled.

in: Notes on Metapattern and enneadic semiosis, part 1

 

[I]t pays […] making (ontological) assumptions (more) explicit. It results first of all in an often quite different conceptual model.

in: On metapattern and other themes in information management

 

In general, supplying the relations establishing additional nodes with direction only holds relative value. For it is often difficult to choose between what should count as situation and what as object to arrive at a situated object. My own practice, it seems, is to start from a node taken as object, and subsequently directing it, i.e. placing it, in a situation. But I find myself sometimes pointing the relation the other way around. That may happen when, as explained above, I find it hard to choose between object and situation. Or I may have, say, esthetical 'reasons'. For example, I just don't like arrows ending up at the horizon. Again, directing relations is not critical, as the resulting additional node is anyway uniquely constituted as situated object.

in: Open conceptual modeling with Metapattern

 

For conceptual modeling, we recommend first of all capturing variety with(in) a single model (horizon).

in: Perspectivism in federated practice

 

[W]hatever version should always be liable to change, because having complete knowledge is impossible.

in: Metapattern for complementarity modeling

 

It is the modeler’s prerogative to decide pragmatically where upward decomposition ends (and, conversely, downward decomposition begins). For a boundary, Metapattern presumes the nil-object. There are no situated objects referring to it as its parts. The nil-object, as Metapattern holds to keep its formalism as tight as possible, is its ‘own’ nil-situation. It can only serve as situation for situated objects answering to another nil-identity. Other nil-identities can only refer to the — nil-identity of — the nil-object as their relevant situation. The nil-object is drawn as a thick horizontal line: horizon.

in: Metapattern for complementarity modeling

 

Situational differentiation must continue until contradictions are sorted out, i.e. when behavior within a situation can be modeled unequivocally.

in: Invitation to contextualism

 

Of course, contexts are about differences. But don’t multiply differences unnecessarily. And keep their equally necessary cohesion controlled.

in: note 53.6

 

What count […] are scope and precision of the particular act, making them relative (!) to the purpose. In fact, the situation is conceived proportionally to the precision required. Are you throwing darts in a pub because you would otherwise be even more bored? Or is your next throw decisive for whether or not you have to pay for the next round of drinks? Or are you a finalist in the Darts World Championship?
Scope, then, should contextualistically be taken as synonymous with … context. Precision determines scope as much as, the other way around, scope determines precision. It is not that scope (or precision) is good, therefore, more scope (or precision) is better. In their relative determination, they depend on the motive for the behavior[.]

in: note 53.14

 

From the idea of interdependence without limit as to the scale of modelling, I find it follows that the assumptions of mutually separate domains is counterproductive.

in: note 56.19

 

Just experiment with positioning concepts you find relevant. From one contextualization, soon enough you’ll get the idea for another, and so on until you are satisfied having exhausted possibilities (finding at some later time that you’ve gained some additional insight, and modifying a model accordingly).

in: note 71.6

 

Such extension might seem irrelevant for the integration at hand. However, in my experience it never fails to yield a more flexible model, both suggesting additional opportunities with information services and better preparation for eventualities with respect to information needs. It certainly is worth the effort, an intellectually rewarding, at that.

in: note 71.6

 

The constraint has not been specified[. …] It is of course a matter for contextual differentiation, too. Adding it to the model, however, would clutter it and distract at this early stage from designing an integrated order for the concepts of major concern. At the relevant node an asterisk or so could be added to suggest such a constraint (or any remark).

in: note 71.6

 

I recommend to document even the obvious. For exactly at that point you are making your assumptions conceptually operational. As you may find yourself getting stuck, anyway, I often do, modeling is largely trial and error, it helps being able to retrace your modeling steps and try a different direction from the earliest point possible (symbolized by a horizon).

in: note 71.14

 

When it is an integrated order that you are after, and of course I believe you should at least conceptually at first, it is illogical to start from the assumption of different applications. For what I have suggested as idealized design, a general idea about approaching design borrowed from Russell Ackoff, with Metapattern you can just make a start more or less anywhere. Soon enough you’ll discover meeting up with what traditionally you might have kept conceptually apart.

in: note 71.19

 

I strongly recommend starting to model differently what is familiar.

in: note 71.21

 

[M]y approach would be to start from conceptually widening the scope. It certainly looks like making problems more complex to solve rather than simple. But that is only apparent. What matters is the extent of relevant interactions. […] That way, interactions can be supported seamlessly across domains previously kept separate through limited/-ing applications. Now, that is really simple and makes the initial effort of seemingly complex modeling pay off.

in: note 71.25

 

Meanwhile, I am afraid I am still at the stage of modeling-around-in-circles, that is, muddling, really. It shouldn’t come as a surprise given such a comprehensive scope. Anyway, no need to get frustrated, not yet. I’ll continue trying out different concepts to start from, and see how far they may take a conceptual model of/for a somewhat more integrated order. At least it helps to find out what doesn’t work.

in: note 71.26

 

When aiming at the widest imaginable scope, starting from concepts associated with some — traditional — domain must be avoided. For boundaries between domains can actually not be kept up.

in: note 71.27

 

A saying in French that I have learned to keep in mind especially for modeling at the scope of integrated order reads: reculer pour mieux sauter. That is, only when you allow for sufficient space, and even far more space than may seem warranted at first, you can make a proper run for it and jump much farther (and in fact land where you need to be, and quickly at that). In English, perhaps a saying like ‘look before you leap’ comes somewhat near.

in: note 71.25

 

[A] so-called constitutional relationship […] makes for infinite re-use (also read: re-appearance) of instances following the same structure (which can thereby kept radically limited; clearly, huge benefits derive when technical implementation can be correspondingly minimalist).

in: note 71.30

 

[It] might seem a counterintuitive approach: radically widening the scope puts heavy pressure on limiting types (or else you’ll get swamped by them). It is really what mathematicians do when thinking up functions; there is only one algorithm for addition, abstracted from whether you are counting apples, pears, or whatever.

in: note 71.32

 

Especially try to run most unlikely thought experiments through the model.

in: note 71.32

 

As there should be no technological constraints holding us back for conceptual modeling, why not take an all-encompassing perspective (which is of course a contradiction in terms :-)? So, there’s a horizon and what appears as differentiated below it are at first just instances of something.

in: note 71.36

 

When modeling concepts I prefer to postpone putting on constraints (and that is why Metapattern models at least look uncluttered). It helps to think: Why not?

in: note 71.36