Re: [port-peer-review] reviews

On 6/26 Jun 2002, Aldo de Moor wrote in response to comments by Phillipe Martin:

The complexity of socio-technical system evolution is such that
methodological support is essential. Most methodologies, e.g. in knowledge
and requirements engineering, focus on the lowest levels (information
system, usage context).

It is apparently all too easy to forget the important distinction you made between TOOL and SYSTEM (in response to a comment on your paper by Janos Sarbo). The pragmatic principle and related notions like Doug Engelbart's of "improving on improvement" essentially require consideration at the meta-level. Peirce's pragmatism is, of course, not a tool, but a theory within the methodological part of his logic, "the highest and most living branch of logic." CP 2.333 (which at one point he interestingly refers to as "transuasional logic"). There seems a tendency to conflate the two, often reducing everything to tools and their use; or alternatively, finding this, and the other distinctions you made, mere "common knowledge" (though, of course, common knowledge itself needs to be criticized in a thorough-going pragmatism), rather than to see reflection at this level essential to the growth of collaborative communities.

As you wrote:

 Pragmatic approaches at the higher meta-levels
(design, improvement) that center on making efficient and effective
community-controlled systems evolution possible, hardly exist. Doug's work
is one of the few exceptions. [emphasis added]

And your work is another. In collaboratories generally, and certainly in a project such as PORT, meant to be pragmatic in the Peircean sense, that is, methodologically pragmatic, I would imagine that the process of "improving upon (systemic) improvement" could be seen as almost equivalent to pragmatic method put into practice by a community. It is, as you suggest, a matter of tools and the people developing and using them within interpenetrating systems and their contexts. There are real complexities here that are far from trivial.

Further, this evolution ought not--if we really want to optimize community and inter-community collaboration as well as maximize the possibilities for evolutionary success in our endeavors--be left to chance, but should rather be guided by agreement on what would constitute the best methods employed at this level--in your sense of an interpenetration of contexts, the highest level of these entraining sub-systems to create a kind of system-of-systems. And this seems the thrust of Peirce's science: the fuller integration that quasi-necessarily follows from the generalization of methods (and findings) in each branch when guided by methodological consensus at the meta-level--your systems/contexts model--with the consequent improvement on improvement. .

This paper only introduces a (rudimentary) tool context model. It is not a
methodology in itself, but rather a meta-model that allows methodologies
to be positioned and compared.

In a brief paper I would think it would be difficult to present much more. Still, your paper seems to me to constitute something of a very general, though vague, blueprint of the kinds of distinctions that need be made and the relations between them. It is not a methodology in itself, for sure; but it is allied, as is Doug's fundamental notion, to the method of inquiry along Peircean pragmatic lines. In this context, it should be remember that while Peirce strictly excludes the socio-psychological from all his logical considerations, finally at the level of methodology he relaxes this stricture. He writes:

Peirce: CP .107. The regulation has served its end; why should it be allowed now to hamper our endeavors to make methodeutic practically useful?

This making "practically useful" seems precisely the point of the PORT project.

PM; Can any high-level methodology or set of "design principles" for
"collaboratories" lead developpers to come up with new ideas, or ease the
technical integration of already developped tools?


AdM: The tool context model is a lens that allows one to focus on, literally,
the missing links between models and methodologies. By structuring 'common
content knowledge' it becomes possible to see the icebergs in the first
place, and to identify gaps in socio-technical methods for collaboratory
development.

I see your answer to Philippe's good question to be "yes." How could it be that improved communication at the design level would but help improve workflows, integrations of elements of projects, etc? And tools themselves could be expected to be developed with greater potential for integration following such systematic analysis applied to practice. It seems to me that such reflective structuring and restructuring would surely lead to increased creativity among tool developers and all others involved in collaboratories.


Links increase complexity. Sometimes this is desired, for example when
linking processes from different levels (e.g. connecting a workflow
process to a design process, so that the workflow definition can evolve).
Sometimes, processes should not be linked too much. This could be the case
with two workflow processes. One such process (e.g. authoring process) can
feed into another (e.g. review process), but the inner workings of the
first process may need only to be a black box to the second process.

Your answer to Philippe's question regarding "links" suggests that this might become a crucial area for further inquiry at the meta-level.

I agree that the concept of 'link' needs to be further worked out. One
interesting issue would be a typology of links useful for collaboratory
evolution modelling.

The notion of a "typology of links" might be a fruitful topic for discussion at the ICCS PORT workshop.

Regards,

Gary