Metapattern > aspects of infrastructure > standardization
By supplying contexts with finely-tuned integrations of the time dimension and accountability, Metapattern holds a rich store of standardized facilities. As such, it greatly extends earlier approaches to modeling infrastructure for information processing.
in: The pattern of metapattern: ontological formalization of context and time for open interconnection
You’re still aiming at standard meaning as the ideal. That not just illusory. It’s even dangerous. [… E]xplicitly including a semantic perspective has become essential.
in: Do you run an ERP software company?
Now, what should we actually be aiming at with a standard? Do you want to receive information from another source in order to — be able to — include it most efficiently in your ‘own’ source, subsequently serving users without having to rely, at the moment of their request, on the other source? That was a most sensible approach when reliability of means of communications didn’t meet the temporal requirements for user service. However, I would say that has changed dramatically … One source no longer needs to maintain copies of information acquired from other sources. For reliable service to users, references must be available for distributed information to be collected as required. But, then, why not accept how a particular source keeps particular information? Conversion to some standard structure for, say, content may in fact compromise authenticity. Standard(s) for content structure may of course be always useful when setting up a new source. Or when differences are irrelevant, please avoid them, if only for your own benefit. For a federation of sources, however, structural differences for keeping content can never be eliminated (if only for ‘political’ reasons). In recognition of relevant structural differences, what should be standardised in principle are — only — references. […] We should abolish the practice of redundancy by re-sourcing (with its risk of loss of authenticity, its multiplication of so-called administrative burden, et cetera).
in: note 53.6
Standard is another concept that is widely ill-understood. Its end is not similarity. Instead, we favour a standard when it offers similarity as a means to the end of facilitating (including: promoting) real variety.
in: note 53.8
The argument goes that [Metapattern] is not (a) standard. No, of course it is not. How can anything develop if it is required to be a standard from the outset? So, it is just an off-setting remark.
in: note 53.14
I cannot help finding that the concept of formalization is often ill-understood, at best. Many people — unwittingly? — apply the term as a euphemism to promote their favored meaning to become standard, i.e. the norm. They are nowadays greatly assisted by limited understanding — please note, including their own — of digital technology. As I see it, the largely implicit reasoning goes as follows. It is assumed to be in the nature of ‘computers’ to require formalization. So far, so good. However, formalization (in this strictest sense, also read: normalization) is only considered possible when first of all concepts (in opposition to form, also read: contents) are taken as mutually independent. Simplisticly, it serves to establish a one-to-one correspondence between atomist content and atomist form. Of course, logical atomism, naïve realism, et cetera, amount to extending formalization to conceptualization, which might — seem to — make programming a computer easier, but undermines — an appreciation of — real variety. It should be the other way around! Escaping exposure, formalization is a modern colonizing force. (I don’t like the label postmodern.) Regretfully, all over, systems are developed from this faulty idea of formalization. As nobody has a clue why resulting systems necessarily fail, yet another attempt is made, more users get more frustrated (or worse), more money is thrown down the drain, and so on. Most people responsible for those failures even don’t want to have a clue (from a belief that only knowledge builds guilt, or some equally anti-social idea). Any suggestion that a change of paradigm is in order, is immediately rejected.
in: note 56.2
The proper approach to formalization is to apply it, not as a preordained master, but in the humble service of people and their living variety. It ‘means’ radically doing away with whatever atomist assumptions. For meaning is through and through interdependent, and dynamically so. So, what we need is a qualitatively different formalism, one facilitating interdependence, variable at that, because the world including how each of us pluriformly ‘sees’ it keeps changing. (Didn’t Heraclitus already succinctly express a theory of change? “Everything flows.”) We should not allow formalization to be used as a euphemism to tempt the rest of us into compliance. And it really is nonsense that digital technology can only process atomist forms. In fact, especially computers can be most helpful when a wide variety of conditions (as particular configurations, also read: contexts) apply. Keyword: helpful. While it must be axiomatically taken that contexts and thereby meanings differ, still a generally applicable method may exist to facilitate such variety. For example, in evolutionary epistemology I find strong support for that hypothesis. The methodic focus, then, is not on some concept by itself. The idea of more or less translating a single concept at the time is, say, the atomist fallacy. Instead, focus should be on how relevant concepts differ from each other. Sufficient context must be added to each term to be able to ‘tell’ concepts apart. In principle, that’s nothing new. You could say it is a kind of structuralism; integral joining of explicit contexts makes it contextualism. It needs to be called subjective, too, as meanings also vary from one individual tot the next. My solution for method is to rely on recursion; a context refers to a concept for ‘entering’ it, leaving less of context to determine, and so on, until an overall boundary condition (Metapattern: horizon) is invoked. This way, formally, there is room for an infinite number of configured conditions, and no condition is presupposed. (And if you want different meanings for context, why not?)
in: note 56.2
Metapattern [may, of course, also be] applied to designing a so-called operating system for networking (for modularity can be tightly controlled). Actually, Metapattern should promote methodically unifying all levels et cetera of processing. Please note, there is no paradox in a unified method for limitless differentiation. It is controlled through an additional parameter. As far as the paradigm goes, that is all.
in: note 56.5
I am aware I won’t be taken seriously when arguing to devalue
standards for data exchange. As a longer term vision, though, I
don’t find it wise to continue to fill each other’s data
silos.
In my view, the answer lies with differential authorization. Initial
messages, then, need only contain necessary and sufficient references,
with further information selectively made available to such a duly
authorized … actor on a transaction basis. {…] In the
meantime, in support of […] whatever way you want to structure
messages, the model should help you recognize, from a federation of
databases, both how relevant information may be selected for message
composition and how messages may be decomposed to distribute
information over registers.
Rather than positioning message structure at the center for overall
importance, its structure becomes supportive when considered from an
integrated-order perspective. For message structure, too, should be
derived from integrated-order structure, and not the other way around.
Maintaining an orientation at separate applications is what has
subsequently made message structure critical for practical
coordination, and “incredibly complex” in the process.
However, it doesn’t help to address variety of meanings. With the
shift to a comprehensive model for integrated-order, separate
applications as they have been traditionally set up, will disappear.
Much complexity dissolves. Of course it does not … mean the end
of programming, but the start of programming from an integrated-order
perspective. We remain lost while deepening the crisis without first of
all drawing up a conceptual model at the real scale of exchange.
in: note 71.40